规范驱动开发

它解决什么问题

当 AI 拿到一句模糊需求就直接动手时，「大概知道要做什么」会被当成明确的需求。结果往往是实现了没人要的功能、漏掉边界条件，或者代码写完之后才发现双方对「完成」的定义完全不同。根因不是模型能力，而是缺少一份双方共同确认的规格。Spec-driven development 把规格文档当作唯一事实来源：先对齐再写代码，代码没有规格就等于猜测。

核心工作方式

四个门控阶段，当前阶段没通过验证就不进入下一个：

• Specify：先把假设全部列出来，不静默补全模糊需求；再用六块核心内容写规格文档：Objective（要做什么、为什么、谁是用户、成功标准）、Commands（带参数的完整可执行命令）、Project Structure、Code Style（一段真实示例胜过三段描述）、Testing Strategy、Boundaries（三层体系：Always / Ask First / Never）。模糊指令要重写成具体、可测试的验收条件。
• Plan：拆出组件与依赖、实现顺序、风险与缓解、可并行与必须串行的工作，输出 tasks/plan.md 与任务列表 tasks/todo.md。
• Tasks：把计划拆成独立小任务，每个任务有明确验收标准和验证步骤，按依赖关系而非重要程度排序，单任务改动不超过约 5 个文件。
• Implement：一次只做一个任务，逐步实现并验证。

规格是活文档而非一次性产物：决策变更先改规格再改代码，范围增减同步回写，规格纳入版本控制，PR 中引用对应规格章节。

适用边界

适合新项目或新功能、需求模糊或不完整、跨多文件多模块的改动、架构决策，以及预计超过 30 分钟的任务。不适合单行修复、拼写纠正、需求明确且自包含的小改动——这类情况写规格的开销大于收益。