先写规约，再让它动
Spec 先行防止范围蔓延和沟通错位。10 分钟写一份规约，省掉几小时返工。
上一章告诉你「范围要划住」，这一章把范围变成一份能给 AI 用的规约（Spec）。vibe coding 最大的返工来源，是 AI 没搞清你要什么就埋头写。规约先行，就是堵住这个源头。
读完你能回答：
- Spec 和 prompt 有什么区别？
- 一份能用的 Spec 至少要写清哪几样？
- 谁先提第一版：你还是 AI？
- 规约写多久才够？
Spec 和 prompt 的差别
贴墙的差一条线：prompt 是一次性的话，Spec 是长期有效的契约。 你把 Spec 写进项目文件（AGENTS/CLAUDE），AI 在后续每一轮对话里都能读到，不用你每次都从头讲一遍。
- 想解决「AI 老搞不清需求」→ 写进 Spec
- 想解决范围蔓延 → 写进 Spec
- 想让多个对话、多个会话保持一致 → 写进 Spec
Spec 不是考试作文，是给 AI 的「项目说明书」：范围、约束、完成标准，一次性写透 anthropic-sdlc。
一份能用的 Spec 至少写清这几样
- 给谁、解决什么问题：一句话定位
- 范围 / 不做清单：明确不碰哪些
- 验收标准：做成什么样算完，具体到能检查
- 约束：技术栈、目录结构、命名规范、API 边界
- 特殊规则：哪些是模型容易犯的错，提前禁掉
写的时候站在模型角度自查：它光读这份 Spec，能不能把活干到你要的程度？不能，就补。
让 AI 先提，别先给草稿
写规约时有个反直觉的顺序：别先把你的想法写成初稿丢给它，让它先提。 你带着草稿进来，模型倾向于同意你；它先提，你才看得到一个真实的第二意见。
提方案之前还有一步：让它先访谈你。一次问一两个问题，专门挑你的假设和没想过的失败模式问。问得越细，说明它越可能真的读懂了问题；问不出来，通常是你前面没讲清。
然后是盲区。你写的那版已经带着你的假设，它照着改，你的盲区就原样变成设计的盲区。它先提，同时也在检验它有没有听懂你的问题——提得不对，说明你前面没讲清，这比它客气地改你的稿子有用得多。
争论的时候有个具体习惯值得学：纠正要带文件。 你指出它错了，同时给出证明它错的那个文件，它改的是自己对系统的认知；只嘴上说"你这里不对"，它改的多半只是道歉——下一轮还在同一个地方错。
什么时候可以例外：你已经把约束想清楚了，只想让它补细节。但「只想补细节」和「还没想清楚」经常分不清，拿不准的时候按后者处理 aase-egm。
写多久才够
别追求完美。10 分钟能写出一版能用的 Spec，就比 40 分钟精雕细琢更快到能跑的东西。
- 大项目、高风险：慢一点，写细一点
- 一次性原型、Demo：粗一点，够用就行
关键是「先有一版」，然后随项目进展迭代。Spec 不写完不动工，是这条线的唯一纪律。
「够不够」有个很硬的判据：这份规约清晰到代码应该能自己写出来吗？ 到了这个程度，剩下的分歧都是执行细节，交给模型不会跑偏；没到这个程度就动手，那些没说定的判断会变成它在一句话中间替你做的决定，最后埋进一份没人设计过的改动里。拿不准的时候，缺的通常不是更多文字，是还没回答的那个问题。
写完规约，接着把完成标准定义得机器可查
把范围写进规约之后，下一步是：让「完成」变成机器可检查的，而不是靠人拍脑袋。