过去半年，如果你还没听过“规范驱动开发”（Specification-Driven Development，简称SDD），那你可能已经有点跟不上AI编程的节奏了。简单来说，SDD的玩法是：别急着让AI写代码，先把规范写清楚——结构化地定义需求、边界、约束、验收标准，然后再让AI基于这份“规范”去生成代码。GitHub的Spec Kit、亚马逊的Kiro、Tessl这些工具都在推这个方向。听起来很美好，对吧？SDD不是银弹。甚至在某些场景下，它会让你的代码质量变得更糟。SDD到底好在哪？先别急着否定
在没有SDD之前，AI编程基本等于“vibe coding”——给AI一个模糊的提示词，让它猜你想要什么，然后祈祷它猜对。结果往往是代码能跑，但离“好用”差着十万八千里。SDD的价值在于它强迫你把需求想清楚。写规范的过程，本质上是在帮你梳理思路、定义验收标准、拆解任务。对于标准化的CRUD、常规的API接口、典型的数据处理流程，SDD确实能大幅提升效率。规范的代码生成质量，远比“一句话提示词”要可靠。但问题在于：SDD把“写规范”和“写代码”强行解耦了，而这种解耦在复杂场景下恰恰是最大的隐患。复杂业务逻辑——规范根本写不清楚
Fred Brooks在1975年的《人月神话》里说过一句话，放在今天依然振聋发聩：“软件的复杂性是本质属性，不是偶然属性。因此，那些抽象掉软件复杂性的描述，往往也抽象掉了它的本质。”
这句话什么意思？规范本身就是对代码的一种抽象。当你把复杂的业务逻辑压缩成几页规范文档时，你不可避免地丢失了大量细节。举个例子：一个电商的促销引擎，涉及满减、折扣、优惠券叠加、会员等级、库存联动、区域限制……这些逻辑用自然语言写出来，AI读一遍就能生成正确的代码？别天真了。AI没有真正的“理解”，它只是在做模式匹配。更致命的是：如果规范本身就有问题，SDD只会把你的错误放大。有开发者分享过一个惨痛经历：花了三天时间写规范、生成实现，流程完美无缺，但最后发现——从一开始对系统的基本假设就是错的。SDD没有帮你发现这个错误，它只是高效地把错误变成了代码。规范写得再详细，也比不上代码本身的精确性。代码才是最终的、唯一精确的规格说明。边缘案例——AI根本想不到你没想到的事
SDD的另一个隐含假设是：你能在写规范的时候把所有边缘情况都想清楚。真实项目中，边缘案例往往是在编码和测试过程中才被发现的。你写代码的时候才会意识到：“哦，如果这个字段是空怎么办？”“如果并发请求同时修改同一条数据呢？”“如果第三方服务超时了呢？”这些不是规范写得不够好，而是规范这种形式本身就限制了你的思考深度。你在抽象层面很难穷举所有具体的异常场景。在规范足够好的前提下，AI可以覆盖基础代码行数的70%-90%。但真正消耗精力的，从来不是“把这些行敲出来”，而是“确保这些行在真实世界里不出错”——边界条件、异常处理、性能瓶颈、需求变更……这些才是那“剩下的大头”。。SDD并没有解决这个问题，它只是把问题从“代码阶段”转移到了“规范阶段”。更糟糕的是，AI不会主动问你“这个边缘情况怎么处理”，当下的skill.md就是在增强SDD的覆盖范围。如果你在规范里没写清楚“当库存为负数时怎么办”，AI大概率会给你一个空指针异常。性能优化和技术选型——AI的命门
作者用GitHub Spec Kit和Claude Code做了一个真实项目的实验，结果在很多方面都令人印象深刻——但在选择正确的库和框架时，AI彻底失败了。性能优化和技术选型依赖于大量的隐性知识：这个库的底层实现有什么坑？那个框架在新版本里改了哪些API？两种方案在特定数据量下的性能差异有多大？这些知识不在规范里，也不在训练数据里（至少不在最新、最准确的版本里）。SDD的工作流是这样的：规范 → 计划 → 任务拆解 → 代码生成。但技术选型这个关键决策，恰恰发生在“规范”和“计划”之间的灰色地带。AI没有真正的“判断力”去做这个决策。它只能根据训练数据里的“常见做法”去猜——而猜错的代价，可能是整个系统的性能瓶颈。有一位从业20多年的资深工程师直言：“那些没什么实际经验的人跑出来说规范是软件开发的银弹，我立刻就想到了《人月神话》。”别忘了：SDD还有“成本”问题
就算你做的是适合SDD的项目，还有一个现实问题：写规范本身是有成本的。对于小改动、简单的UI调整、快速的原型验证，走完整的SDD流程——写规范、生成计划、验证输出——流程本身的开销可能比实际工作还大。- 小改动（如UI微调）：直接用精心设计的提示词，别走完整SDD
目标不是教条地执行某个流程，而是对具体问题应用恰当的结构化程度。那SDD到底该怎么用？说了这么多，并不是要你把SDD扔进垃圾桶。恰恰相反——SDD是有用的，但前提是你要知道它的边界在哪里。SDD适合什么？
SDD不适合什么？
- 需要深度性能优化和技术判断的任务（AI不具备这种能力）
Fred Brooks在40多年前就说过：“构建软件的困难在于规格说明、设计和测试这个概念的构建，而不在于把它表示出来的劳动……如果这是真的，那么构建软件永远都是困难的。本质上没有银弹。”SDD是一个很好的“提示词工程”升级版。它让AI-assisted开发变得更规范、更有结构。但它没有，也不可能，消除软件开发的本质复杂性。别被“规范驱动”四个字忽悠了。工具永远是工具，真正能写出好代码的，还是那个坐在屏幕前、理解业务、能做出判断的人。AI可以帮你写代码，但它不能替你想清楚为什么要写这段代码。（本文观点受 Alex Punnen《Why Specification-Driven Development (SDD) is Not a Silver Bullet for AI-Assisted SDLC》启发，结合近半年行业实践与讨论整理而成。）
夜雨聆风
