Codex完成一个任务后，经常会给出这样的总结：

已修复问题。
相关测试已经通过。
没有发现其他风险。

如果只是个人写一个小工具，这句话也许够用。

但当Agent开始修改支付逻辑、重构公共模块、更新多个仓库，甚至连续工作几个小时以后，团队不能只凭一句“完成了”决定是否合并。

因为“Agent认为完成”和“工程上能够证明完成”，是两件完全不同的事情。

真正可靠的交付，需要回答：

修改了什么？
为什么这样修改？
原问题是否真的复现过？
修复后用什么证明有效？
哪些测试运行了？
哪些没有运行？
中间失败过几次？
当前还有什么没有验证？
谁最终批准了风险？

这些信息连起来，就是本文要讨论的：

AI Evidence Chain——AI工程证据链。

它的核心不是让Agent输出更长的总结，而是让每一次AI交付都留下可以复核、交接和追踪的证据。

---

一、为什么“测试通过”仍然不能代表任务完成？

假设Codex修复一个订单状态Bug，最后告诉你：

修改完成。

测试：
24 passed

结果：
订单状态问题已经解决。

看起来非常完整。

但真正Review时，还要继续问：

测试的是哪24个测试？

可能只运行了某个单元测试文件，并没有运行完整订单流程。

原问题真的复现过吗？

如果Agent从来没有成功复现Bug，那么测试通过只能说明新代码没有触发现有测试失败。

修改范围是不是合理？

Bug只涉及订单状态，却可能顺便修改了缓存、日志、类型定义和公共工具函数。

测试有没有被改弱？

有时“测试通过”的原因不是代码变正确，而是测试断言被删除或修改。

哪些内容没有验证？

例如：

• 没有测试并发；

• 没有测试旧客户端；

• 没有测试生产配置；

• 没有运行完整集成测试。

因此：

PASS只是证据之一，不是最终结论。

---

二、AI Evidence Chain到底是什么？

AI Evidence Chain可以理解为：

从任务输入到最终批准，每一个关键判断都有对应证据，并且这些证据能够互相连接。

一个完整链路可以写成：

需求
 ↓
问题复现
 ↓
根因证据
 ↓
修改Diff
 ↓
测试结果
 ↓
运行时验证
 ↓
独立Review
 ↓
剩余风险
 ↓
人工批准
 ↓
最终交付

其中任何一环缺失，可信度都会下降。

例如：

只有Diff，没有复现证据：

不确定修改解决的是不是原问题。

只有测试，没有Diff检查：

不确定有没有夹带无关修改。

只有Agent Review，没有测试：

只能证明“看起来合理”，不能证明运行正确。

只有全部自动化结果，没有人工批准：

高风险业务决策可能没人真正承担责任。

所以Evidence Chain不是单项质量检查，而是一条连续链。

---

三、第一类证据：任务输入证据

Agent开始执行前，也需要证据。

很多失败并不是发生在代码阶段，而是任务一开始就理解错了。

例如Issue写：

用户登录后偶尔被踢回登录页。

Agent可能理解为：

• 登录接口失败；

• Token过期；

• 路由守卫错误；

• Session丢失。

如果没有进一步事实，它只能猜。

因此任务开始时至少要记录：

任务目标：
原始Issue：
已确认事实：
复现条件：
相关模块：
允许修改范围：
禁止修改范围：
完成标准：

特别重要的是把：

已确认事实

和：

Agent推测

分开。

例如：

已确认：
问题只发生在Token刷新后。

未确认：
可能与路由守卫重复触发有关。

这样后面的Agent不会把一个猜测当成事实继续传播。

---

四、第二类证据：问题复现证据

修Bug之前，最好先建立Failure Evidence。

也就是：

修改之前，系统到底是怎么失败的？

可以是：

• 错误日志；

• 测试失败输出；

• 页面截图；

• 视频；

• API响应；

• Trace；

• 数据库状态；

• 可重复执行的复现步骤。

例如：

复现环境：
staging

步骤：
1. 登录测试账号
2. 等待Token过期
3. 刷新页面
4. 自动Token刷新成功
5. 页面再次跳回/login

复现次数：
5/5

关键日志：
refresh_token success
route_guard unauthenticated
redirect /login

有了修改前证据，后面才能做真正的：

Before / After

比较。

否则Agent很容易修复一个“理论上的问题”，却没有解决用户真正遇到的Bug。

---

五、第三类证据：根因证据

Agent找到根因后，不应该只说：

问题是Token刷新逻辑导致的。

应该说明为什么。

例如：

根因：
Token刷新成功后，用户状态写入Store是异步操作。

证据：
auth.ts第118行已经拿到新Token；
router.ts第64行在Store更新前读取authenticated=false；
因此触发/login跳转。

排除：
后端刷新接口返回正常；
Token内容有效；
Session没有丢失。

这类证据很重要，因为：

修复方案的可信度，取决于根因判断是否成立。

如果根因判断错了，即使代码写得很好，也只是对错误问题进行了漂亮修改。

建议根因输出至少包含：

• 已确认根因；

• 支持证据；

• 被排除的候选原因；

• 当前仍未确认的部分。

---

六、第四类证据：Diff Evidence

代码修改以后，需要证明：

Agent究竟改变了什么？

不要只让它输出：

修改了认证逻辑。

更有效的是：

修改文件：
src/auth/refresh.ts
src/router/guard.ts
tests/auth-refresh.test.ts

核心变化：

1. Token刷新成功后等待用户状态提交完成；
2. 路由守卫增加refreshing状态判断；
3. 新增Token刷新期间导航测试。

未修改：
后端接口
Token结构
公共路由API

随后再检查真实Git Diff。

Diff Evidence重点回答四件事：

修改是不是在任务范围内？

有没有无关重构？

有没有删除测试或降低断言？

有没有改变公开接口？

一个非常实用的规则是：

Agent总结只能做索引，Git Diff才是修改事实源。

---

七、第五类证据：Validation Evidence

测试证据不能只有：

Tests passed.

至少应该记录：

执行命令：
pnpm test auth
pnpm typecheck
pnpm lint

结果：
auth：28 passed
typecheck：passed
lint：passed

未运行：
完整E2E

原因：
本地缺少支付测试服务

这最后一项非常重要。

很多AI交付的问题不是测试失败，而是：

没跑的测试没有被说出来。

因此验证报告应该同时包含：

• 已执行；

• 已通过；

• 已失败；

• 已跳过；

• 无法执行。

“没有证据”不能被自动解释成“没有问题”。

---

八、为什么还需要运行时证据？

代码测试通过，并不一定说明真实流程正常。

尤其是：

• UI；

• 网络交互；

• 异步状态；

• 权限；

• 数据库；

• 多服务系统。

这些问题往往需要运行时验证。

例如一个前端Bug，可以要求：

修复前：
页面刷新后跳回登录页。

修复后：
页面保持当前页面，
Token刷新完成，
用户状态恢复。

验证：
连续执行10次，
10次均未出现重复跳转。

如果条件允许，还可以保留：

• 截图；

• 浏览器Console；

• Network请求；

• 服务日志；

• Trace；

• 性能指标。

这类证据证明的是：

系统实际上做了什么。

而测试证明的是：

预先定义的检查是否通过。

两者不能完全互相替代。

---

九、第六类证据：独立Review

让实现Agent自己说：

我检查过了，没有问题。

可信度有限。

因为实现Agent已经形成自己的方案路径，很容易重复原来的判断。

更好的方式是：

实现和审查分离。

Review Agent只接收：

• 任务目标；

• 完成标准；

• 最终Diff；

• 测试证据。

然后要求：

不要修改代码。

重点检查：

1. 是否真正解决原问题；
2. 是否存在无关修改；
3. 是否遗漏边界场景；
4. 是否改变公共接口；
5. 测试是否足够证明结果；
6. 是否存在兼容性或安全风险。

按P0 / P1 / P2输出。

如果Reviewer提出P1问题，修复后必须重新产生新的Evidence。

这会形成：

Implementation
 ↓
Evidence
 ↓
Review
 ↓
Fix
 ↓
New Evidence
 ↓
Re-review

而不是：

Review一次就永久有效。

---

十、重试后为什么旧证据可能失效？

这是Agent系统非常容易忽略的问题。

假设第一版修改运行：

42 tests passed

随后Review发现问题，Agent又修改了三个文件。

此时原来的：

42 tests passed

还能不能证明当前代码正确？

不能直接证明。

因为测试对应的是旧版本代码。

所以Evidence必须与具体版本绑定。

至少记录：

Commit / Diff：
abc123

测试：
42 passed

Review：
P1：缓存失效逻辑存在遗漏

修复之后：

Commit / Diff：
def456

重新测试：
44 passed

Review：
无P0/P1

这样才构成真正连续的证据链。

可以记住一句话：

代码变了，关键验证证据就应该重新生成。

---

十一、完整案例：线上Bug怎样形成Evidence Chain？

假设问题是：

用户支付成功后，订单偶尔仍然显示“处理中”。

阶段一：任务输入

目标：
修复支付成功后订单状态没有更新的问题。

限制：
不修改支付协议；
不修改数据库结构；
生产数据只读。

阶段二：复现

Agent在测试环境成功复现：

支付成功：是
支付回调：收到
订单最终状态：processing
复现率：4/5

阶段三：根因

发现：

支付回调处理成功后，
消息消费者更新订单时发生数据库Timeout。

消费者没有重新投递失败消息。

证据包括：

• 回调日志；

• 消息ID；

• 数据库Timeout；

• 订单状态记录。

阶段四：实现

修改：

payment-consumer.ts
retry-policy.ts
payment-consumer.test.ts

没有修改：

payment-api
数据库Schema
退款逻辑

阶段五：验证

运行：

pnpm test payment-consumer
pnpm test order-state
pnpm typecheck

结果全部通过。

并模拟：

• 正常回调；

• 数据库第一次失败；

• 重复回调；

• 多次失败达到重试上限。

阶段六：Review

独立Reviewer发现：

重试可能导致同一事件重复写入。

于是要求增加幂等检查。

阶段七：重新验证

代码修改以后，之前测试全部重新执行。

再增加：

重复事件10次
最终只产生一次状态变更

阶段八：风险说明

仍未验证：

真实生产消息积压环境下的性能。

阶段九：人工批准

负责人判断：

• 当前Bug已经解决；

• 未验证风险可以接受；

• 先灰度5%；

• 监控失败重试指标。

这才是完整的：

AI Delivery Evidence。

而不是一句：

Codex已经修好了。

---

十二、证据链中哪些可以自动化？

Evidence Chain不意味着开发者每天人工整理几十页报告。

大量证据可以由工具自动生成。

可以自动生成

• Git Diff；

• 修改文件列表；

• Commit SHA；

• 测试命令；

• 测试结果；

• CI结果；

• Lint和类型检查；

• Agent执行日志；

• Review意见；

• 部署状态；

• 监控指标。

Agent适合生成

• 根因摘要；

• 影响范围；

• Diff解释；

• 剩余风险；

• 未验证项目；

• 回退方案。

人类应该确认

• 业务规则是否正确；

• 风险是否可以接受；

• 是否允许生产变更；

• 是否批准公共接口变化；

• 是否最终交付。

也就是说：

机器收集事实，Agent整理证据，人类接受风险。

---

十三、Evidence应该放在哪里？

不要把所有证据只留在聊天窗口里。

可以根据任务大小选择不同方式。

小任务

直接放在Pull Request描述：

Problem
Root Cause
Changes
Validation
Risks

中型任务

增加：

docs/evidence/ISSUE-123.md

大型迁移

按阶段保存：

evidence/
├── 01-baseline.md
├── 02-migration.md
├── 03-tests.md
├── 04-review.md
└── 05-release.md

Evidence应该尽量跟代码一起版本化。

这样三个月以后重新调查问题时，可以知道：

当时为什么认为这个改动是安全的？

---

十四、团队可以建立Evidence Gate

当Agent承担越来越多任务以后，可以把证据要求变成合并门槛。

例如普通PR：

必须存在：
✓ Diff
✓ 单元测试
✓ Agent Review

高风险PR：

必须存在：
✓ 原问题复现
✓ 根因证据
✓ Diff
✓ 单元测试
✓ 集成测试
✓ 独立Review
✓ 剩余风险说明
✓ 人工审批

如果某项不存在，PR状态就不是：

Done

而是：

Evidence Missing

这会改变团队对“完成”的定义。

从：

Agent停止运行了。

变成：

交付证据满足标准了。

---

十五、不要把Evidence Chain做成新的形式主义

Evidence Chain也有一个风险：

最后变成Agent自动生成两千字报告，但没人看。

因此证据必须满足三个原则。

可验证

必须能回到真实Diff、日志、测试和运行结果。

可定位

出现问题时，可以快速知道证据对应哪个版本。

可决策

内容应该帮助Reviewer判断是否允许继续，而不是单纯增加文字。

例如：

错误写法：

经过全面测试，本次修改质量良好。

正确写法：

已运行：
单元测试：46/46通过
集成测试：8/8通过

未运行：
生产回放测试

原因：
当前环境没有匿名化生产数据。

剩余风险：
低概率支付渠道异常暂未覆盖。

后一种明显更有价值。

---

AI Delivery Evidence通用模板

# AI Delivery Evidence

任务：
负责人：
Agent：
当前版本/Commit：

## 1. Objective
本次需要解决什么问题？

## 2. Baseline Evidence
修改前如何证明问题存在？

复现步骤：
日志：
截图/Trace：
复现率：

## 3. Root Cause
确认根因：
支持证据：
已经排除：
仍未确认：

## 4. Changes
修改文件：
核心Diff：
未修改范围：

## 5. Validation
运行命令：
通过：
失败：
跳过：
无法验证：

## 6. Runtime Evidence
真实流程验证：
截图/日志/指标：
Before / After：

## 7. Review
Reviewer：
P0：
P1：
P2：
处理结果：

## 8. Retry History
失败次数：
失败原因：
重新规划内容：

## 9. Remaining Risks
仍然存在的风险：
未验证内容：

## 10. Rollback
回退方式：
触发条件：

## 11. Approval
人工负责人：
批准范围：
最终状态：

---

十六、从明天开始，团队可以先做三件事

第一，不允许Agent只说：

测试通过。

要求同时给出：

测试命令、结果和未运行内容。

第二，不允许Agent只说：

Bug已修复。

要求提供：

修改前复现证据 + 修改后验证证据。

第三，高风险任务结束前增加一次：

独立Review + Remaining Risks。

不需要一开始建立复杂平台。

先改变团队对“完成”的定义，就已经能减少很多AI交付风险。

---

结语

Agent越来越强以后，一个很容易出现的错觉是：

它能够独立完成任务，所以我们可以减少检查。

实际上恰恰相反。

Agent执行速度越快、修改范围越大、人类参与越少，团队越需要一套机器可生成、人类可复核的证据系统。

真正成熟的AI工程交付，不应该是：

Agent说完成了。

而应该是：

原问题有复现证据；
根因有事实支持；
修改有真实Diff；
测试有完整结果；
运行行为有验证；
Review有独立结论；
重试有历史记录；
剩余风险被明确说明；
高风险交付有人批准。

这才是一条完整的AI Evidence Chain。

未来团队判断一个Agent任务是否完成，最重要的问题可能不再是：

“Codex写完了吗？”

而是：

“它留下的证据，足不足以让另一个人相信并复现这个结论？”

如果答案是否定的，那么任务最多只能叫“Agent停止了”。

还不能叫“工程交付完成”。