AI提速写代码，质量怎么托底？RedGreen TDD给你方案

你有没有遇到过这样的时刻：让AI把某个功能“写出来”，跑起来看似正常，表面也很像那么回事。可等过了三天，某个边界场景突然爆雷，你回头翻代码，才发现AI在某个分支里埋下了「表面通顺、实际有误」的判断。

AI编程最容易让人踩坑的点，并不是它不会写代码，而是写出来的东西太像正确答案——以至于你几乎不再逐行核对。

Django框架的创始人Simon Willison在一次分享里给出了思路：Red/Green TDD。这个办法早在20年前就出现了，但放到AI编程的环境下，它的重要性反而被显著放大。

TDD（Test-Driven Development，测试驱动开发）的整体流程可以概括为三步：

Red —— 先写一个必定失败的测试

在动手实现之前，先准备一个测试用例。这个测试用来描述“代码该做什么”，但由于功能还没写出来，它当然会失败，这就是“Red”。

Green —— 用最少的实现让测试变绿

接着，只写刚好能让该测试通过的代码。不要想太多，也别提前做优化。唯一目标就是：把红灯变成绿灯。

Refactor —— 重构，让代码更清爽

测试通过了，功能大体就对了，但代码可能依然显得别扭。这时就做重构：整理结构、清理重复、提升可读性——而且因为测试仍在，你才能放心去改。

每完成一轮就进入下一轮：写测试→写代码→重构→再写测试→再写代码→再重构……一个功能对应一次小循环。

Simon Willison还提出了一个很难反驳的判断：

AI生成的代码，你根本没法逐行去审。

这不是你不够专业，而是时间不够。AI一秒钟能吐出200行，你逐行检查可能要花20分钟。如果你让它一天生成10个功能，你就不可能逐个认真核对。

但测试不一样。测试是你写的（或至少你审核过的），它反映的是你对需求和边界的理解。只要关键场景覆盖得足够，AI写的代码过不了测试就是错，能过也至少不会太糟。

因此，TDD把质量保障从“人力逐段审查代码”转移成了“用机器验证行为”。在AI辅助编程的语境里，这几乎是唯一能规模化落地的路径。

如果想把Red/Green TDD带进AI编程，可以按下面这套流程来做：

Step 1：先写测试（Red）

不要把这个步骤交给AI。测试本质上是在表达你的需求理解和边界条件判断。举个简单例子：

Step 2：让AI写代码（Green）

把测试丢给AI：“实现calculate_discount函数，让下列测试全部通过”。只要输出的代码能跑通测试即可，不必追求一次就完美。

Step 3：你再审核并做重构（Refactor）

代码能运行了，但逻辑是否清楚、命名是否合理、性能有没有隐患？这时你的身份从“写代码的人”转为“审代码的人”——这种角色转换本身就是一种质量提升。

Willison提出的Egotic Engineering理念也很有意思：未来不是被AI替代的那群工程师，而是把AI当工具来放大自己能力的那群人。

关键的思维转向在于：

这不是在偷懒，而是把精力从“具体实现细节”里挪出来，去更专注地做设计决策与质量把控。

Red/Green TDD并不是全新的概念，但在AI时代，它恰好站在了最合适的位置。

如果你现在正在用AI辅助编程，不妨做个小实验：下一次让AI写功能之前，先花5分钟写出3个测试用例。你会发现——

并不是AI写出来的代码立刻变得更强了，而是你对“好代码”的衡量标准，终于有了可验证的尺度。