推了多年都没人坚持的 TDD，AI 时代突然成了刚需

测试驱动开发，TDD，九十年代就有了。核心思路很简单：先写测试，再写代码。

逻辑上完美，几乎找不到反对的理由。

但凡干过几年的都知道，这东西在团队里，基本推不动。

为什么推不动

不是不懂，是做不到。

我之前在团队里推过好几次 TDD。每次剧情几乎一样：项目初期认认真真写了一批测试用例，过两三个月，需求一紧，测试就没人碰了。

不是谁偷懒，而是这件事有三个绕不过去的坎。

第一，维护成本太高。写测试不难，难的是业务一变，测试也要跟着改。改需求已经够累了，还得改一遍测试，没几个人愿意。

第二，没有这个习惯。大多数工程师是在“先写代码，跑通再说”的环境里成长的。让他先写一个还不存在的功能的测试，反直觉。

第三，也是最致命的——只要团队里有一个人不遵守，测试就会逐渐失效。

一个人跳过了测试直接提交，第二个人一看，反正已经有漏洞了，也跳过。三个月后，测试套件变成了摆设。

这不是技术问题，是人性问题。

AI 写代码，重构是常态

聊完 TDD 的旧账，说一件正在发生的事。

现在越来越多的场景，代码是 AI 写的。AI 写代码有一个特点：第一版通常能跑，但结构几乎一定要改。

举个例子。之前让 AI 写一个业务规则判断的模块，一堆 if-else 从上到下顺着写，逻辑是对的，跑起来也没问题。但规则越加越多，改一个条件其他的跟着串，最后不得不重构成责任链模式。

重构完怎么确认没改出 bug？靠的是重构前补的那一批测试用例。跑一遍全绿，心里才踏实。

这不是个例。还有一个更隐蔽的问题——AI 写的代码，有时候看着逻辑完整，跑起来也没报错，但细节是错的。它会一本正经地写出有细微漏洞的逻辑，肉眼很难看出来。

测试不只是重构的安全网，也是 AI 幻觉的解毒剂。 AI 写代码越多，重构越频繁，幻觉风险越高。没有测试兜底，迟早翻车。

TDD 的障碍，AI 刚好能解

回头看 TDD 推不动的那三个原因，放到 AI 写代码的场景下，全变了。

维护成本高？ AI 不怕重复劳动。需求变了，让它把测试用例一起更新，不会嫌烦。以前最痛苦的“改完代码还要改测试”，现在是顺手就做的事。

没有习惯？ 项目规范里写一条“先写测试再写实现”，AI 就照做。不存在“下次再补”。

一个人不遵守就崩？ 这才是关键。AI 不是“一个人”——你定好规则，它每次都按规则来。没有侥幸心理，没有偷懒的动机。

TDD 推不动，本质上是人的问题。AI 恰恰没有人的问题。

不写代码，更需要安全网

说到底，不是 TDD 这个理念多先进。是 AI 写代码这件事，天然地把重构变成了高频操作。

以前人写代码，改了哪里、影响了什么，心里大致有数。现在代码是 AI 写的，你自己不写了。不写代码会带来两个问题：一是对代码细节的感知在变弱，AI 改了三个文件十几个函数，你未必清楚每一行改了什么；二是人都有懒惰性，不是自己写的代码，review 的意愿也在下降。

写代码的是 AI，但为代码负责的还是你。 你对代码越陌生，越懒得细看，就越需要一张更强的安全网。

测试就是那张网。跑一遍全绿，才敢说这次改动没问题。

TDD 不是回来了，是你不写代码了，却依然要为代码的正确性兜底。测试是唯一靠得住的方式。

AI 时代的代码质量，不靠写得多好，靠改得多稳。关注我，接着聊 AI 工程实践。