AI时代,你还需要软件工程设计方法论吗?

从 TDD 到 CDD：软件工程 30 年，本质就是四个字

正在大量使用 AI 写代码的你，有没有遇到过这样的问题：AI 生成的代码，看起来都对，但经不起追问。为什么要这样设计？边界条件覆盖了吗？异常路径谁验证过？同一个 prompt 跑三次，得到三种完全不同的实现。

这个问题困扰了我很久。后来我把软件工程 30 年的方法论串起来看了一遍——TDD、ATDD、BDD、DDD、MDD、FDD，再到 AI 时代刚冒出来的 SDD、CDD——发现这些看似各不相关的东西，其实都在解决同一件事。四个字：对抗熵增。

而在 AI 时代，这件事不但没有过时，反而变得前所未有地紧迫。

· · ·

一、软件工程 30 年，方法论的本质是”接力赛”

先来快速过一遍软件工程历史上那些重要的方法论。有一个规律贯穿始终：每一个新方法论的出现，都是在回应前一个方法论的”盲区”。

TDD（测试驱动开发）

1990 年代末，Kent Beck 在极限编程（XP）的实践中系统化了 TDD。它的核心流程大家都很熟悉：Red → Green → Refactor。先写一个会失败的测试，再写刚好让测试通过的代码，然后重构。

TDD 出现的背景是什么？代码没有安全网。 在那个年代，改一行代码可能引发连锁崩溃，而你没有自动化手段来验证。TDD 的核心贡献不是”先写测试”这个动作本身，而是把”正确性”从一个主观判断变成了一个可自动验证的客观事实。

ATDD（验收测试驱动开发）

TDD 解决了一个问题，但很快暴露了另一个：你写的测试，真的是用户想要的吗？开发人员写的单元测试，天然倾向于验证”我实现的对不对”，而不是”用户需不需要这个功能”。

ATDD 的回应是：在写代码之前，先定义验收标准。 这个标准由业务方、QA、开发三方共同确认，写成一个可执行的验收测试。代码写完，验收测试通过，才算”真的做完了”。

BDD（行为驱动开发）

2003 年，Dan North 提出 BDD。他发现 ATDD 的验收测试虽然好，但写出来的测试用例业务人员还是看不懂——全是技术术语。

BDD 的核心创新是用自然语言描述行为：”Given-When-Then”。它把测试从”验证代码”升级为”描述系统行为”——让业务人员也能参与进来，确保所有人对”什么是正确”有一致的理解。

DDD（领域驱动设计）

2003 年，Eric Evans 出版了那本著名的蓝皮书。DDD 解决的问题又升了一层：当业务足够复杂时，最大的熵不在代码层面，而在”语言”层面。

业务专家说”客户”，产品经理说”用户”，开发说”User 表”——同一个概念在不同角色脑中是不同的东西。DDD 提出”统一语言（Ubiquitous Language）”，要求团队用同一套术语建模业务领域。代码的结构必须与业务的结构同构。

MDD（模型驱动开发）与 FDD（特征驱动开发）

MDD 试图更进一步：如果能用模型精确描述系统，为什么还要手写代码？——用模型直接生成代码。FDD 则从另一个角度切入：把开发拆成一个个”特征”（Feature），每个特征在两周内端到端交付。

· · ·

▲ 软件工程方法论演进时间线：每一步都在回应前一步的”盲区”

所有这些方法论，表面上在解决不同的问题，但把镜头拉远，它们在做一个共同的事：把”正确”从一个模糊的感觉，变成一个可以被验证、被追溯、被传递的客观存在。

TDD 把正确性变成测试用例。ATDD 把测试用例对齐到验收标准。BDD 把验收标准翻译成自然语言。DDD 把自然语言建模为领域模型。每一步，都在降低系统的”熵”。

· · ·

二、所有方法论，其实都在对抗同一件事：系统熵增

热力学第二定律说：一个孤立系统的熵（混乱度）永远只会增加，不会减少。

软件工程有一个完全对应的规律：任何软件系统，在没有外部约束的情况下，必然走向混乱。

你不需要任何”坏”的决策就能见证这个过程。三个开发者各自理解稍有偏差，两周后代码就开始分叉。一个需求改了五次，设计文档就跟不上代码了。半年不重构，模块边界就模糊了。这就是软件的”熵增”——它不是谁的错，它是系统演化的必然方向。

前辈们总结的每一个方法论，本质上都是一套”对抗熵增”的约束机制：

·TDD 约束的是”实现偏离意图”的熵

·ATDD 约束的是”开发偏离需求”的熵

·BDD 约束的是”理解偏离共识”的熵

·DDD 约束的是”代码偏离业务”的熵

·MDD 约束的是”实现偏离设计”的熵

·FDD 约束的是”交付偏离计划”的熵

方法论的目的从来不是”规范流程”——那是表面。真正的目的是在系统演化的每一个环节，注入”确定性锚点”，对抗必然发生的熵增。

这个认知，在我开始大量使用 AI 写代码之后，变得前所未有的清晰。

▲ 有约束 vs 无约束的系统熵增曲线：方法论就是那条”约束力”

· · ·

三、AI 来了：概率性输出，是新的”熵源”

AI 写代码的本质是一个概率模型在给定上下文后，预测”最可能的下一个 token”。

AI 的每一次输出，都是概率采样。 同一个 prompt，跑三次，得到三种实现。每一次都是”看起来对”的——但”看起来对”和”经得起推敲”之间，有一道巨大的鸿沟。

有一组数据很说明问题：Qodo 发布的《2025 AI 代码质量报告》显示，开发者对 AI 生成代码的信任度只有 29-46%。Google DORA 2025 的报告指出，AI 虽然提升了代码产出速度，但并没有同步提升代码质量。

Martin Fowler 最近也发出警告：AI 自主生成代码的能力越强，”越改越坏”（Verschlimmbesserung）的风险越大——AI 可能在你不知情的情况下，把一个本来能用的系统改到不可维护。

AI 不是救世主。它带来的不确定性本身，就是一种新的”熵源”。

传统的熵增来自”人理解不一致””需求变更””设计腐化”——这些都是人类可控的，至少是可预期的。AI 引入的是一种全新的熵：概率性熵。 它不可复现、边界模糊、难以审计。

你让 AI 写一个函数，它能写。但你不知道它为什么选择了这个实现而不是另一个。你不知道它是否考虑了那个你忘了在 prompt 里提到的边界条件。你不知道这段代码跟项目的其他部分是否风格一致、抽象一致、假设一致。

而且，AI 不会说”我不确定”。它会给你一个信心满满的答案——即使那个答案是错的。

这就回到了方法论。

· · ·

四、VSDD / SDD / CDD：AI 时代的方法论新物种

新的方法论已经在涌现。它们的名字你可能还没听过，但思路跟前辈们一脉相承：用”确定性锚点”对抗”概率性熵”。

SDD（规范驱动开发）

Spec-Driven Development 是 2025-2026 年 AI 工程化领域最重要的趋势之一。核心思想很简单：规范（Spec）取代代码，成为最重要的人工产出。

在 SDD 的工作流中，你不再直接写代码，而是写一份精确的 Spec——描述系统应该做什么、不应该做什么、边界条件是什么、验收标准是什么。然后 AI 基于这份 Spec 生成代码，测试框架基于这份 Spec 自动验证。

关键区别在于：传统的设计文档是”咨询性”的——开发者读一读，然后凭感觉写代码，文档很快过时。SDD 的规范是”强制执行”的——代码偏离规范，测试就失败，构建就过不了。

Andrej Karpathy 给 Vibe Coding（让 AI 自由发挥）划的使用边界是”用于不重要的代码”。SDD 要解决的就是”重要的代码”——那些需要可维护、可审计、可追溯的生产系统。

VSDD（已验证的规范驱动开发）

VSDD 在 SDD 的基础上加了一层：规范本身也需要被验证。

你写的 Spec 真的是对的吗？它覆盖了所有边界条件吗？它跟已有的系统行为一致吗？VSDD 引入了一个关键环节：Eval 驱动。 用一套确定性的测试集作为”裁判”，持续验证 AI 的每一次输出是否向主线收敛。

这让我想起 Kent Beck 最近对 AI 时代 TDD 的重新定义：“TDD 是你和 AI Agent 协作的超能力。AI 是精灵，测试是契约。”

CDD（契约驱动开发）

CDD 是我认为最具前瞻性的方向。它的核心洞察是：在不同的领域，”正确的规范”长得完全不一样。

对于 API 开发，”正确的规范”是 OpenAPI 合约——输入是什么、输出是什么、错误码是什么。对于数据管道，”正确的规范”是 Schema——字段类型、约束条件、数据血缘。对于前端组件，”正确的规范”是 Storybook 场景——每个状态下的渲染结果。

CDD 的思路是：不要把方法论绑定在一种规范格式上。而是定义一个更抽象的”契约”概念，由 AI 根据领域特性，选择最合适的表达方式。

这其实就是 DDD 的”统一语言”思想在 AI 时代的自然延伸——只不过这次的”语言”，AI 也能听懂。

· · ·

五、信任边界：AI 还是 API？代价与博弈

说到这里，你可能会问：既然 AI 输出有概率性，那为什么还要用 AI？直接用确定性的 API 不好吗？

好问题。这涉及到 AI 时代一个关键的架构决策：效率与信任如何Trade-Off

AI 的优势：理解自然语言

AI 的核心优势不是”写代码快”，而是理解意图。 传统的 API 调用需要你把需求翻译成精确的参数和调用序列。AI 可以接受模糊的自然语言描述，帮你完成这个翻译过程。

这带来的效率提升是真实的。一个需要对接三个 API、写 200 行胶水代码的任务，AI 可能用一段自然语言描述就完成了。

代价是什么？

代价是确定性的丧失。 你用确定性 API，输入 A 永远得到输出 B。你用 AI，输入 A 可能得到 B、C 或 D——它们看起来都像正确答案。

还有两个更实际的代价：

·Token 成本。 复杂任务的多轮对话，token 消耗可能远超你的预期。尤其是在需要 AI 做大量上下文推理的场景下，成本曲线是指数级的。

·审核责任。 当 AI 生成的代码出了生产事故，谁来负责？你不能把 AI 拉到 on-call 群里复盘。最终背锅的还是人。

务实的分层策略

我的实践建议是：

·确定性路径（API 调用） 用于已经形成共识的、边界清晰的逻辑。比如：支付、认证、数据校验。这些地方不需要”创造力”，需要”零出错”。

·概率性路径（AI 调用） 用于需要理解、翻译、生成的环节。比如：自然语言查询转 SQL、代码审查建议、文档生成。但前提是——AI 的输出必须经过确定性验证。

这就是方法论发挥作用的地方：在 AI 的输出和系统的核心逻辑之间，永远隔着一层”验证层”。 这层验证层，就是 TDD 的测试用例、BDD 的验收场景、SDD 的可执行规范。

▲ 人/AI/方法论责任边界：AI 做枚举，人做终审，方法论做校验

· · ·

六、AI 落地的最后一公里：审核谁负责？

所有方法论都绕不过一个终极问题：最终审核权在谁手里？

我的答案是明确的：人类。永远是人类。

这不是因为 AI 不够强。恰恰相反，AI 越强，越需要人类做终审。原因很简单：AI 没有”责任”的概念。它不会因为一个 bug 半夜被叫起来，不会因为一个设计决策在三个月后付出重构的代价，不会因为一个安全漏洞背上心理负担。

AI 可以承担”枚举与试错”——生成 10 种方案、跑 100 个测试、探索 1000 种边界条件。但”定规则”和”做终审”，必须是人类的职责。

这不是技术判断，是工程伦理。

· · ·

写在最后

这篇文章想说的，总结起来就三句话：

一、在 AI 时代，方法论的价值重新回归到软件工程的终极本质——管理”熵增”。人类负责定义”正确”（What & Why），AI 负责实现”正确”（How）；方法论则是连接两者的”翻译器”和”校验锁”。

二、AI 时代，工程师的职责从”生产代码”变成了”生产确定性”。而前辈们通过无数屎山代码和生产事故总结出来的方法论约束，就是驾驭新时代猛兽的缰绳。

三、人类定规则与终审，AI 做枚举与试错；用确定性测试集作为”裁判”，驱动 AI 的每一次输出都向主线收敛。

下次你打开 AI 编程助手的时候，不妨先花 10 分钟写一份 Spec。不是给 AI 看的——是给你自己看的。它会逼你想清楚：你到底想要什么。

而这，可能就是这个时代工程师最重要的能力。

· · ·

感谢阅读

如果这篇文章对你有帮助，欢迎点赞、在看、转发，这是对我最大的支持。

有问题或不同意见？评论区聊聊，每条我都会认真看。

· · ·

我是土豆，一个探索 AI 落地的最后一公里的后端程序员。

不写新闻、不写入门教程、不贩卖焦虑。

只写自己踩过的坑、想明白的事，用大白话讲给你听。