用 AI 编程助手做一次可复现的代码审查：从提示词模板到落地清单

很多团队用 AI 编程助手做代码审查时，得到的反馈时好时坏：同一段代码，今天说没有问题，明天又列出一堆风险。问题往往不在模型，而在审查过程不可复现：没有固定输入、没有固定检查维度、没有可核对的结论。本文给出一套可以在团队里直接复用的做法，目标不是让 AI 代替人审查，而是让每一次审查都有相同的起点和相同的输出结构。

一、为什么 AI 审查容易失真

第一，上下文不完整。只贴出单个函数，助手看不到调用方、异常处理约定和数据来源，只能凭猜测补全。第二，指令太宽泛。「帮我看看这段代码」没有说明审查重点，模型会把风格、命名、性能混在一起，重要问题反而被淹没。第三，结论不可验证。只说「可能有风险」，却不指出文件、行号、触发条件和修复方向，审查人无法复核。解决办法是把审查变成一个固定流程：先准备材料，再按维度检查，最后输出清单。模型换了、人员换了，流程不变，结论才可比较。

二、准备三份材料，缺一不可

1. 变更说明：这次改了什么、为什么改、影响哪些接口或数据。2. 最小上下文：被改代码、直接调用方、相关类型定义和测试用例，尽量控制在一次审查能讲清楚的范围。3. 约束条件：语言版本、编码规范、必须遵守的安全规则，例如不得记录敏感字段、不得信任外部输入。示例：审查一个用户资料更新接口时，至少要提供接口定义、参数校验逻辑、数据库更新语句和对应的单元测试。如果只给接口定义，助手很难判断校验是否遗漏。

三、一个可复用的提示词模板

可以直接把下面模板保存为团队文档，审查时只替换括号部分：请按以下维度审查代码，并逐项给出结论：1. 正确性：边界条件、空值、异常分支是否完整。2. 安全性：输入校验、权限检查、敏感信息处理是否合规。3. 可维护性：命名、重复逻辑、函数长度是否影响后续修改。4. 性能：是否存在明显的不必要循环、重复查询或大对象拷贝。代码背景：变更说明；约束条件：编码规范与安全规则；代码：粘贴最小上下文。输出要求：每个问题写明位置、触发条件、影响和建议修复方式；没有问题的维度写「未发现问题」，不要编造。这个模板的关键在最后一句：明确要求「没有问题就写没有问题」，可以显著减少模型为了凑结论而虚构风险的情况。

四、分三轮检查，不要一次问完

第一轮：正确性和安全性。先确认代码在正常和异常情况下都能工作，输入不可信时是否有兜底。第二轮：可读性和可维护性。检查命名是否表达意图、重复代码是否应该抽取、注释是否解释了「为什么」而不是复述「做了什么」。第三轮：回归与测试。让助手根据代码列出需要补充的测试用例，例如空列表、超长字符串、并发更新、权限不足等，再由人工确认哪些用例真正需要落地。分轮的好处是每一轮的结论更聚焦，也更容易发现上一轮被忽略的细节。

五、把 AI 结论转成落地清单

AI 的输出不能直接当作审查结论，需要经过一次人工过滤。建议用下面这张表做最终记录：必须修复：影响正确性或安全性的问题，合并前必须改掉并补充测试。建议优化：影响可读性或性能但不阻塞上线的问题，记入后续迭代。存疑待确认：助手提出但证据不足的问题，人工复核后再决定。误报：已经核实不存在的问题，记录原因，避免下次重复讨论。例如，助手指出「更新接口没有校验昵称长度」，人工核对后发现校验在网关层已经做了，那么这条就应记为误报，并把「网关层校验」补充进下一次审查的上下文，而不是每次都重新争论。

六、一个小型示例

假设更新昵称的函数只做了非空判断就直接写数据库。用模板审查后，值得人工确认的问题至少包括：昵称长度上限在哪里校验？用户是否有权修改该用户编号？昵称中是否允许特殊字符和空白？更新失败时是否需要事务回滚？这些问题都不需要模型替你做决定，但模型可以帮助你把遗漏点系统地列出来。

七、团队落地建议

1. 把提示词模板放进代码仓库的审查文档，而不是只存在某个人的聊天记录里。2. 每周复盘一次误报和漏报，不断收紧模板里的约束条件。3. 审查结论只认「位置、触发条件、影响、修复方向」四要素齐全的条目。4. 涉及权限、资金、敏感数据的变更，AI 审查只能作为补充，不能替代人工终审。

结语

AI 编程助手最适合做的事情，是把审查从「凭感觉」变成「按清单」。当输入固定、维度固定、输出结构固定，审查质量就不再依赖某一次对话的运气。先从一个小模块开始试用这套模板，跑两三个迭代后，再根据团队的误报情况调整它，效果会比频繁更换提示词更稳定。