用AI构建大型系统：测试、可观测性与人的判断

我热爱测试。我一直都喜欢测试，而AI让我对测试思考得更多。如果AI要帮我们写生产代码，重要的问题不是它能不能快速生成大量代码。重要的问题是，我们能不能建起一个反馈回路，告诉我们什么才是真正有效的。

这就是我做那场演讲的原因——《当测试说谎：用可观测性让AI保持诚实》。我想搞清楚一件事：把AI用在比玩具项目大得多的东西上，会发生什么。小工具很好玩。你半天就能写完，可以狠狠地测，结果也还算让人放心。但你能用AI去构建一个大型、复杂的基础设施系统吗？

我决定拿S3兼容的对象存储来试。对象存储是我最喜欢的云服务，而我看过的大多数实现，写出来至少要两年。有些花了十年。我清楚这东西会又大又复杂。到演讲那个时间点，代码库已经有大约35万行Rust，我并不打算假装自己读过每一行。

这也是实验的一部分。我想要高质量的代码。我有自己的架构观点。我在意安全、性能和分布式系统行为。我也想让人留在回路里，因为我想知道哪里出了问题，而不是一开始就把一切都自动化掉。

先造一个测试预言机

复制一个已有系统的好处是，你得到了一个测试预言机。就我而言，我可以拿测试去跑S3，观察真实行为，然后告诉AI：我们的实现必须表现得和它一模一样。

这改变了工作的质量。我最终有了大约1500个测试，全部跑在S3上，把行为锁定下来。对一个智能体来说，这比一句含糊的指令好太多。它给了模型一个有据可依的基线，也让我在判断是否该信任这个实现时，手里有证据。

我现在认为，如果你要写一个复杂系统，一个好的起手式是先造一个非常简单的版本。它不必是最终架构。它可以只是行为的一个简化模型。但如果你能针对这个简单版本建起一套测试，就能在构建更复杂版本的过程中，把它当作预言机来用。

这并不完美。S3在某些地方是最终一致的，尤其是授权行为附近，所以测试有时需要重试，才能正确反映真实行为。预言机并不完全等同于规格说明。你仍然得去解读自己看到的东西。

文档不够用，覆盖率也不是答案

另一个发现是，文档不够用。S3有大量文档，但一旦进入细节，文档往往是近似的、过时的，或者干脆没有描述你实际观察到的行为。甚至就是错的！文档能给你一些关于该测什么的提示。而测试告诉你真正发生了什么。

我一开始追求100%测试覆盖率，觉得这似乎是个好主意。我测量了不同种类的覆盖率，包括集成测试带来的覆盖率。结果并没有人们有时以为的那么有用。

当我让一个AI智能体去做到100%覆盖率时，它写的是琐碎的测试。有些测试在数字上确实提升了覆盖率，却没有提升我的信心。如果正确行为只是返回一个错误或者panic，那就不需要为每一条随机数生成器的失败路径都写测试。最有用的证据不在那里。

我仍然有很多测试。大多数文件的覆盖率在75%到100%之间。重点不是说覆盖率不好。重点是100%语句覆盖率并不能替代思考。

测试是发现工具。它们不是魔法答案。你在不确定的地方、怀疑的地方、觉得系统可能藏着错误的地方加测试。如果某段代码让你担心，你就多花时间试着把它弄坏。

这正是我希望在AI辅助开发中保持的心态。智能体可以生成测试，但我仍然需要决定自己到底想暴露什么风险。

AI找到了500错误，但人更会找边角

让我获得信心的时刻之一，是AI在S3里发现了一个可复现的500错误。当时它正在针对一个边缘情况写测试，结果发现了看起来像真bug的行为。后来它又发现了另一个可复现的500错误。

这很让人兴奋，因为这意味着测试套件不只是在检查显而易见的路径。它探索了足够多的行为空间，能找出奇怪的案例。构建复杂系统时，你会在“一切都糟透了，这永远不会成功”和“其实它又能跑了”之间来回移动。好的测试帮你往信心那一侧移动。

有意思的是，在从文档里找某些边缘情况这件事上，我比AI更强。我会读AWS文档，心想“这真的是对的吗”，然后让AI去写测试，接着发现真实行为只是近似等于文档描述。而当我直接把文档指给AI、让它自己去找边缘情况时，它做得并不好。

这说明了一些关于人类角色的事。我仍然得像个测试人员那样思考。我得去问零长度、一长度、10001长度，以及系统容易出问题的那些奇怪角落。智能体可以帮我把这种怀疑变成可执行的测试，但怀疑本身仍然重要。

不稳定测试是这个项目里最有意思的部分之一。AWS会随着时间收敛到真相，这浪费了大量时间。但我的硬规则很简单：绝不允许AI留下不稳定测试。立刻修掉它们。

原因是，智能体会从围绕不稳定测试的文化里学到错误的教训。有时感觉训练数据告诉模型……