当 AI 编码代理必须证明自己写对了

这项进展的关键不只是模型能否生成测试代码，而是代理是否能建立一条可检查的证据链：执行过程、通过条件，以及明确列出的未测试区域。软件交付的基本单位因此从“生成了一个补丁”变成“在规定条件下实际运行过这个补丁”。语法检查适合发现明显错误，却无法替代对真实行为的验证；录屏和报告把验证结果带进了代码评审流程。

实现机制应当被拆成多个相互独立的环节。代理需要理解需求或缺陷截图，修改代码，选择测试路径，操作模拟器或产品环境，观察结果，再把观察内容整理成报告。任何环节都可能失败。报告写得准确，不代表测试路径足够；录屏显示程序启动，也不代表关键业务性质已经被断言。评估时必须把补丁生成能力和验证能力分开测量。

证据首先要有出处。每次运行都应绑定提交或构建版本、模拟器配置、输入序列、测试数据、依赖服务和时间戳。报告还要区分自动断言、视觉观察和“没有观察到错误”。否则，“代理没有发现问题”很容易被误读为“相关性质已经得到测试”。原文确认了录屏、通过项和未覆盖项的形式，但没有规定完整的追踪字段；这些字段应由采用方补齐。

最大的瓶颈是覆盖范围的选择。代理很可能反复执行最容易成功的主流程，同时产出看起来完整的材料。截图驱动的修复也有边界：修复后截图能够说明某个可见状态发生变化，却不能证明响应式布局、无障碍、数据持久化、网络失败、权限控制和相邻流程都没有回归。产品状态越开放，越需要在运行前定义不变量、负面用例和恢复路径。

因此，减少人工读代码并不等于取消评审，而是改变评审重点。工程师可以少看一部分低风险胶水代码，把时间投入接口变化、安全敏感逻辑、数据迁移和遗漏状态的检查。但这会产生新的自动化偏差：一段制作精良的录屏可能制造“已经覆盖全面”的错觉。证据质量本身必须成为评审对象，不能只检查补丁是否存在。

环境稳定性决定了这套流程能否真正节省时间。移动模拟器、桌面容器、凭据、第三方服务、特性开关和预置数据都可能引入非确定性。若没有隔离副作用、固定测试数据并保存完整构建产物，失败就难以重现，代理生成的证据也难以被另一位工程师复核。速度收益可能转化为更昂贵的环境排障，因此基础设施是方案的一部分，而不是附属条件。

可复现实验应使用同一批固定仓库、缺陷工单和种子数据，对照团队现有流程。记录逃逸缺陷、依据人工评分表计算的测试计划覆盖率、结果复现率、评审耗时，以及把未测试路径错误标为通过的比例。还要按 Web、后端、桌面和移动任务分层，并分别统计生成补丁与验证结果。OpenAI 的材料只提供案例叙述，没有这些指标；企业应先测量，再决定是否减少人工评审。