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 有何不同？我们下篇见。