第 2 章：Test–Code 循环——为什么测试代码比功能代码更重要

“你一定要花非常多，超过 50% 的时间来写 testing code。”

延伸阅读：在无状态世界里，为什么测试案例库是唯一可靠资产，参见AI 的无状态性与 Context Window。

在 AI 之前，大家其实都知道 test code 很重要，但实际上 99% 的团队都不会去写 test code。原因在于：

这个逻辑在过去是说得通的，但是在今天就不行了。

今天有了 AI 的帮助，每个人的产能都太高了，直接导致团队人数的减少。

“不管 AI 再怎么强，人脑还是要对项目有掌控力的。你一旦放松了掌控力马上就会崩溃。”

过去，一个项目有十个人的团队，每个人都可以分担一部分，而且大家做得又慢，时间周期又长，这样大家有充分的时间去理解、掌握代码里的每一个细节。

但在今天，过去十个人做的事，可能一个人就能做完，而且时间只有以前的三分之一。
这就意味着：你要在一颗大脑、三分之一的时间里，去记住和理解过去“一个团队 × 三倍时间”才能掌握的信息。

对 AI-native 团队来说，这是一个非常巨大的挑战。

在这样的情况下，如何保证软件质量？一个非常自然的想法就是：

“用海量的 test code 去 cover 你人脑 cover 不了的部分。”

在这种前提下，唯一有效的自我保护方式就是用海量的 test case 去 cover：

"今天的 AI 编程，你可以理解成是一种在不确定性中、在混沌中、在混乱中的一种编程。我们已经非常清楚地知道 AI 写出来的代码是不可靠的。"

延伸阅读：人类评审如何与测试驱动的质量保证相结合，参见Human-in-the-loop 与新人培养。

但我们又不得不让 AI 来写代码，因为它的产能实在太高了。我们不得不接受这种混乱，不得不接受这种不确定性。

在这种情况下，你唯一有效的保护自己的东西，就是你的测试用例：

测试用例就可以始终保护好你各个层级、各个 scope、各个环节。

第一点，test code 当然要符合你的要求，最开始的时候还是要定好测试的框架和测试的 convention。

因为 AI 写代码的时候，它会去参考临近的或者相关的代码：
你已经有了一些测试案例放在那里，它就会用类似的 pattern 去写，这样大概率是没有问题的。

第二点，你在修改代码、评审代码的时候，一定要花非常多的时间和注意力去看：AI 到底有没有动测试案例？

在硅谷有很多团队是做 AI 测试相关的，他们有一张曲线图：

但出现了 AI 之后，这个情况变了：

你一定要花非常多，超过 50% 的时间来写 testing code。