Agent Skill「spec-driver」：用 spec 锁住范围，开发不跑偏

痛点：开发过程中需求理解不一致，做出来和预期不符

开发最磨人的不是代码难写，而是**「说的」和「做的」对不上**：

• 需求理解不一致：你心里想的是 A，对方理解成 B，写出来自然是 C，最后验收时大眼瞪小眼。
• 验收靠感觉：做得好不好全凭主观判断，没有一份「当初到底说了什么」的凭据。
• 事后说不清：过了两周再回头，谁也记不清当初的需求细节，只能翻聊天记录，还翻不全。

口头共识最大的问题就是会遗忘、会变形。spec-driver 就是把「凭感觉开发」换成「照着规格开发」。

适用场景

• 需求已经想清楚，希望严格锁住范围，不被中途的新想法带偏。
• 多人 / 多轮改动，需要一个统一的参照物对齐理解。
• 改动频繁的项目，希望每个改动都能追溯到当初的需求。

流程怎么用

① 把需求写成自包含的 spec

动手前，先把需求落成一份自包含的 spec，包含四部分：

• 目标：这次要做成什么。
• 范围：哪些做、哪些明确不做。
• 验收标准：每条可验证的「完成」定义。
• 边界：前提、约束、例外情况。

关键在「自包含」——这份 spec 单独拿出来，任何一个人读都能看懂，不依赖口头补充。

② 开发时一切以 spec 为准

开发过程中，每个改动都对照 spec，逐条落实：

• 动一处代码，先确认它对应 spec 里哪一条。
• 遇到 spec 没覆盖的情况，先回 spec 确认，而不是自己拍脑袋扩展。
• 中途冒出的新想法，先记下来，不急着塞进当前开发——范围是锁住的。

③ 验收时按 spec 逐条打勾

验收不靠感觉，按 spec 逐条打勾：目标达成了吗、验收标准逐条过、边界内有没有越界。每一条都有「通过 / 不通过」的明确结论，验收记录就是最终的凭据。

关键

spec 是「唯一事实来源」。所有人、所有改动、所有验收都对照同一份文档，避免口头共识被遗忘。开发可以快，但锚点只有一个——spec。