一、问题：90%时间在做表面功夫

现状统计：

工作内容	时间占比
写代码、做设计	10%
手动测试、验证	90%

痛点分析：

痛点	说明
手动验证	点网页、输入数据、盯着Agent跑、人脑判断好坏
系统不确定	改一句prompt可能崩掉，且无法一眼看出是否真的坏了
反复循环	只能再跑一遍、再跑一遍，用感觉判断对错

---

二、理论基础：验证不对称性

来源： 2025年OpenAI/Meta研究员Jason Wei提出

Verifiers Law（验证者定律）：

任何易于验证的任务，终将被AI解决。

核心洞察：

维度	传统任务	AI Agent任务
生成	较贵	便宜
验证	较贵	依然很贵

解决思路：

• 把”肉眼判断”变成”自动可重复的验证体系”
• 把难验证的问题改造成容易验证的问题
• 一旦容易验证，按定律，剩下的交给AI

---

三、类比：芯片行业的经验

冷知识： 芯片行业写代码的人比验证的人少

阶段	人力投入
设计	1x
验证	2-3x 或更多

原因： 芯片一旦流片出错，几百万美金打水漂，没有改Bug重来的可能。

芯片验证核心：

• 设计回归测试体系
• 主动暴露Bug
• 埋下检查点
• 衡量测试覆盖度

类比到AI Agent：

• AI让写代码变便宜（就像EDA让写Verilog变容易）
• 新的价值点：能否设计一套体系，让AI的每次改动都可被验证

---

四、解决方案：构建可验证架构

第一步：前后端分离

为什么之前痛苦：

• 系统入口是网页UI，是给人用的
• 要测试就得有人在那点、输入
• 从第一天起就是为人的手和眼设计的

面向AI Agent开发的三个核心问题：

问题	说明
脱离UI能跑吗？	系统在没有人的手和眼睛之后，还能独立运行吗？
中间状态可见吗？	运行过程中的信息，有没有留下足够多让另一个AI能看懂？
接口为AI设计吗？	有没有专门设计接口，让AI能自主拿到它需要的信息？

两条路：

方案	说明	优劣
MCP模拟操作	用MCP调用模拟网页操作，让Agent直接独立访问	有边界case和效率问题
前后端彻底分离	后端变成独立Agent，所有调用做成命令行控制	直接、快速、彻底

选择： 前后端彻底分离

ACI（Agent Computer Interface）概念：

• 来自普林斯顿SWE agent论文
• AI Agent是全新的用户，和人不一样
• 需要专门给它设计接口
• 接口设计的好坏，对Agent表现的影响甚至大过换更强的模型

---

第二步：两层裁判体系

问题： 谁来当裁判？

Agent输出是自然语言、运行路径，不是直接相减的数字，传统pass/fail不够用。

解决方案：

层级	类型	特点
第一层	确定性断言（Assertion）	绝对可靠、确定性、零成本
第二层	LM裁判（Supervisor）	处理模糊部分，量化打分

第一层：确定性断言

• 工具是否触发
• 中间状态有多少条路径
• 覆盖到哪些情况

第二层：LM裁判

• 上下文干净，不参与开发，只看预期
• 不判断对错，而是量化打分
• 通过分数判断最终结果好坏程度

---

第三步：持续积累测试案例

两类测试：

来源	说明
Happy Path	基于验收标准设计的快乐路径
真实输入	从真实用户/测试中捞五花八门的输入

功能开关（Feature Flag）：

• 每加一个新功能，配一个开关
• 开/关两个版本跑同样回归测试
• 清楚看到新功能带来什么：哪些变好，哪些被悄悄弄坏

---

第四步：形成闭环

在Codex中的工作流：

设计回归测试 → 设计功能开关 → 编写代码 → 开/关分别跑回归测试 → 根据结果反馈修改 → 直到通过

关键： 整个过程人没有参与，Coding Agent通过可验证体系把一切连成闭环。

---

五、核心结论