一句话：和 Agent 配合，验证看证据。但证据要花在刀刃上——不是每轮改造都端到端验证，而是重要节点强制自证 + 日常靠人抽查，把验证成本压到最低、把返工率打下来。
现象：AI 的"应该没问题"是最廉价的断言
让它改一段逻辑，10 次里有 9 次结尾都是同一句话：“改好了，应该没问题。”
"应该没问题"没有成本，也不可信：
-
它看不见运行态——语法对 ≠ 行为对；
-
它对自己的输出天然自信——推理链路无论对错，语气一样确定；
-
最要命的是它会"自欺"——自测走的是它自己预设的路径，测不到它没考虑过的 case。
但真相是：端到端验证很贵，不能每轮都上
写脚本、跑真实链路、贴大段响应回来——每一步都在烧 token 和时间。如果每轮改造都这么来，人会陷入"一套套看证据"的疲惫，Agent 也在重复劳动，上下文会暴增、任务完成质量也会越来越低。验证的边际收益会迅速归零。
所以正确的姿势不是"全量验证"，是分级：
什么时候必须验（重要节点，三选一就上）
-
跨层/链路级改动：动了协议、RPC、存储、前后端数据流——这类错一处，外观完全正常但行为全歪；
-
收尾交付前：准备从"能跑"变成"要用"的时刻；
-
老 bug 复发区的改动：同一个模块修过一次还出问题，说明它有隐藏依赖，别信口头保证。
什么时候不用每轮验（省 token 的重点）
-
单文件、纯函数小改：改个常量、算法分支，肉眼 + 抽查足够；
-
可再生成的资产：Agent 造的临时工具/脚本——错了大不了重生成，不需要为它建完整验证管线。
怎么验：三步，收口到节点
1. 在节点处立规矩
对话里明说（只在节点轮说，别写进全局约束）：
这次是跨层改动，收尾后写一个端到端验证脚本，打真实接口，
把真实响应贴给我看，而不是说"应该没问题"。
2. 贴真实响应，不贴结论
脚本输出原样贴出来。半截 JSON、错误码、字段缺失，一眼可见，不需要懂全部实现。
3. 人抽查，不放跑
你不是替它重跑，而是抽查它贴回来的响应。抽查成本低，但能挡住"自测路径正确、用例没覆盖到"的盲区。
案例：它自测全过，我抽查抓到一个隐藏 bug
有轮链路级改造，它报告"脚本全过"，我抽查响应时发现：同一个工具被调用了两次。
真相是：工具结果消息被回填到了用户消息之前，模型把"执行任务的指令"又看了一遍，照着又执行了一次。这样一个"用例对、链路逻辑也通"的 bug，靠它自证永远测不出来——它的用例里根本没"轮次顺序"这一条。
而这正是节点验证的场景：脚本负责可重放，人负责找它没想过的问题。
如何验证
验证脚本骨架（Node，打真实接口）：
// 端到端自证脚本：跑完把真实响应打印出来，贴给用户看
async function rpc(method, params = {}) {
const res = await fetch("http://127.0.0.1:8787/rpc", {
method: "POST",
headers: { "content-type": "application/json" },
body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params }),
});
return (await res.json()).result; // 真实响应，不脱敏
}
// 用例 1：造工具链路
console.log(await rpc("proposals.upload", {/* ... */}));
// 用例 2：调用工具链路
console.log(await rpc("tools.call", {/* ... */}));
注意：脚本里不要 catch 吃掉错误——想让用户看到的恰恰是异常本身；输出保持 JSON，别包装成"测试通过"。脚本是消耗品，用一次打一次，别保存成永久资产。
写在最后
验证是有成本的资源，花在关键节点上才划算。和 Agent 协作的性价比排序大概是：重要节点强制自证 > 日常人工抽查 > 每轮全量验证。
