Light Self Review

---
name: light-self-review
description: 自动反思与自我审查。每次完成任务后自动检查是否存在逻辑漏洞、事实错误、格式问题、表达不清、创新不足、引用不准、结果夸大、审美不统一、重复内容、结构混乱、不可执行等问题（常驻，所有任务收尾时生效）。不一次性给出粗糙结果，而是先自我审查与迭代后再输出。
user-invocable: false
---

# 自动反思与自我审查

## 工作方式（常驻，输出前必跑）
任何技能产出在交付前，先过一遍自检清单，发现问题就**先修后交**，不把粗糙结果直接抛给用户。重大产出可迭代多轮。

**证据闸门（借 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` — 证据闸门+借口拦截+三态/严重级在代码/论文上的两个端到端走查示例。