light-self-review

# 自动反思与自我审查 ## 工作方式（常驻，输出前必跑） 任何技能产出在交付前，先过一遍自检清单，发现问题就**先修后交**，不把粗糙结果直接抛给用户。重大产出可迭代多轮。 **证据闸门（借 verification-before-completion）**：不下「完成/通过/修好了」之类结论，除非当前轮就有新鲜证据。五步——①想清「什么命令/检查能证明它」②当场重跑(不引用旧结果) ③读完整输出、查 exit code、数失败 ④确认输出真支撑结论 ⑤才下结论。跳步=撒谎而非验证。红旗词：should/probably/seems to、提前自我满足、轻信子代理报告。 - 测试通过 = 有 0 失败的测试输出；构建成功 = exit 0（光过 lint 不够）；bug 修复 = 原始症状被测且通过；需求满足 = 逐条核对清单。 - **借口拦截**：临交付前大脑最会编借口跳过验证。「改动小不用跑/应该能过/上次跑过/先交了再说/审稿人不会注意」等都是借口而非判断，命中即回到证据闸门重跑。完整 26 条 excuse→reality 见 `references/excuse_intercept.md`。 **三态判定**：自检每一项都落到 通过✓ / 不通过✖ / 警告! 的明确判定（同 Deepchecks 的 check+condition、安全工具的 HIGH/MED/LOW/SAFE），不写含糊感受。不通过项附严重级 Critical(立即修)/Important(交付前修)/Minor(记录待办)。 ## 通用自检清单 > 每项的最小 通过✓/不通过✖ 反例对照见 `references/self_check_contrasts.md`；可勾选清单见 `assets/self_review_checklist.md`。 □ **逻辑**：论证链有无断点、跳跃、自相矛盾？ □ **事实**：数据/引用/声称是否真实可核查？有无臆造(CONVENTIONS §4)？ □ **格式**：是否符合目标要求(模板/字数/引用风格/编号)？ □ **表达**：是否清晰、专业、无歧义、无口语？ □ **创新**：贡献是否突出、不是常规堆叠(联动 m04 视角)？ □ **引用**：是否准确、相关、不遗漏、不堆砌(联动 m10)？ □ **夸大**：结论是否超出证据支撑(慎用 novel/significantly)？ □ **审美**：图表/排版/PPT 风格是否统一(联动 a07)？ □ **重复**：有无冗余内容、重复段落？ □ **结构**：组织是否合理、层次是否清晰？ □ **可执行**：方案/代码/步骤是否真能跑通、能落地？ ## 按产出类型补充 - **代码**：能否运行、有无测试、安全隐患(联动 a03 verification)。回归测试要走红-绿循环——撤掉修复必须失败、恢复后通过，「永不失败的测试什么都没证明」。新功能/改 bug 走 TDD：先写失败测试→看它真失败(不是 error)→写最简代码转绿→重构。依赖安全可用 SCA/能力分析视角自查：装包脚本、网络/shell 访问、混淆代码、typosquatting(仿冒名)；CLI 可借 `snyk test`(SCA)/`snyk code test`(SAST)/`sfw <装包命令>`(Socket 装前拦截)，severity-threshold 在 CI 降噪。若产出本身是 agent skill/MCP，按 skill-scanner/mcp-sca...