代码评审时让AI全量扫一遍，输出往往又长又平，真正的高风险反而被淹。本文用五个不同岗位的真实场景，拆开“只让它挑高风险”的提示词怎么写：角色、范围、风险等级、输出格式分别怎么约束，附失败版与改好版对照，照着当天能跑一遍。
先给判断：代码评审这件事，让 AI“通读一遍找问题”是效率最低的用法。它对着一百行代码能列二十条，其中十五条是命名、注释、空行这类低风险内容，剩下五条里还有三条是它没看清上下文猜的。真正值得你花时间的高风险——金额算错、并发写脏、权限漏判、异常吞掉——反而混在噪音里，你要花比自己看还久的时间去筛。
所以本文只讲一件事：怎么用提示词把 AI 的输出范围压窄，让它只报“会让你半夜被叫起来”的那几类问题。读完你能自己写出这种约束，而不是复制一段模板。
做完你能得到什么
一段三十行的 Python，原本让 AI 全量评审，输出约 900 字、17 条建议，你要逐条读完才知道哪些要改，大概 8 分钟。换成“只挑高风险”的写法后，同样的代码输出 4 条，每条带行号、触发条件和修法，你 2 分钟内能决定改不改。
不是 AI 变聪明了，是你把它的注意力收窄了。这个差别在代码越长、语言越陌生的时候越明显——接手别人的 Go 项目、临时改一段没写过的 SQL、看实习生提交的 200 行改动，都是这套问法能省时间的地方。
代价也说清楚：约束越紧，漏报的可能性越高。它只报你让它报的那几类，别的它真会跳过。所以这套方法适合“你已经知道该防什么”的场景，不适合第一次接触一个陌生系统时做全面摸底——那种情况反而该让它宽一点，先认路。
准备工作：三样东西先摆到手边
第一步，把你要评审的代码单独抠出来，连同它依赖的上下文一起。只贴函数体，AI 看不到入参校验在上一层做过，就会把“没做空判断”报成高风险。上下文给到“调用它的那一段 + 它操作的表结构或数据结构定义”就够，不用整文件。
第二步，想清楚你这次最怕什么。这一步不能省，也是很多人跳过的一步。怕的是钱算错、怕的是并发、怕的是外部输入没校验、怕的是删数据前没备份——每种怕对应的提示词完全不同。你不用写得很专业，大白话写“这是给客户算退款金额的，算多了公司赔钱”就行，AI 吃这个。
第三步，选工具。三种我实测过的组合，各自适合不同量级：
| 工具组合 | 适合场景 | 成本与限制 |
|---|---|---|
| 网页版对话（DeepSeek、通义千问、Kimi） | 单文件、单函数，几十到两百行 | 免费可用，长代码要分次贴，上下文会丢 |
| 编辑器内插件（VS Code 里的通义灵码、Copilot 一类） | 边写边看，定位到选中代码 | 免费版有次数限制，企业版要管理员开通 |
| 命令行接入 API 自建脚本 | 每次提交自动跑，团队统一口径 | 要 API Key 和一点脚本能力，按量计费 |
普通读者从第一种开始就行。下面所有步骤都按网页版对话来写，插件和脚本只是把同一段话术换个地方贴。
步骤1：先固定角色和评审范围，别一上来就贴代码
打开对话窗口，第一句不贴代码，先交代你是谁、代码是什么。
你是做了八年【支付对账】的【Java】后端评审者。
接下来我给你一段代码，只评【资金计算与幂等】相关的风险，其他一律不评。
你的评审对象是【生产环境会真实调用】的代码，不是教学示例，所以请按线上事故的严重度判断。
为什么这么做？直接贴代码说“帮我看看”，AI 会把“代码质量”整个默认维度全打开，命名、格式、注释覆盖率一起报。先声明评审范围，等于给它一个过滤网，后面所有输出都会往这个范围收。
这一步有个坑我踩过：角色别写成“资深程序员”这种空话，要写成具体工种。“支付对账”和“数据可视化”两个角色，看同一段浮点数计算，前者会立刻指出精度问题，后者不会提。角色越具体，它调用的判断标准越偏向那个领域的真实事故类型。
步骤2：给它一份可勾选的高风险清单
这是本文的核心动作。不要让 AI 自己定义什么叫高风险，你给它一张清单，让它在这张清单上打钩。
按下面五类逐条检查，只报命中的，没命中的不用为了凑数编：
1. 金额、数量、积分等数值计算：精度丢失、单位混用、四舍五入方向错
2. 并发与重复提交：同一笔操作被执行两次会怎样
3. 外部输入与权限：越权访问、未校验的参数直接进数据库或文件路径
4. 异常处理：吞异常、异常后状态不一致、失败没有回滚
5. 资源与边界：空集合、超长字符串、除零、分页越界
为什么列成清单而不是让它自由发挥？开放式提问下，模型的输出分布会向“容易说、不容易错”的内容倾斜，也就是风格问题。给它封闭清单，等于把输出空间从几百种可能压到五类，它想跑偏也难。
这份清单你可以按项目替换。做嵌入式换成正则/内存/中断；做前端换成 XSS、状态竞态、跨域；做数据分析换成空值传播、类型隐式转换、分组键重复。清单条数控制在五到七条，超过十条它会开始逐条硬套，反而编出不存在的问题。
工具差异在这里也显出来：网页版对话里清单效果最稳，因为它会逐条回看；编辑器插件的行内建议通常没耐心走完五条，更适合单点提问“这行有没有并发问题”。做团队统一口径，还是得走 API 脚本那条路，把清单写死在提示词里。
步骤3：规定输出格式，让它给出能直接动手的东西
每条按这个格式输出，最多五条，按严重度排序：
【风险】一句话说清后果，例如“退款时金额被重复累加”
【位置】行号或函数名
【触发条件】什么输入或时序下会出问题，要具体
【修法】最小改动，不要重写整段
没有命中任何一类就直接说“未发现清单内风险”，不要补充建议。
最后那句“不要补充建议”很关键。不加这句，它会觉得只报两条显得不认真，尾巴上补一句“另外建议增加日志和单元测试”。这些不是错，但会稀释你的注意力，而你本来就是为了筛掉它们才写的这段提示词。
“最多五条”是在防另一个跑偏：有清单之后它会开始过度敏感，把“这里理论上可能”也报上来。给条数上限，它必须自己排优先级，排的过程就是一次风险判断，这个判断本身对你有用。
步骤4：贴代码，同时给一条只有你知道的业务背景
代码之外补一句话，说清这段代码在业务上的要害。下面三个完整示例，场景各不相同，可以直接复制改。
示例一：财务对账脚本（Python）
失败版：
帮我review一下这段代码，看看有什么问题。
结果：报出变量命名不规范、缺少类型注解、建议拆分函数，真正的高风险——退款金额用 float 累加、失败重试没有幂等键——一条没提。
改好版：
你是做了八年电商财务系统的Python评审者。
这段代码每天跑一次，给【3000 个商家】算应结货款，算错会直接打款打错。
只按下面清单评：金额精度、重复执行、空数据、除零、异常吞掉。
每条给【风险/位置/触发条件/最小修法】，最多四条，没命中就说未发现。
【贴代码】
差别在哪：加上“每天跑、3000 个商家、打款打错”之后，它把 float 累加提到了第一条，并指出“金额用 Decimal、入库转分存整数”这个最小修法。缺了这句背景，模型只知道这是段计算代码，不知道精度错误的代价是打错钱。
示例二：接手别人的接口代码（Go）
失败版：
这段Go代码有什么可以优化的？
“优化”这个词会把输出拉向性能与风格，权限和并发问题基本不会被提。
改好版：
你是Go后端评审者，这段代码是【订单查询接口】，会暴露给【外部合作方】调用。
我担心的是越权和注入，不是性能。只评：
1. 传入参数有没有直接拼进SQL或文件路径
2. 查询有没有带上当前登录用户的ID做隔离
3. 出错时返回给调用方的信息会不会泄露内部结构
每条给行号和一句修法，最多三条。
【贴代码 + 贴这段代码查询的表字段】
待替换部分要填准：接口暴露给谁（外部还是内部）、担心什么、依赖哪张表。漏填“暴露给外部合作方”，它就不会把返回错误信息泄露当回事；漏贴表字段，它无法判断有没有按用户隔离。
示例三：SQL 改动（数据分析岗）
失败版：
帮我检查这条SQL有没有问题。
改好版：
你是有五年经验的数仓评审者。这条SQL明天要【全量重跑】，结果直接进【经营日报】。
只报三类：会不会扫全表导致超时、join 会不会放大行数导致指标虚高、时间范围边界会不会漏掉最后一天。
每条写明“在什么数据量下会出问题”，最多三条。
【贴SQL + 说明表的大致数据量级】
这里补的是数据量级，因为“扫全表”在小表上根本不是问题。不给量级，它会给你一条空泛的“建议加索引”。
步骤5：拿到结果后做一轮人工回筛
AI 报完不等于完事。逐条过一遍，问自己两个问题：它的触发条件在我这个系统里真实存在吗？修法改下去会不会引入新问题？
我实测下来，五类清单里第 2 类（并发与重复提交）误报率最高。模型会假设“这个方法可能被并发调用”，但你的代码可能上层有分布式锁，它看不到。这一类命中后一定要回到调用链确认，别直接改。
第 3 类（越权与未校验输入）漏报率相对低，但有个陷阱：它只检查你贴出来的那段，如果校验在上一个函数里做，它会报“未校验”。所以准备工作里说的“贴调用它的那一段”不是可选项。
怎么检查这次评审做对了
三个可核对的信号。
一是条数。按上面的写法，输出稳定在三到五条，多了说明清单约束没生效，少了（零条）说明代码确实干净或者你贴得太短。
二是每条都能落到行。如果它只说“这个方法可能有并发问题”而不给行号和触发时序，回去补一句“每条必须给具体行号和触发输入”。
三是你能在一分钟内决定改不改。要是每条都要你再研究五分钟，说明它报的是“可能性”而不是“风险”，把清单写得更具体、加一句“只报你能举出具体触发输入的”再跑一次。
关于成本，二十份左右的重复评审下来，我的记录是单次从翻开代码到决定改什么，从大约七分钟压到两分钟上下。样本小，你按自己的项目再核。
做不出来时的排错清单
| 现象 | 大概率原因 | 怎么回退 |
|---|---|---|
| 报了一大堆风格问题 | 没写清单，或写了“优化”这类开放词 | 删掉“优化”，只留清单五条，重跑 |
| 一条都不报 | 代码贴太短，AI 看不到上下文 | 补入参来源和调用方，再跑一遍 |
| 报的风险是编的 | 没给业务背景，它在通用猜测 | 补一句“这段代码在什么业务里、出错的代价是什么” |
| 输出格式乱 | 格式要求没放在最后 | 把格式模板挪到提示词末尾，紧贴代码 |
| 换了个文件效果就差 | 角色没换，还在用上一个领域的判断 | 重新开对话，别在同一段对话里换评审领域 |
最后两条提醒：涉及金额、权限、数据删除的结论，AI 的判断只能当线索，最终要人工确认，尤其是你不熟悉的语言或框架；企业代码贴到公网对话工具前，先看你们公司的数据规范，很多公司要求这类内容只能走内部部署的模型。
明天可以先试这一件
挑你今天正在改的一段代码，写四行：角色（具体到业务）、风险清单（三到五条）、输出格式（风险/位置/触发条件/修法）、一句业务要害。跑一次，对比你平时的问法，看报出来的东西是不是更集中。别贪多，一段就够，试完再决定要不要把它写成你团队的固定模板。
写作过程中查阅了《阿里巴巴Java开发手册》（阿里巴巴，2024）与《Microsoft Learn：代码审查最佳做法》（Microsoft，2025）；文中案例与操作顺序为独立整理，具体执行以官方说明为准。
