长会话里的周期性评审清单

10 月 4 日，我让 Claude Code 搭一个口语陪练的小 demo。骨架写完、提交以后，它在汇报最后加了一句：

接下来按计划会连续改不少文件。需要的话可以开 /loop 5m，让我每 5 分钟自动 review 一次新改动。

这句是我规则文件里要求的，长一点的编码会话，主动建议开定时评审。我回了两个字：「开吧」。

接下来的 30 个小时里，这个评审一共跑了 100 多轮。其中 101 轮的结果是同一句话：

✅ 最近变更已 review，未发现问题

真正查出问题的，只有一轮。

那一轮查出了什么

那天下午，我把接入第三方聊天平台要用的东西给了它，它一口气写完了接入层，跑通 36 个测试，提交、推送。不到一分钟，下一轮评审开始，汇报第一句是：

这一轮 review 了 P1 那次提交（6177d4a），它还没经过这个循环。发现 2 个问题，已修复并推送（85f9a6c）

第一个问题：用户发来的原始语音，转成文字以后一直留在媒体目录里，越积越多，也就是一直存着用户的声音。改成识别完就删原件，转码失败也删。

第二个问题：平台接口的 token 过期时，同时进来的几个请求会各自去换一次新 token，而换 token 的接口有频率限制。改成所有请求共用同一次正在进行的刷新。

两处都补了回归测试，38 个测试全部通过。汇报最后还有一段，我觉得写得最好：

还有两点我看过，判断不用改

一条是回调没做防重放，它的理由是就算被重放也只会多拉一次消息，而消息本来就去重，不会重复回复；另一条是某条消息处理失败时游标照样往前走，理由是会记一条失败日志，能排查。

这一段让我知道它看过哪些地方、为什么放过。只列问题的评审，你不知道没列出来的是没问题，还是没看到。

规则写的是 git diff，问题出在提交里

我那条规则的第一步是「git diff 查看未暂存变更，逐文件 review」。

可 agent 干活的节奏是写完就提交。那个接入层写完马上就提交推送了，等下一轮评审开始，git diff 早就是空的了。如果它老老实实只看未暂存的改动，那一轮也会回一句「未发现问题」。

它多走了一步，去看了还没经过评审的那次提交。这一步不是规则要求的。所以评审的范围应该写成「上一轮评审过的提交之后的所有改动」，已提交的、没提交的都算，别写成 git diff。

那 101 轮

那 101 轮，绝大多数时候仓库里根本没有新代码。开评审后 10 分钟，它自己就说过：

下一步要等你给大模型 key……在那之前不会有新代码。需要的话我先关掉它

我没理，它就一直跑。中间还有一段网络断了，好几轮直接报连接错误。直到第二天傍晚我说了一句「先把 review 循环停了」，这个定时任务才删掉。

每一轮「未发现问题」都很短，读起来不费事，可每一轮都是一次完整的模型调用，要读仓库、比对提交。没人写代码的时候，它就是在空转。

所以我会给这份清单补一条：连续几轮都没有新改动，就提醒一次该关了。至于提醒了要不要关，还是人说了算，这次没关的是我。

它能查出什么，查不出什么

还有一点得说清楚：那次评审和写代码的是同一个会话里的同一个 agent。自己查自己，盲区是共享的，写的时候没想到的事，查的时候大概率也想不到。

这次就有个现成的例子。开循环之前，它自己 review 过一遍骨架，发现转写用的临时 wav 文件一直留在媒体目录里，改成了用完即删。后来那一轮查出的第一个问题，是同一类事，只是这回留下的是用户发来的原件。同一类坑，第一次只补了眼前那一个。

即便这样，它还是查出了两个实打实的问题。我的理解是，写代码的时候注意力都在「让它跑起来」，回头看的时候换了一个问题：「这段代码会不会出事」。换个问题，就能看到一部分之前没看到的东西。

但它代替不了另一双眼睛。重要的改动，还是值得开一个独立的 reviewer 再看一遍。

可以直接抄的版本

这是我规则文件里那条，按上面两点改过的版本：

## 周期性评审
连续改 3 个以上文件或持续 15 分钟以上的编码会话，主动建议用户开 `/loop 5m`，每轮按下面检查：
1. 范围：上一轮评审过的提交之后的所有改动，已提交和未提交的都算，逐文件看
2. 正确性：逻辑是否完整，边界条件，类型是否匹配
3. 安全性：注入、XSS、信息泄露
4. 性能：多余的循环、未关闭的资源、N+1 查询
5. 一致性：是否遵循项目现有的模式、命名和 import 风格
6. 可维护性：重复代码、过度复杂的逻辑
7. 有问题按 `[文件:行号] 类别 - 问题描述 → 建议修复` 汇报；看过但判断不用改的，单列并写理由
8. 没问题只回一句：`✅ 最近变更已 review，未发现问题`
9. 连续 3 轮没有新改动，提醒用户关掉

第 5 条和第 6 条可以按项目改。那次 demo，我在一致性里多写了绝对导入和跨边界数据要做校验，在可维护性里写了函数不超过 50 行、文件不超过 500 行。

那 100 多轮里，真正干活的只有一轮。空转的那 101 轮，第 9 条能省掉大半；干活的那一轮，查出了用户的语音一直留在磁盘上。