light-self-review

自动反思与自我审查

工作方式（常驻，输出前必跑）

任何技能产出在交付前，先过一遍自检清单，发现问题就先修后交，不把粗糙结果直接抛给用户。重大产出可迭代多轮。

证据闸门（借 verification-before-completion）：不下「完成/通过/修好了」之类结论，除非当前轮就有新鲜证据。五步——①想清「什么命令/检查能证明它」②当场重跑(不引用旧结果) ③读完整输出、查 exit code、数失败 ④确认输出真支撑结论 ⑤才下结论。跳步=撒谎而非验证。红旗词：should/probably/seems to、提前自我满足、轻信子代理报告。

• 测试通过 = 有 0 失败的测试输出；构建成功 = exit 0（光过 lint 不够）；bug 修复 = 原始症状被测且通过；需求满足 = 逐条核对清单。
• 借口拦截：临交付前大脑最会编借口跳过验证。「改动小不用跑/应该能过/上次跑过/先交了再说/审稿人不会注意」等都是借口而非判断，命中即回到证据闸门重跑。完整 27 条 excuse→reality 见 references/excuse_intercept.md。

三态判定：自检每一项都落到 通过✓ / 不通过✖ / 警告! 的明确判定（同 Deepchecks 的 check+condition、安全工具的 HIGH/MED/LOW/SAFE），不写含糊感受。不通过项附严重级 Critical(立即修)/Important(交付前修)/Minor(记录待办)。

• 假阳校准：凡判「非问题/可放行」（✓ 或把疑似问题降级为非问题），必须附一行带证据的放行理由（指向具体命令输出/原文行号/检查结果），不许凭印象放行——没证据就当不通过处理。

分级执行档（先判档再跑，避免轻任务全跑或整体跳过）

全量 11 项对轻任务（改一句摘要、调个措辞）= 要么慢、要么干脆整体跳过导致失守。按产出量级择档：

• 重产出全量档：跑下方 11 项全清单。判据（命中任一即全量）：产出 ≥1 个完整章节/小节；含数字结论或定量主张；对外交付（投稿/提交/客户/公开）；新增或修改代码/脚本；涉及引用、合规、伦理。
• 轻任务最小三项：其余轻改动至少跑——① 证据（结论是否有当轮新鲜证据，过证据闸门，不下未验证的"改好了"）；② 事实（改动引入的数据/声称是否真实可核，无臆造 CONVENTIONS §4）；③ 夸大（措辞是否超出证据，慎用 novel/significantly）。三项任一不通过即就地修。

判档本身要显式（心里点一下命中哪条判据）；拿不准用重档。orchestrator 阶段间检查点按此档调用本技能（见 light-orchestrator/references/checkpoints.md）。

通用自检清单

每项的最小 通过✓/不通过✖ 反例对照见 references/self_check_contrasts.md；可勾选清单见 assets/self_review_checklist.md。

□ 逻辑：论证链有无断点、跳跃、自相矛盾？ □ 事实：数据/引用/声称是否真实可核查？有无臆造(CONVENTIONS §4)？ □ 格式：是否符合目标要求(模板/字数/引用风格/编号)？ □ 表达：是否清晰、专业、无歧义、无口语？ □ 创新：贡献是否突出、不是常规堆叠(联动 m04 视角)？ □ 引用：是否准确、相关、不遗漏、不堆砌(联动 m10)？ □ 夸大：结论是否超出证据支撑(慎用 novel/significantly)？ □ 审美：图表/排版/PPT 风格是否统一(联动 a07)？ □ 重复：有无冗余内容、重复段落？ □ 结构：组织是否合理、层次是否清晰？ □ 可执行：方案/代码/步骤是否真能跑通、能落地？

按产出类型补充

• 代码：能否运行、有无测试、安全隐患(联动 a03)。回归测试走红-绿循环（撤掉修复必失败、恢复后通过）；新功能/改 bug 走 TDD。依赖安全按 SCA/能力分析自查（装包脚本、网络/shell 访问、混淆、typosquatting；CLI 可借 snyk/Socket sfw）；产出本身是 skill/MCP 则按 prompt injection/数据外泄/含糊触发/跨技能重叠等维度自查，「无发现≠无威胁」仍需人工复核（工具命令见 references.md）。
• 论文/材料：用同行评审维度自审——原创性、方法学、结论逐句回溯结果(最经典失败点：不止口头确认"被支撑"，而是把每条主张逐句拎出，指出结果中支撑它的那句原话并带行号/表号/图号定位；找不到对应支撑句的主张即判 ✖ 删除或降级)、文献根基、贡献、格式合规(联动 m14)；科学主张过批判性思维（独立 verify 源头、相关≠因果、可证伪、举证责任在提出方）。
  • 核心撞车终检（交付前最后一道闸）：定稿前用核心结论/方法当关键词再检索（至少 2 库），找"最像的那一篇"。三态：✖ 撞车且未承认前作=Critical，回 m08/m04 重定位（承认前作、改打广度/严谨/负结果牌，绝不假装首创）；! 已承认并讲清 delta=警告，确认 framing 收到证据撑得住；✓ 无撞车且阴性证据充分。并预演审稿人拒稿 top-3。与 m03/m04 撞车检查同源，是输出端兜底。
• 数据/结果：统计是否站得住(联动 m06)。对照/样本/漂移可借 Deepchecks/Evidently 检查清单逐项核（套件用法见 references.md）。
• 合规：伦理/版权/隐私风险(联动 a10)，当带证据逐条核查：定范围→三态判定→不通过附修复建议与来源位置。
• 自评打分(对抗式批判)：按 5 维打分——可操作性、具体性、论证、是否给解法、语气专业；致命问题排在格式问题前，别陷入只挑表述的表面陷阱。
• 开场即上强度(grill 规则)：仅重产出全量档适用——自审首句就直接列三个最致命弱点，禁客套开场与缓冲句（对自己的产出缓冲就是放水），三个弱点按严重度排序、先于任何肯定表述。轻任务最小三项档不强制三弱点开场，按其三项就地修即可。

失败循环识别

同一问题修两次仍不对，停止打补丁、诊断根因、换思路（systematic-debugging：细读报错→稳定复现→查最近改动→边界埋点定位→源头修不在症状处修；一次只改一个变量）。修≥3 次仍不行=架构问题：停手质疑架构（信号：每修一处暴露新耦合/按下葫芦浮起瓢），与用户讨论后再动。四阶段全文见 light-backend-coding/references/debug_protocol.md。

接收外部意见（借 receiving-code-review）

对评审/反馈不「表演式同意」、不「盲目实现」：先核验意见技术上是否成立、是否清晰，对可疑处提质疑或要澄清，只在理解+验证后才改；反驳要给代码/测试/技术理由，不空驳。

• 禁表演式同意：「你说得太对了/马上改/好的好的」等空附和一律禁用，同意必须带证据，反驳也必须带证据。
• 不清楚就全停：对意见含义/范围/目标有任何不确定，停下要澄清，不用猜测继续往下做。
• 范围纪律 + YAGNI：只改被指出的问题，不借机重构无关代码；不为「将来可能用到」加抽象/配置/防御代码。
• 禁用措辞清单、标准流程、问题分级见 references/receiving_feedback.md。

产出

默认静默自检并直接交付修正后的结果；若发现无法自行解决的重大问题，明确告知用户问题与建议，不隐瞒。

衔接

是所有技能的输出闸门；与 a07(一致性)、a10(合规)、m04/m14(审稿)互补。

---

逐工具真实端点/参数/CLI/评审维度与已知坑见 references.md。 交付前自检的配套资产：

• assets/self_review_checklist.md — 可勾选的交付前清单（含证据闸门）。
• references/excuse_intercept.md — 27 条自我借口→真相拦截表。
• references/self_check_contrasts.md — 11 项通用自检的最小 ✓/✖ 反例对照。
• references/receiving_feedback.md — 禁表演式同意 + 不清楚就停 + YAGNI。
• references/walkthrough.md — 证据闸门+借口拦截+三态/严重级在代码/论文上的两个端到端走查示例。