写得更快，审得更薄：编码提效指标达标之后，评审成了瓶颈

产出计数翻倍之后，压力去了哪里

设想一家研发组织下达硬指标：一年内用人工智能工具将每位工程师每月合入的合并请求（即被接纳进代码库的代码变更）数量翻倍。一段时间后，看板上的合入曲线终于达标；可如果审阅人数没有同步增加，待审的变更就只能靠无评论的“静默批准”或自动放行来消化。

本文的核心论点是：当管理层围绕单一产出计数设定提效目标时，数字可以达标，但它并非靠号令立竿见影，而是靠每人持续数月的累积使用，且代价集中落在下游人工评审上^[1]。当编写增速远超审阅扩容，达标的吞吐计数便掩盖了人工把关的稀释^{[1, 3]}。

从吞吐爬坡到评审稀释：纵向实证、感知偏差与自动化滥用

一项追踪企业编码提效指令的纵向案例研究记录了这一过程。He、Agarwal、Denisov-Blanch、Azaletskiy、Koyejo 与 Vasilescu（2026）分析了某家中型、积极采用人工智能的软件企业在 2024 年 1 月至 2026 年 4 月间的内部遥测与变更历史，覆盖 802 名开发人员与 196,212 个合并请求^[1]。2025 年 6 月，其技术负责人公开要求在十二个月内借助人工智能将人均每月合入变更数翻倍，且工具预算不封顶^[1]。研究采用非随机的交错双重差分法，将每人启用工具后的产出与自身此前对比，并以当月使用状态未变的同事为参照^[1]。

吞吐端，宣布目标当月产出几乎未动；每人启用工具时产出约升 12%，随后随累积使用增长：严格日历月控制下，观测使用水平对应约 1.5 倍产出，个人用满约九个月才达 2 倍；全公司人均 2 倍直到宣布后第十个月（2026 年 4 月）才实现^[1]。增量并非源于加班或拆碎提交：额外工作天数最多解释总增幅的五分之一，变更规模反而变大（中位数 35 行升至 61 行），功能与缺陷修复增速快于日常维护^[1]。各资历增幅相近，但集中在 2022 年以来新建的代码库（+44%），老代码库增幅很小且不显著（+12%）^[1]。

瓶颈集中在评审端。随着人工智能编写的变更占到约 90%，全公司变更总量较 2025 年初基线增长 3.1 倍，而审阅人池仅扩大 1.5 倍，人均评审负荷约翻倍（2.0 倍）^[1]。至少经一次人工评审的变更占比从 89% 降至 68%，接受自动人工智能评审的占比从约 19% 升至约 84%，在指令后不久反超人工——自动评审替代了部分人工评审而非仅作补充^[1]。附带人工评论的实质性人工评审占比从约 39% 降至约 21%，无评论的静默批准维持在约 50%；中位审阅人每月有评论的评审持平（约 3 次），静默批准却约翻倍^[1]。控制规模后，同一作者同月内由人工智能编写的变更从首次人工评审到合入耗时延长约 20%，总周期延长 22%（相关关系）^[1]。观察期后段，公司开始将变更路由至自动评审与自动批准——组织靠绕开人工评审而非加快人工审阅来维持节奏^[1]。

短期质量代理指标未见急性崩塌：合入率持平、回滚占比未升、作者在合入后也没有更多地提交缺陷修复；但这些短期指标会漏掉缺陷、事故与可维护性，合入计数也未记录“谁在审代码”的转移^[1]。作者建议把这类指令视为转型的起点而非一次工具部署，以季度为周期，先提升使用深度再要求达标，并按古德哈特定律的警示为目标指标配上其他信号，并像规划编写容量一样规划评审容量^[1]。其局限在于：样本为单一预算不封顶且新代码库众多的激进企业，估计值更接近上限而非行业均值；采纳非随机，效应量有不确定性；变更计数仅反映活动量，质量代理仅限短期^[1]。

短期主观体感同样不可靠。Becker、Rush、Barnes 与 Rein（2025）对 16 名成熟开源项目资深开发人员（平均 5 年经验）的 246 项任务做随机对照试验，随机允许或禁止使用人工智能工具：事前预测省时 24%，事后仍估计省时 20%，实测却使完成时间增加 19%^[2]。主观体感与实测可背离，且成熟项目的减速与前述老代码库收益微弱相一致^{[1, 2]}。

Parasuraman 与 Riley（1997）解释了人类工效学风险：自动化误用即过度依赖，易在负荷与可靠性影响下导致监控失效或决策偏差；弃用常源于误报；而滥用是不顾人类作业后果推进自动化，使操作员角色沦为自动化的副产品并加剧误用与弃用^[3]。当评审负荷翻倍、自动评审接管覆盖面时，人类的静默批准便面临沦为副产品的风险^{[1, 3]}。

工程落地与 rlab.works 能力映射：评审容量、准入分类与注意力队列

基于此，我们的工程判断是：（1）在吞吐目标旁并列报告实质性人工评审占比、静默批准占比、人均负荷与人工评审耗时；（2）上线前书面规定哪些变更可由自动评审单独放行、哪些必须有人类评论；（3）把注意力队列视为容量而非形式——负荷增速快于审阅人时应限流或扩容，而非任由批准变静默；（4）记录批准人与所据证据，事后区分“已批”与“已读”；（5）按季度与多指标考核，不把感知问卷当证据^[2]。

在 rlab.works 的智能中枢模块中，可映射三项技能包与三项组件：

• 交付与复核关口：复杂任务拆解与执行（S01）执行“拆解任务清单 → 确认执行范围（人工关口） → 逐项执行 → 验收交付（人工关口）”，配合协作交付、审批与证据门槛（提供会话室、暂存草稿、注意力队列、决策、产物版本、审批及有证据支撑的完成与交接）与可审计工作流、人工确认与决策复盘（版本化工作流与步骤、权限、暂停等待人工决定并记录复核）。该包在制造业可迁移：仅编排软件任务与人工记录，物理检修由人执行，需配置作业许可与检查点。我们的工程判断是在“验收交付（人工关口）”按变更类别强制要求人工评论。
• 本地执行治理：经审批的电脑操作（S03）执行“准备账号与登录 → 审批操作清单（人工关口） → 执行并截图 → 检查改动（人工关口）”，配合本地编码智能体执行治理（归一化编码智能体钩子事件，在本地工具执行前判定允许、拒绝或需审批并记录结果）。该包在法律行业可迁移：须显式限制读写目录，外部提交不在默认权限内。我们的工程判断是在“检查改动（人工关口）”留存结构化证据以控制下游审阅负荷。
• 发布准入核验：版本发布与回退（S05）执行“整理发布清单 → 演练备份恢复 → 批准上线（人工关口） → 分批上线 → 验收或回退（人工关口）”。该包在能源行业可迁移：仅支持软件交付，不控制场站设备，需适配离线环境、可信签名与现场变更流程。我们的工程判断是在“批准上线（人工关口）”核验变更是否经过实质性人工审阅。

需诚实说明：所有技能包均为合成数据演示的拟议未集成方案；前两项组件静态检查为可用，「可审计工作流、人工确认与决策复盘」为原型；上述技能包与组件目前均不度量审阅人负荷、评审深度（有评论或静默批准）或自动批准占比——这些是我们从论文提炼的要求。

设定研发提效目标前的三项行动清单

• 将评审覆盖与深度并入核心看板：与人均合并请求数并列追踪人工评审覆盖率、有评论的实质性评审占比、静默批准占比与人均负荷^[1]。
• 预先界定自动批准与强制人工评论清单：上线前写明哪些变更允许自动放行，哪些必须在“验收交付（人工关口）”与“批准上线（人工关口）”留下人工评论。
• 按季度考核实测周期并管控队列容量：以季度为单位评估累积效应与评审耗时，拒用主观问卷替代实测^{[1, 2]}；按我们的工程判断，注意力队列积压时应主动限流或扩容。