AI 疯狂写代码，TDD 还要硬上吗？老派软件工程才是护城河

AI 疯狂写代码，TDD 还要硬上吗？老派软件工程才是护城河

AI 写代码越来越快，快到你开始怀疑自己的手艺还有没有用。现在流行一种模式：写份需求规范丢给 AI 生成代码，出了 Bug 也不看代码，只改规范让 AI 重来。很多人高呼：代码很廉价，基础能力过时了。

但 Matt Pocock 在 AI 工程师峰会上抛出反直觉结论：AI 时代，软件基础知识反而比任何时候都重要。社区却吵成一团——Matt 提倡用 TDD 约束 AI，Bob 大叔很少亲自跑严格 TDD，还有人吐槽 token 疯狂消耗。怎么取舍？聊聊我的理解。

1 「规范转代码」是陷阱：坏代码才是最贵的资产

「spec-to-code（规范转代码）」听起来很美：人只维护业务规范，AI 负责产出全部代码。但 Matt 实践后发现：反复调用 AI 迭代，代码质量持续滑坡，最后产出一堆无法维护的乱码。本质上，这只是换了外壳的氛围编程（Vibe Coding）——放弃人对代码的把控。

坏代码的成本，比以往任何时代都更昂贵。AI 是放大器：在架构清晰的代码库里它是效率神器；面对烂代码库，它只会加速堆积技术债务。系统架构、模块划分、接口设计必须由人类扛起来。

规范转代码循环：只改规范不看代码，代码质量持续滑坡

2 AI 编码的四大典型故障，解法都在经典软件工程里

故障 1：AI 产出和你想的不一样。 根源是缺少统一的设计概念。解法是「拷问我」式提问：让 AI 针对方案不停追问，直到达成认知共识，先对齐设计共识，再写代码。

故障 2：AI 输出啰嗦、术语错位。 解法借鉴 DDD 建立通用语言 扫描代码库提取业务术语，生成术语对照表，全程统一。 故障 3：逻辑看着没问题，代码却跑不起来。 大模型习惯一次生成大段代码再校验，不擅长用好反馈。解法是 TDD 强制 AI 小步迭代，先写测试，再实现，后重构——但争议也从此开始。

故障 4：AI 疯狂产出代码，开发者脑力过载。 解法是人设计接口，内部实现委托给 AI——把模块当灰盒。关键是深度模块 少量大模块，接口极简。TDD 发挥价值的基础就是深度模块化的代码库；烂架构下强行 TDD，只会加倍灾难。

AI 编码四大故障与解法：设计共识、通用语言、TDD、深度模块

3 TDD 大辩论：Matt 提倡，Bob 却不硬上，听谁的？

很多人误解 Bob 大叔全盘否定 TDD。他的核心立场：TDD 是可选纪律，不是银弹，不能替代架构设计；GUI、原型探索类代码收益很低；坏 TDD 危害巨大，根源是模块没做好接口隔离。他现在不亲自跑完整 TDD 循环，但极度重视自动化校验——不读 AI 生成的内部代码，却设严苛质量约束。

Matt 与 Bob 底层高度一致：好的模块、接口、架构是一切的前提，测试建立在好架构之上。为什么反对 AI 全自动跑 TDD？TDD 本是人类的认知拐杖，大模型没有这个短板；全自动闭环 token 消耗暴涨 3-8 倍；AI 还容易写出绑定内部实现的测试，改一点逻辑整套失效。

社区分化出三种模式：Agent 全自动 TDD（纯业务深度模块）、人写测试，AI 实现（核心业务模块，最优折中）、测试后置/裁判模式（UI、原型、胶水代码、旧项目）。

社区三种模式：全自动 TDD、人写测试 AI 实现、测试后置

4 写给开发者：AI 时代的人机协同观

1. 抛弃教条。深度模块完备可以试 AI TDD；UI、原型、老旧混乱代码库，优先后置测试。
2. 你的核心价值已转移AI 能搞定语法、样板代码、具体实现；但需求共识、术语、模块划分、接口设计、系统架构，依然是人的护城河。AI 是战术执行的前线士官，而你必须做战略决策的人。

代码可以交给 AI，架构契约设计要握在自己手里

5 结尾

AI 大大降低了写代码的门槛，但写出可维护高质量代码的门槛反而更高。不懂基础，你只会被 AI 带着跑；吃透基本功，你才能驾驭 AI。代码可以交给 AI 生成，但架构、契约、设计要握在自己手里。

你在日常使用 AI 编码时，会用 TDD 吗？欢迎评论区聊聊。