专题演讲嘉宾：何伟

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 改进效果