智能体式 AI 需要更多测试人员，而非更少

智能体式 AI 正在改写软件交付的方式。助手起草拉取请求，智能体发起迁移，而审查机器人声称某项变更安全，此时人类甚至还没喝完咖啡。业界常把这种发展描绘成减少质量领域人手的途径。这种看法恰恰弄反了。当机器编写的代码占据代码库越来越大的比例时，稀缺的技能不是代码生成，而是独立验证。

2025 年的 Stack Overflow 开发者调查发现，84% 的受访者正在使用或计划在开发中使用 AI 工具，51% 的专业开发者每天都会使用这些工具。对 AI 持正面态度的比例降至 60%；积极不信任 AI 准确性的开发者（46%）多于信任它的开发者（33%）。66% 的受访者指出，最令人沮丧的是那些几乎正确、却又不完全正确的解决方案。Google Cloud 2025 年的DORA 研究报告显示，软件开发专业人士中的 AI 采用率达到 90%，超过 80% 的人表示 AI 提高了生产力，但仅有 24% 的人表示对 AI 有很大或相当程度的信任。没有信任的有用性，恰恰会扩大测试人员的工作，而不是缩减它。

速度不等于证明

我是一名软件质量工程师，专注于智能体测试，以及针对 AI 编写代码的 CI 门禁。在内部，我们推出了 PR 审查工具和测试用例生成器。两者都只是起草工具，都不会给自己的作业打分。这条规则很重要，因为智能体说话时总是信心十足。但信心十足不等于正确。

我们为此付出了不小的代价才学到这个教训。在一次由 AI 构建的 PR 审查工具试点中，一项变更在不到 4 分钟内通过了 CI。两天后，下游仪表板却显示出不可能出现的温度。某条代码路径上的摄氏度到华氏度换算比例被反转了，而测试套件从未覆盖这条路径。流水线显示通过，产品却是错的。从未追问关键问题的绿色 CI，只是一场表演。

这一事件也反映出更广泛的趋势。CodeRabbit 的《AI 与人工代码生成现状报告》分析了 470 个 GitHub 开源拉取请求（320 个由 AI 与人类共同编写，150 个仅由人类编写）。AI 编写的变更总体上产生的问题约多出 1.7 倍，其中逻辑和正确性问题常见 75%，安全问题发现数最高可达 2.74 倍。Veracode 2026 年的《生成式 AI 代码安全报告》对多个模型在安全任务上的表现进行了测试，发现其安全测试平均通过率为 56%，与上一份报告中的 55% 相比几乎没有变化；与此同时，AI 代码生成任务中约有 44% 引入了已知漏洞。语法问题几乎已经解决，但安全、正确的行为还没有。测试人员正是那些拒绝把这两者混为一谈的人。

幻觉依赖项是测试问题

代码生成还会凭空编造依赖项。USENIX Security 2025 的研究《我们为你准备了一个软件包！》评估了 16 个代码生成大语言模型在 576,000 个样本中产生的软件包幻觉。商业模型平均至少有 5.2% 的概率会编造软件包；开源模型的平均比例为 21.7%，产生了 205,474 个独特的幻觉名称。持续存在的虚假软件包为“幻觉包抢注”创造了现成的目标：攻击者注册这些编造出来的名称，然后等着开发者或智能体安装它们。

依赖项来源核查应与功能测试处于同一层级。如果智能体虚构了一个 NuGet 或 npm 包，合并就应失败，而不必等到有人争论单元测试是否足够全面。来源核查并非可有可无的卫生措施，而是 AI 编写的变更必须通过的质量门槛。

随智能体规模扩展的门禁

我们曾借助 AI 辅助自动化，在大约两周内完成全组织范围的 .NET 8 到 .NET 10 升级，我负责质量门禁。速度确实快，但我们也确实需要不会轻信智能体摘要的检查机制。我会对变更后的代码运行以下门禁：

• 对修改过的逻辑，将变异得分目标设在 60% 到 70% 的范围内，确保测试套件能够杀死真正的变异体，而不只是覆盖代码行
• 对高风险逻辑进行基于属性的测试，因为仅靠示例不足以充分规定其行为
• 进行依赖项来源验证，以防范幻觉包抢注和编造的软件包
• 利用重复代码和代码变更频次信号，标记智能体造成的复制粘贴式反复折腾
• 独立验证智能体的说法，例如“迁移已完成”，因为在证据出现之前，这种说法只是假设

变异得分不是虚荣指标。它衡量的是测试能否发现人为引入的故障。代码覆盖率可以上升，但测试套件仍可能漏掉摄氏度换算路径。基于属性的检查会迫使系统模型在整个取值范围内都成立，而不只是在一种理想情况下成立。来源验证堵住了软件包供应链的漏洞。代码变更频次和重复代码则能发现智能体把同一个想法改写成三种形式的习惯。这些措施共同构成一种工作原则：在测试套件证明相反之前，先假定智能体是错的。我在代码审查中始终坚持这条校准原则。

这些措施都不能取代 API 测试、身份验证测试、冒烟测试或 UI 自动化。FlaUI 和 PowerShell 仍能发现 API 测试遗漏的问题。通过 NuGet、MSI 和 MSM 进行打包时，仍需验证安装流程和静默安装路径。智能体工作流会放大工作量，但不会让这些测试领域失去必要性。

需要更多测试人员，只是工作内容不同了

令人担心的是，智能体编写测试后，人类可能变得可有可无。智能体可以起草测试用例，但不应为自己起草的用例背书。计划今后将 AI 用于测试的 Stack Overflow 受访者，仍然认为人们对 AI 缺乏信任是核心问题之一：当他们会向其他人求助时，最主要的原因是不信任 AI 给出的答案。这种直觉正是这个职业的宝贵资产。

招聘并帮助拥有非传统职业发展路径的人发挥所长，在这里至关重要。我曾从事人力资源运营和数据工作，之后转入质量领域；2024 年 5 月，我在 UMBC 完成了信息系统理学硕士学位。如今，我每天都在努力让智能体质量门禁切实可行。智能体 AI 不会等待所有人拥有同一种履历。它需要更多能够设计证据的人，而不是更少会对绿灯构建照单全收的人。

产品层面的问题很简单。如果智能体的发布速度快于验证能力的思考速度，那就谈不上提高了生产力，只不过是把事故推迟了。我们应该投资于测试人员：他们会对智能体的每项声明保持怀疑，会将变异测试和溯源机制接入 CI，并会在模型表达最流畅、却最不可靠的地方保持独立判断。智能体 AI 需要更多测试人员，而不是更少。