AI Coding 与 Vibe Coding 正在大幅提升软件交付速度，但自动化测试、回归验证与质量门禁并没有同步演进，Verification Debt 正成为 AI 软件工程的新挑战。传统 GUI 自动化依赖大量脚本编写和维护，面对多端形态、频繁变更和复杂交互时，验证成本很难随研发速度线性扩展。

本次分享将介绍一个全平台 GUI 持续验证框架的实践路径：第一阶段通过 MCP 将 GUI 操作、界面观察和录制能力接入 Coding Agent，验证 AI 辅助录制与测试生成的可行性；第二阶段进一步演进为独立的自动化生成 Agent，以自然语言 Case 作为核心测试资产，通过需求上下文、历史用例、录制轨迹和界面状态生成结构化验证规格，并结合可插拔 Driver、共享 Harness、证据包与独立验证机制，支持 Windows、macOS、Android、iOS 和 Web 的统一 GUI 验证。分享将重点介绍架构演进、自然语言 Case 到验证规格的生成思路、跨平台执行抽象、稳定性治理和实践效果。

演讲提纲

1. 背景：AI Coding 提速后的 GUI 验证断层

• GUI 自动化的长期难题：复杂业务回归中，GUI 自动化长期面临编写门槛高、跨平台覆盖难、录制成本高、脚本维护重、回归反馈慢等问题
• Vibe Coding 放大 Verification Debt：AI Coding 提升了功能迭代速度，但测试资产、回归执行和质量门禁没有同步提速，导致“功能变了，验证没跟上”的问题更加突出
• 目标：把 GUI 验证从工具能力变成研发闭环能力：目标不是单纯让 AI 写测试代码，而是降低 GUI 自动化从用例表达、录制、规格生成、执行到结果验证的整体成本

2. 第一阶段：通过 MCP 把 GUI 自动化能力接入 Coding Agent

• MCP 作为 Coding Agent 与 GUI 环境的连接层：通过 MCP 暴露 GUI 操作、界面观察、元素信息、截图和执行能力，让 Coding Agent 能够理解并调用真实 GUI 环境
• 录制不是录屏，而是采集可生成测试的上下文：录制过程中沉淀用户操作、控件信息、界面状态、截图、等待条件和断言意图，使 Agent 能够基于结构化上下文生成可执行测试
• AI 辅助录制路线的阶段性验证：该阶段验证了“借助 AI 完成 GUI 自动化录制与测试生成”的可行性，在实践中取得了相当好的效果
• 第一阶段边界：仍依赖人工完成验证闭环：测试代码生成、调试、更新和流水线接入仍需要人工参与，当功能变化加快后，测试资产更新仍容易滞后

3. 第二阶段：Agent 驱动的验证规格生成

• 从依赖 Coding Agent 到独立自动化生成及验证 Agent：第二阶段不再依赖外部 Coding Agent，而是由 Agent 理解自然语言 Case、变更上下文和历史执行结果，生成或更新可执行验证规格
• 自然语言 Case 的生成与约束思路：自然语言 Case 不是随意文本，而是由需求描述、Code Diff、历史用例、录制轨迹和业务规则共同约束，抽取前置条件、用户路径、关键操作、断言点、异常分支和数据依赖，形成更适合审查和生成的结构化用例表达
• YAML 作为可审查、可执行的中间规格：自然语言 Case 面向人维护，YAML 面向机器执行。通过 YAML 固化步骤、定位策略、等待条件、断言和运行配置，让测试资产可版本化、可 diff、可审查、可回放
• 可插拔 Driver 与全平台支持：底层平台能力通过可插拔 Driver 承载，统一支持 Windows、macOS、Android、iOS 和 Web，屏蔽控件树、输入事件、截图、权限弹窗和生命周期差异
• Harness 确定性执行与证据包：Harness 负责执行 YAML、采集日志、截图、控件树、步骤轨迹和断言结果，避免最终验证结果完全依赖模型判断

4. 关键技术设计与工程取舍

• 跨平台 GUI 能力抽象：统一界面观察、元素定位、点击输入、等待、断言和截图能力，同时保留各平台 Driver 的可扩展空间。
• 录制与回放一致性治理：通过结构化录制、多信号定位、显式等待、环境初始化和失败证据回溯，降低分辨率、动画、异步加载和平台差异带来的不稳定。
• Agent 生成与确定性执行分层：Agent 负责理解、生成和修复验证规格；Harness 负责执行、采集和判定结果，在生成效率和工程可信度之间做平衡。
• 实践效果与评估指标：实践中节省约 30% 测试资源。除发现缺陷支撑项目质量外，更关注自动化用例生成效率、跨平台覆盖能力、回放稳定性、人工介入率、维护成本下降和回归反馈时效。

5. 未来展望：从自动化录制走向持续验证闭环

• 自然语言 Case 成为核心测试资产：让 QA 和研发主要维护可审查的自然语言 Case，减少对测试代码细节的直接维护
• 研发流水线中的自动验证：通过“功能更新 → Case 更新 → 提交触发 → Agent 更新规格 → Harness 执行 → 证据反馈”，形成从变更到回归的持续验证闭环
• 面向 Verification Debt 的质量内建：长期目标是让 GUI 验证能力持续发生在研发过程中，而不是发布前集中补债

实践痛点

这类技术并不是把 GUI 自动化复杂性完全消灭，而是把复杂性从“人工写脚本”转移到“用例表达、规格生成、跨平台执行和结果可信度”上。

• 自然语言 Case 的质量决定后续生成质量。需求描述过粗、断言不明确、数据依赖缺失时，Agent 容易生成看似合理但不符合业务意图的验证规格，因此需要结构化 Case 模板、上下文约束和必要审查
• 全平台统一抽象存在取舍。统一 Driver 能降低接入成本，但 Windows、macOS、Android、iOS、Web 在控件树、输入事件、权限弹窗和页面生命周期上差异明显，过度统一会损失平台特性，过度定制又会增加维护成本
• 录制与回放一致性仍是核心难点。分辨率、动画、异步加载、环境初始化和测试数据都会影响流水线稳定性，需要 Harness、显式等待、多信号定位、证据包和失败诊断共同治理
• AI 生成不等于可信验证。方案选择让 Agent 负责生成和修复，让 Harness 负责确定性执行和证据沉淀，但这也带来了规格设计、证据采集和独立验证的额外工程成本

前沿亮点

• 自然语言 Case 到可执行验证规格的生成链路：不只是让 Agent 直接操作界面，而是将需求、Code Diff、历史用例、录制轨迹和界面状态转化为结构化自然语言 Case，再生成可审查、可版本化、可执行的 YAML 规格，提升验证资产的长期可维护性
• Agent 生成与 Harness 确定性执行分层：与完全依赖 Agent 在线探索和判断不同，该方案让 Agent 负责理解、生成和修复，让 Harness 负责执行、采集和判定，既保留 AI 的生成效率，也保证回归结果可复现、可审计
• 面向全平台的可插拔 Driver 架构：通过统一上层验证规格和可插拔底层 Driver，同时支持 Windows、macOS、Android、iOS 和 Web，能够在不同 GUI 技术栈之间复用用例表达、执行流程和证据模型

听众收益

• 理解 AI Coding 时代 GUI 验证的新问题：了解 Verification Debt 在 GUI 自动化中的具体表现，以及为什么传统脚本维护模式难以跟上 Vibe Coding 的交付速度
• 获得一套可参考的全平台 GUI 验证架构：了解 MCP 接入、自然语言 Case、验证规格、可插拔 Driver、Harness 和证据包如何组合成可落地的工程体系
• 借鉴 AI 测试落地中的关键取舍：了解如何平衡 Agent 自主性与执行确定性，如何避免“AI 生成看起来正确但验证不可信”，以及如何用结构化规格和证据机制提升质量闭环的可信度

本次演讲源于支付宝生活缴费一个包含约 60 万行 Java 代码、600 多个接口的核心在线系统跨语言重构实践。系统包含复杂的业务分支、机构差异配置、分布式调用链和外部依赖。传统依靠代码评审、补充用例和上线观察的交付方式，能够发现局部实现问题，却难以证明新系统在预期业务边界内保持了老系统的关键行为。

为此，我们将重构目标从“迁移代码”转变为“迁移行为”，建立两个相互校验的 Loop：Loop 1 从老系统提取业务行为，通过 PERS 建模、Case-Forge 路径压缩和人机协同完成场景生成；Loop 2 使用 Bubble 在新系统回放相同场景，验证实际执行路径，判定新老系统的行为差异，并结合真实流量回放为分阶段切流提供依据。

本次演讲重点剖析两个工程问题：一是如何从复杂分支中提取规模可控但不失真的行为集合；二是如何识别 AI 生成用例中的路径偏移与假覆盖，并将差分结果转化为可发布、可观测、可回退的工程决策。

演讲提纲

1. 现象：代码完成了，为什么重构还没有完成

• 大规模跨语言重构面对的不是简单的语法转换，而是散落在代码分支、机构配置和外部交互中的业务行为迁移
• 代码评审通过、生成用例 PASS、覆盖率上升，都只能说明部分实现得到检查，不能证明目标业务分支真正执行
• 重构交付最终需要回答三个问题：老系统有哪些关键行为需要迁移；新系统是否真实复现了这些行为；发现差异后，能否据此作出发布决策

2. 思路：把跨语言重构转化为行为迁移

• 不要求新旧代码结构逐行对应，而是在明确的建模与可观察边界内，验证业务终点、核心返回、副作用和关键交互是否等价
• 建立两个相互校验的 Loop：Loop 1 回到老系统，确定“需要迁移什么行为”；Loop 2 进入新系统，验证“这些行为是否被真实复现”
• 将场景生成与执行验真分离。AI 可以参与理解和生成，但不能同时负责生成目标、修改数据并证明目标已经完成
• 重构交付物不再只有新代码，还包括行为模型、可执行场景、实际路径证据、差异结论以及发布与回退依据

3. 方法：双 Loop 如何贯穿重构与上线

• Loop 1 从老系统识别业务终点，使用 PERS 表达行为，通过路径压缩控制组合规模，再由 AI 补全业务数据、机构配置和 Mock 语义
• Loop 2 在相同输入和依赖响应约束下回放新系统，验证实际执行路径，并比较新老系统的业务结果和外部影响
• 两个 Loop 通过行为场景连接。每个场景都需要具备目标行为、输入约束、实际路径证据和差分结论，才能进入后续流量验证
• 整体过程形成“老系统行为提取—新系统回放验真—差异驱动修复—真实流量验证—分阶段切流”的交付链路

4. 技术深挖一：如何得到规模可控但不失真的行为集合

• PERS 将前置条件、触发事件、业务结果和副作用组织为独立于编程语言的行为描述，使老系统中的业务知识能够进入新系统验证
• 在复杂接口中，请求参数、机构配置和外部返回会共同影响执行路径。直接组合所有因素会产生场景爆炸，简单保留高频或 Top-N 路径又可能遗漏低频失败终点
• Case-Forge 首先按照业务终点组织候选路径，复用共享分支条件，对只影响局部结果的独立因素进行增量展开，并剪除约束冲突或不可达的组合
• 路径压缩的目标不是得到最少的用例，而是在执行成本可控的前提下，为每类关键业务终点保留具有代表性的可执行路径
• 确定性分析负责提供路径骨架和条件约束，AI 负责将抽象条件展开为具体的业务数据、机构配置和 Mock，人负责确认高风险终点及语义边界
• 以一个同时受请求参数、机构配置和外部返回影响的接口为例，展示如何从大量路径组合中识别业务终点、压缩候选路径，并生成人可以审查、机器可以执行的场景

5. 技术深挖二：如何识别假覆盖并完成差分验真

• 实践中曾出现这样的场景：AI 生成的用例描述合理，最终断言也能 PASS，但实际执行在前置分支提前结束，目标调用和目标业务终点并未发生
• 进一步分析发现，问题不在断言本身，而在输入、配置和 Mock 的组合没有满足目标路径约束。AI 完成了一个可以通过的用例，却没有完成预期行为的覆盖
• 因此，有效覆盖不能只检查最终断言，还需要同时确认目标终点是否到达、关键条件是否满足、必要调用是否发生、副作用是否符合预期
• 只有实际运行证据与目标路径一致，场景才计入有效覆盖。通过这一规则，将“用例执行成功”与“目标行为真实发生”区分开来
• Bubble 在相同请求和依赖响应约束下分别回放新旧系统，将行为一致性转化为一组可判定的等价约束：业务终点一致、核心返回语义一致、关键副作用一致、重要 IO 交互可解释
• 差异并不直接等于重构错误。空串与 null、时间戳等非确定字段需要归一化；老系统已有行为和本次主动变更需要单独确认；无法归因的差异则阻断下一阶段
• 离线场景验真通过后，再结合录制流量回放验证真实请求分布，并通过白名单、小流量和分阶段切流逐步扩大范围。每个阶段都需要具备明确的观测指标和回退路径

6. 经验：最终沉淀下来的工程判断

• 用例 PASS 不等于目标行为被覆盖。覆盖必须建立在实际路径证据上，而不能仅依赖用例数量、断言结果或覆盖率
• AI 可以参与场景生成，但不能独立证明自己生成的场景正确。目标定义、场景生成和执行验真需要形成相互独立的约束关系
• 老系统是行为参考，而不是绝对正确的规格。历史问题、本次主动变更和真正的重构偏差需要分类处理，不能机械追求所有字段完全一致
• 离线一致不是上线的充分条件。缺少路径证据、差异无法归因、真实流量表现不明确或没有回退能力时，都不能继续扩大流量
• 该方法不依赖单体或分布式架构。单体系统重点观察返回结果和状态变化；分布式系统还需要将外部调用、消息和副作用纳入行为边界。关键在于能否定义并观测需要保持的业务行为

实践痛点

• 行为完整性与执行成本之间存在取舍。复杂分支无法全部穷举，但过度压缩又可能遗漏低频失败行为。我们的判断规则是先保证关键业务终点不丢失，再压缩到达同一终点的等价路径
• AI 生成效率与路径真实性之间存在冲突。实践中出现过用例断言通过、目标调用却未发生的假覆盖。如果只统计 PASS 数量，会高估重构验证程度，因此必须引入独立的实际路径证据
• 严格一致与生产差异之间存在冲突。逐字段比较会被空值表达、时间戳等差异产生的噪声淹没；整体放宽比较又可能掩盖真实业务偏差，因此需要按业务终点、核心语义、副作用和 IO 交互进行分层判定
• 离线可重复与线上真实性之间存在取舍。离线场景便于复现和定位，但无法覆盖全部真实请求分布；真实流量更接近生产环境，却需要控制影响范围并保留快速回退能力

演讲亮点

• 建立面向大规模 AI 重构的双 Loop 方法，将老系统行为提取、新系统回放验真和上线切流连接起来，使 AI 重构从代码生成延伸到可验证、可发布的完整交付过程
• 将覆盖判断从“用例是否通过”升级为“目标行为是否真实发生”，通过实际路径证据识别 AI 场景中的路径偏移与假覆盖，并利用分层行为等价约束形成差异归因和发布依据

听众收益

• 理解为什么代码评审、覆盖率和用例数量无法单独证明大规模重构的正确性
• 掌握以业务终点组织行为模型、压缩复杂路径规模并控制场景成本的方法
• 掌握 AI 语义展开的适用边界，以及路径偏移和假覆盖的识别方法
• 掌握新老系统差异的分层判定方式，以及从离线验真、真实流量回放到分阶段切流的工程决策框架

AI 提升了编码效率，但一人完成三端交付仍面临业务理解不一致、长流程易中断和评测成本高等问题。本分享介绍 Hybrid Coding Agent 的 Harness 实践：外环统一契约与任务编排，内环将验证贯穿方案、编码与构建，以反馈驱动各端生码和修复；通过结构化 Journey、脚本执行和封存证据提高评测可靠性，并将失败与修复沉淀为知识、Skill 和回归用例，驱动生码与评测共同演进。实践覆盖 10 大场景、约 65.5 万行代码重构与评测上线，线上 Bug 下降 80%，展示如何将单端编码提效转化为三端交付能力。

演讲提纲

1. 背景：从单端编码提效走向一人主导三端交付

• 多端协作的交付成本： 同一业务需求需要在 Android、iOS、Msite 三端实现。传统方式由各端独立理解、设计和开发，容易产生重复沟通、业务语义差异、进度等待与后期联调返工
• AI 生码提速后的工程缺口： 代码可以更快生成，但参与端识别、依赖协调、环境准备、验证与修复仍需衔接。并行生成能力需要与统一目标和状态管理配套，才能形成完整交付
• 验证效率决定三端交付能否提速： 一人主导三端交付后，如果验证仍依赖逐端操作、人工判断和反复确认，就会成为交付瓶颈。需要将验证贯穿生码全过程，及时反馈并驱动修复，让并行生码的效率转化为整体交付收益
• 目标：一人负责目标，Agent 协同完成三端交付： 由研发明确业务目标和关键取舍，Harness 组织多端实现与验收，并把每次执行经验沉淀为后续可复用的能力

2. 架构：外环协同编排与内环生码验证

• 外环统一需求与交付状态： 从需求澄清、参与端识别、跨端契约到任务依赖和验收结果，外环维护统一目标，组织各端执行，并汇总阻塞与待决策事项
• 验证贯穿整个生码阶段： 需求阶段明确验收目标，方案阶段检查跨端契约和可测性；编码过程中按任务执行逻辑测试与架构检查，构建后进行运行验证。每轮反馈都用于校正实现与局部修复，使验证随代码逐步完成
• 持续自验证与独立验收相互补充： 生码过程中持续验证逻辑、工程约束及具备运行条件的模块行为；交付前再对 UI、交互和埋点进行独立验收，补充端内检查难以发现的业务差异。生成器消费失败证据修复，评估器依据既定标准复验
• Skill 与工具形成可组合能力： 编排层负责阶段衔接和人机交互，原子能力承接仓库探索、构建、设备操作、评测等具体任务，通过明确的输入输出连接起来
• 人机协同与停止条件： Agent 处理能够通过工程事实判断的问题；无法推导的业务取舍、范围调整和最终交付决策由人负责。重复修复不收敛时停止并汇总证据，避免无效循环

3. 关键设计一：通过契约与上下文工程提高三端生成一致性

• 业务契约先于端内实现： 将需求拆解为共享功能点、接口语义和验收目标，再由各端生成实现方案，允许技术实现不同，同时保持触发条件、异常行为和埋点口径一致
• 按角色装配必要上下文： 编排器读取全局计划与状态，生成器读取端内方案、源码和规范，评估器读取验收标准与运行证据，减少无关信息和重复全文注入
• 分层知识与渐进式加载： 区分全局规范、跨端领域知识、端内实践和单次任务产物，通过索引与工件路径加载当前阶段所需内容，控制上下文规模和版本差异
• 计划作为持久化工作记忆： 将任务阶段、端内状态、产物路径、阻塞原因和下一步动作写入计划，支持跨会话恢复；会话内复用端内 Worker，减少重复探索
• 方案与测试同步设计： 在方案中明确业务断言、路由、模块标识、交互定位、Mock 协议和测试映射，先确定如何验证，再按任务生成实现与测试。随着代码逐步具备运行条件，及时验证模块行为，缩短问题发现与修复的间隔
• 案例：下单挽留弹窗： 从展示条件、展示次数、继续下单、确认离开与埋点口径出发，展示统一业务规则如何落到三端不同的退出机制和组件实现

4. 关键设计二：以持续验证反馈驱动生码与可信验收

• 验证随任务推进： 将验证目标关联到具体生码任务，逻辑与工程检查随实现执行，设备验证在模块具备运行条件后介入；未通过的检查形成修复输入，修复后复验，最后汇总为交付验收证据
• 从测试意图到执行契约： 测试计划描述“验证什么”，Journey 固化执行环境、操作步骤、定位信息和检查点，将自然语言中的隐含前提转化为可检查输入
• 可控数据与页面直达： 用协议校验约束 Mock 字段、类型与挂载位置，通过页面直达聚焦当前模块，减少外部依赖和无关操作；真实入口与完整业务链路另行验证
• 脚本执行与 Agent 消歧分层： 设备能力层统一环境设置、操作和观察。脚本按步骤执行，遇到定位歧义或页面阻塞时由 Agent 介入，处理后返回既定流程
• 证据包与独立评估： 按步骤保存截图、UI Tree、埋点和日志，评估器只读封存产物，避免在判断过程中改变运行现场、验收目标或业务代码
• UI、交互与埋点的判定机制： UI 通过坐标归一化、锚点定位和匈牙利匹配比较设计树与运行时树；交互依赖显式断言与前后状态证据；埋点采用事件与参数规则校验
• 无法可靠判断时保留未决： 确定性规则先处理可判定项，Agent 复核未决项。缺少基线、证据不全或定位置信度不足时，不强行输出通过结论；修复后重新采证和复验，保留原始失败记录

5. 持续演进：让真实问题同时改善三端生码与评测

• 从完整执行现场提取反馈： 保存需求输入、代码产物、操作轨迹、失败证据和修复过程，区分需求理解、方案、生码、环境执行与评估规则的问题。
• 生成侧沉淀业务与工程约束： 将经过确认的业务规则、端间差异、框架用法和架构约束写入对应知识与 Skill，让后续三端生成提前规避同类错误。
• 评测侧沉淀执行与判断经验： 将环境准备缺口、定位失败、采证不足和误判原因转化为工具与规则改进，减少重复探索，提升验证效率与准确度。
• 失败与修复转化为回归资产： 将触发条件、失败现场与正确行为组织为可复现案例，既检验生成产物，也检查工具调用、执行路径与证据是否符合要求。
• 按范围更新，避免过度泛化： 端内经验进入端内知识，多端共性进入共享规范，编排和工具问题进入对应能力层。每条经验需要明确适用条件。
• 用固定案例检验 Harness 更新： 在可比输入与环境下回放案例，从产物质量、过程质量和耗时观察变化。改进生码与评测时保持验收约束，避免通过放宽标准获得更高通过率。

6. 实践效果：业务覆盖、代码产出与线上质量

• 三端业务覆盖： 覆盖下单、搜索、详情、SKU、首页、推荐瀑布流、购物车、订单、类目、物流 Tracking 共 10 大核心场景，支持 Android、iOS、Msite 三端，并结合 AHE 跨端实现能力。
• 生成与评测规模： 累计生成 654,763 行代码，约 65.5 万行，并完成对应质量评测
• 线上质量效果： 线上 Bug 数量下降 80%，用于观察整体实践的业务质量结果；同时保留运行证据与失败明细，支撑具体问题分析
• 持续改进的观察方式： 关注业务验证范围、验收产出时效、重复错误和判断准确性，检验经验积累是否改善后续需求，而非只统计执行次数或通过率

实践痛点

• 三端自动交付需要将原本由研发人员隐式承担的业务理解、技术差异处理、过程协调和结果判断，转化为明确的契约、工具与反馈机制
• 并行生码可能放大理解偏差。 如果共享业务规则不清晰，各端可能生成各自合理但行为不一致的实现，因此需要先对齐业务契约，并保留端内实现空间
• 上下文增长可能带来噪声和过期信息。 仅增加知识量会提高读取成本，甚至引入版本冲突，需要按角色和阶段加载，并以持久化状态支持恢复
• 运行成功与业务正确之间仍有距离。 构建通过、操作完成或页面变化不能单独证明需求实现，必须将验收目标关联到实际运行证据
• 误判会反向影响代码生成。 环境异常若被当作代码缺陷，修复循环会产生无效修改；需要区分恢复环境、补充证据、校准规则和修改代码
• 经验沉淀也可能传播错误。 一次修复未必适用于所有端和场景，需要经过复验、记录适用条件并用回归案例验证，再进入共享知识或工具规则
• 统一验证存在平台与业务边界。 UI 树、布局单位和生命周期存在端间差异，Mock 与页面直达也无法替代真实业务链路，需要明确统一能力与专项验证的分工

前沿亮点

• 面向三端交付的双循环 Harness： 外环统一业务契约、任务状态与阶段编排，内环承接各端生码、自验证和修复，使一人主导的交付过程具备明确边界与可追踪状态
• 贯穿生码全过程的验证机制： 将验收目标与可测性前置到需求和方案，在编码、构建与运行中持续验证并驱动修复，再以封存证据和独立评估形成交付结论
• 三端生码与评测共同演进： 同一真实问题可以同时补充生成侧知识和评测侧规则，再通过固定案例回测检验更新，使每次需求交付产生可复用的工程资产

听众收益

• 理解多端 AI 交付的工程挑战： 了解为什么单端生码提速之后，跨端一致性、上下文管理、验证与反馈成为新的制约因素
• 获得可参考的 Harness 架构： 掌握外环编排、端内生码、分层知识、持久化状态和独立验收的职责划分与协作方式
• 借鉴生成与验证的关键取舍： 理解如何将验证贯穿方案、编码、构建和运行，通过契约、结构化 Journey 和证据机制提供及时反馈，避免问题积累与无效修复
• 掌握持续演进的方法： 学习将失败现场、修复经验转化为知识、Skill 和回归用例，并通过产物、过程和耗时检验 Harness 改进效果

Vibe Coding 时代，代码生产力激增，质量债加速累积，传统 AI 审查“只发现不闭环”。本课题分享 AICR 以点破面的实践：通过 MCP 上下文扩展、多 Agent 异构协同、增量追踪与集成交付闭环，将审查从“能审”推进到“审准、审得起、审出闭环”；并进一步联动 SonarQube 静态扫描、部署、单测、接口自动化等节点，借助 ACP 编排业务自定义 Agent，双向印证、降噪提效。最终展望静态 AICR 与动态智能测试双向补齐，构建多 Agent 协同的质量网络，为 Vibe Coding 时代的新质量债提供可落地的治理范式。

演讲提纲

1. Vibe Coding 时代，Code Review 的质量挑战

• 代码生产力与验收能力的剪刀差
• 三种 AI 审查形态的断裂：直调 LLM / IDE内嵌 / CI 后置扫描
• AICR 以点破面：构建能闭环的质量债审查体系
• 技术架构全景速览

2. 让 AI 从“看代码”到“懂业务”

• 审查前：动态上下文拓展
• 审查中：MCP 调度动态拉取需求文档、仓库文件、运行时数据
• 多维配置驱动注入

3. 多 Agent 与增量：放大审查效果，完成工具层闭环

• 异构多轮次采样：不同模型视角互补，CDS + MAS 动态决策轮次
• 异质垂类分工：主审查 Agent + 垂类 Agent 矩阵
• 增量评审：只审 Commit/Push 变更，语义去重过滤噪音
• 路由与编排：多轮采样 + 主/子/辅助 Agent 调度多轨协同

4. 集成交付与反思闭环：让审查结果真正落地

• 双 Agent 联动闭环流程：Push 触发→审查报告→企微通知→修复→追踪验证
• 数据驱动改进：一键采纳/一键忽略，反馈回流自学习
• 典型高价值案例
• Bug 根因分析与 Agent 自沉淀

5. 自动化节点与 AICR 双向联动及 ACP 编排

• 静态扫描智能评审：双向印证代码质量
• 传统 CICD 自动化赋能：借 AI 智能，还确定性验证
• ACP 编排：联动业务高度自定义 Agent，复用能力、拓展边界

6. Coding 时代质量保障体系的未来演进与规模化落地

• 落地效果：20000+ 高价值问题发现，全业务线接入
• 动静结合展望：AICR 与动态智能测试双向补齐，多 Agent 生态协同

实践痛点

• 依赖流程事件驱动，适合体系化实施，较不适合个人试用拓展
• 独立沙箱、Agent 审查保障标准化、客观性，但缺少 Coding 阶段的审查灵活前置性

演讲亮点

• 基础、深度的上下文拓展
• 工具层闭环
• 流程闭环
• 体系联动，规模化收益

听众收益

本演讲将帮助听众看清 Vibe Coding 时代质量债的根源，理解为何“只发现不闭环”的 AI 审查必然失效；掌握 AICR 以点破面的可复用框架——MCP 上下文扩展、多 Agent 异构协同、增量追踪与集成交付闭环，并可迁移到测试生成、文档巡检等场景；学会更高效地使用 AICR，知道它擅长抓哪些高危问题、如何通过采纳/忽略反馈让它越用越准；了解传统自动化工具与 AICR 双向联动的落地方法，实现降噪、召回、提效、可追溯；并获得动静结合的质量体系演进视野，为团队治理新质量债提供可落地的路径参考。

随着 AI Coding 工具普及，代码生成大幅提速，但测试验证没有同步跟上——生成与验证之间的缺口正沉淀为一笔“验证债”，传统后置测试已难以偿还。

本次分享基于飞猪真实业务的落地实践，介绍我们“还债”的基本思路：QA 判断前置、质量左移，由 AI 承担规模化执行。目前用例采纳率稳定在 85% 以上，80% 左右的用例可由平台自动执行，UI 自动化成功率稳定在 85% 以上，单需求平均验证周期从 3 天缩短至 1 天左右。内容以一个真实需求为主线，讲清落地要跨过的三道坎——测得准（AI 与人在用例生成、执行上的认知对齐）、接得住（与产品、研发、视觉等多角色协同完成上线闭环）、铺得开（接口与 UI 自动化从跑通链路到真正覆盖业务）。

分享结合真实 Case，说明 AI 在各测试环节的效果、依赖条件与能力边界，以及哪些环节还得靠人。

演讲提纲

1. 什么是“验证债”：AI 一天写出的代码，我们测了一周

• 速度断层的形成：代码生成效率大幅跃升，验证能力原地踏步，缺口持续累积为“验证债”
• 传统后置测试无法承接：用例编写、执行、结果判定集中压后，量级一旦放大将无法承接
• 还债的基本思路：质量判断前置，QA 角色左移，由 AI 承接规模化执行

2. 如何“还债”：AI Native 测试在飞猪的落地实践

• 测得准：对齐“测什么、怎么算对”
  • 认知偏差根源：需求上下文缺失、判定标准不一致
  • 生成怎么保证准：生成前先对需求/技术方案做完备性检查，识别缺失信息并补齐后再生成；业务知识库与历史用例作为生成输入；生成结果定位为候选池，由 QA 按业务规则 Review 收敛，以采纳率量化生成质量并反哺生成规则
  • 执行怎么保证准：用例自带结构化验证点，机器转译为可执行断言（接口侧转译为断言表达式，UI 侧采用文本 + 视觉语义双重检查点），执行阶段不做二次理解
  • 前后一致性怎么做到：用例生成、case 识别、数据构造、执行共用同一份结构化用例契约，验证点从生成端直通执行端，执行结果回写到用例粒度，全程可追溯
• 接得住：AI 融入多角色协同的全流程
  • 质量前置：与产品、开发协同，提测前基于完备性检查清单完成需求准入的问题识别，把字段、交互、异常分支的缺口清单化
  • 质量后置：与视觉、开发打通，通过设计稿与页面实际渲染的自动化比对，完成视觉稿的自动化验收闭环，差异以清单形式回流
  • AI 在各环节的实际介入方式与效果：AI 产出、人工在准入与准出等关键节点做确认门禁
• 铺得开：从“跑通链路”到“真实业务覆盖”
  • 用例分轨机制：按数据构造能力与执行引擎能力边界，将用例自动判定为接口自动化 / UI 自动化 / 人工三轨，避免把执行不了的用例硬塞给 AI
  • 接口与 UI 自动化方案的迭代演进与执行成功率提升：断言分层转译、执行加固（显式等待、异常弹窗处理、失败重试）
  • 规模化交付路径与真实案例演示：Skill 与后台 Agent 两种交付形态，支撑批量需求测试

3. 对账：AI 能做什么，哪些仍需依赖人

• 能力边界：AI 已可承担新功能用例生成、接口/UI 自动化执行；仍需 QA 接入的是存量场景影响评估、业务数据构造、风险研判与准出结论
• 演进制约：业务知识与历史用例沉淀不均衡；数据构造的瓶颈在于特定业务状态的生成
• 下一阶段的债：失败用例自动归因、数据构造能力建设、知识库自更新机制探索

实践痛点

• 认知不一致的问题很难做到彻底消除，只能在“前置 Review”和“后置 Review”里找平衡
• 效率本质没有想象中提升的那么多，因为自动化覆盖的天花板不在 AI，而在于数据和环境

演讲亮点

• AI Native 测试在飞猪真实需求中跑通并产生实效，可为同类团队直接借鉴
• 把零散的 AI 测试实践收敛成一个可复用的三支柱模型，并配真实 case 与能力边界分析
• 明确 AI 已能承担与仍依赖 QA 的环节，以及落地所需的数据构造、知识沉淀等前提

听众收益

• 理解 AI 生成代码时代“验证债”的成因，以及质量左移 + AI 规模化执行的应对框架
• 掌握 AI 与人在用例生成、执行环节的认知对齐与信息补齐方法
• 掌握接口 / UI 自动化从链路跑通到完整覆盖业务需求的演进路径
• 获得一份可迁移的落地清单：AI 能接哪些环节、需要什么前置条件、还有哪些坑