Appearance
一句话需求怎么落成一份 Spec？
导读
一句话需求要经过三步才落成 Spec：先用苏格拉底提问把隐性假设挖出来，再用 JTBD 收成一句可执行的任务，最后写成一份带可核验验收标准与终止条件的 Spec。重心是验收与终止，不是写死步骤。
请注意
我的写作身份，迫使我必须兼顾观点本身的严谨与完整，而这很有可能会给你带来困扰。日常实操中，所有规则、流程、提示词、上下文，都不需要你百分百原样复刻，你也不必依赖一份面面俱到的完整规范文档。我们追求的目标从来都只是 与 AI 达成一份验收标准（共识）。
Spec 是什么
在业务实践中，我们通常用 Spec 文档来承载任务的目标、边界、约束、上下文和验收标准。
Spec 是把模糊任务收束成 AI 可执行、可自查、可验收的规范说明。
重大误区：Spec 的核心不是写死步骤，而是写清可核验的验收与终止条件。
Spec 写得再完整，也不应把每一步操作都提前写死；否则 AI 就不再是能够自主规划、寻找解决方案的智能体，而只是按顺序执行指令的脚本。
为什么验收标准是自主工作的关键
长线任务通常会经历多轮对话。多轮任务中，你不可能每一轮都重新定义完成标准，所以需要给 AI 一个核心指令、一个判断标尺：每一轮工作循环结束后，AI 都通过标尺自查，判断任务是否达标、是否可以结束、下一步是否继续推进。
没有清晰验收标准的情况下，AI 很容易出现两种极端：
要么草草收尾，假装任务完成；
要么不断扩张工作范围，陷入无限循环，越做越多。
什么算可核验的验收标准
验收条件是否达成，必须能被客观判定，而不是依赖主观描述。
比如：
「代码写得整洁完善」属于主观描述，非常容易失控；
「全部测试用例执行通过、不改动数据库结构、输出变更清单」，则是可以自动核验的标准。
具体可核验的验收标准怎么写，参见提示词到底该怎么写？。
终止条件同样要可客观判断。例如：验收标准全部满足、连续两轮没有实质进展、需要突破任务边界，或出现无法自动判断的冲突。否则，AI 就不知道什么时候该停。
本章边界
本章只负责把需求收束成 Spec，并明确验收与终止条件。验收标准的具体写法参见提示词到底该怎么写？；Spec 文档的完整写法参见Spec 到底该怎么写？。