Spec 驱动开发

先回答一个问题：规格说明书用来干什么

AI 写代码最容易翻车的节点，不是模型能力不够，而是它和人类工程师之间没有一份双方都认可的"完成标准"。需求是模糊的，Agent 不会停下来反问，它会直接按自己的理解把代码铺开。结果往往是：功能写完了，方向却偏了，改起来比手写一遍还贵。

这份规格说明书要解决的就是这件事：把"我们要做什么、为什么要做、做到什么程度算完成"写下来，让 Spec 成为 Agent 与人类之间的唯一事实来源。

四道闸门，不许跳步

这个技能把开发过程切成四个阶段，每一阶段验收通过才能进入下一阶段：

• Phase 1: Specify —— 先提澄清问题，把模糊需求追问到具体。假设必须在写规格之前就摆上台面，不允许悄悄替用户补全模糊点。最终产出一份覆盖六个核心区域的文档：Objective（目标）、Commands（可执行命令，而不是工具名）、Project Structure（目录与测试、文档位置）、Code Style（用一段真实代码示例代替三段文字描述）、Testing Strategy（框架、位置、覆盖率、测试层级）、Boundaries（Always / Ask First / Never 三层权限边界）。模糊指令还要被重写为可验证的成功条件。
• Phase 2: Plan —— 基于已确认的 Spec 生成技术方案，拆解组件依赖、实施顺序、风险与缓解、可并行与必须串行的部分。产出物按约定保存为 tasks/plan.md 和 tasks/todo.md，供下游命令消费。这份计划需要人类点头。
• Phase 3: Tasks —— 把计划拆成独立可完成的任务，每个任务带验收标准和验证步骤，按依赖关系而非重要性排序，单任务改动文件不超过约 5 个。
• Phase 4: Implement —— 逐任务执行，引入 incremental-implementation 与 test-driven-development 两个技能配合增量推进和测试先行，并用 context-engineering 按需加载对应规格片段，避免把整份 Spec 一次性灌进上下文。

规格不是一次性产物。决策变了先改 Spec，再动手改代码；范围变了同样先更新文档；Spec 要和代码一起提交进版本库，PR 里要链接对应的规格章节。

什么时候不该用

改动一行代码的修复、拼写纠错、需求明确且完全自包含的小改动，不适合这套流程。它的价值在需求含糊或变更会波及多个文件、模块时才真正兑现。

上手前先自查：有没有书面需求？"完成"的定义是否具体可测？三层边界是否已经划定？Spec 是否已落盘到仓库里？这几项不成立，就别急着写代码。