AI编码框架TDD与SDD实战对比推荐
在 Harness 时代，AI 编码必须有一套系统化方法论。与 Harness 工程体系适配的两种主流开发方式分别是 TDD（测试驱动开发）和 SDD（规范驱动开发），两者在社区中热度极高。
经常有人把这两种方法论放在天平两端对比，似乎非要二选一。但深入剖析后会发现，它们根本不在同一抽象层级，不存在竞争关系。
Vibe Coding 为何崩塌
2025 年下半年至 2026 年，AI 编码工具迎来井喷式增长。Claude Code、Cursor、Codex 已深度融入开发者日常流程。仅 Claude Code 一个工具就贡献了 GitHub 上约 4% 的新代码，预计到 2026 年底这一比例将攀升至 20%。
然而，工具强大并不等于产出可靠。
“Vibe Coding”概念随之走红，中文译作“氛围编程”——核心是用随意的自然语言提示驱动 AI 生成代码。
在小型试验项目中，Vibe Coding 看似高效：几分钟就能跑通一个原型。可一旦进入生产环境，问题全面暴露：代码偏离原始意图、产生幻觉、技术债务迅速堆积。Vibe Coding 的本质是跳过了“想清楚要做什么”这一关键环节，任由 AI 自由发挥。说穿了，这根本算不上严谨的工程实践。
当 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 的优势所在。
但 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 并非完美无缺。对已有存量项目适配较难，全新项目效果明显更优。
组合使用而非非此即彼
网上常有人宣称“比起 TDD，我更喜欢 SDD”。这类观点将 TDD 与 SDD 视为一道单选题，仿佛只能择一而从。实际情况并非如此——TDD 与 SDD 是非竞态关系，完全能够协同配合，打出组合拳。
如上图所示，TDD 负责单元级别的正确性，SDD 负责全局方向与架构，两者完全可以分工协作。具体可实践 SDD 在上、TDD 在下：先用 SDD 定义全局规格与架构，明确要构建什么；然后将规格拆解为具体实现任务，在每个任务级别用 TDD 保障局部正确性。
但组合使用会带来 Token 消耗和开发时间的明显增加。如果 AI 仅做小范围修改，也硬套 TDD + SDD 流程，反而得不偿失。此外，规范文档并非一成不变——项目推进到后期，规范通常需要同步更新，维护好项目规范文档至关重要。
行业趋势信号
近期一系列事件表明一个明确趋势：SDD 正走向行业主流。
实操建议
实际工作中切忌教条。Bug 修复、快速验证等场景，直接上 TDD 就够了，没必要为了方法论而方法论。只有当你开始开发一个有一定规模的新功能或新模块时，才值得花时间先写规格再动手。许多公司的代码规范和流程已经固化，不可能因为你读了一篇文章就推倒重来。
你完全可以在自己的新项目里试试“SDD 在上、TDD 在下”的工作流，亲身体验一下它跟“边写边想”的区别。