作者 / 来源：中智凯灵 / AiDD
【篇首语｜企业 AI，正在从“会用”走向“能交付” 】
国庆七日谈·第五日｜质量验证
▼
过去，团队担心的是测试跟不上开发。现在，新的问题正在出现：AI 可以读需求、生成用例、执行操作、判断结果，甚至在失败后自动修复脚本。测试速度越来越快，但“测试完成”是否等于“风险已经被覆盖”？
如果同一个 Agent 既出题、又答题、还负责判卷，那么一份漂亮的通过报告，可能只说明它完整执行了自己的理解，并不能证明它理解的是对的。
这不是对测试 Agent 的否定。恰恰相反，正因为它开始进入真实研发流程，质量验证才不能停留在“生成了多少用例”“跑了多少步骤”或“自动化率提高了多少”。企业必须建立一套独立于 Agent 自述的证据链：任务依据是什么，预期结果从哪里来，执行环境是否真实，过程能否回放，失败如何接管，结果由谁签署。
2026 年 AiDD 上海站、北京站和成都站的三场分享，从用例生成与评审、AI 测试执行和质量门禁三个方向，给出了同一个提醒：自主测试不是省掉测试责任，而是重新分配验证责任。
▍会生成测试，不等于会证明质量
在 AiDD 北京站《研发已提速 10 倍，测试怎么办？——从错判到重构：AI 测试这两年我看到的三件事》中，Testin 云测 CEO 徐琨把 AI 测试拆成设计层和执行层：大模型擅长理解需求、发散场景和辅助生成，但在控件识别、复杂业务流、跨端执行等环节仍可能遇到困难。
图 1：徐琨《研发已提速 10 倍，测试怎么办？——从错判到重构：AI 测试这两年我看到的三件事》：课件区分了 AI 在测试设计与真实执行上的能力边界（PPT 第 7 页）
这一区分非常重要。生成用例主要回答“应该测什么”，执行与验证则要回答“在什么环境、按什么步骤、出现什么结果才算通过”。前者允许探索，后者必须能够重复、定位和追责。
测试 Agent 最容易制造的错觉，就是把“输出完整”当成“覆盖充分”。它可能生成大量格式正确的用例，却遗漏跨系统链路、异常数据、权限变化和历史缺陷；也可能顺利跑完步骤，却没有观察到真正应该验证的业务状态。
在 AiDD 成都站《Agent 驱动的 AI Native软件生命周期端到端质量保障体系建设》中，顺丰科技研效运营唐亮将非功能场景、隐性业务逻辑、跨模块链路和边界异常数据列为当前测试 Agent 容易出现的盲区。
图 2：唐亮《Agent 驱动的 AI Native软件生命周期端到端质量保障体系建设》：课件列出的测试 Agent 四类能力盲区（演讲 PPT 第 8 页）
这不是对所有模型和场景的普遍判定，却提醒团队：一份完成报告不能自动证明风险覆盖。验证测试 Agent 的第一步，不是再让它生成更多内容，而是把“用例数量”“执行完成”与“质量证据”分开。
第一层验证：生成者和审核者必须分责
在 AiDD 上海站《智能UI用例生成与执行》中，快手研发效能中心智能质量平台方向负责人苗星展示了用例生成从 Prompt 工程、Multi-Agent、知识工程到 Agentic 自进化的演进。
其中一个关键变化，是不再要求模型“一步到位”。需求解析、测试模块、具体用例被分阶段生成，每个阶段都设置 Review 和纠偏。课件将职责写得很直接：AI 负责生成，人负责审核与纠偏。
图 3：苗星《智能UI用例生成与执行》：分阶段 Review 让 AI 负责生成、人负责审核与纠偏（PPT 第 15 页）
这种分责的价值，不只是修改措辞，而是防止错误理解沿着任务链一直传到执行末端。如果需求理解错了，后面生成再多模块和用例，也只是在扩大同一个偏差。
更重要的是，人工职责不应该只出现在 Agent 失败之后。业务与测试团队需要提前定义：哪些规则不能遗漏，哪些风险必须覆盖，哪些结果可以由确定性规则判断，哪些异常必须转给人。
换句话说，人不是“最后的兜底按钮”，而是验收契约和责任边界的设计者。
第二层验证：评审标准必须写在 Agent 外面
测试 Agent 可以做自主评审，但自主评审不能等于独立证明。
苗星的课件给出了模块级和用例级的评审维度：结构是否合理、覆盖是否完整、步骤是否清晰、预期是否明确、场景是否完整、优先级是否合理。低质量用例经用户标记后，进入 Bad Case 规则库，供后续评审调用。
图 4：苗星《智能UI用例生成与执行》：模块级、用例级评审维度与 Review-Critique 循环（PPT 第 21 页）
这一步的价值，是把“感觉不错”改造成可检查的契约。评审 Agent 不只是给一个总分，而是逐项说明覆盖、步骤、预期和场景是否满足要求。
但即使换了一个“评审 Agent”，也可能与生成 Agent 共享同一批知识盲区、同一种提示结构或同一个模型偏差。真正的独立性，需要来自不同性质的检查：预先冻结的评测集、确定性断言、规则或扫描工具、权限隔离的验证流程，以及高风险节点上的人工判断。
所以，自主评审是内部检查层，而不是最终裁判。
第三层验证：概率推理不能独自承担确定性放行
测试 Agent 的感知、规划和脚本生成可以使用大模型，但最终判定不能只依赖模型“感觉正确”。
徐琨的课件把大模型的概率特性与回归测试的确定性要求放在一起比较：相同输入下，模型输出可能变化；而回归测试要求重复执行、规模化和快速反馈。课件反对的是让大模型直接、无人、全自动承担回归执行，而不是排斥大模型参与测试。
图 5：徐琨《研发已提速 10 倍，测试怎么办？——从错判到重构：AI 测试这两年我看到的三件事》：概率模型与确定性回归测试之间存在工程张力（PPT 第 11 页）
一个更稳妥的结构是：大模型负责理解、生成和诊断，执行引擎负责稳定动作，断言与规则负责客观校验，人负责关键节点的验收和风险判断。模型可以建议“这可能是一次失败”，但放行或阻断需要来自可复现证据。
每一次“通过”都应该附带最小证据包：执行环境、输入数据、版本与配置、操作轨迹、断言结果、截图或日志、异常与重试、人工干预记录。没有这些材料，结果既难复现，也难解释为什么放行。
第四层验证：跑通不等于测对，临时修复不能自动固化
测试 Agent 进入真实环境后，脚本遇到页面变化、元素位置变化或执行异常并不罕见。此时，AI 可以生成临时修复动作，让当次任务继续运行。
但一次“继续跑通”并不等于修复逻辑正确，更不能直接成为正式测试资产。徐琨的方案中，运行阶段生成临时修复动作，复核阶段经测试人员采纳后，才进入正式脚本。
图 6：徐琨《研发已提速 10 倍，测试怎么办？——从错判到重构：AI 测试这两年我看到的三件事》：临时自愈动作需经测试人员复核采纳，才能固化为正式脚本（PPT 第 24 页）
这个人工确认点，本质上是在防止一次偶然成功被写成长期规则。测试人员需要判断：修复的是元素位置，还是业务逻辑已经改变；断言是否仍然有效；这次变更是否会影响其他设备、版本和环境。
成熟的自愈不是让 Agent 无条件修改自己，而是让它提出候选修复、保留证据、接受复核，再进入下一轮回归。
第五层验证：上岗要靠客观门禁，而不是自述完成
唐亮把 Agent 的上岗资格拆成 Graph 条件边、HITL、Checkpoint 和客观验证层：关键判断保留人工节点，失败可以回到稳定状态，编译、测试、扫描等工具提供客观证据。课件中一句话很关键：自述完成不算完成。
图 7：唐亮《Agent 驱动的 AI Native软件生命周期端到端质量保障体系建设》：客观验证、人工节点与 Checkpoint 共同构成 Agent 的上岗复核（演讲 PPT 第 14 页）
这里最重要的不是术语，而是裁决权从哪里来。
生成 Agent 可以说“任务完成”，评审 Agent 可以说“结构合理”，执行 Agent 可以说“步骤跑通”，但真正的门禁必须检查外部证据：是否通过确定性断言，是否触发安全规则，是否覆盖关键风险，是否需要降级或人工接管。
人工接管也不是自动化失败，而是生产系统的一部分。成熟的测试 Agent 不应该假装自己永远有答案，而应该知道何时停止、何时请求补充条件、何时把证据交给人。
第六层验证：Bad Case 必须变成下一轮考卷
如果每次漏测、误判和人工纠偏只留在聊天记录里，测试 Agent 下次还会重复犯错。
苗星的实践将用户运营与 Bad Case 驱动闭环连接起来：收集问题后按覆盖、质量和业务理解分类，再分别回写知识库、提示词和业务模板；经过优化与验证，才沉淀为下一轮能力。
图 8：苗星《智能UI用例生成与执行》：Bad Case 经收集、分类、优化和验证后，回写知识与评审规则（PPT 第 33 页）
这里要避免另一个误区：反馈回写不等于质量已经提升。未经筛选的反馈可能带来新偏差，某次人工修改也不一定适用于其他场景。进入回归资产之前，还要确认问题是否可复现、规则是否具有边界、修改是否通过离线验证，以及是否会破坏既有用例。
真正有价值的闭环，不是“Agent 会记住”，而是 Bad Case 会经过验证，成为下一轮评测集、回归用例或门禁规则。
最终验证者，是一组有责任归属的角色
“谁来验证测试 Agent”并不是寻找另一个万能 Agent，而是建立一条角色清晰的责任链。
唐亮给技术管理者的动作清单里，包含把计数改成效果、将客观验证接入门禁，以及划清人机责任边界、把关键判断留给人。这几项恰好回答了自动化之后的管理问题：速度和数量可以由系统产生，质量结论必须有人负责。
图 9：唐亮《Agent 驱动的 AI Native软件生命周期端到端质量保障体系建设》：测试 Agent 的管理要从计数转向效果，并保留客观门禁和人的关键判断（演讲 PPT 第 29 页）
这条责任链可以这样分工：
业务与产品负责人定义不可丢失的业务规则和验收结果；测试负责人设计风险模型、评测集和人工接管点；平台与工程团队保证环境、执行引擎、证据采集和回放能力；发布责任人根据门禁证据决定放行、退回或降级；运行团队把线上逃逸和 Bad Case 回写回归体系。
测试责任没有被一个 Agent 取代，而是被拆成可执行、可验证、可追溯的多个环节。
企业引入测试 Agent，先检查六件事
第一，是否有独立于 Agent 的验收标准，而不是让它自己解释什么叫“完成”？
第二，测试用例是否包含明确前置条件、原子步骤、可观察预期和环境依赖？
第三，执行结果是否保留版本、数据、日志、截图、轨迹、重试与人工干预记录？
第四，评测集是否包含历史缺陷、异常分支、跨系统链路、非功能风险和线上 Bad Case？
第五，高风险节点是否有明确的人工接管、风险降级、回退和责任签署机制？
第六，每次漏测、误判和人工纠偏，是否会经过验证进入下一轮评测与回归，而不是留在聊天记录里？
这六件事比“自动生成了多少用例”更接近测试 Agent 的真实成熟度。
结语：真正被自动化的，是执行；不能被自动化掉的，是责任
上海站的实践说明，测试生成要与人工审核分责，自主评审也需要明确维度和 Bad Case 闭环；北京站的分析说明，大模型适合理解、生成和候选修复，但确定性执行、客观断言与人工采纳仍是质量落地的基础；成都站的质量体系则把能力盲区、客观复核、人工节点和责任边界连接起来。
因此，测试 Agent 的可信度不能由它自己“说通过”。它需要被验收契约约束，被真实环境检验，被过程证据记录，被独立检查复核，被门禁裁决，并在关键风险上接受人工签署。
当测试会自动生成、自动执行，测试团队真正要守住的，不是每一步都由人操作，而是每一个放行结论都有依据、每一次异常都有人负责、每一个 Bad Case 都能成为下一轮考卷。
国庆七日谈·第六日，我们继续讨论：Agent 会调用工具之后，谁来决定它能做什么、不能做什么？
主要参考演讲
下一站
北京营销中心
北京通州北京ONE国际广场10层
上海研究中心
上海市浦东软件园
厦门研究中心
厦门观音山国际商务运营中心
海外市场中心
香港中环香港站国际金融中心
加入智库
成为客户
