workflow_post_loop_critical_review

道-方法 · 道层 skill 全文

本页是 <code>rules/skills/drafts/workflow_post_loop_critical_review.md</code> 的逐字投影（仅隐私清洗，零改写）。

Skill：Loop 后关键审查

元数据

• 类型: Workflow / Draft
• 适用场景: 已完成或声称完成的 loop、agent 集成任务、skill fusion、评测报告，需要独立核验 Final Report 是否真实
• 输出位置: 审查证据放 adhoc_jobs/；面向用户的正式报告放 contexts/survey_sessions/
• 创建日期: 2026-05-02
• 状态: Draft
• 来源: 2026-05-02 大 context 信息提取 skill loop 审查与 full rerun 稳定性测试

解决什么问题

这个 skill 用来审查一个 loop 任务是否真的产出了用户需要的结果，而不是只相信执行 agent 的 final answer、self-review、PASS 报告或局部测试。

默认边界：这个 skill 聚焦一次具体检查，也就是一个 loop / 一个执行主体 / 一个 final report target。若用户要比较两个 loop，必须先分别得到两个单 target 审查结果，再另写 comparison。comparison 是独立评价任务，不属于本 skill 的正式报告结构，也不应该混进单 target verdict。

与 workflow_controller_loop 的 online review 分开：Controller review 在任务运行中决定下一步反应；本 skill 在完成声明或历史 loop 之后冻结源状态，裁决 final report 或 completion claim 是否可信。它不继续执行目标 loop 的业务工作，也不替代 runtime executor。

与 workflow_long_context_scale_up 分开：本 skill 可以把长聊天记录、长 run ledger、书籍 distillation 产物或多 session 原文交给 scale-up 做全量覆盖提取；但本 skill 拥有审查目标、requirements matrix、completion claim verdict 和正式审查报告。scale-up 的 coverage report 只是审查输入，不能替代本 skill 的 verdict。

任务审查是一种特异性信息提取：它从大量上下文中提取“用户需求、执行声明、实际产物、测试证据、失败边界和过度声称”。这不等于通用 Large Context Extraction。通用 extraction 负责覆盖与压缩；本 skill 负责把压缩结果用于完成状态裁决。

核心目标：

1. 从实际产物、代码 diff、测试、日志、PROGRESS/HANDOFF、版本记录开始审查。
2. 独立判断用户 requirements 是否被准确实现。
3. 解释旧实现、新实现和行为变化。
4. 验证测试是否真实、可复验、能支撑结论。
5. 检查局部最优、奖励黑客、mechanical PASS 被误当 semantic PASS 等坏行为。
6. 如果用户要求稳定性核查，执行一次全量 rerun 写入，并比较两次报告是否一致。
7. 让一个没有参与过原任务的人只读正式报告，就能明白：用户要什么、被审查对象做了什么、审查者怎么查、测试怎么跑、结论为什么成立或不成立。

触发条件

用户出现以下意图时使用：

• “检查 loop 执行情况”
• “审查 Final Report 是否真实”
• “不要相信它自己的总结”
• “全量重新跑一次，而不是抽查”
• “检查两次写入是否稳定”
• “把审查 prompt / protocol 做成 skill”
• “确认当前 skill / draft / loop 是否已经完成”

硬规则

1. 不能把执行者 final answer 当证据。final answer 只能作为线索。
2. 不能把 PASS 字样当测试有效证据。必须检查测试文件、输入、运行方式、输出和失败边界。
3. 不能只抽查。如果用户要求 full rerun 或全量核查，必须在临时目录重新写入完整审查结果。
4. 正式报告必须自洽。用户不应需要阅读中间文件才能理解结论。
5. 审查对象清晰。正式报告要声明当前 target；如果涉及两个 loop 的结果比较，建议先分别完成两个单 target 报告，再做综合比较。
6. 写作由主 agent 负责。sub-agent 可以产出中间审查文件，但最终报告必须由主 agent 冲突消解后重写。
7. 正式报告必须明文写出用户需求。不能只写“需求满足情况”表格，也不能假设读者知道原始 prompt。报告开头必须有“用户原始需求”或“本次审查要回答的问题”小节，用 3-7 条把用户需求重述清楚，并引用原始 prompt 路径或行号。
8. 正式报告必须说明审查过程。至少说明读了哪些产物、派了哪些审查角色、是否做了 freeze、哪些证据被采纳或排除。不要把过程藏在附录。
9. 测试说明必须可复验。测试章节必须写测试目标、输入、执行方式或命令、输出文件、判定口径、证明了什么、没有证明什么。只有“PASS”字样或结果数字不够。
10. 通俗化解释必须落地到本 target。解释要围绕本次被审查任务的具体目标和证据，不写泛泛类比，不为了通俗而省略关键边界。

冻结时间协议

如果被审查的 loop 仍在运行，先冻结审查边界。否则报告会被“移动中的源状态”污染。

在证据目录写入或记录一个 freeze snapshot，至少包含：

• 冻结时间、时区、当前日期。
• 被审查的 source directories。
• loop_state / 最新 state 文件的状态。
• run ledger 最后一条记录。
• 最新 PROGRESS、HANDOFF、VERSION_LOG 或等价文件的关键行。
• 被审查路径的 git dirty 状态。
• 是否存在仍在运行的 automation / loop。

Freeze 后的规则：

• 默认只审查 freeze 时间点及之前存在的产物。
• 如果 loop 继续产出新文件，把它作为 moving-source risk 单独报告，不混入已冻结结论。
• full rerun 必须使用同一个 freeze snapshot；否则两次报告不稳定可能只是因为源数据变了。
• 如果无法暂停 loop，就明确采用“ignore-after-freeze”策略。

2026-05-02 的实测教训：Codex loop 在第一次审查后从 Loop 024 继续推进到 Loop 030。初次报告的顶层 verdict 仍然成立，但进度数字已 stale；因此这个 protocol 必须先 freeze source state。

推荐审查分工

复杂任务使用 sub-agent；简单任务可以由主 agent 合并角色。每个 sub-agent 都必须拿到原始需求、correction prompt、证据目录、旧实现、新实现、测试路径和 freeze snapshot。

需求审查员

输出 requirements_matrix.md：

• requirement_id
• 用户原文或 source path
• 用户需求的 plain-language 重述
• 实现位置
• 实现方式摘要
• 证据文件与行号
• 状态：PASS / PARTIAL / MISS / WRONG / NOT_TESTED
• 批判性评价：是否只是表面满足
• 至少指出 3 个最可能被误判为完成的点

实现 Diff 审查员

输出 implementation_diff.md：

• 旧实现目标、工作方式、输入/输出、限制
• 新实现目标、工作方式、新增/删除/改变、输入/输出
• behavior / workflow / data-schema / prompt-protocol / validation 变化
• 标注判断来自代码、文档还是推断

测试验证审查员

输出 test_validation.md：

• test_id
• 文件路径
• 执行命令或执行方式
• 输入数据
• 输出或日志路径
• PASS / FAIL / NOT_RUN
• 是否真实、可复验、语义有效
• oracle 泄露、隐藏上下文、过度 mock、简化 eval 风险
• 最小补测方案

失败行为审查员

输出 failure_behavior_ledger.md，逐项标注 PASS / RISK / FAIL：

• 局部最优
• 奖励黑客
• mechanical PASS 被当成 semantic PASS
• 后置 gate 累积
• source 完整但 operational drift
• 简化 eval
• oracle 泄漏
• 缺少 fresh consumer 的 self-eval
• sample=1 过度泛化
• 指令过载
• 便利指标
• 目标漂移
• frame lock

必须提出至少 3 个 adversarial questions。若问题足以推翻方向，写 NEEDS_REBUILD。

通俗解释员

输出 plain_language_explanation.md：

• 用非代码读者能懂的方式解释用户原始需求、旧方法、新方法、变化原因、测试证明了什么
• 不强行比喻
• 明确写出简化了哪些细节
• 明确写出哪些结论仍然不能证明，避免把 PARTIAL 讲成 PASS

通俗解释一致性检查员

输出 plain_language_consistency_check.md：

• 对照实现、测试和需求矩阵检查解释是否准确
• 标出过度简化、遗漏边界、错误因果
• 给出建议改写

全量重跑稳定性检查

当用户要求“重新跑一次”“全量核查”“不要只抽查”时执行。

1. 创建独立临时目录，例如 adhoc_jobs/<task>_full_rerun_<date>/。
2. 把 freeze snapshot、原始需求、correction prompt、证据目录、目标输出清单写入 rerun prompt。
3. 启动独立 session 重新写入完整审查结果。可以使用 cli_agent、Codex session 或 Claude session；工具路径从 tools/INDEX.md 查，不在 skill 中硬编码。
4. 要求 rerun session 在写完自己的报告前不要读取第一次正式报告，只能读取源产物和 freeze snapshot。
5. rerun 至少重新生成：
• requirements_matrix.md
• implementation_diff.md
• test_validation.md
• failure_behavior_ledger.md
• 当前 target 的 final_report.md
6. 主 agent 比较两次输出：
• 顶层 verdict 是否一致
• requirement 状态是否一致
• 关键数字和 loop 进度是否一致
• 测试风险是否一致
• 是否出现 moving-source 差异
• 是否有第一次遗漏、第二次发现的关键证据
7. 输出 full_rerun_comparison.md，并在正式报告正文说明稳定性结论。

多 target 情况下，先为每个 target 各自执行上述步骤；最后可以额外写一个 cross_target_summary.md，只比较不同 target 的状态，不重新定义任何单 target verdict。

稳定性判读：

• verdict、关键风险、证据路径一致：报告设计较稳定。
• verdict 一致但数字不同：通常是 source 未 freeze 或 loop 持续推进。
• verdict 不一致：需要回到证据文件裁决，不按多数投票。
• rerun 只复述第一次报告：失败，不能证明稳定。

正式报告结构

正式报告面向用户，不是中间文件拼接。默认顺序固定：

1. 用户原始需求与审查边界
• 用 3-7 条重述用户原始需求；每条带 source path 或行号。
• 声明当前只审查哪个 target、freeze 时间、source directories、是否忽略 freeze 后新产物。
• 若用户还要求跨 target comparison，声明该 comparison 将在单 target review 之后另写。

1. 需求满足情况
• 一句话 verdict：PASS / PARTIAL / FAIL / NEEDS_REBUILD / NEEDS_MORE_EVIDENCE
• 需求矩阵：需求、实现情况、实现方式是否准确、证据、状态
• sub-agent 分歧与主 agent 裁决

1. 审查执行过程
• 本次读取了哪些实际产物、日志、测试、版本记录。
• 使用了哪些 sub-agent 角色或等价审查视角。
• 哪些证据被排除，原因是什么。
• 审查过程中发现的 source freshness / moving-source 风险。

1. 具体实现说明
• 旧实现是什么
• 新实现是什么
• 新旧变化：行为、流程、数据结构、prompt/protocol、测试验证

1. 测试执行情况
• 测试文件路径
• 执行命令或方式
• 输入数据
• 输出或日志路径
• 执行结果
• 测试证明了什么、没有证明什么

1. 通俗化解释
• 本质解决的问题
• 旧方法为什么不够
• 新方法为什么更合理，或为什么仍不充分
• 哪些细节被简化

附录列出中间审查文件路径。

若需要 Claude Code vs Codex、方案 A vs 方案 B 这类横向评价，单独写 comparison 报告。comparison 可以引用两个单 target 报告，但不得替代它们；comparison 的评价维度可以是任务理解、执行推进、证据质量、测试有效性、报告可读性、最终可用性和风险控制。

裁决 判定

• PASS: 原始需求已准确实现，测试真实且充分，未发现关键 bad behavior。
• PARTIAL: 主要方向成立，但有明确未覆盖需求或证据不足。
• FAIL: 关键需求未实现，或测试不能支持结论。
• NEEDS_REBUILD: 当前方向本身错误，继续局部修补会放大问题。
• NEEDS_MORE_EVIDENCE: 可能正确，但现有证据不足以判断。

不要为了“看起来完成”而给 PASS。如果缺少 fresh consumer 测试、完整重放、真实输入覆盖或冻结证据，通常不是 PASS。

常见误判

• 流动 source 被误读为报告不稳定：Loop 继续运行导致数字变化；先看 freeze。
• 机械 PASS 被当成语义 PASS：JSON 解析、行数、字段覆盖只证明格式，不证明检索判断正确。
• 同样本 oracle 泄漏：用 silver label 或历史修正样本校准后，只在同一批样本上证明效果。
• 策略差异重放被当成 fresh 重放：bounded 重放只能说明某个修正规则可重放，不说明新 chunk 上泛化。
• 后置 gate 累积：失败后不断补 gate，表面指标改善但核心能力没有变。
• 最终 skill 未产出却被说成完成：实验 draft、候选提示词、局部 policy 不等于可复用 skill。

验收标准

一次合格的 post-loop critical review 必须满足：

• 有 freeze snapshot 或明确说明 source 已静止。
• 正文明文写出用户原始需求或需求重述，并引用来源。
• 正文说明审查执行过程，而不只列最终发现。
• 每个关键结论都有实际产物路径和行号。
• requirements、diff、test、failure behavior 至少四类中间审查齐全。
• 正式报告能独立阅读，不依赖附录才能理解。
• 测试部分说明真实执行方式、输入、输出和未覆盖风险。
• 通俗化解释能让未参与任务的人理解“在做什么、怎么做、怎么验证”，且没有把未证明的事情讲成已证明。
• 多 target 综合评价与单 target review 分离。
• full rerun 被要求时，已在临时目录全量重新写入并比较稳定性。
• 报告正文写出发现的 bad behavior，不只藏在附录。