代码评审还在人工排队？用评审任务流和审核人推荐先跑完初审
代码评审还在人工排队？用评审任务流和审核人推荐先跑完初审
核心提示：代码评审的瓶颈往往不是"没人会审"，而是"没人有空审"。评审任务流（JH Advanced Code Review）可以让 Agent 智能体先完成一轮行级初审与评审摘要，推荐审核人任务流则按审批规则、可用性与工作负载自动推荐最合适的评审人。人工评审从"逐行排查"退到"裁决关键问题"，评审等待周期可以显著缩短。
评审任务流是极狐GitLab Duo Agent 平台的内置任务流，19.3 版本引入，在评审合并请求时除分析代码差异和仓库上下文外，还会读取相关议题和流水线失败信息，并以简体中文发布行评论、评审摘要和审核结论。推荐审核人任务流则根据审批规则（包括代码所有者规则）推荐满足要求的最少审核人数量，并综合可用性、工作负载和时区给出人选建议。
评审为什么总在排队
把团队评审的日常拆开看，等待大多消耗在三类杂活上：
首轮初审没人愿意做。大量合并请求的问题集中在命名、空指针、缺失的边界测试这类"扫一眼就能发现"的缺陷，让资深工程师逐行排查这些内容，成本结构并不合理。
指派评审人靠拍脑袋。谁熟悉这块代码、谁最近有空、谁和作者时区重叠，这些信息散落在每个人脑子里。指派不准的直接后果就是评审请求石沉大海，或者被拉进一个并不合适的人。
重复阅读已经讨论过的问题。评审意见提出后，作者修了、评审人忘了，同一问题在下一个合并请求里再被提一遍，双方都在做重复劳动。
这三类杂活的共同点是：规则明确、上下文可获取、结论可复核——正是适合交给 Agent 智能体的部分。人工评审的价值应该集中在架构权衡、业务语义与团队规范的裁决上。
让任务流先跑完初审
第一步：开启评审任务流
顶级群组所有者可以为群组及其项目开启 JH Advanced Code Review：
在顶部栏中，选择搜索或跳转到并找到您的顶级群组。
选择设置 > 极狐GitLab Duo。
选择更改配置。
在任务流执行下，选中允许任务流执行和允许内置任务流。
选中 JH Advanced Code Review，选择保存更改。
开启后，极狐GitLab 会准备一个名为 JihuLabDuo 的服务账号（若用户名被占用会自动加后缀），它就是这个评审 Agent 在项目里的"身份"。私有化部署实例需要实例管理员先为实例开启任务流执行与内置任务流，群组所有者再进行群组级配置。
第二步：请求完整审查
在合并请求中通过任一方式启动完整审查：
/assign_reviewer @JihuLabDuo或者在右侧边栏的审核人中直接将 @JihuLabDuo 指派为审核人。审查进度可以在左侧边栏人工智能 > 会话中查看；审查完成后，回到合并请求概览查看评审摘要，在变更页查看逐行评审意见。后续提交后需要重新审查时，在 JihuLab Duo 审核人旁选择重新请求审核。
评审任务流的一个细节值得注意：它会先读取已有讨论，避免重复发布相同发现。对于已经修复的问题，它会回复并解决相应讨论；对于仍然存在的问题，则保留讨论并补充新增发现——这意味着它接手的不只是"提意见"，还有"跟进度"。
第三步：把"找谁评审"也自动化
评审人选择可以组合两个机制：
自动审核人指定基于 CODEOWNERS 文件工作。开启后，合并请求以就绪状态创建（或草稿标记就绪）时，极狐GitLab 自动把已更改文件的代码所有者指派为审核人：
# CODEOWNERS
# 内部目录由平台组把关
/internal-api/ @platform-team
# 安全敏感目录由安全组必审
/security/ @appsec-team推荐审核人任务流更进一步：它推荐满足每条审批规则所需的最少审核人数量，并按可用性、工作负载和时区筛选人选，结果展示在合并请求侧边栏，由你决定指定哪些。注意该任务流在 19.3 及更高版本中取代了旧的"审核人指定策略"项目设置。
两个机制一个保证"该审的人一定在"，一个保证"被点名的人真的有空"，组合使用时人工协调成本基本消失。
第四步：对评审结论追问
Agent 的评审意见不必照单全收。在包含评审意见的讨论中直接提问：
@JihuLabDuo 请解释这条审查意见。任务流会读取该讨论中的已有评论，按需读取相关文件或议题后回复当前讨论。注意追问不会启动新的完整审查，这保证了上下文聚焦、用量可控。
配置与使用中的注意事项
仅在评论中 @JihuLabDuo 不会启动完整审查，必须指派为审核人或使用
/assign_reviewer快速操作。这是最容易踩的第一个坑。项目 Runner 必须带有
gitlab--duo标签且使用支持 Docker 镜像的执行器（或开启极狐GitLab 托管 Runner），否则任务流会话创建了但不会开始运行，表现为"审查未启动"。服务账号需要时间创建。开启设置后 JihuLabDuo 没有出现在审核人列表里，等创建完成再刷新合并请求即可，不必反复改配置。
用量按实际消耗计费，不是按审查次数收固定费用，实际用量取决于合并请求大小、可用上下文和任务流调用模型的次数。大型合并请求建议先自行拆分，这也是控制成本的有效手段。
模型跟随 Agent 平台配置。此任务流使用为极狐GitLab Duo Agent Platform 配置的模型，代码建议类功能的模型设置对它不生效。
常见问题
问：评审任务流会不会把人工评审挤掉？
不会，也不该。它的定位是初审与进度跟踪，行评论、摘要和审核结论只是参考输入。审批规则的裁决权、合并的最终判断始终在人的流程里，审核结论是给你省时间用的，不是替你签字用的。
问：私有化部署能用吗？
可以。专业版、旗舰版均支持，私有化部署需要实例管理员开启任务流执行与内置任务流，并为实例配置支持该功能的人工智能网关，之后由顶级群组所有者完成群组级开启。
问：它和代码所有者审批冲突吗？
不冲突。CODEOWNERS 与审批规则决定"谁必须审"，推荐审核人任务流在这些规则约束内推荐人选，评审任务流提供初审输入，三者各司其职。
立即体验
代码评审的等待时间，本质上是在为"杂活没人做"付利息。把初审和指派交给 Agent 任务流，让资深工程师只处理真正需要人拍板的问题：
阅读 评审应用与代码评审任务流官方文档，按步骤为群组开启
参考 自动审核人指定与推荐，配好 CODEOWNERS 与审批规则
顺手把这份配置清单转给团队的评审负责人，本周就能跑通第一个"AI 先审、人后裁"的合并请求
