一个真实的故事

上个月我用 Cursor 帮一个做电商的朋友做价格计算模块。需求很简单：商品原价 × 数量，减去折扣，加上运费。

AI 唰唰唰写了一段代码，看起来完全没问题：

function calculateTotal(price: number, quantity: number, discount: number, shipping: number) {
  return price * quantity - discount + shipping;
}

我看了一眼，逻辑清楚，Accept 了。部署上线。

然后三天后我朋友说："有个客户投诉，说他买了 100 块的东西，用了 120 块的优惠券，结果显示需要付 -20 块。"

calculateTotal(100, 1, 120, 10) → 100 - 120 + 10 = -10

负数。AI 没有处理"折扣大于商品总价"的情况。代码语法完全正确，逻辑也说得通（原价减折扣加运费），但在业务层面是错的——你不能让用户付负数的钱。

如果我在 Accept 之前跑了一个测试，这个 Bug 三秒就能发现。

"AI 写的代码不需要测试"是最危险的想法

你可能觉得 AI 都那么聪明了，写出来的代码应该很靠谱吧？

说实话，在语法层面确实很靠谱。AI 写的代码很少有拼写错误、括号不匹配、变量未定义这种低级问题。但在业务逻辑层面——也就是"代码是不是在做正确的事情"——AI 犯错率依然很高。

原因很简单：AI 不知道"对"的标准是什么。 你说"帮我写一个价格计算函数"，AI 能写出一个函数，但它不知道"折扣不能超过商品总价"、"运费满 200 免"、"VIP 用户打 85 折后再用优惠券"这些业务规则——除非你每次都在 Prompt 里把所有规则列清楚。

而测试做的事情恰好就是：把"对"的标准写成代码。

test('折扣不能超过商品总价', () => {
  expect(calculateTotal(100, 1, 120, 10)).toBe(10); // 最少付运费
});

test('基本计算', () => {
  expect(calculateTotal(100, 2, 30, 10)).toBe(180); // 200 - 30 + 10
});

test('零折扣', () => {
  expect(calculateTotal(50, 3, 0, 15)).toBe(165); // 150 + 15
});

有了这些测试，不管是 AI 写的代码还是人写的代码，只要测试通过就说明功能是对的。测试不通过？那就是有 Bug，不管代码"看起来"对不对。

为什么 AI 时代测试"更"重要？

你可能注意到了一个悖论：AI 让写代码变容易了，但同时也让代码的"产量"大幅增加了。以前一个开发者一天写 200 行代码，现在用 Cursor 一天能生成 2000 行。

代码量增加了 10 倍，但你 Review 代码的速度没有提升 10 倍。你不可能把 AI 生成的每一行代码都仔细检查一遍——那就失去了用 AI 的意义。

这就是测试的价值：测试是自动化的 Review。你不需要人肉检查 2000 行代码，你只需要跑一下测试，看看有没有红色的。

我现在的习惯是：让 AI 写完代码后，第一件事不是 Accept，而是让它一起写测试。 如果测试过了，我就比较放心；如果测试暴露了问题，我就知道代码还需要调整。