在特定场景下，由合适的人来运用时，自动编程能极大加快软件编写的速度。就我的经验而言，其产出的结构质量和对复杂度的精简控制，仍不及最优秀的手写代码。然而，并非所有软件都出类拔萃，我的感觉是，自动编程在大多数情况下（如果运用得当）已经超过了水准尚可的手写代码的质量。

不过，用 AI 编写新软件时，质量与速度之间存在权衡。在我做过的一些项目里，这种权衡非常极端——原本可能需要数月完成的项目，几周内就能做完。然而，也有一些领域，大语言模型直接开辟了严格意义上更强大的全新自动化路径，而无需在质量上做出任何妥协。其中之一就是软件 QA 与测试。

传统上，软件测试依赖由局部测试和集成测试组成的测试套件（以 Redis 为例：测试执行 SET foo 10 后能否通过 GET foo => 10 取回是—回事，测试这种情况下主从复制是否正常工作则是另一回事）。此外还有通常需要手动执行的 QA 轮次，用来弥补可运行测试套件中的遗漏。众所周知，覆盖了所有代码行并不意味着覆盖了所有可能的状态。而且，集成测试在结构上本身就很困难：存在大量时序问题、环境配置，以及某些只能靠肉眼检查、无法自动校验的质量输出，使得许多测试机会因时间或后勤条件的限制而始终未能得到充分利用。

大语言模型在现有测试方法之上，为 QA 提供了一种全新的方式。其思路是创建一个 Markdown 文件，让 AI 智能体以 QA 工程师的身份对新版本执行一系列手动测试。例如，在 DwarfStar（一个面向开放权重 LLM 的推理引擎）这个项目中，我采用了如下做法。在 Markdown 文件中，要求智能体先查看在已发布版本之上新增了哪些 commit。接着，告知模型需要执行的一系列事项，例如：

• 检查分布式推理在 MacBook A 和 MacBook B 之间能否正常工作，确保输出一致，推理在两台机器上的所有 GGUF 文件上都能正常运行，……
• 确保此版本不存在任何性能回退。

诸如此类。值得注意的是，在性能回退检查这部分，我不必告诉智能体此前预期的速度是多少，因为这是一个会随着新版本和新优化而不断变化的动态目标。同样，分布式推理的集成测试也不需要太多指令，在文件的开头只需给出 SSH 接入点和所用密钥、相关路径等信息即可。

要求智能体对照新增的 commit 来检查这一长串 QA 事项，尤其是要先审视变更内容，识别可能受到影响的部分，从而让这一轮 QA 更有针对性地去发现特定的回归问题。

在 Redis Arrays 的案例中，我也采用了类似的方法，让智能体构建一个基于数组的大型 Redis 应用，搭建带有主从复制和持久化的生产环境，模拟该应用在多用户场景下连续运行数天的情况，并检查是否有异常。

采用这类方法的测试，还可以触及软件质量中更偏主观感受的层面，例如让智能体去识别那些从用户视角看可能令人困惑、文档不足或总体上显得粗糙的新功能。这些事情过去都需要手动完成，而大多数时候都被直接跳过了。

我有一种感觉，自动化 QA 的引入可能会提升软件新版本的品质门槛，并或许能在一定程度上弥补因高速使用自动编程而导致的代码质量下降。