规格驱动开发

当需求只存在于一句模糊想法里时，直接开工往往意味着返工。规格驱动开发（Spec-Driven Development）解决的正是这个问题：在写任何代码之前，先产出一份结构化规格，作为 agent 与工程师共享的“真相源”，明确“建什么、为何建、怎样算完成”。

核心能力

这个技能采用四阶段门控工作流：当前阶段未验证通过，就不得进入下一阶段。

• 阶段 1 规格（Specify）：从高层愿景起步，先用澄清问题把需求问具体，并立刻摊开假设——假设是最容易藏住误解的地方，规格的精髓就是提前暴露它们。
• 规格文档覆盖六核心区：Objective（目标、用户与验收标准）、Commands（带 flag 的完整可执行命令，而非只给工具名）、Project Structure、Code Style（一段真实代码片段胜过三段描述）、Testing Strategy、Boundaries（总是做 / 先问 / 绝不做三层边界）。
• 成功标准改写：把“让仪表盘更快”这类模糊诉求改写成可测量的指标，例如首屏 LCP 达到某阈值。
• 阶段 4 实现（Implement）：逐任务落地，遵循增量实现与 TDD；通过 context-engineering 在每步只加载相关规格段落，而不是把整个规格塞满上下文。

适用边界与注意点

规格的价值取决于它是否鲜活：决策或范围变化时，先改规格再实现；规格随代码进版本控制，PR 里回链对应规格段落。规格必须经人类评审批准后才能进入实现。

它不适合单行修复、拼写更正或需求明确且自包含的小改动——这类任务直接写码更划算。