凌晨 1 点，AI 开始翻我的代码仓库——发现的 Bug 比我想象的多

装上这个"夜间巡检员"，睡一觉起来 Bug 已经标好了

● ● ●

你有没有经历过这种事——

项目上线后发现一个低级 Bug，回头一看代码，问题就明晃晃写在那里。你同事的 PR 三天前就合进去了，只是没人认真审过。

小团队的困境就在这里：一共就三四个人，大家忙着写业务，PR 审查全靠"差不多看看就行"。没有专门的 QA，没有自动化检查，代码质量全靠运气。

所以我做了一个决定——雇一个只上夜班的 AI 审查员。每天凌晨 1 点，大家都不在线的时候，它开始干活。

STEP 1

它不审所有代码——只盯"今天改过的"

这个夜间巡检 Skill 的核心逻辑很聪明：它不会把整个仓库读一遍——那太浪费了。它只看最近 24 小时内有变更的仓库，而且只看最近 5 个 commit 改了什么。

具体来说，凌晨 1 点一到，cron 触发脚本，它会遍历你组织下所有仓库，用 git diff HEAD~5 拉出最近变更的文件列表。没改动的仓库直接跳过，有改动的才叫 AI 来看。

这就解决了一个关键问题：不是盲目巡检，而是精准盯防——改哪审哪。你的项目可能有几十个仓库，但每天真正活跃的可能就两三个。AI 不会浪费算力去审查那些几个月没动的代码。

💡 更妙的是，它会给仓库分优先级。核心项目 P0 级关注，辅助仓库 P1/P2 级。这样即使有大量仓库，AI 也知道先审哪个。和你自己心里的重要程度完全对齐。

STEP 2

AI 审代码，和人类审哪里不一样？

它的评审分成三级——和人类审查员的思路完全一致，但更冷血：

P0 —— 要命的。安全漏洞、数据丢失风险、权限绕过。比如 API 接口没做鉴权，或者用户输入直接拼进 SQL。这类问题 AI 反而比人敏锐——它不会被业务逻辑干扰，一眼看到代码本身的风险。

P1 —— 会出事的。逻辑错误、竞态条件、边界值遗漏。比如并发场景下没加锁、分页查询忘了考虑空状态。这类问题人类审查也容易漏，但 AI 会像扫描仪一样逐行比对模式库。

P2 —— 看不顺眼的。代码风格、性能优化建议、可维护性问题。这类问题人类审查员可能懒得提，AI 却会老老实实一个个标注出来。

还有一个很重要的设计：只有 P0 和 P1 才会自动创建 Issue。全是 P2 的建议？说明代码没问题，跳过，不产生噪音。这避免了你的 Issue 列表被一堆"建议加个注释"之类的东西淹没。

STEP 3

你早上起床，Issue 已经躺在仓库里了

审查完成后，AI 会把结果整理成你熟悉的格式：

每个 Bug 单独一条，标注文件路径、严重程度、问题描述、建议修复方案。就像你的同事给你提了一个代码审查评论——只不过这个同事从来不会累，也不会因为赶时间而"算了算了过了过了"。

还有去重逻辑：同一个文件 24 小时内不会重复提 Issue。你今晚刚修了一个 Bug，明晚 AI 不会再对着同一段代码说"这里有问题"，因为它知道你已经看过了。

整个过程不需要你参与任何一步。你下班前提交的代码，第二天早上打开电脑，Issue 已经分好类等着你了。

● ● ●

不花钱的机器人同事，它晚上干活你白天改

这个 Skill 最让我心动的地方，不是审查质量——AI 审代码当然没有资深架构师厉害。但它解决了小团队最本质的问题：缺人手。

你没有 QA → AI 当 QA。你没有人 code review → AI 先把低级 Bug 筛一轮。你是唯一的技术负责人，所有代码都要你审 → AI 帮你过滤掉 80% 的噪音，你只需要看它标出来的那几条。

还有一个被低估的好处：它利用的是非高峰额度。凌晨 0:00 到 6:00，GLM-5.1 的 token 消耗只要 1 倍抵扣——而你白天高峰期用同样的服务要花 3 倍。省的不是一点半点。

说到底这是一个很朴素的逻辑：让 AI 做它擅长的事（模式识别、逐行扫描、不知疲倦），把人的时间省下来做只有人能做的事（架构决策、业务理解、复杂权衡）。

鸿爪派 · 一篇一 Skill

你睡觉时，AI 替你写代码——改天，AI 替你审代码

本文首发于「鸿爪派」公众号