验证与评审：结果要有证据
可靠的 agent 工作流一定包含验证。不要停在“已完成”，而要拿到命令结果、页面截图、复现路径、diff 解释和剩余风险。验证越自动化，你越能放心让它跑得更远。
本章目标
- 会把验证要求写进任务，而不是交付后再补问。
- 知道不同任务需要不同强度的验证闸门。
- 能用 Codex Review pane、/review 或 fresh reviewer 做结果复核。
验证是任务的一部分
- Bug 修复：先复现，再修，再用同一路径确认不复现。
- 代码修改：项目有测试时跑最窄相关测试；没有测试时跑 lint、类型检查、构建或脚本验证。
- 前端修改：启动页面，用浏览器检查关键视口、交互和状态。
- 内容修改：确认标题、导航、链接、RSS、sitemap 和构建是否受影响。
- 安全相关：验证还要包含权限、日志、敏感信息和失败路径。
验证要挂多硬的闸
同一句“运行测试”，在工程上可以是很轻的提醒，也可以是确定性硬闸。任务越长、越想让它无人盯着运行，就越需要更硬的闸门。
- 同一条 prompt 里自查：适合短任务，你在场盯着。
- 跨会话完成条件：适合多轮任务，要求它反复检查直到条件成立。
- Hook 硬闸：适合必须每次执行的 lint、format、安全扫描或路径拦截。
- 独立 reviewer：让另一个上下文尝试反驳“已经做对了”的结论。
- 证据优先：要求命令输出、截图、复现结果，不接受“应该没问题”。
验证要分层，不是永远全量
- 最窄验证：改哪个函数就跑哪个测试；没有测试就跑最接近的脚本或复现步骤。
- 项目验证：改共享逻辑、路由、元数据、构建配置时再跑 lint、typecheck 或 build。
- 真实界面验证：布局、响应式、图片、代码块、交互状态必须看浏览器。
- 发布验证：内容、RSS、sitemap、SEO metadata 和导航入口要单独查。
- 未验证要诚实：没跑就是没跑，不要把推断写成通过。
CASE
共享读取逻辑怎么验
场景
它调整文章读取逻辑，只测了文章详情页就说完成，但这段逻辑还被列表、标签页、RSS 和 sitemap 使用。
可以这样说
这次改到 src/lib/writing.ts 的共享读取逻辑。请先列出所有依赖入口（详情页、列表、标签、RSS、sitemap），再选最小验证集逐一确认，最后说明哪些入口已验证、哪些没有。验收点
- 先列全部依赖入口。
- 验证覆盖非 happy-path 入口。
- 遗漏入口被补回。
- 汇报区分已验证和未验证。
Codex 里的 Review pane 和 /review
Codex App 的 Review pane 看的是 Git 仓库真实 diff，所以会显示用户自己或其他进程留下的未提交改动。让 agent 汇报时，要区分 uncommitted changes、branch changes 和 last turn changes，避免把已有改动误算成本轮成果。
- 用 Review pane 看文件级和 hunk 级 diff，再决定保留、退回或继续修改。
- 用 inline comment 给具体行反馈，比一句“这里不对”更容易修准。
- 用 `/review` 做只读评审：审未提交改动、某个 commit，或按 base branch 做 PR 风格审查。
- 评审结果仍要人工判断：只修影响正确性、需求或安全的问题。
要求它这样汇报
- 改了什么：关键文件和行为变化。
- 怎么验证：命令、页面、复现步骤、截图或对照结果。
- 结果如何：通过、失败、未执行要分开写。
- diff 风险：无关改动、共享逻辑影响、回滚方式。
- 剩余风险：没覆盖的边界，不要用“应该没问题”结束。
请按这个格式汇报：1. 改了什么；2. 运行了哪些命令和结果；3. 检查了哪些页面或复现路径；4. diff 中最需要 review 的地方；5. 没有验证的风险。不要把未运行的检查写成通过。