OpenSpec 实战：4 个命令让 AI 按规矩写代码
用 AI 写代码最怕什么？不是它写不出来，而是它写跑偏了——你想要个登录功能，它给你顺手重构了半个项目。OpenSpec 就是解决这个问题的：先把需求、设计、任务拆清楚，再让 AI 动手。写错了还能随时回退修正，不用从头来过。
一、先搞懂 OpenSpec 在干嘛
你可以把 OpenSpec 想象成一个漏斗，需求从上往下越来越具体：
| 层级 | 文件 | 干什么 |
|---|---|---|
| 最上层 | proposal.md | 确定方向——要做什么、为什么做 |
| 中上层 | specs/*.md | 定义验收标准——做成什么样算合格 |
| 中下层 | design.md | 技术方案——用什么技术、怎么实现 |
| 最底层 | tasks.md | 行动清单——拆成一步步可执行的任务 |
这套东西的核心思路叫 SDD（Spec-Driven Development，规格驱动开发）——先写规格，再写代码。AI 不是对着你一句话需求瞎猜，而是照着一份完整的"施工图纸"干活。
二、四个命令，对应开发的四个阶段
OpenSpec 提供了 4 个 /opsx 开头的快捷命令，刚好覆盖从想法到上线的完整流程。
/opsx:explore — 想清楚再动手
这个命令让 AI 当你的"思考搭档"。你丢一个模糊的想法过去，比如"我想加个支付功能"或者"这段代码太乱了怎么重构"，AI 会帮你梳理思路、查阅现有代码、找出潜在的坑。
关键点：这个阶段 AI 绝对不会改你的代码。纯粹的脑暴时间，PM 和开发都能用。
/opsx:propose — 一键生成全套文档
想清楚了，跑这个命令。AI 会一口气帮你生成：
proposal.md— 背景和目标design.md— 技术方案specs/*.md— 验收标准tasks.md— 任务拆解
相当于把你脑子里的想法（或者 PM 丢过来的需求文档）转化成一份严谨的"技术契约"。后面 AI 写代码就照着这份契约来，不会跑偏。
/opsx:apply — 真正开始写代码
这是核心阶段。AI 会先读 proposal.md 和 design.md 理解上下文，然后严格按照 tasks.md 里的任务列表，一步一步改你的项目代码。每完成一个任务就打勾 - [✅]，进度一目了然。
跟直接让 AI "帮我写个 XXX" 的区别在哪？它写出来的代码是对着设计方案和验收标准来的，不是随心所欲瞎写。
/opsx:archive — 收尾归档
tasks.md 里的任务全部完成、代码测试通过后，跑这个命令。AI 会帮你整理归档这次的文档，保持仓库整洁。
三、写错了怎么办？随时回退
如果 OpenSpec 只是个单向流水线，那它跟写个 TODO List 也没什么区别。
它真正值得说的地方是 "Stages are fluid"——阶段是流动的，你可以在任何时候回退修正。这才是规格驱动比"直接让 AI 写"强的地方：出了问题，你知道该改哪里。
在 Apply 阶段发现错误时，根据错误性质走不同的路：
局部错误：改文档，重新跑
比如 design.md 里的技术方案有个细节没考虑到，或者 tasks.md 的任务拆得不对。
处理方式很简单：
- 停掉当前的 Apply
- 直接改对应的文件
- 重新执行
/opsx:apply
不用回到起点，改哪补哪就行。
意图错误：方向跑偏了，退回去重新想
比如做着做着发现，这个需求压根不应该这么做，或者 proposal.md 的范围定错了。
这种情况需要退得更远：
- 停掉当前的 Apply
- 执行
/opsx:explore重新梳理思路 - 更新
proposal.md的范围 - 重新走 Propose → Apply 流程
说白了，这套工作流不怕你犯错，怕的是你犯了错不知道该回到哪一步去改。OpenSpec 把每个阶段的产出物（proposal、design、tasks）拆得很清楚，哪层出问题就回哪层，不用推倒重来。
