夜雨聆风在 Harness 时代，AI Coding 需要讲方法论。和 Harness 工程适配的、比较火的 开发方式有 TDD和SDD，也就是测试驱动开发和规范驱动开发。
这两种方法论经常被拿来做对比，好像非要选一个不可。但深入了解之后就会发现，这俩不在一个层级上，不是竞态的。
Vibe Coding的失败
2025年下半年到2026年，AI Coding 工具爆发。Claude Code、Cursor、Codex，这些工具已经深度嵌入了开发者的日常工作流。光Claude Code一个工具就贡献了GitHub上大约4%的新代码，预计到2026年底这个数字会达到20%。
但工具厉害不代表产出就靠谱。
一个叫"Vibe Coding"的概念开始流行起来，中文是“氛围编程”，就是用随意的自然语言提示驱动AI生成代码。
小项目里看起来挺酷，几分钟就能出一个原型。但一旦到了生产环境，全tm是问题，随手就能举出几个：代码偏离意图、幻觉、技术债快速累积。
Vibe Coding的本质是把"想清楚要做什么"这一步跳过了，直接让AI自由发挥。
这不是愚蠢吗？哪个正经的工程师会这样乱搞？
我之前也写了篇文章去抨击 Vibe Coding，我说实话 Vibe Coding 太sb了。
在Vibe Coding大面积翻车之后，社区开始认真思考一个问题：怎么让AI编程变得可控？
TDD和SDD是答案之一。
TDD
TDD 在1999年就被提出来了。它的核心是这样一个循环：
写一个会失败的测试，写最少的代码让测试通过，然后重构。Red-Green-Refactor。
在AI编程场景下，TDD的流程有了一点变化。你先写好测试用例，把测试交给AI，让AI生成代码来通过这些测试。如果没通过，AI自动迭代修复。Fusion Collective的研究团队拿Claude Code、Cursor、Codex和GitHub Copilot做了一次横向评测，统一走TDD流程，得出了以下结论：
"TDD在指向AI编码工具时做了一件有用的事：它迫使工具在写代码之前先对'完成'做出承诺。测试就是契约，代码要么通过要么不通过，AI没法用花言巧语蒙混过关。"
测试通过了就是通过了，没通过就是没通过，没有什么“基本通过了”，结果是二元的，这就是TDD的好处。
但是呢，TDD有个问题：它不告诉你该构建什么。
Planu.dev的分析可谓一针见血啊，TDD的前提是你已经有了清晰的需求，功能是什么、输入输出是什么、边界怎么处理、跟其他模块怎么交互。问题是，"想清楚要什么"这件事本身就是软件开发中最难的部分之一。
你可能写了一个完美的测试，但测试的是错误的行为，AI也可能"取巧"通过测试，代码恰好满足测试用例，不过整体设计一塌糊涂。而且每次只关注一个测试，容易丢失全局上下文。
这就是 TDD 的缺陷了。
SDD
SDD是2025年新兴的方法论，它的核心是：规范是软件开发的唯一事实来源。
SDD的工作流分四步。先用自然语言详细描述系统应该做什么，包括用户旅程、体验、成功标准。然后基于规格生成技术架构和实现计划。接着把计划拆分成可执行的原子任务。最后AI根据任务列表逐一生成代码。每个阶段都有人工审核的检查点，确保意图跟实现对齐。
Martin Fowler在2025年10月的一篇分析中，把SDD分成了三个递进的层次。
最基础的是Spec-First，先写规格再用AI辅助开发，这是所有SDD工具的基线。往上是Spec-Anchored，任务完成后保留规格用于后续演化和维护。最高层是Spec-as-Source，规格是主要的源文件，人类只编辑规格不碰代码。目前主流工具基本做到了Spec-First，部分做到了Spec-Anchored，而Spec-as-Source还是个愿景。
毕竟对于一个正经的企业项目来说，现在的 AI 完全做不到人类不用碰代码的程度。
给定一段代码，TDD回答的是"这段代码做对了吗"，SDD回答的是"我们正在构建正确的东西吗"。
有了规格之后，AI就有了明确的验收标准、必须遵守的架构约束，以及人和AI都能验证的"完成定义"。
这也是 Harness Engineering 的一部分。
当然SDD也不是一全其美的,对已有项目来说适配起来比较难，全新项目效果相对好些。
Martin Fowler 批评 GitHub Spec Kit 会为每个规格生成8个以上的Markdown文件，称其"重复、冗长且审核起来令人厌倦"。他还指出，Agent经常无视规格中的指令，这是一个很现实的问题。
男女搭配，干活不累
我在网上冲浪的时候，看到有些网友发表 “比起TDD，我更喜欢SDD”之类的言论。此类言论将TDD 和 SDD做比较，就好像是道单选题一样，只能选一个。
实际不然，TDD和SDD是非竞态的，你可以一起用，打出组合技。
从上图可以看出，TDD负责单元级别的正确性，SDD负责全局方向，这俩完全可以搭配干活的。
比如SDD 在上、TDD 在下，先用SDD定义全局规格和架构，搞清楚要构建什么。然后把规格拆成具体的实现任务，在每个任务级别用TDD保障局部正确性。
不过搭配起来有个问题，就是 Token和时间的花费加倍的更多，如果AI做小修改也完全按照 TDD + SDD 来实现的话，就没必要了。
另外规范文档不是一尘不变的，项目做到后边，一般规范文档也会跟着更新，维护好你项目的规范文档。
相关事件
Google Cloud Next 2026专门开了"From Vibe Coding to Rigor"的主题演讲，讲的就是SDD在大规模AI编程中的实践。Spring I/O 2026上Simon Martinelli讲了"Spec-driven Development: How AI Changed Everything (And Nothing)"。
arXiv在2026年2月发表了《Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants》，为SDD提供了学术基础。
GitHub官方开源了Spec Kit，声明"我们开源它是因为这种方式比任何一个工具或公司都更大"。IBM、Red Hat、Jama Software等企业级厂商也纷纷发布了SDD指南和解决方案。
GitHub Spec Kit已经是9万+ star的项目，支持Copilot、Claude Code、Gemini CLI。OpenSpec在六个月内增长了863%，是增长最快的SDD框架。AWS推出了Kiro集成在VS Code里，强调结构化需求捕获。
这些事件表明一个趋势，就是SDD成为行业主流。
写在最后
不要对号入座。
实际工作中别教条，bug修复、快速验证这些，直接上TDD修就行的，没必要为了方法论而方法论。如果你开始做一个有一定规模的新功能、新模块时，才值得花时间先写规格再动手。很多公司的代码规范和流程已经固定了，不可能因为你读了这篇文章就推倒重来。
你可以在自己的新项目里试试"SDD在上、TDD在下"的工作流，感受一下跟"边写边想"的区别。
如果你觉得这篇文章有帮助，点赞关注，点点赞~
