Review 同事写的代码, 和 review agent 写的代码, 是两套不同的事。

一起干活久了, 多少知道同事写代码的习惯——谁喜欢用 reduce, 谁总忘记处理边界。但 agent 没有"习惯", 它的每一次输出都取决于那次会话的上下文。

Review agent 代码的时候, 我养了几个自己的检查点。

第一: 看它改了不该改的地方吗

Agent 最大的问题不是写不对, 是管不住自己。它可能为了修一个 bug, 顺手把旁边的配置也改了, 或者把另一个函数的重命名顺便带上了。

Diff 文件里所有不在任务范围内的改动, 都是危险信号。

第二: 看它处理边界了吗

Claude 写的 happy path 通常很漂亮。问题出在用户输入为空、网络请求超时、权限不足的时候——这些分支常常没覆盖。

Review 的时候我会专门盯着 if/else 的分支看: 所有 else 和 catch 里的逻辑是真的处理了错误, 还是只是打了个 log 就过去了?

第三: 看测试是真测还是假测

这是 agent 最喜欢偷懒的地方。写出来的测试看起来跑过了, 但仔细一看——mock 了整个函数, 断言了一个硬编码的值, 或者测了一个从来不会失败的条件。

我有个检查习惯: 把测试里的数据换一批, 看看它还能不能过。换数据就挂的测试, 说明测的是假逻辑。

第四: 看代码风格是不是和项目一致

Agent 有自己的默认风格——它写出来的代码可能技术上没问题, 但跟你们项目里现有的代码风格格格不入。

命名风格、错误处理模式、甚至空行的习惯——这些不一致不会让代码出 bug, 但会让维护的人很痛苦。如果发现风格不一致, 回 CLAUDE.md 里加一条规则, 下次就好了。

第五: 看它是不是过度工程了

Agent 喜欢把事情做得"完美"。你让它加一个筛选功能, 它可能给你整了一套完整的过滤框架, 支持多条件组合、排序、缓存——而你就只需要一个简单的下拉框。

Review 的时候问自己: 这段代码在未来三个月真的用得上吗? 用不上就是过度工程。

进阶: Writer/Reviewer 双会话模式

自己 review 完了还不够的话, 可以用两个 Claude 会话来做:

• Session A (Writer): 实现功能
• Session B (Reviewer): 在新上下文里审 Session A 的 diff

Session B 是干净的上下文, 它只看到 diff 和 review 标准, 不知道 Session A 当时的推理过程。这样能发现埋在原推理里的盲点。

Claude Code 自带的 /code-review 命令做的就是这件事——在独立 subagent 里审查当前 diff 并报告问题。

Review agent 的代码, 核心逻辑只有一条: 不要因为觉得它比你强就放松标准。相反, 正因为你不知道它在哪一步走偏了, 才要查得更仔细。

文章链接：