在 AI 编程工具快速普及之后，很多研发团队已经开始使用大模型辅助写代码。但相比“生成代码”，我认为更适合企业落地的方向是：基于大模型的代码 Review 助手。

原因很简单：企业项目中，代码不是写出来就结束了，更重要的是能否稳定运行、是否符合规范、是否存在安全隐患。传统 Code Review 主要依赖人工经验，但人工 Review 容易受时间、精力和业务熟悉程度影响。大模型可以作为“第一轮审查员”，帮助研发人员提前发现明显问题，提高 Review 效率。

本文聚焦一个具体场景：如何用大模型构建一个可落地的代码 Review 助手，而不是简单把代码丢给 ChatGPT 让它提建议。

---

一、代码 Review 助手要解决什么问题？

在真实研发流程中，代码 Review 通常关注以下几类问题：

1. 代码规范问题
   比如命名不清晰、重复代码、函数过长、异常处理不统一。

2. 潜在 Bug
   比如空指针、数组越界、并发安全、事务未回滚、资源未关闭。

3. 安全风险
   比如 SQL 注入、越权访问、敏感信息泄露、接口参数未校验。

4. 性能问题
   比如循环里查数据库、重复调用远程接口、无分页查询大量数据。

5. 业务逻辑风险
   比如订单状态流转错误、金额计算精度问题、权限判断遗漏。

传统静态扫描工具适合发现格式和安全规则类问题，但对业务语义理解较弱。大模型的优势在于能够结合上下文理解代码意图，发现一些“看起来能跑，但逻辑上可能有问题”的风险点。

---

二、不要直接 Review 整个项目

很多人第一次尝试 AI Code Review，会把整个文件甚至整个项目代码丢给大模型。这种方式效果通常不好，原因有三个：

• 输入太长，容易超出上下文限制；
• 无关代码太多，模型难以聚焦；
• 成本高，响应慢，不适合接入 CI/CD。

更合理的方式是：只 Review 本次提交的变更代码，也就是 Git Diff。

例如开发者提交了一个 Pull Request，系统可以获取本次改动：

bash

git diff origin/main...HEAD

然后将 diff 内容作为输入，让大模型重点分析新增和修改部分。

Git Diff 的好处是范围明确，模型只需要关注“这次改了什么”，也更符合实际 Code Review 场景。

---

三、整体架构设计

一个基础版 AI Code Review 助手可以这样设计：

text

开发者提交 Pull Request  ↓触发 CI 流程  ↓获取 Git Diff  ↓过滤无关文件  ↓按文件或函数切分  ↓调用大模型 Review  ↓结构化输出问题  ↓自动评论到 PR  ↓开发者修改或忽略

其中有两个关键点：

1. 过滤无关文件
   比如 package-lock.json、构建产物、自动生成代码、图片资源等，不应该交给模型 Review。

2. 按文件切分
   如果一次提交改动很大，需要按文件或函数级别拆分，避免单次输入过长。

---

四、Prompt 设计：让模型输出可执行建议

Code Review 的 Prompt 不能写得太泛，例如“帮我看看这段代码有什么问题”。这种问法会导致模型输出很多空泛建议，比如“建议增加注释”“注意异常处理”。

更好的 Prompt 应该明确 Review 维度和输出格式。

示例：

text

你是一个资深 Java 后端代码 Review 工程师。请根据以下 Git Diff 进行代码审查。
重点关注：1. 是否存在空指针、事务、并发、资源泄露等潜在 Bug；2. 是否存在 SQL 注入、越权访问、敏感信息泄露等安全问题；3. 是否存在循环查询数据库、无分页查询等性能问题；4. 是否存在明显业务逻辑风险；5. 不要纠结代码风格，除非会影响可维护性。
输出要求：- 只输出真实可能存在的问题；- 如果没有发现问题，输出空数组；- 使用 JSON 数组输出；- 每个问题包含 level、file、line、problem、suggestion。
Git Diff：……

期望输出：

json

[  {    "level": "high",    "file": "OrderService.java",    "line": 86,    "problem": "取消订单接口仅判断了订单归属，没有校验订单当前状态，可能导致已支付或已发货订单被取消。",    "suggestion": "在取消前增加状态校验，仅允许待支付或待确认状态取消。"  }]

这种结构化输出方便程序解析，也方便自动评论到 GitLab、GitHub 或 Gitee 的 PR 页面。

---

五、结合项目规范，减少无效建议

大模型如果不了解项目规范，容易提出一些不符合团队习惯的建议。例如有的项目统一使用全局异常处理，不要求每个方法都 try-catch；有的项目使用 MyBatis Plus，不需要手写分页 SQL。

因此，建议给模型提供一份“项目 Review 规则说明”。

例如：

text

项目规范：1. Controller 层不直接访问 Mapper；2. Service 方法涉及多表写入时必须加 @Transactional；3. 金额字段统一使用 BigDecimal，不能使用 double；4. 用户权限必须通过 PermissionService 校验；5. 查询列表接口必须分页；6. 不要求每个方法单独 try-catch，项目已有全局异常处理。

当模型结合项目规范后，Review 结果会更贴近实际业务，而不是输出通用化建议。

---

六、一个典型案例：金额计算风险

假设某次提交中出现如下代码：

java

double totalAmount = price * count;order.setTotalAmount(totalAmount);

如果 Prompt 中明确了“金额字段必须使用 BigDecimal”，大模型可以指出：

json

{  "level": "medium",  "file": "OrderService.java",  "line": 42,  "problem": "订单金额使用 double 计算，可能产生精度误差，影响支付和结算。",  "suggestion": "使用 BigDecimal 进行金额计算，并明确舍入规则。"}

这类问题传统编译器不会报错，但在业务系统中非常关键。尤其是电商、金融、支付、结算类系统，金额精度问题必须严格控制。

---

七、结合静态扫描工具效果更好

大模型并不是要替代 SonarQube、Checkstyle、ESLint 这类工具。更合理的做法是分工合作：

• 静态扫描工具：负责格式、复杂度、重复代码、已知安全规则；
• 大模型：负责上下文理解、业务逻辑风险、代码意图分析；
• 人工 Review：负责架构设计、复杂业务判断、最终决策。

整体流程可以设计为：

text

代码提交  ↓静态扫描  ↓AI Review  ↓单元测试  ↓人工 Review  ↓合并代码

这样可以避免让大模型处理所有问题，也能减少误报。

---

八、如何控制误报？

AI Code Review 最大的问题之一是误报。模型有时会把不存在的问题说得很严重，甚至误解代码逻辑。

可以通过以下方式降低误报：

1. 只让模型输出高置信问题

Prompt 中明确要求：

text

如果只是猜测，不要输出。只有当代码中有明确依据时，才指出问题。

2. 加入严重等级

让模型区分：

• high：可能导致线上故障、安全漏洞、资金损失；
• medium：可能导致异常、性能下降或维护困难；
• low：一般优化建议。

上线初期可以只自动评论 high 和 medium，low 级别不展示。

3. 支持开发者反馈

开发者可以对 AI 评论选择：

• 有效；
• 无效；
• 已修改；
• 忽略。

这些反馈可以用于后续优化 Prompt 和规则。

---

九、落地到 GitLab CI 的简单思路

如果团队使用 GitLab，可以在 CI 中增加一个 Review Job：

yaml

ai_code_review:  stage: review  script:    - git diff origin/main...HEAD > diff.txt    - python scripts/ai_review.py diff.txt  only:    - merge_requests

ai_review.py 的核心逻辑包括：

python

diff = read_file("diff.txt")chunks = split_diff(diff)
all_comments = []
for chunk in chunks:    result = call_llm_review(chunk)    comments = parse_json(result)    all_comments.extend(comments)
post_comments_to_gitlab(all_comments)

实际项目中还需要处理：

• diff 过长切分；
• 模型调用失败重试；
• JSON 解析异常；
• 评论去重；
• 同一行不要重复评论；
• 敏感代码脱敏。

---

十、数据安全问题不能忽视

企业代码往往包含业务逻辑、接口地址、配置项甚至内部系统信息。如果使用外部大模型 API，一定要评估数据安全。

可以采取以下措施：

1. 过滤敏感文件
   如 .env、配置文件、密钥文件不发送给模型。

2. 脱敏处理
   对 token、password、secret、url 等字段进行替换。

3. 私有化部署模型
   对安全要求高的企业，可以部署本地代码大模型。

4. 只发送 diff，不发送完整仓库
   降低代码暴露范围。

AI Code Review 不是单纯技术问题，也涉及企业安全和合规，需要提前设计边界。

---

总结

基于大模型的代码 Review 助手，是 AI 在研发效能领域非常实用的细分方向。它的价值不在于替代人工 Reviewer，而是提前发现潜在 Bug、安全风险和业务逻辑问题，让人工 Review 更聚焦于架构和核心设计。

一个可落地的方案通常包括：

• 基于 Git Diff 而不是全量项目进行审查；
• 使用明确 Prompt 约束 Review 维度；
• 输出结构化 JSON，便于自动评论；
• 结合项目规范减少无效建议；
• 与静态扫描工具配合使用；
• 建立开发者反馈机制持续优化。

如果只是把代码复制给大模型问“有没有问题”，效果往往不稳定。真正能落地的 AI Code Review，一定是嵌入研发流程、结合团队规范、控制误报并保障代码安全的工程化系统。