在某些用例中，如果运用得当，Automatic programming(自动编程)能够极大地加快软件编写的速度。就我的经验而言，其产出的代码在结构质量和复杂度的精简程度上，仍不及最优秀的手写代码。然而，并非所有软件都出类拔萃，我的感觉是，大多数时候（如果管理得当）Automatic programming 的质量反而会超过那些写得尚可的手写代码。

然而，就用 AI 编写新软件而言，质量与时间之间存在权衡。在我开发的某些项目中，这种权衡可能非常显著——原本需要数月才能完成的项目，几周内就能做完。不过，也有一些领域，LLMs 只是单纯地开辟了更强大、自动化程度更高的流程，而无需在质量上做出任何妥协。其中一个领域就是软件 QA 与测试。

传统上，软件测试依赖于由局部作用域测试和集成测试组成的测试套件（以 Redis 为例：一回事是测试 SET foo 10 是否能被 GET foo => 10 正确匹配，另一回事是测试这种情况下 replication 是否正常），以及通常需要手动执行的 QA 流程，后者能够发现可执行测试套件中的遗漏。众所周知，覆盖所有代码行并不意味着覆盖所有可能的状态。此外，集成测试在结构上就很困难：存在大量时序问题、环境配置，以及某些只能通过目视检查而无法自动校验的质量输出，由于时间或后勤条件的限制，很多测试机会实际上并未得到充分利用。

LLMs 在现有测试方法之上提供了一种全新的 QA 方式。其思路是创建一个 markdown 文件，要求 AI agent 以 QA 工程师的身份，对新版本执行一系列手动测试。例如，就 DwarfStar（一个面向 open weights LLMs 的 inference engine(推理引擎)）而言，我采用了如下方法。在 markdown 文件中，要求 agent 检查软件项目已发布版本之上的新增 commits。然后，告知模型需要执行的一系列事项，例如：

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

等等。值得注意的是，在 speed regression 部分，我不必告诉 agent 之前预期的速度是多少，因为这是一个会随着新版本和新的优化而不断变化的动态目标。同样，针对 distributed inference 的集成测试也不需要太多指令，在文件的开头只需提供 SSH endpoints、要使用的密钥、路径等等即可。

要求 agent 检查长长的 QA 活动清单，*尤其是*结合新增的 commits，从审视变更内容入手，并识别可能受影响的部分，从而让这次 QA 流程更有针对性地去发现特定的 regressions。

在 Redis Arrays 的案例中，我使用了类似的方法，要求 agent 构建一个大型的基于数组的 Redis 应用，搭建一个带 replication 和 persistency 的生产环境，模拟多用户对该应用连续数天的使用情况，并检查是否有异常。

采用这些方法的测试还可以触及软件质量中更偏心理层面的部分，例如要求 agent 识别所有那些从用户视角来看可能显得突兀、文档不足或总体上较为粗糙的新功能。这些都是过去需要手动执行、而大多数时候基本被跳过的事情。

我有一种感觉，引入 automatic QA(自动化 QA)可能会提高软件新版本的质量门槛，并或许能在一定程度上弥补通过 Automatic programming 高速产出代码所带来的质量下降。