很多团队把 AI 接进代码审查，结果无非两种：要么它只在旁边刷一堆没用的风格建议，要么它每次都换个说法、说不到点上。问题一般不出在模型，出在没配：什么时候触发、让它看哪些文件、按什么仓库规范审、哪些结论必须人工复核。这篇给一套配置顺序，照着填参数、写规则文件，就能把 AI 变成稳定的第一道审查。
把 AI 接进代码审查，翻车的方式基本就那几种：要么它只在旁边刷一堆没用的风格建议，要么它每次换个说法、说不到点上。问题一般不在模型，在没配。什么时候触发、让它看哪些文件、按哪份仓库规范审、哪些结论必须人工复核——这几件事不定清楚，它就只是个会打字的评论机器人。
下面给一套配置顺序，从触发时机到规则文件、提示词模板、降噪与放行，照着填参数、写规则，就能把 AI 变成稳定的第一道审查。每一步都写了「怎么验证配对了」和「什么情况下这套不成立」，别跳着做。
先定触发时机：AI 审查到底插在哪一步
触发时机决定了后面的成本结构和体验。插得太早，依赖每个人的本地环境，配不起来的人就绕过去了；插得太晚，人已经审完一轮，AI 的意见反而变成额外负担。先想清楚它在流程里的位置，再谈规则。
| 插法 | 覆盖情况 | 主要代价 | 适合谁 |
|---|---|---|---|
| 提交前本地跑 | 看个人习惯，容易漏 | 快、省额度 | 想先试水的个人 |
| PR 打开时自动跑 | 覆盖面广，不靠自觉 | 会拖慢流水线 | 多数团队起步选它 |
| 合并前人工点一次 | 最可控 | 容易忘、依赖人 | |
| 多环境并行 | 最完整 | 配置成本高 | 流程已经稳定的团队 |
五人以内的团队，建议先做「PR 打开时跑 + 只输出评论不阻断合并」。等评论质量稳定了，再把其中一部分升级成放行门禁，顺序别反。
- 审查范围写清楚：只看本次 diff，还是允许拉被改文件的上下文；只给 diff 会漏跨文件影响，给全文又吃额度，通常做法是 diff 加被改文件所在模块的少量上下文
- 明确 AI 结论的性质：是普通评论、是必过门禁，还是只给建议由人点采纳；这一条不定，后面所有人都会为「它说的算不算数」争一遍
- 不适用情况：团队还没有一份统一的代码规范文档，先补规范再接 AI，否则它只会按通用习惯给建议，跟你们实际要求对不上
把规范写进仓库：规则文件与项目上下文
审查规则应该放在仓库里，而不是塞进提示词。一份人和 AI 共用的规范文件，改规则走一次代码评审，谁改的、为什么改，都能追溯。提示词里只放模板和输出格式，规则内容引仓库文件。
不同编辑器或客户端的规则文件名和加载方式不一样。先到站内客户端配置相关页面确认你的工具读哪个文件、放哪个目录，配错位置会静默不生效，你还会以为 AI 不给力。具体哪个文件对应哪个工具，到 /tools 里的工具目录逐个核对。
- 可判定规则
- 「禁止在循环里做数据库查询」能判，「代码要优雅」判不了，写成「看到 X 就报 Y」
- 项目上下文
- 技术栈、目录职责、允许用的内部库，给最小必要的一份就够
- 规范文件位置
- 放仓库根目录或约定目录，跟代码一起版本管理
- 抽一版规范出来把现有口头约定和文档里的规则合并成一份，删掉没法判定的条目
- 按工具约定落位确认工具读哪个文件名和目录，放进去后故意写一段违规代码验证它是否被触发
- 标注优先级给每条规则标级别（阻断 / 建议），方便后面按级别分流评论
- 补充最小上下文写清楚技术栈版本和目录职责，内部库只列常用的一两个，别把整个架构文档塞进去
审查提示词模板：让它稳定输出你要的格式
提示词的价值在于让输出稳定，而不是让它更聪明。一个固定四段的模板就够用：角色与范围、判定依据、输出格式、边界。边界那段最容易被省掉，但它恰恰是控制胡说八道的关键。
- 角色与范围：说明只看本次改动，不做重构建议，不给与改动无关的优化意见
- 判定依据：要求引用仓库规范里的具体条目，引不出来就不要提
- 输出格式：统一成问题、位置、严重级别、建议改法四个字段，方便后按级别分流
- 边界：明确写「不确定就标注为待确认，不要编造调用关系和业务含义」
输出格式怎么写、字段怎么约定，参考站内结构化输出相关页面，别自己发明一套字段名，否则下游处理和别人的工具接不上。格式定了一版之后就别频繁改，改一次所有历史评论的对比就断了。
提示词改完别凭感觉判断好坏。留一小批历史 PR 做固定用例，改一次跑一次做对比，具体做法在站内提示词版本与评测相关页面。没有固定用例，你只是在拿真实项目做实验，出问题也说不清是哪次改动引起的。
降噪与放行：怎么让它别变成刷屏机器
AI 审查最常见的死法是被忽视。原因通常不是它说错了，是它说得太多、太碎、重复。降噪要在配置阶段解决，不能指望大家自己过滤。下面三件事不做，一周之内就没人看它的评论了。
- 限制每个 PR 的评论条数上限，超出的合并而不是逐条发
- 低于某个级别的建议合并成一条摘要，人想看再展开
- 同一个问题在同一个 PR 里只说一次，不要每推一次提交就重报一遍
| 路径类型 | 处理方式 | 原因 |
|---|---|---|
| 锁文件、依赖清单 | 直接跳过 | 改动是机器生成的，没有审查价值 |
| 自动生成的代码 | 直接跳过 | 按模板产出，报的问题改不了 |
| 纯文案与配置改动 | 跳过或只给建议 | 通常不涉及逻辑，误报率高 |
| 鉴权、支付链路 | AI 只做参考 | 必须指定的人复核 |
| 数据库迁移脚本 | AI 只做参考 | 出错代价高，不能让模型拍板 |
分级放行是控制信心的手段：先只让 AI 对少数几个目录生效，跑顺了再扩范围。一上来全仓库开启，前几周的误报会把人的耐心一次性消耗掉，之后再想推广就难了。
人工兜底要写进流程文件里，不是口头约定：安全相关改动、鉴权与支付链路、数据库迁移，AI 结论只作为参考，必须由指定的人复核签字。这条不写下来，出了事没人知道该谁看。
什么情况下这套不适用：仓库历史混乱、没有统一构建和测试的团队。先把 CI 跑通，再谈 AI 审查，否则你只是在本就嘈杂的流程上再加一层噪音。工具本身稳不稳定，可以到 /tools/speed-test 做一次探测再决定接不接。
下一步先把触发时机和规则文件两件事定下来，再动提示词。具体工具的配置入口和当前可选的审查类工具，到工具目录里按你的技术栈筛一遍；各家方案的现状可以到 /rankings 看当时的排序，别照搬别人的组合。→常见问题
AI 审查和现有的 lint、静态检查是不是重复了？
不重复，但边界要划清。格式、明显的空指针、未使用变量这类交给 lint 和静态检查，它们更快也更确定；AI 更适合看逻辑分支、边界条件、错误处理是否一致、命名与分层是否符合仓库规范。把 lint 已覆盖的东西也丢给 AI，只会让它看起来全在说废话。
提示词写得越长，审查效果会越好吗？
不会。长提示词的收益很快到顶，真正决定效果的是仓库里的规则文件是否可判定、上下文是否给对。常见做法是提示词保持短而固定，把项目特有的判断依据放进仓库规则文件里按需加载；规则更新走代码评审，比每次改提示词更容易被团队接受和追溯。
误报太多，团队快不用了，先改哪一处？
先砍范围，再调提示词。第一步把触发目录缩到最核心的几个模块，锁文件、生成代码、纯文案直接跳过；第二步给输出加条数上限和严重级别，只把阻断级问题单独拎出来。两步做完通常能明显降噪。提示词本身放最后改，并且每次改都要用固定用例对比，别直接上生产。
