夜间自动代码评审

凌晨的代码变更，谁来审？

多人协作的组织仓库里，master 分支的 commit 几乎不会停。白天的 PR 评审能覆盖大部分逻辑，但总有一些改动落在评审视野之外——深夜的 hotfix、跨仓库的 SDK 更新、无人关注的实验性分支。等到第二天有人发现 Bug 时，变更已经和其他几十个 commit 混在一起，定位成本陡增。

这个技能每天凌晨自动对组织下的活跃仓库做一轮增量评审，把「今天改了什么」这件事变成固定流程，而不是靠人记得。

核心机制

按优先级覆盖仓库

评审范围限定在配置好的组织仓库表里，从 P0 的主项目到 P3 的实验性仓库依次递减。P0 仓库每次必审，P3 仓库只要 24 小时内没有 commit 就直接跳过。

增量与分块

不是全量 checkout，而是只取 git diff HEAD~5 的变更文件。为了不让大模型上下文溢出，每次 claude --print 只处理 3-5 个文件，分批推进。

问题分级与去重

评审结果按严重程度分级：

• P0：安全漏洞、明确的 Bug——直接创建 Issue
• P1：逻辑错误、质量风险——同样创建 Issue
• P2：建议类——只记录不提交，避免 Issue 噪音

同一仓库同一文件在 24 小时内不会重复提交 Issue，防止夜间循环刷同一条问题。

边界与注意点

这个方案有几个隐含前提，值得提前想清楚：

1. 评审质量依赖大模型。它适合发现明显的逻辑漏洞和安全风险，无法替代架构层面的设计评审。
2. 凌晨额度。调度选在 UTC+8 凌晨 1:00，正好落在部分模型的非高峰计费窗口，单轮 token 消耗约 50k-200k，成本可控。
3. 只审增量。如果历史代码本身存在债务，这个技能不会去处理，需要单独排期。
4. Issue 只是触发器。它负责把问题抛出来，修复仍然需要人。