AI Is Writing Code at Lightning Speed—Should We Still Enforce TDD? Classic Software Engineering Remains the Moat

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

Spec‑to‑code looks attractive: humans maintain only business specifications while AI generates all code. Repeated AI iterations cause code quality to degrade into unreadable, unmaintainable code, essentially “vibe coding” that abandons human control. In a clean architecture AI can boost productivity, but in a messy codebase it amplifies technical debt. Therefore system architecture, module boundaries, and interface design must remain human responsibilities.

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

故障 1 ：AI 产出与预期不符。根源是缺少统一的设计概念。解决方案是“拷问”式提问：让 AI 反复解释方案，直至达成设计共识后再编写代码。

故障 2 ：输出冗长、术语错位。借鉴领域驱动设计（DDD）建立通用语言：扫描代码库提取业务术语，生成术语对照表并在整个生成过程中保持一致。

故障 3 ：逻辑看似正确但代码无法运行。大模型倾向一次生成大量代码后再校验，缺乏反馈循环。采用测试驱动开发（TDD）强制 AI 小步迭代：先写失败测试，最小实现代码使其通过，再重构。

故障 4 ：AI 产出代码量过大导致开发者认知负荷。解决方案是人类设计简洁接口，内部实现交给 AI，将模块视为灰盒。关键是深度模块化、少量大模块、极简接口。

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

Bob认为 TDD 是可选的纪律，而非万能解决方案，不能替代架构设计。对 GUI、原型探索类代码收益低，糟糕的 TDD 可能因模块缺乏接口隔离而危害巨大。他不亲自执行完整的 TDD 循环，但强调自动化质量约束，避免直接读取 AI 生成的内部实现。

Matt 与 Bob 在根本上认同：良好的模块、接口、架构是前提，测试建立在此之上。全自动 AI‑驱动 TDD 会导致 token 消耗暴涨 3‑8 倍，并产生紧耦合内部实现的测试，稍微改动业务逻辑就会导致整套测试失效。

社区形成三种协作模式：

Agent 全自动 TDD ：适用于纯业务深度模块。

人写测试，AI 实现 ：核心业务模块的折中方案。

测试后置/裁判模式 ：用于 UI、原型、胶水代码和旧项目。

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

抛弃教条 ：在深度模块化的代码库中可以尝试 AI‑驱动 TDD；对 UI、原型或混乱的旧代码库优先采用后置测试。

核心价值转移 ：AI 能处理语法、样板代码和具体实现，但需求共识、术语、模块划分、接口设计、系统架构仍是人的护城河。AI 充当战术执行者，战略决策仍需人类把握。

5 结尾

AI 大幅降低了写代码的门槛，却提升了产出可维护高质量代码的门槛。缺乏基础会被 AI 带着跑，掌握基本功才能驾驭 AI。代码可以交给 AI 生成，但架构、契约、设计必须由开发者掌控。

Code example

AI