随着 AI 工具加速代码生产，软件团队可以从制造业借鉴一个思路：将测试中的重复工作自动化，同时明确保留对质量、安全和治理的责任。真正需要扩容的，不只是代码生成能力，还包括承接变更的质量系统。

这里的关键不在于给现有流程再接一个 AI 工具，而在于重新审视交付链路：代码生成更快后，哪些检查必须同步变快，哪些判断仍必须由人承担，出现异常时又该由谁接手。只有把这些问题放进同一条流水线，AI 才可能提升吞吐量，而不是把风险更快地推向发布环节。

测试供需缺口正在扩大

UiPath 产品工程副总裁 Ingo Philipp 在接受 ITPro 采访时表示，团队面对的 测试需求与测试能力的错配正在扩大。Codex、Claude、Copilot 和 Cowork 等 AI 助手能帮助开发者更快产出代码，但变更量增加，也会让需要验证的内容同步增加。

这种压力并非只是猜测。Stack Overflow 最新开发者调查显示，84% 的开发者已经使用 AI，其中 51% 每天使用。Faros 报告称，与引入 AI 驱动的开发流程之前相比，团队人均报告的缺陷数量增加了 54%。GitLab 的研究也显示，AI 编写的代码量正在快速上升，同时 92% 的开发者认为治理面临明显挑战。

这说明了一个核心问题：代码生产线更快，不等于质量系统也会更快、更安全。如果测试能力没有随交付速度一起演进，供需缺口就会转化为缺陷、风险发布和治理债务。测试需要前移到变更进入下游之前，而不是在发布前集中承压。

可以把这种错配看成三条队列的失衡。第一条是变更队列，AI 让实现代码、配置和测试草稿更快进入仓库。第二条是验证队列，团队需要判断哪些改动值得跑哪些检查、环境是否可信、失败是否可复现。第三条是决策队列，面对不确定结果时，仍要有人决定继续、回退还是升级处置。前一条队列提速，而后两条不变，发布节奏就会被看似更快的产出拖慢。

因此，测试能力不能只按测试用例数量来理解。稳定的测试环境、清晰的预期结果、可定位的失败证据，以及有边界的人工介入，都是测试能力的一部分。AI 可以帮助生成候选实现和候选检查，但它不能自动补齐需求上下文，也不能替团队决定某次通过是否足以支持发布。

从黑灯工厂到黑灯测试工厂

Philipp 将这种机会类比为无人工厂，也被称为黑灯工厂。在这一模式下，高度自动化的生产线几乎不需要人工参与日常操作。日本工程企业 FANUC 已经采用这种方式超过 20 年，人则主要负责质量控制和监督。

UiPath 将对应的软件测试模式称为 黑灯测试工厂。它的目标并不是把人从质量工作中移除，而是让 AI 智能体在交付流水线更早的位置完成可重复的操作性检查，让缺陷在造成下游问题前被识别出来。

软件测试中的可重复工作，通常不是简单地把同一批用例跑得更快，而是把明确、低歧义的检查稳定地接到正确的位置。例如，对改动范围做初步分类，执行已有的回归检查，整理失败日志，或把同类异常归并给相应负责人。这类工作适合自动化，是因为输入、动作和可接受结果可以先由团队说清楚。

在这个模式中，测试人员不只是执行更多测试用例，而是要定义并维护这个工厂的工作方式：界定智能体可以做什么，明确哪些检查真正重要，审查异常，并维护自动化背后的质量标准。测试人员的价值会更多体现在建立判定依据、识别不可靠的信号、维护回归资产，以及让失败能被快速定位和处理。

黑灯测试工厂也不应被理解为一个一次性的大项目。更稳妥的路径是先把一小段高频、低风险、重复性强的验证流程做成闭环：输入是什么，自动化要做什么，结果如何记录，触发什么条件时必须停止并交还给人。闭环稳定后，再逐步扩大自动化范围，而不是一开始就让智能体接管整条发布链路。

自动化需要受控的运行模型

Philipp 将这个方向描述为强化版的自主测试。预期结果是减少人力消耗在重复、操作性的测试工作上，让测试人员转向质量领导者的角色。

但这不应被理解为完全自主测试的承诺。组织需要为智能体的动作设置 严格护栏，明确升级条件，并保持人工监督。Philipp 描述的一家客户就限定了智能体可独立执行的动作范围，把特定情形回退给测试人员处理。

一个受控的运行模型，至少要把权限、判定依据、证据和升级路径分开处理。权限回答智能体可以读什么、运行什么、提交什么；判定依据回答什么结果算通过，什么结果必须拦截；证据回答失败后团队凭什么定位原因；升级路径回答遇到模糊、危险或超出范围的情况时，谁负责接管。自动化的边界越清楚，人工介入才越有价值。

责任归属仍是关键问题：谁拥有质量，谁来提供智能体可以继续还是必须停止的规则？AI 智能体可以在控制体系内执行，但无法替代这套控制体系。如果团队只把智能体当作会自动点击和执行的工具，却没有明确质量所有者，自动化往往只会更快地产生需要人工解释的结果。

这也是为什么护栏不能只是一条笼统的禁止规则。它应当落实到可观察的条件：哪些动作只能读取信息，哪些动作会改变环境，哪些失败可以自动重试，哪些异常必须保留现场并升级。规则越接近真实交付场景，智能体的执行就越可预测，测试人员也越能把时间投入真正需要专业判断的地方。

短期目标不是完全自主

客户正在以适中的速度转向这一方法。Philipp 直言，UiPath 几乎没有客户实现完全自主测试，他也不认为这个目标会在短期或中期内实现。

对软件团队而言，更务实的做法是把 AI 辅助测试视为分阶段的工程变革：先隔离安全、可重复的检查；将它们接入流水线的更早位置；明确智能体权限、升级条件和回退规则；继续由人对质量、安全和治理决策负责。这样做的重点不是增加一层自动化，而是把自动化纳入可追责的质量流程。

第一阶段可以先建立基线。团队先找出最耗时、最容易重复、且预期结果最清楚的一类检查，记录它目前的触发条件、耗时、失败类型和人工处理方式。没有这个基线，后续即使引入了智能体，也很难判断它究竟减少了重复劳动，还是只是把问题换了一种呈现方式。

第二阶段是在有限范围内试运行。把智能体限制在只读分析、触发既有检查、汇总结果等低风险动作上，并为每次执行保留输入、输出和异常证据。此时最值得关注的并非自动化比例，而是失败是否更早被发现，异常是否更容易定位，测试人员是否能据此更快做出明确决策。

第三阶段才考虑扩大权限和覆盖面。当团队已经能稳定处理常见异常，并能持续更新检查规则时，再逐步让智能体参与更复杂的编排。每扩展一次范围，都应重新确认质量所有者、停止条件和人工接管方式。先证明控制有效，再扩大自动化，比追求表面的自主程度更重要。

制造业的类比之所以有价值，是因为它将问题从是否自动化，转为如何构建一个既能提升吞吐量、又不失去质量控制的生产系统。对软件团队来说，成熟的目标不是让人退出测试，而是让人从重复执行中退出来，持续负责质量标准、风险判断与改进方向。

收录于 FunTester 原创专题：AI ，测试有点东西

相关阅读：AI 编程提效后，什么值得做 · AI 写用例之后，测试稀缺能力是什么 · AI 写的快，回归测试要跟上 · 传统测试不够用了 · AI 代码草稿化，质量护栏不能少