SDD 最大的幻觉：你以为在写 Spec，其实在绕路写代码

SDD 最大的幻觉：你以为在写 Spec，其实在绕路写代码

这半年，Spec Driven Development 很火。 很多人相信一件事：先把 spec 写够细，再交给 coding agent，质量和效率就能一起上去。

我曾经也接近相信这件事。直到我把 Gabriella Gonzalez 的《A sufficiently detailed spec is code》和 STRRL 的《我对 Spec Driven Development 的看法》放在一起看，才越来越确定——SDD 没有消灭软件工程的难题，它只是把难题改头换面，推迟到后面爆炸。

我不反对写 spec。但把 spec 当成银弹，当成可以跳过工程判断、跳过迭代反馈、跳过维护现实的捷径，这事有问题。

足够精确的 Spec，本质上就是代码

Gabriella 在文中拆解了 OpenAI Symphony 的 SPEC.md。她指出这个所谓的”规格说明”，里面大量内容其实已经是伪代码、结构化算法、字段定义清单，甚至直接就是代码形状的文本。

你会看到数据结构字段逐条列举、类型约束状态都写得很细，会看到并发控制和重试策略直接给公式和阈值，会看到专门加”Cheat Sheet”来让模型”更快实现”。

要让 agent 稳定生成可运行实现，你必须把 spec 写到接近代码的精度。写到这个精度时，你做的已经不是”更轻量的前置描述”，而是在做另一种语法的编程。

这其实呼应了 Dijkstra 很早就说过的：复杂系统协作依赖窄接口，口语化、宽松化表达并不会减少劳动，只会把劳动转移成更多沟通成本和更多歧义。你不可能在降低表达精度的同时，要求实现可靠性上升。

SDD 经常把团队带回瀑布流

STRRL 那篇里有个我非常有共鸣的点：SpecKit 用久了之后，开发流程会变成”提前设计 + 脑内推演 + 一次性交付大块产出”，结果是巨大 PR 堆着不敢合。

这和我们过去反复踩坑后形成的共识正好反着来。软件不是一次性设计出来的，它是在持续变化里长出来的。需求会变、边界会变、约束会变、认知会变。

而 SDD 在实践里最容易发生的事，是把”变化中的探索”提前冻结成”文档中的确定性”。你为了让 agent 少犯错，会逼自己在编码前把大量细节一次性想完。这个动作看似更”工程化”，实际常常是把不确定性藏了起来。

最后开发节奏就悄悄退化成：先花大量时间写 spec，一次性生成大量代码，在后期集中爆雷，然后人工返工收拾残局。这套节奏，本质上就是瀑布流的现代外观版。

Spec 的边界，就是系统的盲区

支持 SDD 的人常说：只要 spec 写得足够好，agent 就能稳定交付。

问题是，工程里最难的部分，往往恰恰是你没预见到的部分。STRRL 说得很直白：覆盖到的地方执行还行，覆盖不到的地方就是一坨大便。Gabriella 也做了实测，按 Symphony 的 spec 让 Claude Code 生成 Haskell 版本，结果并不可靠，修了很多轮也有行为不符合预期的地方。

这不是个例。YAML 这种规格已经非常细、还有一致性测试套件的标准，现实里仍然有大量实现并不完全符合规范。

所以真正的问题不是”有没有 spec”，而是：你是否承认 spec 永远不可能完备，你是否为”spec 之外”预留了快速反馈和修正机制，你是否把工程质量建立在可验证循环上，而不是建立在文档完整性的幻觉上。

Spec 能定义边界，但也会制造边界。边界之外，就是盲区。

当 Spec 也开始追求速度，它会退化成”文档形状的 Slop”

理论上，写 spec 应该比写代码更慢、更谨慎、更抽象。现实里，在”快速交付”的压力下，spec 经常变成了另一种流水线产物：句子很多、术语很全、结构看起来很专业，但整体缺乏真正的设计判断和一致性。

Gabriella 批评 Symphony 某些章节像”specification-shaped sentences”，我觉得这个描述很精准——像规格说明，但不是规格说明该有的思考密度。

如果你先用 AI 快速生成一份”像样的 spec”，再让 AI 按这份 spec 生成代码，那中间其实是两次信息压缩和两次语义漂移。每一层看着都像在”提炼”，但总信息量很可能在流失。

最后你得到的不是”规格驱动开发”，而是提示词驱动文档、文档驱动提示词，最后人类在尾端兜底。

别把 Spec 当圣杯，把它放回工具箱

我现在的做法更保守，也更务实：

重要系统照样写设计文档，但只写关键决策和关键约束。不追求前置完整性，追求小步可验证。让 agent 快速产出，但把质量建立在测试、回归和审查闭环上。文档服务于沟通和决策，不服务于”幻想一次性正确”。

我不反对 spec。我只是觉得把 spec 当成可以替代工程判断、替代迭代反馈、替代长期维护经验的”银弹”，太天真了。

软件工程最贵的成本从来不是”敲代码”这件事，而是理解问题、做出取舍、承担后果。这部分，今天没有被 SDD 解决。

---

写 spec 的时候多想想，这东西到底是在帮你理清思路，还是在帮你凑一份更长的输入。这俩区别很大。