OpenSpec：轻到起飞的AI编程规范精选

上一篇分析了 Superpowers 这套偏重型的 AI 编程纪律框架。好用，但说实话，对不少团队来说太重了。

如果你只想要 AI 写代码时“别跑偏”，不想折腾 TDD、子 Agent 或心理学那一套，有没有更轻量的替代方案？

有。OpenSpec 就是为此设计的。

OpenSpec 是什么？

OpenSpec 由 Fission AI 团队开源，slogan 很有意思——"The Most Beloved Specification Framework"（最受欢迎的规范框架）。

它要解决的核心痛点和 Superpowers 相同：让 AI 和你写代码之前先对齐需求。但实现路径完全不同。

Superpowers 是一套纪律系统——你得按预设流程走。OpenSpec 更像一个规范层——在对话与代码之间插入一份动态文档，AI 和人盯着同一份文档干活。

轻量、灵活，不搞瀑布式流程。

核心思路：Delta Spec（增量规范）

OpenSpec 最巧妙的概念是 Delta Spec（增量规范）。

它不要求你先完整定义整个系统。每次改动时，只需写下变化的部分：

• ADDED：新增的需求
• MODIFIED：修改的需求
• REMOVED：删除的需求

举个实际例子，你要给应用加暗黑模式。Delta Spec 大致如下：

## ADDED Requirements
### 用户可以选择亮色/暗色主题
- GIVEN 用户在任意页面
- WHEN 用户点击主题切换按钮
- THEN 主题立即切换
- AND 偏好跨会话持久保存

## MODIFIED Requirements
### 会话超时
系统将在 30 分钟不活动后过期会话。
（之前是 60 分钟）

没有长篇大论的需求文档。只关心“加了什么、改了什么、删了什么”。

开发完成后，执行 archive 操作，这些 Delta Spec 会自动合并入主规范——新增的追加，修改的替换旧的，删除的直接移除。主规范始终保持系统当前行为的事实来源。

这个设计确实巧妙。它将规范变成了活的文档，而不是写完就尘封的废纸。

三步走完一个功能

OpenSpec 的核心工作流只有三步：propose → apply → archive。

第一步：propose

你对 AI 说：/opsx:propose add-dark-mode

AI 自动生成一个变更目录，内含四个文件：

• proposal.md — 为什么做、做什么
• specs/ — Delta Spec（新增、修改、删除）
• design.md — 技术方案
• tasks.md — 实现清单（带 checkbox）

你审阅、调整，确认无误后进入下一步。

第二步：apply

你对 AI 说：/opsx:apply

AI 按 tasks.md 里的清单逐项实现。完成一项勾一项。全部搞定。

第三步：archive

你对 AI 说：/opsx:archive

AI 将 Delta Spec 合并进主规范，变更目录移入 archive 文件夹存档。干净利落，准备下一个功能。

就这么简单。没有六步流程、没有子 Agent、没有心理学。三个正常人能理解的步骤。

和 Superpowers 的本质区别

拿暗黑模式这个例子来对比：

Superpowers 的处理方式：

它从需求分析开始，生成测试用例，然后 TDD 驱动，甚至可能引入子 Agent 验证。流程严谨，但时间成本高。

OpenSpec 的处理方式：

你写一个 Delta Spec，直接进入实现。过程你掌控，AI 只是你的执行者。

Superpowers 适合“我要对输出质量完全放心，让 AI 自己跑两小时”。OpenSpec 适合“我只想让 AI 别跑偏，过程我自己把控”。

一个重纪律，一个重灵活。

为什么它自称“轻量”？

几个具体体现：

零复杂安装。 npm install -g @fission-ai/openspec@latest，然后 openspec init。完事。

不强制工作流。 你可以写完 spec 再让 AI 实现；也可以先让 AI 干着、边干边改 spec。没有阶段门控，没有“必须按顺序来”的教条。

支持 20+ AI 助手。 Claude Code、Cursor、Copilot、Codex、Gemini CLI……几乎所有主流 AI 编程工具都兼容。通过斜杠命令触发，无需特殊插件市场。

随时可改任何产物。 实现到一半发现设计不对？直接改 design.md 和 tasks.md，继续干。不需要“重新走流程”。

不绑定 IDE 或模型。 官网特意对比了 Kiro（AWS 的 AI IDE）——Kiro 锁定自己的 IDE 和 Claude 模型，OpenSpec 用你已有的工具。

项目目录结构

初始化后，项目根目录下会多一个 openspec/ 文件夹：

openspec/
├── specs/                    ← 系统当前行为的真实来源
│   └── auth/spec.md
│   └── payments/spec.md
├── changes/                  ← 正在进行的变更
│   └── add-dark-mode/
│       ├── proposal.md
│       ├── design.md
│       ├── tasks.md
│       └── specs/ui/spec.md     ← Delta Spec
└── config.yaml

specs/ 是系统规范，按功能域分目录。changes/ 存放当前正在做的变更。archive 后变更目录会移至 changes/archive/，方便审计追溯。

这个结构的优点：每个变更都是一个独立文件夹。你可以同时并行多个变更，互不影响。

一个容易忽略的细节

OpenSpec 的 spec 采用类似 BDD（行为驱动开发）的格式编写场景：

#### Scenario: 手动切换主题
- GIVEN 用户在任意页面
- WHEN 用户点击主题切换按钮
- THEN 主题立即切换
- AND 偏好跨会话持久保存

GIVEN-WHEN-THEN 结构并非随意选择——它借用了 Cucumber 等测试框架的写法。好处是 AI 理解清晰，且与可执行测试用例仅一步之遥。

你无需真的跑 BDD 测试，但你的规范天然具备测试结构。未来若想加入自动化测试，迁移成本极低。

OpenSpec 的设计哲学

官方列出了五条核心原则：

• fluid not rigid — 灵活，不僵化
• iterative not waterfall — 迭代，不搞瀑布
• easy not complex — 简单，不搞复杂
• built for brownfield not just greenfield — 既适合新项目，也适合改造已有代码
• scalable from personal projects to enterprises — 从个人项目到企业级都能用

翻译成人话：别搞那么重，能用就行，随时可改。

谁适合用？

推荐场景：

• 觉得 Superpowers 太重，但又不满足于“纯聊天式”AI 编程的人
• 个人开发者或小团队，不想被流程绑架
• 已有项目（brownfield），希望逐步引入规范
• 同时使用多种 AI 编程工具的人

不太适合：

• 需要严格 TDD 和代码审查的团队（建议用 Superpowers）
• 完全不需要规范的轻量使用场景

下期预告：《Spec Kit：GitHub 官方出品，规范即代码》——同样是规范驱动开发，GitHub 官方是怎么做的？和 OpenSpec 有何不同？我们下篇见。

来源：互联网