预发布自我审查

要解决的问题

大模型生成代码时，往往输出"看起来够用"的结果，而不是真正经得起推敲的实现。当没有人工 review 这一环时，agent 的自动提交会绕过本该拦截回归与边界问题的检查。最典型的下场是：问题直到 CI 才暴露，更糟的是直接进线上，由用户先发现。这个技能把关卡前移到 git commit 之前。

技能如何工作

它不替代完整的代码评审，而是提供一道轻量的结构化闸门，分三步走：

• 判断是否值得跑：改动超过 100 行、涉及超过 5 个文件、触碰核心基础设施（executor、storage、主调度循环）、引入新抽象或公共 API、对边界情况没把握——满足任一条件即触发。
• 快速放行：50 行以内、3 个文件以内、纯文档、仅测试改动、单行 bug 修复、无逻辑变化的机械重构，直接跳过，避免对琐碎改动过度流程化。
• 按五张清单过一遍：依次检查 Edge Cases、Error Paths、Test Coverage、Documentation、Code Quality，最后跑一遍冒烟测试。任何一步不过，先修复再提交。

清单之外还配了一份反模式表，专门纠正几种典型的自我欺骗："CI 会兜底"、"之后再补测试"、"手动测过了没问题"、"错误信息先用 TODO 占位"、"从代码看应该处理了"。每一条都指向同一个事实：没有测试覆盖的地方，未来一次重构就会悄无声息地把它弄坏。

适用边界与注意点

这套检查的价值在于提交前拦截明显问题，它无法替代深层的设计评审。对高风险的架构变更，应配合更彻底的多视角审查；针对 agent 自身的惰性与自欺，则有另一个互补的技能。另外要明确：清单是给 agent 用的纪律工具，人工 review 依然重要，但至少 agent 自己不再把半成品直接推上去。