代码评审 Agent 不是替代工程师，而是把重复检查前置
代码评审 Agent 不是替代工程师，而是把重复检查前置
代码评审（Code Review）是软件工程中质量保障的核心环节。但在很多团队中，它正在变成瓶颈。
合并请求排着长队，资深工程师被反复拉去审查同样的编码规范问题——空指针风险、硬编码密钥、缺失的错误处理……真正需要架构层面讨论的设计问题，反而被淹没在"这里少了个空格""这个变量命名不符合规范"的琐碎反馈中。
极狐GitLab Duo 的代码审查流程（Code Review Flow），正在改变这个局面。
01 问题根源：评审者不是"格式检查器"
先看一个普遍现象：团队引入 AI 编程助手后，开发者写出代码的速度确实变快了，合并请求的数量随之增长。但评审侧的产能并没有同步提升，瓶颈从"写代码"转移到了"审代码"。
这背后有一个结构性矛盾：代码评审的本质是工程判断，但大量评审时间花在了重复性检查上。
具体来说，评审者每天要做的事情包括：
编码规范检查：命名是否符合约定、缩进是否统一、注释是否完整。
安全基础检查：有没有硬编码密钥、有没有 SQL 注入风险、用户输入是否做了校验。
可维护性检查：函数是否过长、是否有明显的重复代码、错误处理是否到位。
跨文件依赖检查：这个改动会不会影响其他模块的接口、有没有破坏既有契约。
这些检查重要吗？当然重要。但它们应该是自动化的第一道筛选，而不是占用资深工程师大量时间的手工劳动。当评审者把精力花在格式和规范上，留给架构设计、业务逻辑和边界条件的判断力就会稀释。
02 Code Review Flow：平台级 AI 评审，不是 IDE 插件
市面上有不少 AI 编程工具能在 IDE 里做行内建议，但它们的上下文有限——通常只能看到当前打开的文件或当前函数。对于代码评审这个场景，这远远不够。
极狐GitLab Duo 的代码审查流程运行在合并请求上下文中，而不是开发者的本地编辑器里。这意味着：
完整的变更上下文：它能分析整个合并请求的代码变更，理解这次改动"做了什么"，而不仅仅是"改了哪一行"。
代码仓结构理解：它对整个仓库的结构和跨文件依赖有增强的上下文理解，能判断一个改动是否会影响到其他模块。
可操作的反馈：审查评论不是泛泛而谈的"建议优化"，而是包含具体的代码位置、问题描述和修改建议。
使用方式也很直接：在合并请求中，把 @GitLabDuo 分配为审查者，或者使用快速操作 /assign_reviewer @GitLabDuo。审查启动后，你可以实时监控会话进度，直到审查完成。
评审完成后，你还可以与极狐GitLab Duo 交互——回复它的审查评论请求澄清或替代方案，在任何讨论线程中 @GitLabDuo 提问后续问题。这不是一个"跑完就结束"的静态报告，而是一个可以对话的评审过程。
03 自定义审查指令：把团队规范变成 AI 规则
不同团队有不同的编码规范和评审重点。一个金融科技团队可能最关心 SQL 注入和密钥泄露，一个 IoT 团队可能更关注嵌入式代码的内存安全。如果 AI 评审只能做通用检查，价值就打了折扣。
极狐GitLab Duo 支持通过 mr-review-instructions.yaml 文件定义项目专属的审查指令。这个文件放在仓库的 .gitlab/duo/ 目录下，使用 YAML 格式，通过 glob 模式匹配不同文件。
一个实际的配置示例：
instructions:
- name: TypeScript Source Files
fileFilters:
- "**/*.ts"
- "!**/*.test.ts"
instructions: |
1. 确保正确的 TypeScript 类型（避免 'any'）
2. 遵循命名约定
3. 为复杂函数编写文档
- name: All Files Except Tests
fileFilters:
- "!**/*.test.*"
- "!**/*.spec.*"
instructions: |
1. 确保正确的错误处理
2. 为复杂逻辑添加有意义的注释
3. 避免硬编码凭据几个关键特性：
附加而非替换：自定义指令附加到极狐GitLab Duo 的标准审查标准之后，不会覆盖内置的安全检查。
模式匹配：支持 glob 模式，可以按语言、目录、文件类型精确匹配，也支持 ! 前缀排除特定文件。
多指令叠加：单个文件可以同时应用多个指令组，比如同时检查 TypeScript 规范和通用安全规则。
可追溯：由自定义指令触发的审查评论会标注"根据 '[instruction_name]' 中的自定义指令"，标准评论不使用此格式，方便区分。
更实用的是，你还可以用极狐GitLab Duo Chat 分析代码库，让它帮你生成初始的审查指令草稿，再根据实际需要调整。
04 自动审查：让每个合并请求都有"初审"
手动分配 @GitLabDuo 适合需要时按需使用，但很多团队希望每个合并请求都自动获得一次 AI 初审，确保基础质量问题不会溜过去。
极狐GitLab Duo 支持项目级、群组级和应用级的自动审查设置：
项目级：在项目设置 > 合并请求中启用"极狐GitLab Duo 自动审查"。创建合并请求后（非草稿状态），极狐GitLab Duo 会自动进行审查。
群组级：群组所有者可为整个群组启用，设置从群组级联到下属项目。
应用级：管理员可为实例上所有项目启用。
设置从应用级联到群组再到项目，更具体的设置会覆盖更宽泛的设置。这意味着企业可以先在群组级设定基线标准，再让个别项目按需调整。
05 人在回路：AI 做初审，人做终审
极狐GitLab Duo 的代码审查流程不是要取代人类评审者。它的定位是"初审助手"——把重复性、规则性的检查前置，让工程师把精力留给真正需要人类判断的事情。
一个典型的协作模式是这样的：
1. 开发者提交合并请求，极狐GitLab Duo 自动进行初审。
2. AI 识别出编码规范、安全隐患和可维护性问题，在合并请求中给出具体反馈。
3. 开发者根据反馈修复问题，或者与极狐GitLab Duo 对话讨论替代方案。
4. 人类评审者介入时，基础问题已经被过滤掉了，他们可以专注于架构设计、业务逻辑和边界条件。
5. 评审者可以回复极狐GitLab Duo 的评论，进一步追问或确认。
这个流程的关键在于分工明确：AI 负责广度和速度，人负责深度和判断。当代码生成越来越快，如果没有一个同样快速的评审机制来承接，合并请求队列只会越排越长。
写在最后
代码评审的真正价值，从来不在于找出每个分号和空格的问题，而在于确保每一次合并都在架构上合理、在业务上正确、在安全上可靠。
极狐GitLab Duo 的代码审查流程，通过平台级的上下文理解、可自定义的审查指令和自动化的初审机制，把重复性检查交给了 AI。这不是让工程师变得多余，而是让他们从"格式检查器"的角色中解放出来，回到代码评审最该做的事情上——用工程判断守护代码质量。
当代码生成越来越快，评审也必须跟上。把重复交给 AI，把判断留给人。
