给代码评审定 6 条检查项，再让 AI 逐条跑出评审清单

一句话结论

先让 AI 列出 6 条能判对错的评审检查项，再逐条跑，比丢一句“帮我看看”稳定得多。

这篇解决什么问题

改完一段代码，随手丢给 AI 一句“帮我看看有没有问题”，回来的往往是命名建议和注释建议，真正会炸的边界条件反而没人提。不是模型不行，是你没告诉它按什么标准看。

适用：几十到几百行的单次改动，尤其涉及金额、时间、权限这类容易出错的逻辑。不适用：模块从零设计的阶段，或者你自己还没想清楚要做什么的探索期。

开始前要准备什么

• Claude 或 Cursor 任选其一，都有免费额度，日常够用
• 一份能贴进对话的 diff，控制在几百行以内
• 一张空白检查项表，或直接写在 PR 描述里
• 预计耗时：刚开始约半小时，熟了十分钟出头

具体怎么做

第 1 步 · 先让它复述改动范围

AI 不知道你改了哪几行。先把背景和担心点交代清楚，它才不会跑去挑三年前的老代码。

你是我的代码评审助手。下面是一次改动的范围说明，请先只做一件事：复述你理解的改动目的、影响到的模块、以及你认为需要重点看的地方。

变更目的：给订单导出接口加按时间范围过滤。改动文件：order_export_service.py、export_validator.py、api/order_export.py。改动规模：约 180 行新增、40 行修改。

涉及的依赖：订单库只读、导出队列。我担心的点：时间边界和时区。

先不要给评审意见，等我下一步。

预期产出：一段它对你这次改动的理解。对不上，说明背景没交代够，别急着往下走。

第 2 步 · 让它自己列 6 条检查项

这步是整件事的关节。不给检查项，AI 是随机挑刺；让它先列清单，你就有了可核对的尺子。

现在请为这次改动生成一份代码评审检查项，数量固定 6 条，不多不少。

要求一：每条必须是能用是或否判断的句子，不能写成“注意健壮性”这类空话。要求二：每条后面用一句话说明，这条不通过时线上会出什么事。

要求三：覆盖优先级按这个顺序排——数据正确性、边界与异常、并发与幂等、可观测性、可读性。要求四：至少有一条和我上面提到的时间边界、时区有关。

输出成表格，三列：编号、检查项、不通过时的后果。

预期产出：一张 6 行表格。我一般在此时删掉一两条太套话的，换上只有我们业务里才有的约束。

第 3 步 · 人工筛一遍，补业务项

模型列的 6 条里，通常有一两条放之四海皆准但对你没用。删掉，换成你知道的业务约束，再让它给验证方式。

我把你上一轮的 6 条调整成了下面这版，后面以这版为准：

1 时间范围参数跨时区时是否仍按 UTC 落库。2 起止时间相等时返回空还是全量。3 导出超过 5 万行时是否分页推进队列。4 空结果和异常返回的状态码是否区分。5 过滤条件是否走了索引。6 新增参数是否打日志。

请做两件事：一是指出这 6 条里有没有互相重叠的；二是每条给一个验证方式——看代码、跑测试、还是查日志。

预期产出：一份最终清单，每条后面挂着验证手段。后面几轮就照这张表走，不再临时想。

第 4 步 · 一次只喂一条

六条一起丢过去，它往往只认真答前两条。一条一轮，每条单独开对话，结论才收得住。

只评审第 1 条：时间范围参数跨时区时是否仍按 UTC 落库。

规则：只输出这一条的结论，不要顺带评价别的。结论只能是三种：通过、有问题、信息不足。说有问题时，必须给出文件名、行号区间和原始代码片段。信息不足时，说明还缺哪段代码，不要猜。不要重写代码，除非我明确要求。

预期产出：一条结论加一段带位置的证据。六条跑完通常要来回好几轮，遇到“信息不足”就补代码再问。

第 5 步 · 收成一张评审表

结论散在对话里没人愿意看。最后让它汇总成表，直接贴进 PR，评论就落在这里。

把前面 6 轮的结论汇总成一张 Markdown 表格，列固定为：检查项、结论、证据位置、建议动作、优先级。

结论只用通过、有问题、信息不足三种。证据位置写文件名和行号区间，没有就写未定位。优先级只能 P0、P1、P2，判断标准是会不会导致数据错。

表格后面另起一段，列出需要我确认的问题，最多 3 条。不要写开场白和总结语。

预期产出：一张能粘进 PR 评论区的表。我现在 PR 描述里放的就是这张，评审人扫一眼就知道哪条没通过。

实测记录

拿一个真实需求做对照：给订单导出加时间过滤，约 180 行改动，涉及两个服务和一次队列改造。

整体算下来比纯手工快一半左右。但真正的差别不是速度，是漏项少了——跨时区那个边界，手工评审时我大概率会跳过去。

最容易错的 3 个地方

1. 检查项写成形容词，像“逻辑要健壮”，AI 只能回空话。改成能判是或否的句子。
2. 六条一起丢过去，上下文一长它就只答前两条。一条一轮，分开跑。
3. 直接采信结论，它偶尔会编出不存在的函数。每条都回代码里对着行号核一遍。

可复用的东西

把 6 条检查项存成一个文件，按场景拆成两三份：涉及金额的一份、涉及时间的一份、涉及权限的一份。下次改动调出对应那份，改两个词就能用。

提示词也存成片段：复述范围、生成检查项、单条评审、汇总成表，四段各放一处，换项目时只替换文件路径和业务描述。

说到底，AI 评审靠不靠谱，一半在模型，一半在你给的尺子够不够具体。

你们组现在最常返工的是哪种改动——时间边界、权限判断还是并发？可以照这套先跑一遍，把不合用的检查项直接换掉。

如果你也经常要做这件事，欢迎在评论区说说你的卡点和做法；也可以留言告诉我，你想看哪个岗位的哪件活怎么用 AI 拆。

admin 普通

收藏 海报 链接