技术 · 熟练
规格写好了，为什么还是没人照着做
规格越长越没人读，越长越容易跑偏
「先把需求写成规格」这条建议本身没错，错的是它默认了「写完就会被读」。2026 年 9 月下旬在 Hacker News 上被顶到 528 赞的一篇复盘来自编码应用 Nuanced 的作者：她把整个产品做成了瀑布式流程（对话 → 消歧 → 规格 → 评审 → 批准 → 实现），最后宣告它失败了 —— 规格太长没人读，为补救加的「Spec Tour」只增加了复杂度；用户无法中途退出；而且越强的模型越不需要那么精确的指令。
这一页不是推翻规格化，而是给站上那份《AI需求规格化》补上它没写的那半：规格的职责不是把话说全，而是把「还没定的取舍」暴露出来；交付物不该是一份文档，而该是一条能随时被检视、被澄清的路径。
方法 · 一图看懂
1
先分清规格管什么 — 它管「还没定的取舍」和「验收标准」，⛔ 不管「把每一步都预先写死」
2
把长度砍到能被读完 — 加一条硬上限：任何人读完不该超过几分钟；超了就说明这份规格在替你思考
3
改成可中途退出的形状 — 每一段都能单独被讨论、被推翻、被跳过，⛔ 不是一次性签字的瀑布
4
把「为什么改」写在最前 — 目的在前、做法在后；只写做了什么，读者就只剩「重建意图」这一条路
5
以「检视得动」验收 — 一次交付好不好，看的不是规格多完整，而是人家能不能在一次阅读后指出哪一处该改
原理 · 为什么有效
失败的原因不是规格化，是「计划变成了文档」。原作者的总结很锋利：一旦计划变成一份文档，就没人读了 —— 因为文档是一次性签字的产物，而计划真正的作用是让人持续保持理解。这两件事形状完全不同：文档追求完整，理解追求「随时能指到那一行」。
第二个原因是读者的负担被 AI 放大了。让 AI 起草是很便宜，可读的人是有限的：同一份改动，写的人多了三倍篇幅、读者就要多花三倍时间去把目的从描述里挖出来。所以「写得全」在这里是负收益 —— 篇幅不是信息量，篇幅是别人的阅读成本。
第三个原因最容易被忽略：模型越强，对精确指令的依赖越低。当执行的容错变大时，把每一步事前定死的收益在下降，而它的代价（流程僵化、无法中途退出）却没变。于是合理的做法反过来：少写死步骤，多写清取舍与验收。
适用场景
适合：已经试过「先写规格再让 AI 干」、却发现规格写完就没人看的人；交付物要给同事或下游 agent 继续用的人；同一个需求反复被理解错的人。
不适合：需要审计留痕、必须逐条签字的合规类交付（那里的规格不是给人读的，是给流程留证的，不要按本页砍长度）；以及一句话需求就能一次做对的小任务 —— 那种情况下规格本身就是多余的开销。
自测 · 5 问
我上一份规格，别人读完用了几分钟？我数过吗？
规格里有没有把「还没定的取舍」单独列出来，还是一股脑按步骤写死？
我有没有给执行的人（或 agent）一个「中途说不对」的入口？
我是不是把「为什么改」写在了最后，或者压根没写？
这份规格被推翻一段之后，剩下的部分还能用吗？
怎么上手 · 验证步骤
上手第一步：把现有规格按「取舍」重排一遍。拿一份你写过的规格，删掉所有「怎么做」的细节，只留三类 —— ① 还没定的取舍（每一条写清楚选项和判据）② 什么算做完（验收标准）③ 为什么这次要改。多数规格砍完会剩不到原来的三成，而这剩下的三成才是别人真正需要读的部分。
第二步：给它加一条退出规则 —— 「任何一段都可以被单独推翻，推翻之后其余部分照旧有效」。写下来之后你会发现，原本很多「必须整体同意」的设计，其实是几个互不相干的决定。
自检动作：把规格交给一个没有背景的人或一个新会话的 AI，只说一句「照着它走一遍，遇到要你自己决定的地方圈出来」。圈出来的地方，就是规格里还没定的取舍 —— 它们本该由你定，而不是由执行者补。返工两三轮之后，这份规格会越来越短，而漏掉的取舍会越来越少。