Hi～大家好呀，我是清汤饺子。
我曾经让 AI 改个按钮颜色，它噼里啪啦一顿操作，把整个配色系统重构了。
你问我什么配色系统？我没说要重构配色系统啊。
AI：但重构之后更好看啊。
……行吧。
这个场景你经历过吗？需求说加个功能，AI 直接把项目翻了个底朝天。最后你花的时间比不用 AI 还多三倍。
问题出在哪？不是 AI 不够聪明，是你和 AI 之间没有"签字画押" 。
然后我发现了 OpenSpec。
一、解决什么问题
AI 编程最大的噩梦，不是它写得慢，是它完全按自己的理解来。
你脑子里想的是 A，AI 理解的可能是 B，它输出的变成了 C。你还得花时间把 C 改回接近 A 的样子。
这就是没有"需求对齐"的问题。
传统的软件开发里，有个东西叫Spec（需求规格说明书） ——在动手之前，产品、设计、开发三方签字确认"我们要做什么"。
OpenSpec 把这个机制引入了 AI 编程：先签字，再干活。
不是让 AI 写文档，是让 AI 和你在"做什么"这件事上真正对齐。
二、OpenSpec 是什么
作者是 Fission-AI，GitHub 上叫 OpenSpec。
定位是：The most loved spec framework。
核心价值主张：在写代码之前，AI 和人类对"要做什么"达成一致。
它解决的是 Superpowers 和 ECC 没覆盖到的那个环节——Superpowers 管"工程纪律"，ECC 管"性能和记忆"，OpenSpec 管**"需求对齐"**。
三个工具解决的问题正好互补。
三、核心理念
OpenSpec 的 Philosophy 里有几条我特别认同：
fluid not rigid — 流畅不僵硬
它不是要你写几十页的瀑布式文档。Spec 应该像对话一样自然，迭代式的。
iterative not waterfall — 迭代而非瀑布
以前的需求文档是一次性写完，然后"锁死"。OpenSpec 的 spec 是可以迭代的，每次改动都有记录。
easy not complex — 简单不复杂
不要搞得太重，简单到你可以随时改。
built for brownfield not just greenfield — 支持存量项目
不只是新项目可以用，存量项目也能用。真实开发场景大多是在别人写的代码上改，不是从零新建。
scalable from personal to enterprise — 从个人到企业级
一个人能用，团队也能用。
四、核心工作流
OpenSpec 的工作流就三步，非常简单：
1. propose —— 提案
你告诉 AI：/opsx:propose add-dark-mode
AI 自动生成一整套文档：
- proposal.md — 为什么要做这个改动
- specs/ — 具体需求和边界情况
- design.md — 技术方案
- tasks.md — 任务清单，每个任务精确到文件路径
这是最让我惊喜的地方——以前要人类自己写需求文档，现在 AI 帮你写。你只需要确认、修改，不需要从零憋字。
2. apply —— 执行
你确认 spec 之后：/opsx:apply
AI 按照 tasks.md 清单一个个执行。每完成一个任务打一个勾，你可以随时喊停。
最关键的是：AI 严格按照 spec 来执行，不会自己跑偏。
你改个按钮颜色，它就只改按钮颜色，不会顺手把配色系统重构了。
3. archive —— 归档
收尾：/opsx:archive
归档到 openspec/changes/archive/，保持项目干净，下次新需求不影响旧的。
五、Artifact-Guided Workflow（新功能）
这是 v2 的核心升级。
以前是你手工写 spec，AI 按 spec 执行。现在是 AI 根据你的 idea 自动生成完整 artifact。
你只管说想做什么，AI 把 proposal、specs、design、tasks 全套给你生成出来。你审核、修改、确认，然后 apply。
人类只需要在关键节点做决策，不需要从头参与到每一个细节。
六、我的真实感受
惊喜时刻：
- 终于有了一个"需求对齐"的机制。AI 不会自己跑偏，因为它要按 spec 执行
- propose 之后 AI 自动生成 spec，质量居然还不错
- 有了 spec 做依据，code review 也轻松多了
崩溃时刻：
- spec 写错了，apply 之后全错了。AI 是严格按照 spec 执行的，spec 对它就是对，spec 错它就错
- 需要花时间养成写 spec 的习惯，一开始会觉得"这么麻烦干嘛"
适合谁：
- 有一定复杂度的需求，不是"改个 typo"这种
- 团队协作场景，需要对齐多方预期
- 讨厌 AI 自己跑偏的人
不适合谁：
- 简单任务，直接让 AI 写反而更快
- 纯探索性开发，还没想清楚要做什么
七、和 Superpowers + ECC 的关系
这三个工具解决的问题正好互补：
| 工具 | 解决的问题 |
|---|---|
| OpenSpec | 需求对齐 — 先签字再动手 |
| Superpowers | 工程纪律 — TDD、task 分解、子 Agent 编排 |
| ECC | 性能和记忆 — Token 优化、memory 持久化、安全扫描 |
OpenSpec 在最上游——它管的是"做什么"。
Superpowers 在中游——它管的是"怎么做"。
ECC 在底层——它管的是"怎么跑得更好"。
三个一起用，才是完整的 AI 编程工作流。
八、技术原理
看完 GitHub 仓库，我发现 OpenSpec 的核心设计非常简洁——它不是给 AI 增加能力，而是给 AI 和人类之间增加一个"共同文档"作为契约。
1. 核心机制：Artifact + 人类确认
OpenSpec 的工作流核心是 Artifact 生成 + 人类确认：
- 你 提出一个 high-level 的想法（"我想加个深色模式"）
- AI 根据你的想法，自动生成一整套 Artifact（proposal.md、specs、design.md、tasks.md）
- 你 审核、修改、确认这整套文档
- AI 严格按照确认后的 Artifact 执行
关键是：在第三步你签字确认之前，AI 不会动手写代码。
2. OpenSpec Directory 结构
OpenSpec 在项目根目录创建的结构非常清晰：
openspec/
├── changes/
│ └── archive/ # 每次改动的归档
├── specs/ # 需求规格
├── design/ # 技术方案
├── tasks/ # 任务清单
└── .openspecrc # 配置文件
这个结构让每一次改动都有据可查、可回滚。
3. propose 的内部逻辑
当 AI 执行 /opsx:propose 时，内部经历：
- 理解需求：AI 解析你的自然语言输入
- 生成 proposal.md：回答"为什么要做这个改动"
- 生成 specs/ ：拆解需求成具体规格和边界情况
- 生成 design.md：给出技术方案和备选方案
- 生成 tasks.md：拆解为可执行的任务清单，每个任务精确到文件路径
这个过程本质上是 Socratic 式的 逆向工程——AI 不是在执行，而是在问你"你要做什么、做到什么程度"。
4. 人类在环（Human-in-the-Loop）
OpenSpec 每一层都有"人类确认"的节点：
想法 → proposal → 你确认 → specs → 你确认 → design → 你确认 → tasks → apply
这不是审批流程，这是 协作编辑。你在确认的过程中可以修改、补充、否定。AI 的 proposal 不是终点，是起点。
5. v2 Artifact-Guided Workflow 的升级
v2 最大的变化是：AI 不再只是执行者，还是提案者。
以前是"你写 spec，AI 执行"。现在变成"你说想法，AI 帮你写 spec，你确认，AI 执行"。
从"你主导"变成了"AI 主导生成，你主导确认"——这降低了使用门槛，让不擅长写 spec 的人也能用上这套方法论。
GitHub 仓库：github.com/Fission-AI/…
写在最后
OpenSpec 解决了一个根本问题：AI 编程最大的风险不是 AI 不够聪明，是人类和 AI 对"做什么"没有对齐。
你花 10 分钟写清楚 spec，AI 按 spec 执行，省掉的可能是一小时的返工。
当然，它不是万能的。spec 写对了才有效，写错了反而会误导 AI。
核心问题是：你愿不愿意在动手之前，先花时间想清楚"到底要做什么"？
这件事，AI 帮不了你。
你在 AI 编程时有没有过"AI 完全按自己理解来"的经历？最后是怎么解决的？欢迎评论区聊聊。
如果觉得有帮助，点个赞收藏一下，我会更有动力更新下一期。
也欢迎关注我的公众号「清汤饺子」，获取更多技术干货！
