Redis创始人antirez在最新文章中提出了一个引人深思的观点：AI辅助编程在开发速度上带来了质的飞跃，但在代码质量上往往无法达到手工代码的"结构品质和复杂性经济性"。然而，在软件测试和QA领域，LLM打开了一条新的路径，且没有任何质量上的妥协。

传统软件测试依赖测试套件——由本地化单元测试和集成测试组成——以及通常需要手动执行的质量检查流程。以Redis为例，测试SET foo 10是否能被GET foo匹配是一个单元测试问题，但测试复制功能在特定场景下是否正常工作则是一个集成测试问题。而集成测试本身在结构上就很难做到自动化：存在大量时序问题、环境配置问题，以及只能靠人工检查而非自动化验证的输出质量——这些因素导致大量测试场景因时间或流程限制而无法真正被执行。

LLM提供了一个全新的QA工作方式。其核心思路是创建一个Markdown文件，在其中指定一个AI Agent作为QA工程师，对新版本执行一系列手动测试。例如在DwarfStar（一个针对开源权重LLM的推理引擎）项目中，antirez采用了以下方法：在Markdown文件中，Agent首先被要求检查新提交相对于已发布版本的所有变更，然后被告知需要执行的一系列检查项，包括验证分布式推理在MacBook A和MacBook B之间是否正常工作、输出是否一致、是否兼容所有GGUF文件，以及确认本次发布不存在任何速度回归问题。

值得注意的是，速度回归检测不需要Agent知道此前的预期速度——这是一个随新版本和新优化不断变化的目标，Agent只需要检查当前版本的速度表现。同样，分布式推理的集成测试也不需要太多指令，文件开头只需提供SSH端点、密钥、路径等信息即可。

Agent被要求特别针对新增提交进行QA活动，从检查变更内容开始，识别可能受影响的区域，从而使QA检查过程专注于发现特定回归。在Redis Arrays项目中，antirez使用了类似方法：让Agent构建一个大型基于Redis数组的应用，搭建带有复制和持久化的生产环境，模拟多用户连续运行数天的场景，并检查是否有异常。

这种测试方法甚至可以延伸到软件质量的"心理层面"——让Agent识别所有可能令用户感到意外、未充分文档化、或从用户角度看显得粗糙的新功能。这些以前都需要人工执行，且大多数时候因时间限制被直接跳过。

antirez的判断是：自动QA的引入可能提升新版本软件的质量基准线，并在一定程度上弥补高速AI辅助编程带来的代码质量下降问题。这是一个在开发效率与质量之间寻找新平衡点的实践路径。

参考来源：https://antirez.com/news/168