AI写代码越来越快,但质量谁来兜底?Red/Green TDD是你的答案

你有没有遇到过这种情况：让AI写了一个功能，跑起来没问题，看起来也像回事。但三天后，一个边缘case炸了，你翻回去看代码，才发现AI在某个分支里埋了一个「看起来对但其实错」的逻辑。

AI编程最大的陷阱不是它不会写代码，而是它写的代码太像对的——以至于你根本不会逐行检查。

Django框架创始人Simon Willison在最近的一个分享中给出了解法：Red/Green TDD。这个方法诞生于20年前，但在AI编程时代，它变得前所未有的重要。

Red/Green TDD 是什么？

TDD（Test-Driven Development，测试驱动开发）的核心流程只有三步：

Red —— 先写一个会失败的测试

在写任何实现代码之前，先写一个测试用例。这个测试描述了「代码应该做什么」，但因为功能还没实现，它必然失败——这就是「Red」。

Green —— 写最少的代码让测试通过

然后，写刚好够用的代码让这个测试通过。不要多想，不要提前优化，目标只有一个：把红灯变绿灯。

Refactor —— 重构，让代码干净

测试通过了，功能是对的。但代码可能写得丑。这时候重构，优化结构、消除重复、提升可读性——测试还在，你敢改。

三步走完一个循环，再开下一个。写测试→写代码→重构→写测试→写代码→重构……每一个功能都是一次小循环。

为什么AI时代TDD变得不可或缺？

Simon Willison提出了一个让人无法反驳的观点：

AI写的代码，你没有能力逐行审查。

这不是能力问题，是时间问题。AI一秒生成200行，你逐行审查要20分钟。如果你一天让AI生成10个功能，你根本没有时间逐个检查。

但测试不一样。测试是你写的（或你审核过的），它表达的是你对功能的理解。只要测试覆盖了关键场景，AI生成的代码过不了测试就是错的，过得去至少不坏。

TDD把质量保障从「人肉审查代码」变成了「机器验证行为」。这对于AI辅助编程来说，是唯一可规模化的方案。

实际怎么操作？

把Red/Green TDD融入AI编程，有一套可落地的流程：

Step 1：你写测试（Red）

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

def test_calculate_discount():    # 满100减20    assert calculate_discount(150) == 130    # 不满100不减免    assert calculate_discount(80) == 80    # 负数输入应该抛异常    assert_raises(ValueError, calculate_discount, -50)

Step 2：AI写代码（Green）

把测试丢给AI：「请实现 calculate_discount 函数，让以下测试全部通过」。AI产出的代码只要能跑通测试就行，不需要完美。

Step 3：你审核+重构（Refactor）

代码能跑了，但逻辑清晰吗？命名合理吗？有没有性能问题？这时候你的角色从「写代码的人」变成了「审代码的人」——这个角色切换本身就是质量提升。

Simon Willison 和 Egotic Engineering

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

核心思维转变：

这不是偷懒，是把精力从「实现细节」抽离出来，聚焦到「设计决策」和「质量把控」上。

开始行动

Red/Green TDD 不是什么新概念，但它在AI时代找到了最合适的位置。

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

不是AI写的代码变好了，而是你对「好代码」的标准，终于有了可验证的指标。