代码审查的质量，往往取决于它离提交有多远。等合并请求堆积三天再回头看，上下文已经冷了，返工成本也跟着上涨。把 AI 审查接进日常流程，本质是让检查发生在离开发动作最近的地方。

这篇 AI代码审查教程 面向的是已经能写代码、也大概知道怎么调模型，但还没想清楚“审查这一步该插在哪里”的工程师。下面按准备、接入、验证、排查四个阶段展开，每一步都保留可回退的空间。文中涉及的接口地址、模型名称与计费规则，请以你所用平台控制台的实际显示为准。

一、先想清楚：AI 审查该插在流程的哪一段

把 AI 审查直接挂在合并请求上，是最常见也最容易失败的做法。原因是反馈太晚：开发者已经切换了任务，看到评论要重新加载上下文，最后往往变成“改个格式应付一下”。

更实用的做法是按三个位置分层：

• 提交前（本地钩子）：只做低成本检查，例如命名、日志残留、明显的空指针风险、硬编码密钥。目标是拦住低级问题，不追求深度。
• 推送后（CI 阶段）：对本次变更做结构化审查，输出问题清单并附行号，允许失败但不阻塞合并且只做提示。
• 合并前（人工复核节点）：AI 只负责列清单和给建议，是否放行仍由人决定，尤其是权限、计费、数据删除这类改动。

这样分层的意义在于：不同位置的容忍度不一样。本地钩子可以慢一点但不能频繁误报，CI 阶段可以严格一点但不能拖垮流水线。

哪些代码适合交给 AI 先看一遍

经验上，重复度高、规则明确、样板代码多的改动最划算：接口适配层、DTO 与校验逻辑、异常处理分支、日志与埋点、单元测试补充、依赖升级后的调用点替换。反过来，涉及并发模型设计、账务一致性、加密协议、架构取舍的改动，AI 审查更适合作为“提问者”，帮你列出需要考虑的分支，而不是给出结论。

把 AI 审查定位为“第一个不厌其烦的读者”比定位为“最终裁判”更接近实际收益。它能显著减少漏看，但不能替代对业务语义的判断。

二、接入前的准备工作

准备一：固定审查规则与输出格式

审查结果忽好忽坏，八成不是模型问题，而是提示词每次都在变。建议把提示词当成代码来管理，放进仓库，随版本演进。

一条可复用的结构是：角色 + 输入范围 + 关注维度 + 输出格式 + 禁止事项。输出格式尽量定死，例如按“文件 / 行号 / 严重级别 / 问题 / 建议修改”五列输出，严重级别只用 blocker、major、minor 三档。格式固定之后，后续做统计和自动去重才可行。

准备二：准备模型调用凭据

无论你自建脚本还是接现成工具，需要准备的通常只有三样：API Key、Base URL、模型名称。如果团队同时评估多个厂商的模型，逐个申请 Key、逐个维护地址会很麻烦。这时可以把 通联AI中转站 这类 AI 中转站纳入候选：它提供 OpenAI 兼容风格的调用方式，用一个 Base URL 和统一管理的 Key 即可切换不同模型，适合需要横向对比审查效果、又不想频繁改动配置的团队。

准备三：控制输入体积

审查质量下降的常见原因不是模型不行，而是塞进去的上下文太杂。建议按“变更 diff + 相关文件摘要 + 项目约定”三块组织，diff 之外的内容只给必要的接口签名和数据结构，不要整仓投喂。单次变更过大时，先按模块拆成多次调用，再合并结果。

三、实操步骤：把审查接进日常开发流程

下面是一套从零到可用的顺序，建议按步推进，每步都留下可验证的产物。

1. 跑通最小调用。先用一段几十行的 diff 验证鉴权、地址和模型是否配置正确，确认能拿到稳定输出，再谈集成。
2. 固化提示词与输出格式。把提示词写入配置文件或独立模块，版本化提交，避免散落在脚本里。
3. 接入本地钩子。在提交前钩子里只跑“快速档”：限制变更行数、限制超时时间，超时就跳过并提示，不阻塞提交。
4. 接入 CI。在推送后触发一次完整审查，把结果以评论或流水线日志形式输出，第一周只告警不拦截，观察误报率。
5. 建立误报清单。把被人工判定为无效的问题记录下来，反向补充到提示词的禁止事项里，逐步收敛噪声。
6. 设置降级路径。接口超时、额度不足、返回格式异常时，流程应降级为“跳过 AI 审查”，而不是让整条流水线卡住。
7. 定期回看。每两周抽一批被 AI 拦下的问题，统计哪些是真问题、哪些是人本来就会发现的，据此调整审查范围。

最小调用示例

下面是结构示意，字段名以对应 SDK 文档为准，值请替换成控制台给出的实际内容：

from openai import OpenAI client = OpenAI( api_key="你的 API Key", base_url="控制台给出的 Base URL", ) resp = client.chat.completions.create( model="控制台显示的模型名称", messages=[ {"role": "system", "content": "你是资深评审者，只指出可复现的问题。"}, {"role": "user", "content": diff_text}, ], ) print(resp.choices[0].message.content)

这段代码本身不重要，重要的是把 api_key、base_url、model 三个值抽成环境变量，方便在不同环境与不同模型之间切换。团队如果同时用多家模型做效果对比，统一入口能省下大量维护成本，具体可用的模型与协议兼容方向，以 通联AI中转站 控制台和文档页面的当前信息为准。

四、常见问题与排查思路

问题一：审查结果大量重复、报同一处

多半是输入里既有 diff 又有完整文件，模型在两处都看到了同一个问题。解决方式是明确告诉它只针对 diff 行报告，并在输出后按“文件 + 行号 + 问题类型”做一次去重。

问题二：只报格式问题，不报逻辑问题

通常是提示词里的关注维度没有分层。把维度显式列出，并要求按严重级别排序，把逻辑、边界、并发、错误处理放在格式之前，效果通常会明显改善。

问题三：流水线变慢或偶发超时

检查三件事：单次请求的变更行数是否过大、是否设置了超时与重试上限、是否串行等待了多个模型。建议对超长变更先拆分，并给整个步骤设置总时长上限。

问题四：消耗超出预期

审查类调用是典型的“高频小请求”，用量容易被低估。至少要做三件事：给审查用的 Key 单独设置额度上限；记录每次调用的输入输出规模；定期查看余额与消耗明细，避免在生产高峰期因额度不足导致审查静默跳过。计费方式、余额与充值入口，以平台控制台的实时展示为准，本文不引用任何具体价格。

五、最后：判断这套流程是否真的有用

不要只看“AI 提了多少条建议”，要看三个更实际的指标：合并请求的一次通过率是否上升、同类问题是否在后续提交中重复出现、人工评审花在低级问题上的时间是否下降。这三个指标都改善，说明接入位置和审查范围基本对了；如果建议数量很多但没人采纳，问题通常出在噪声太高，而不是模型不够强。

回到开头那句话：审查要发生在离开发动作最近的地方。先用最小成本跑通一次调用，再逐步把规则、格式、降级路径补齐，这套 AI代码审查 流程才算真正落进日常开发里。