适用场景：完成声明和现场证据出现偏差
这类问题常出现在长任务、多人接手、静态内容生成、前端改版和 AI 自动化办公批处理里。模型回复“已完成”，但本地文件里没有新内容；命令输出显示通过，截图却是旧页面；栏目页有链接，sitemap 没有；或者测试命令是在另一个目录执行的。问题不一定是模型故意说错，更多时候是证据没有绑定到同一个时间、同一个工作目录和同一批文件。
永沃云枢建议把 Codex 的交付分成三层来看：结果文件、验证动作和复核入口。结果文件说明改了什么，验证动作说明怎么确认，复核入口说明接手人怎样独立再跑一次。它和任务证据包交接相近，但本篇重点是证据互相矛盾时怎样倒推。
先确认四个基准
第一是时间基准。命令输出、文件修改时间、截图时间和最终回复时间要能排出顺序。第二是路径基准。Windows 本地任务尤其要确认当前工作目录，避免在相似目录里跑了测试。第三是版本基准。若工作区本来有未提交改动，应区分用户改动、模型改动和生成产物。第四是验收基准。任务开始时写的成功条件，才是判断完成的依据，而不是最后一句总结。
如果任务涉及 AI API 接入或 AI 模型接口，不要只看一次请求成功。还要核对请求参数、profile、模型名、返回 ID 和日志里的时间。若使用 CCSwitch 配置，也要确认实际命中的 profile，而不是只看界面选中项。Codex 接入、CCSwitch 配置和开发者 AI 调用之间最好保留可关联的 trace 或文件路径。
操作步骤：从最便宜的证据开始复核
- 先运行只读检查，例如
git status --short、git diff --stat和目标目录列表。不要急着让 Codex 继续改。 - 把最终回复里提到的文件逐个打开，确认标题、日期、链接、关键字段和修改时间。静态页面还要检查 canonical、JSON-LD、站内链接和编码。
- 复跑最小验收命令，并记录命令所在目录。若第一次输出来自旧日志、缓存目录或另一个分支，本次结果不能算通过。
- 截图或浏览器验收要刷新缓存，并确认 URL、页面标题和截图文件名。只看图片内容容易误把旧截图当成新证据。
- 如果证据冲突，先标记“未确认”，再让 Codex 解释冲突来源。要求它引用具体文件和命令，不要只给概括性判断。
- 修复后重新生成一份短验收摘要，包含变更范围、复跑命令、失败项、剩余风险和不做的动作。
常见问题 / 避坑
第一个坑是把聊天总结当验收结果。总结只能帮助阅读，不能替代文件状态和命令输出。第二个坑是复制旧命令输出，尤其是长任务中断后续跑时，日志里可能混入上一轮结果。第三个坑是只验证成功路径，不验证禁止路径，例如安全字段、密钥目录和发布脚本是否保持未修改。第四个坑是让模型在没有新证据的情况下继续解释，越解释越像完成。
AI 自动化办公场景还要特别注意输出文件是否覆盖源文件。比如批量生成报告、邮件或表格后，验收证据应同时包含源文件快照、生成文件路径和人工确认点。对 AI API 接入任务，则要把调用日志与页面展示分开核对，避免接口成功但业务写入失败。
检查清单
- 最终文件列表与任务白名单一致，没有越界修改。
- 每条命令都能说明工作目录、执行时间和本次输出来源。
- 截图、HTML、sitemap、栏目页和发布 URL 指向同一批内容。
- AI 模型接口调用证据包含模型、profile、请求 ID 或等价关联字段。
- 用户已有改动没有被格式化、覆盖或混入本轮总结。
- 可继续参考 静态发布一致性检查、未提交变更边界、Codex 专题 和 AI API 接入专题。
验收标准：让接手人不用相信口头结论
一份合格的验收记录，应能让没有参与本轮任务的人在十分钟内复核核心结果。文章类任务要能打开新页面、栏目页、sitemap 和发布 URL；代码类任务要能看到修改文件、复跑命令和失败样本；配置类任务要能确认哪些字段没有被触碰。若某条证据需要解释很多背景才能成立，就说明记录还不够清楚。
团队还可以约定一个简单状态：通过、未验证、失败、跳过。不要把未验证写成通过，也不要把跳过项从总结里删掉。Codex 的价值在于加快执行，但验收语言必须比执行语言更硬。
FAQ：发现证据对不上，要不要全部重做
不一定。先把证据冲突点缩小到文件、命令或页面缓存。若文件正确但截图旧，只需要重跑浏览器验收；若命令在错目录执行，应在正确目录复跑；若文件本身缺失，才回到生成步骤。验收的目标不是追求一份漂亮总结，而是让接手人可以在永沃云枢的本地工作流里独立确认：任务确实完成，未完成项被明示，风险没有被藏进一句“已验证”。