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更新前读取authenticatedfalse 因此触发/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 结果 auth28 passed typecheckpassed lintpassed 未运行 完整E2E 原因 本地缺少支付测试服务这最后一项非常重要。很多AI交付的问题不是测试失败而是没跑的测试没有被说出来。因此验证报告应该同时包含已执行已通过已失败已跳过无法执行。“没有证据”不能被自动解释成“没有问题”。八、为什么还需要运行时证据代码测试通过并不一定说明真实流程正常。尤其是UI网络交互异步状态权限数据库多服务系统。这些问题往往需要运行时验证。例如一个前端Bug可以要求修复前 页面刷新后跳回登录页。 修复后 页面保持当前页面 Token刷新完成 用户状态恢复。 验证 连续执行10次 10次均未出现重复跳转。如果条件允许还可以保留截图浏览器ConsoleNetwork请求服务日志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.mdEvidence应该尽量跟代码一起版本化。这样三个月以后重新调查问题时可以知道当时为什么认为这个改动是安全的十四、团队可以建立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停止了”。还不能叫“工程交付完成”。