那篇价值50万美元的 AI 重写故事其实是关于测试套件的故事

Source: Dev.to

背景

一家公司的最近声明称，AI 通过将一个 JavaScript 库重写为 Go，帮助他们每年在计算成本上节省约 30 万美元。标题暗示了 AI 的奇迹，但真正的英雄是早在任何人敲下提示之前就已经存在的测试套件。

测试套件的作用

团队拥有一套完整、经受过实战考验的测试，覆盖了原始的 JavaScript 库。他们使用这些测试来验证 AI 生成的每一段 Go 代码。

• AI 的贡献： 将语法从一种语言翻译到另一种语言，这确实是有价值的工作。
• 测试套件的贡献： 确认翻译后的代码行为正确。没有它，团队就会把未经验证的 Go 代码直接投产。

5 万美元的节省来自于使用 Go 而非 JavaScript 所带来的基础设施改进。AI 只是加速了迁移的时间表；测试则让这种加速变得安全。

为什么测试很重要

软件历史上每一个生产力倍增器都依赖于一种验证输出的方式：

• 编译器依赖类型系统。
• 重构工具需要测试覆盖率。
• 代码生成器需要验证。
• AI 代码助手同样需要安全网。

如果把测试套件从这个故事中剔除，团队就会交付一个未经验证的重写版本——一种“我们走运了”的情形，甚至更糟，可能会导致事后检讨。

对团队的启示

许多团队会尝试复制这种成功。大多数会失败，不是因为 AI 不能翻译代码，而是因为他们缺乏足够的测试覆盖来捕捉细微错误。

• 重写中的细微 bug 是最糟糕的：代码能够编译，正常路径工作，却在数周后出现隐藏问题（例如竞争条件）。
• 任何 AI 辅助重写的非性感前提是严格的测试驱动开发。

对测试的投入在多年后以意想不到的方式收回了价值。

结论

当你看到关于 AI 为公司省下巨额费用的病毒式故事时，留意其背后乏味的基础设施——测试套件、CI 流水线以及细心的工程师。AI 是强大的工具，但没有让其输出可信赖的工艺，工具本身不应被过度赞誉。

问题： 如果你的团队明天尝试对核心系统进行 AI 辅助的重写，你们的测试覆盖率是否足以识别错误？