文章探讨了规范驱动开发(SDD)的复兴，认为它虽为AI编程提供了结构，却可能牺牲敏捷性。作者指出，这种强调前期文档的瀑布式方法可能不适合现代开发，建议采用更迭代、自然的语言方式。开源社区通过分层文档引导AI编码的尝试，反映了传统与新兴开发模式的碰撞。

规范驱动开发：瀑布模型的复辟与反思

核心观点
规范驱动开发（SDD）通过详尽的Markdown文档指导AI编程，本质上是瀑布模型的现代翻版。虽然它为AI编程提供了结构化框架，但过度文档化可能扼杀敏捷性。

SDD的运作机制

1. 三层文档体系
   • 由LLM生成产品规范、实施计划和详细任务清单
   • 典型工具链：GitHub的Spec-Kit、AWS的Kiro等
2. 典型案例
   • 为时间追踪应用添加日期显示功能：产生8个文件/1300行文本
   • CRM系统添加"推荐人"字段：包含需求/设计/任务三份文档

七大实践缺陷

1. 上下文盲区：AI难以识别需要更新的现有函数
2. 文档泛滥：开发者60%时间消耗在阅读Markdown文件上
3. 官僚流程：三阶段设计流程对简单功能过度设计
4. 伪敏捷实践：滥用"用户故事"概念（如系统管理员视角的需求）
5. 双重审查：需同时审查规范中的伪代码和最终实现代码
6. 安全假象：AI可能标记未完成的测试任务为已完成
7. 收益递减：仅适用于新项目，对大型代码库效果锐减

根本性矛盾

SDD试图通过精密规划解决"如何让开发者退出软件开发"的错误命题，本质重复了瀑布模型的致命缺陷： - 违背软件开发的非确定性本质（参见《没有银弹》论文） - 实际使用者仍需兼具业务分析师和开发者的双重技能

替代方案：自然语言开发

作者提出基于精益创业方法论的三步迭代法： 1. 识别产品中最关键的风险假设 2. 设计最简单的验证实验 3. 开发验证（失败则退回第2步） 典型案例：使用Claude Code在10小时内构建的3D雕刻工具，全程零规范文档

行业启示

AI编程助手应当像内燃机发明那样开启新可能，而非被束缚在"文档火车头"的旧范式。视觉交互工具的缺失是目前自然语言开发的主要瓶颈。

（注：保留原文所有超链接和图片说明，压缩了重复的Markdown示例内容，突出核心论证逻辑）

评论总结

支持SDD（Spec-Driven Development）的观点

1. SDD与瀑布模型不同：SDD避免了瀑布模型的两个主要问题——多年开发周期和无法迭代。

   • "the problem with waterfall wasn't the detailed spec, it was... no (cheap) way to iterate" (评论1)
   • "specs are per feature, it’s just an up front discussion" (评论3)

2. SDD适合LLM开发：规范可作为LLM的上下文入口，帮助生成代码并保持敏捷迭代。

   • "spec-based development is one of the future methodologies for developing projects with LLMs" (评论4)
   • "LLM will be able to build sufficient initial context... now you are in agile again" (评论4)

3. 规范减少错误：明确的规范能减少AI代理的失误，提高开发效率。

   • "The agent makes less mistakes, it stays on the path" (评论7)
   • "I get 20x ROI on well defined, comprehensive, end to end acceptance tests" (评论23)

反对SDD的观点

1. 规范编写困难：编写规范比直接写代码更耗时且难以表达细节。

   • "I find writing specs much harder than writing code" (评论6)
   • "the many many hours—tweaking, asking, correcting... before getting to see any code challenging" (评论8)

2. SDD类似瀑布模型：后期规范复杂化会导致难以维护，与瀑布模型问题相同。

   • "SDD/Waterfall helps the LLM... but problems come when you are deep into the project" (评论15)
   • "The constant increasing of complexity... can not be managed by LLM or human" (评论15)

3. 规范灵活性不足：过度依赖规范可能限制迭代和用户反馈。

   • "the lack of iterative end-to-end feedback is foreign and frustrating" (评论8)
   • "A spec is never complete... any methodology that does not allow revision will cause trouble" (评论18)

中立或平衡观点

1. 规范与敏捷可结合：规范可以分阶段编写，与敏捷迭代共存。

   • "There’s nothing keeping you from scoping the spec to an agile package of work" (评论13)
   • "You can iterate. Requirements are a thing that grow with a project" (评论26)

2. 规范形式多样：规范不限于文档，Jira任务或研究笔记也可作为轻量级规范。

   • "A spec is not a prompt. It’s an actual definition of how to tell if something is behaving as intended" (评论23)
   • "Every team should be capturing requirements... just with incredibly vague specs in Jira tickets" (评论26)

3. 方法论需因地制宜：不同项目适合不同方法，无普适解决方案。

   • "If you have an example that worked for you it doesn’t mean that it’s useful for everyone" (评论28)
   • "I’m willing to believe there are scenarios where this makes sense" (评论22)

关键争议点

• 规范的价值：支持者认为规范能提高确定性（评论7、23），反对者认为其僵化且低效（评论6、15）。
• LLM的角色：部分人认为规范是LLM的必要输入（评论4、20），另一部分认为LLM应作为辅助工具而非流程核心（评论22、24）。
• 历史教训：支持者强调前期规划的重要性（评论2、27），反对者警告不要重蹈瀑布模型覆辙（评论15、18）。

总结：SDD的可行性取决于项目规模、团队习惯和工具支持，需平衡规范严谨性与迭代灵活性。