第 9 章 / 共 10 章
什么时候不该写规格
9.1 计划税与评审疲劳
前面八章都在讲规格的好处。这一章讲代价，因为不讲代价的方法论都是不可信的。
实践者的批评相当具体：
- 计划税。规格增加了计划成本、评审瓶颈和流程开销。对高风险工作，这个成本值得付；对低风险工作，它就是浪费。
- 评审疲劳。把规格切成小块确实让单次评审变轻，但也提高了评审频率。团队里的评审者是有限资源，高频小规格同样会把他们耗干。
- 认知过载。如果一次性把整个项目规格化，人类根本处理不完这个量的信息，负责评审的人最终会变成一个疲惫的、闭着眼签字的办事员——那时候规格已经彻底失去意义了。
这些不是「用错了工具」，而是方法本身的固有成本。
9.2 过度规格：把程序写两遍
另一类失败更隐蔽：规格写得太细，细到变成伪代码。
当规格开始描述循环结构、变量命名和函数内部逻辑时，你实际上把程序写了两遍——第二遍还是用一种不能编译、不能测试、不会报错的语言写的。更糟的是它带来虚假的信心：符合一份错误的规格，并不能满足任何真实需求。
判断线很清楚：规格描述可观察的行为，不描述实现结构。
| 过度规格 | 恰当规格 |
|---|---|
| 「遍历 subscriptions 数组，对每个元素调用 escapeXml，拼接成 outline 标签」 | 「当订阅标题包含 XML 特殊字符时，系统应对其转义」 |
| 「用 Map 按 folder 分组，key 为 folder 名」 | 「当订阅列表包含分组时，系统应生成对应的嵌套 outline 结构」 |
右边给了 agent 判断对错的标准，同时把「怎么实现」的自由留给它——那本来就是它擅长的部分。
9.3 四档严格度决策表
把两个维度组合起来：不可逆性（做错了多难收回）与不确定性（你自己对该做什么有多确定）。
| 象限 | 典型任务 | 建议严格度 |
|---|---|---|
| 低不可逆 + 低不确定 | 改文案、加日志、重命名变量 | 不写规格。直接下指令，做错了撤回即可 |
| 低不可逆 + 高不确定 | 试一个新交互、不确定方案的原型 | 先探索。跑原型，稳定后再补规格 |
| 高不可逆 + 低不确定 | 数据迁移脚本、发布流程改动 | 轻规格。重点写非目标和验收标准，方案部分可略 |
| 高不可逆 + 高不确定 | 跨模块重构、改数据结构、对外 API | 完整规格。采访、规格、计划、任务、验证全套 |
官方文档里有一条更简洁的判断法，可以当作快速筛子：如果你能用一句话描述最终的 diff，就跳过计划。 计划最有用的时候是——你不确定方案、改动跨多个文件、或者你对要动的这段代码不熟。
9.4 追溯性的取舍
第4章提过的那个研究结论，在这里可以给出实操建议：追溯性和确定性之间存在取舍——要求逐行引用需求会降低输出的确定性，但换来了自动检测幻觉的能力。
所以：
- 个人项目：任务卡回链验收标准就够了，不做逐行引用。
- 团队项目：产物级追溯（每张任务卡标注覆盖的标准）性价比最高。
- 合规场景：才值得上逐行引用，并接受随之而来的确定性损失。
不要因为「更严格看起来更专业」而默认选最严的那一档。 几乎所有认真讨论过这个问题的来源，最后都收敛到同一句话：按需要选择严格度，而不是一律用最激进的做法。