规范驱动开发（Spec-Driven Development, SDD）试图通过大量文档来指导 AI 编程，但这本质上是瀑布模型的回归，会导致文档冗长、审查重复和效率低下等问题。相比之下，更优越的方法是“自然语言开发”，它借鉴敏捷理念，通过小步快跑和迭代试验与 AI 协作。这种方式更灵活，更符合现代软件开发的不确定性，能有效提升开发效率。
什么是规范驱动开发 (SDD)？
面对一个只有聊天输入框的编程助手，开发者很容易感到不知所措。为了给 AI 编码代理提供指导，开源社区设计了一种方法：基于初始提示，由大语言模型（LLM）生成产品规范、实施计划和详细任务列表。用户可以编辑这些文档来完善需求，然后将其交给编码代理执行。
这种方法被称为 规范驱动开发 (SDD)，目前已有多种工具支持，例如：
- GitHub 的 Spec-Kit
- AWS 的 Kiro
- Tessl
- BMad Method (BMM)
这些规范本质上是一堆 Markdown 文件。例如，为一个简单的功能（在应用中显示当前日期），就可能生成 8 个文件和超过 1300 行的文本。
“Markdown 疯狂”：SDD 的实际问题
乍一看，这些文档似乎很有用，但细节中隐藏着问题。一旦开始使用 SDD，其缺点就变得非常明显：
- 上下文缺失：AI 代理通过文本搜索来理解上下文，常常会忽略需要更新的现有功能，因此仍需人工审查。
- 文档疯狂：SDD 产生过多文本，尤其是在设计阶段。开发者大部分时间都在阅读冗长的 Markdown 文件，而不是思考。
- 系统性官僚主义：三步设计流程对大多数情况而言都过于繁琐，规范中充满了重复和对想象中边缘情况的过度设计。
- 伪敏捷：SDD 工具包会生成所谓的“用户故事”，但常常用词不当（例如，“作为一个系统管理员，我希望关系能存储在数据库中”），这并非真正的用户故事，只会分散注意力。
- 双重代码审查：技术规范本身就包含代码，开发者必须先审查一次。由于 AI 写的代码仍会有 Bug，开发者还需要审查最终的实现，导致审查时间加倍。
- 虚假的安全感：尽管 SDD 旨在让 AI 代理保持在正轨上，但代理并不总是遵循规范。例如，它可能在没有编写任何单元测试的情况下，就将“验证实现”的任务标记为完成。
- 收益递减：SDD 在从零开始的新项目中或许有些用处，但随着应用规模扩大，规范会越来越偏离重点，并拖慢开发速度。对于大型现有代码库，SDD 基本上无法使用。
回到过去：瀑布模型的阴影
有人可能认为 SDD 的问题只是因为工具尚不成熟。但我认为，SDD 本身就走错了方向。它试图解决一个错误的问题：
“我们如何将开发者从软件开发中移除？”
SDD 试图用编码代理取代开发者，并通过 meticulous 的规划来约束这些代理。这让人想起 瀑布模型，它也要求在编码前编写大量文档。但软件开发本质上是一个 非确定性过程，预先规划无法消除不确定性。
此外，SDD 的目标用户到底是谁？你必须是业务分析师才能在需求阶段发现错误，又必须是开发者才能在设计阶段发现错误。这说明它并没有解决其声称要解决的问题（移除开发者），反而只有少数同时精通两种技能的人才能使用。
新希望：自然语言开发
敏捷方法通过 适应性 取代了 可预测性，为我们指明了方向。与其将复杂需求转化为复杂的设计文档，我们不如将复杂需求拆解为多个简单的需求。
只要给编码代理一个足够简单的问题，它就不会偏离轨道。我遵循一个简单的、受精益创业启发的方法，成功地构建了相当复杂的软件：
- 识别产品中下一个风险最高的假设。
- 设计最简单的实验来测试它。
- 开发这个实验。如果失败，就回到上一步；否则，从头开始重复。
我没有写任何规范，只是逐一添加小功能，当代理误解我或我自己的想法行不通时进行纠正。当实现简单想法的成本很低时，小步迭代是通向好产品的最快方式。
这种方法还没有一个正式的名字。我们可以称之为 自然语言开发 (Natural Language Development)。它让产品经理和开发者的协作变得空前紧密，我们可以直接把产品待办事项写出来，然后看着它被实时构建出来，不再需要任何模型或设计文档。
结论：我们真的需要复活规范文档吗？
敏捷方法早已宣告了规范文档的死亡。我们真的需要把它从坟墓里挖出来吗？
编码代理就像内燃机的发明。规范驱动开发想把它们限制在铁轨上跑的火车头，而我们应该用它们来制造汽车、飞机以及各种各样的东西。
SDD 似乎是那些梦想将开发者排除在外的计算机科学毕业生的想法。我认为这错失了一个巨大的机会：用编码代理来赋能新一代的开发者，让他们用自然语言进行迭代式开发。