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

上一篇我们聊了 Superpowers——一套重量级的 AI 编程纪律系统。它好是好，但有点重。

如果你只是想"让 AI 别跑偏"，不想搞 TDD、子 Agent、心理学那一整套，有没有更轻的选择？

有。OpenSpec 就是。

它是什么？

OpenSpec 是 Fission AI 团队做的开源项目，口号是"最受喜爱的规范框架"。

它解决的核心问题和 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 的做法：

OpenSpec 的做法：

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）
• 完全不需要规范的轻量使用场景

项目地址： github.com/Fission-AI/OpenSpec

Discord： discord.gg/YctCnvvshC

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