
代码审查是质量的守门环节,也是最耗资深工程师时间的环节。MiniMax Code 代码审查靠不靠谱,取决于审查分工的三层设计:机器管规则,Agent 管关注点,人管复核。
审查的三层结构
第一层是规则审查。命名规范、格式统一、圈复杂度这类确定性规则,工具链的静态检查就能覆盖,Agent 把规则配置进审查流程,机器自动判,零成本跑全量。
第二层是审查关注点层。AI 代码审查的用武之地:空指针风险、资源泄漏、并发隐患、注入漏洞、异常处理缺失,这些需要理解代码语义才能发现的问题,M3 的深度推理正对胃口。它逐文件扫描,按风险等级输出问题清单,每条附定位和修改建议。
第三层是人工代码复核。架构合理性、业务逻辑正确性、设计取舍的权衡,这些需要业务上下文和工程判断的问题,资深工程师的领域。机器过滤后的疑点清单交给他们,精力聚焦在真正需要人脑的位置。
三层结构的核心逻辑是各归其位:规则给机器,语义给 Agent,判断给人。全盘交给 Agent 不现实(第三方实测口径:重要代码必须人工审查),全靠人肉不可持续(产能瓶颈),分层才是出路。
三层结构的边界也说明一下:层与层之间不是瀑布式的先后,是并行加汇聚。规则检查在提交时自动跑,Agent 审查在提测时批量跑,人工复核在关键节点跑,三层的产出汇总到统一的审查视图。设计的初衷是过滤漏斗:底层拦截量大的低级问题,顶层聚焦少量的高价值判断,人审看到的问题越少越精,说明前两层的工作越到位。

三层结构的成本账也摆一下:规则层近乎零成本,Agent 层按任务计费(每千行代码的审查成本在分位),人工层最贵但被前两层稀释后总量可控。三层的边际成本递增、边际价值也递增,把钱花在刀刃上的结构天然合理,这也是分层设计比单层方案(纯人审或纯机审)先进的地方。
Agent 审查的强项
一致性是第一强项。人审会累,第十个文件的注意力质量和第一个没法比;Agent 每个文件的处理标准恒定,最后一个文件和第一个同等待遇,审查质量无衰减。
覆盖度是第二强项。1M 上下文把整个 PR 的改动连同上下游依赖放进视野,跨文件的影响分析做得动:这个函数的签名改了,哪些调用方受影响,影响链路一路追到底,人肉追这个链路要翻半天文件。
速度是第三强项。批量改动几百个文件的审查,Agent 分钟级出清单,人肉按天计。提测前的快速过滤,Agent 先筛一遍,明显问题当场改掉,人审看到的是二筛后的精华。
留痕是第四强项。每条审查意见带定位、理由、建议修改,审查记录自动归档。复盘时审查发现的问题类型可统计,质量趋势可追踪,审查从一次性劳动变成可积累的质量数据。

安全类的审查值得单独点出:注入漏洞、敏感信息硬编码、不安全的依赖引用,这类问题的模式相对固定,Agent 的模式识别正好发力。把安全清单固化进审查流程,每次提交自动过一遍,安全左移从口号变成默认动作,这可能是 Agent 审查投入产出比最高的一个点位。
人审的不可替代
说完强项说边界,人审的不可替代:业务语义的判断在人。代码逻辑跑得通,不代表业务规则对:优惠计算的四舍五入方向、权限判断的边界包含关系,这些对错只有业务方说了算。Agent 不知道你们的业务约 定,这块盲区必须人补。
架构取舍的判断在人。同样的功能,抽象成工具类还是内联实现,加缓存还是直查,这些权衡没有标准答案,取决于系统的演进方向和团队的技术债策略,资深工程师的直觉在这里仍是金标准。
审查的文化职能在人。代码审查同时也是知识传递的场合,新人通过审查意见学习团队的口味,老人通过审查了解新人的成长,这个社交层的价值机器替代不了。全机审的团队,知识传递的通道会悄悄萎缩。
人的复核还有个隐性职能:对 Agent 审查结果的校准。机器审查的问题清单里,误报和漏报的分布会随代码库的特点漂移,定期抽核清单的准确率,发现某类误报高发就调整审查配置。人审不仅是把关,还是在训练这套人机协作的审查体系,越用越准的飞轮从这里转动。
不可替代清单的最后一项是责任归属。代码合入后出了问题,审查签了名的人要能回应为什么当时放行,这个责任链条机器接不住,Agent 的审查意见是参考,放行的决定权和责任在人。质量体系里可以有机器的劳动力,不能有机器的责任人,这条边界写在流程里就是人审的最终确认权。
落地的分工建议
三层结构讲完,落地的分工建议:提测前的自查交给 Agent:提交前自动跑一轮关注点审查,问题清单直接反馈给提交人,低级问题不过人审的手。这一层拦截做得好,人审的工作量直接减半。
人审聚焦增量判断:架构影响、业务正确性、设计权衡,按文件的风险分级分配注意力,核心模块细看,边缘模块抽查。审查的深度跟着风险走,产能和质量得兼。
审查的标准沉淀成 Skill:团队审查的关注点清单、历史高频问题的模式、特定模块的特别注意项,写成 SKILL.md 挂进审查流程。Agent 的审查口径从此带团队基因,新成员的审查产出也自动对齐团队标准,规范传承有了新通道。
工具好不好,落到自己业务里跑一遍才知道。目前,云巴巴提供 MiniMax Code 审查场景的配置咨询,你可以先联系我们了解实际部署情况和使用效果;在云巴巴,你还能找到覆盖不同行业、不同团队规模的更多同类产品,按自己的业务场景挑最合适的那一个。


2026年9月22日由阿里云主办的2026云栖大会在杭州开幕,云巴巴作为阿里云MaaS生态伙伴受邀出席;9月23日云巴巴首席AI架构师倪江玮在【智启新程:AI驱动创新企业】分论坛发表《从账号到产能,千问办公落地真实场景的FDE实践》主题演讲,系统呈现云巴巴推动千问办公进入企业真实场景的FDE方法论与三阶段六模块交付体系。

报销解决员工垫付回款,结算解决合作方按成果取酬,两者解决的问题不同。本文对等说明两种路径的形态、报销路径适合的场景与范围、平台结算路径的适用条件、四处关键差异以及按条件做选择的判断方式。

责任划分的起点是关系性质。本文说明标准劳动关系、不完全劳动关系与民事合作关系的区分依据,用工责任与控制环节的对应关系,平台承担的审核与留存义务,人员自身应尽的信息真实性义务以及争议的处理路径。

对公划转、个人收款、托管账户与批量代付各有适用条件。本文对等说明四类通道的形态、对公收款的适用场景与前提、个人收款的限制与维护要点、通道选择要看的四类条件以及合规核对的三条线索。

批量发放出现退回是规模上去之后的常见情形。本文说明退回的三类直接原因、人员与账户的分层核对顺序、退回之后的处理顺序与时限安排、减少同类退回的四项前置动作以及台账应保留的字段。