前言
- 目前项目里统一使用 OpenSpec 管理 AI 开发流程。用了几个月，它确实解决了一些问题，但也暴露了几个越来越明显的痛点。
- 这篇文章整理一下我对开发流程 SKILL 的判断：OpenSpec 做对了什么、哪里不合适，以及我希望换成什么样的流程。
OpenSpec 做了什么
- OpenSpec 是一套”规格驱动开发”的工具，核心流程是：提案 → 实现 → 归档。
- 提案（propose）：为每次改动创建一个变更目录，生成提案（proposal）、设计（design）、需求规格（specs）和任务清单（tasks）。
- 实现（apply）：按任务清单逐项开发。
- 归档（archive）：开发完成后，把这次变更的规格合并进主规格，变更目录移到归档目录。
- 对我来说，它主要提供了四个能力：
- 需求拆分：把需求拆成可执行的任务清单。
- 测试用例：规格里写明场景，可以对照验证。
- 归档：开发完的规格合并进主规格。
- 变更记录：每次改动都留下一个完整的变更目录。
遇到的问题
1. 小改动也会产生一整套变更记录
- 不管改动大小，每次都是一整套流程：提案、设计、规格、任务四份文档，加上归档。
- 迭代频繁的时候，归档目录增长得很快，每个变更目录下都是成套的文档。
- 很多变更其实是同一个功能的小迭代：比如同一份配置，先做后台管理，再做业务读取，就拆成了两个完整的变更目录。
- 对小改动来说，写文档的成本已经接近甚至超过写代码本身。
2. 开发中途改需求，文档就不同步了
- 实际开发中，需求在开发过程中调整是常态：发现边界没考虑到、策划改了规则、实现时发现原方案走不通。
- 这时代码改了，但变更目录里的提案、设计、规格、任务不一定会跟着改。AI 默认的行为是直接改代码。
- 要保证同步，只能在 Agent 的规则里强制要求”改需求必须先改变更文档”，而且每次都要盯着它执行，否则最后归档进主规格的就是一份过时的内容。
3. 历史归档基本没人看
- 归档目录越来越大，但回头看，AI 和人基本上都不会去翻它。
- 想知道某个功能现在是什么规则，看的是代码和当前的功能文档；想知道某次改了什么，看的是 git 提交和 PR。
- 归档成了只写不读的数据，却还在持续增加每次开发的成本。
4. 各个环节绑在一起，不好替换
- OpenSpec 的提案、实现、归档是一个整体，文档格式和目录结构也是固定的。
- 想换掉其中某一环（比如换一个更适合项目的需求澄清方式），或者跳过某一环（比如小改动不归档），都比较别扭。
我希望的流程
把 OpenSpec 拆成五个独立的环节，每个环节由一个 SKILL 负责：
① 澄清需求 grill-me + 当前功能文档
│ 产出：完整的需求对话上下文
▼
② 生成需求文档 创建需求文档的 SKILL
│ 产出：本次需求文档
▼
③ 拆分需求与测试 需求拆分的 SKILL
│ 产出：拆分后的任务文档 + 测试用例
▼
④ 按文档开发 逐个任务实现，可中断、可换窗口继续
│
▼
⑤ 测试完成后归档 更新该功能模块的文档，不保留历史
1. 先澄清需求
- 用
grill-me结合当前功能文档确认需求、补全规则。 - AI 会按依赖顺序逐轮追问，每个问题附带推荐答案，把边界条件、异常情况、和已有功能的交互在开发前一次问清楚。
- 这一步的目的是让后面的文档建立在已经确认过的规则上，而不是 AI 的假设上。
2. 生成需求文档
- 把第 1 步的对话结果作为上下文，调用一个专门创建需求文档的 SKILL。
- 文档格式由这个 SKILL 决定，可以按项目习惯定制，不必套用固定模板。
3. 拆分需求，生成测试
- 再调用需求拆分的 SKILL，生成一份拆分后的任务文档，每个任务附带对应的测试。
- 这一步最主要的作用是让开发可以中断：
- 每个任务都是独立、可验证的一小块，做完一块就有明确的完成标准。
- 上下文快满时，可以直接开一个新窗口，读取拆分文档继续做下一个任务，不用把整段历史对话带过去。
- 这样可以避免长时间开发导致上下文爆炸、AI 开始遗忘前面的约定。
4. 按文档开发
- 按拆分后的任务逐个实现，每完成一个任务跑对应的测试。
- 如果开发中途需求变了，回到第 1、2 步更新需求文档，再调整拆分文档。因为这份文档只服务于本次开发，改起来没有负担。
5. 测试完成后归档
- 归档时不产生任何历史文档，只维护一份该功能模块的文档。
- 这份文档描述的是功能当前的样子：核心规则、数据结构、关键流程，以及一些容易踩坑的特殊规则。
- 项目里其实已经有类似的机制：每个功能模块都维护了一份说明文档，以 SKILL 的形式提供给 AI。归档这一步只需要把本次改动更新进对应模块的文档。
- 本次的需求文档和拆分文档在归档后就可以删掉。改动历史交给 git 提交和 PR，不再单独存一份。
两种方式对比
| OpenSpec | 拆分后的流程 | |
|---|---|---|
| 需求澄清 | 提案阶段由 AI 生成 | 先用 grill-me 逐轮确认 |
| 文档格式 | 固定的提案/设计/规格/任务 | 每个环节的 SKILL 自定义 |
| 小改动 | 也要走完整流程 | 可以跳过不需要的环节 |
| 需求中途变更 | 需要强制 Agent 同步变更目录 | 只改本次的需求文档和拆分文档 |
| 中断后继续 | 依赖任务清单 | 拆分文档本身就是为中断设计的 |
| 归档结果 | 主规格 + 不断增长的历史变更 | 只有一份模块文档 |
| 改动历史 | 归档目录 | git 提交和 PR |
这样做的好处
- 环节拆开，每个 SKILL 都可替换、可自定义：需求澄清、文档生成、需求拆分、归档各是一个独立的 SKILL，哪一环不合适就单独换掉或改掉，让整个流程更适配项目，而不是让项目去适配工具。
- 去掉了历史归档：不再为一份没人看的历史持续付出成本，文档数量不会随着迭代次数增长。
- 文档始终反映当前状态：模块文档只描述功能现在的样子，AI 和人读到的都是最新规则，不用在多份历史版本里判断哪份才是对的。
- 小改动更轻：不需要的环节可以直接跳过，比如一个小 bug 修复，可能只需要第 4、5 步。
需要注意的地方
- 模块文档要真的被更新：去掉历史归档后，模块文档就是唯一的规则来源。如果归档这一步被跳过，文档就会过时，所以第 5 步最好作为开发完成的必要条件。
- 改动原因要写进提交和 PR：不再保留变更目录后，”为什么这样改”只能从 git 记录里找，提交信息和 PR 描述要写清楚。
- 团队要有统一约定：每个环节用哪个 SKILL、文档放在哪里、什么规模的改动可以跳过哪些环节，需要提前约定好，否则拆开之后容易各用各的。
总结
- OpenSpec 证明了”先写规格再开发”对 AI 开发是有效的，但它把所有环节绑成一个整体，对小迭代太重，对中途改需求不友好，还会积累一份没人读的历史。
- 我更想要的是把它拆开：用 grill-me 澄清需求，用独立的 SKILL 生成和拆分文档，开发完只维护一份模块文档。
- 每个环节都是一个可以随时替换的 SKILL，流程跟着项目走，而不是项目跟着工具走。
