--- title: "SDD 最大的幻觉：你以为在写 Spec，其实在绕路写代码 | 行开心的颠倒世界" description: "Spec Driven Development 并没有消灭软件工程的难题，足够细的 spec 本质上就是另一种语法的代码；它还会把团队带回瀑布流，把不确定性藏在文档的完整性幻觉里，spec 永远覆盖不到的地方才是系统真正的盲区。" canonical: "https://xingkaixin.me/posts/spec-as-new-fig-leaf/" language: "zh-CN" --- # SDD 最大的幻觉：你以为在写 Spec，其实在绕路写代码 Spec Driven Development 并没有消灭软件工程的难题，足够细的 spec 本质上就是另一种语法的代码；它还会把团队带回瀑布流，把不确定性藏在文档的完整性幻觉里，spec 永远覆盖不到的地方才是系统真正的盲区。 2026年3月19日·1,457 字·4 分钟 SDD[工程实践](https://xingkaixin.me/tags/%E5%B7%A5%E7%A8%8B%E5%AE%9E%E8%B7%B5/)[Coding Agent](https://xingkaixin.me/tags/Coding%20Agent/)[软件设计](https://xingkaixin.me/tags/%E8%BD%AF%E4%BB%B6%E8%AE%BE%E8%AE%A1/) ![SDD 最大的幻觉：你以为在写 Spec，其实在绕路写代码](https://xingkaixin.me/cover/spec-as-new-fig-leaf.webp) 这半年，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 的时候多想想，这东西到底是在帮你理清思路，还是在帮你凑一份更长的输入。这俩区别很大。 ## 版权声明 作者 XingKaiXin 标题 SDD 最大的幻觉：你以为在写 Spec，其实在绕路写代码 发布时间 2026年3月19日 文章链接 [https://xingkaixin.me/posts/spec-as-new-fig-leaf/](https://xingkaixin.me/posts/spec-as-new-fig-leaf/) 本作品采用[CC BY-NC-ND 4.0 DEED](https://creativecommons.org/licenses/by-nc-nd/4.0/deed.zh-hans)许可。 导览 展开导览