15天工业C++仓库实地研究：AI批量修复代码后，CI与评审成为主要瓶颈，改用目录分批并限制单次文件数才恢复吞吐
核心概要
该研究在一家闭源工业C++仓库中开展为期15天的探索性单案例实地研究，由一名经验丰富的开发者使用命令行AI编程助手批量修复普遍存在的代码问题，通过Gerrit元数据、开发者日记与团队聊天三角互证并做描述性统计与定性编码，发现AI辅助修复迅速产生数百次提交、触及数千行代码，使构建即提交的CI与评审注意力饱和；按文件逐次提交会压垮CI，改为按目录分批并限制每次变更的文件数后吞吐恢复，但仍需显式请求评审、协商可接受的提交粒度并反复跟进以解决构建与静态分析失败，说明当机械性编辑变便宜时，CI容量、评审投入与变更编排成为主要瓶颈。
深度剖析
研究刻画了AI辅助大规模代码修复在工业仓库中的真实工作流影响：AI辅助修复迅速生成数百次提交、触及数千行代码，使构建即提交的CI与评审注意力饱和。 以往关于LLM编码助手的研究多关注生成能力或受控实验，本文把观察对象放在闭源工业C++仓库的真实协作流程上，把CI与评审作为被影响对象来测量。 15天探索性单案例实地研究，一名经验丰富的开发者使用命令行AI编程助手，Gerrit元数据与开发者日记、团队聊天三角互证，采用描述性统计与定性编码。
研究识别出提交粒度是核心调节变量：按文件逐次提交会压垮构建即提交的CI，改为按目录分批并限制每次变更的文件数后吞吐得以恢复。 把“提交粒度”从工程习惯提升为AI辅助修复能否可持续的关键机制，并给出可操作的批处理与文件数上限做法。 基于同一案例中前后两种提交策略的对比观察，由Gerrit元数据与开发者日记支持，属于单案例内的经验性发现。
即使吞吐恢复，AI辅助修复仍需要显式请求评审、协商可接受的提交粒度，并反复跟进以解决构建与静态分析失败。 说明瓶颈不只是技术容量，还包括评审协调与协商这类社会技术环节，把“修复完成”重新定义为需要持续编排的过程。 来自开发者日记与团队聊天的定性编码，配合Gerrit元数据，属于单案例的定性证据。
研究提出应把语义变更集（如“修复所有X类警告”）视为一等工作单元，可针对开发者、评审者与CI做不同切分。 把工作单元从文件或提交重新定义为语义变更集，为在超大仓库中协调AI辅助修复提供组织与流程层面的设计方向。 属于基于案例观察提出的结论性主张，文中以案例经验与定性分析支撑，未做跨仓库验证。
启示与展望
该研究面向在大型、长期维护的工业仓库中引入AI辅助机械性修复的工程团队与流程负责人，尤其是使用构建即提交CI与Gerrit式评审流程的组织。其结论适用于“机械性、可批量”的修复场景，例如统一处理某类警告；在此设定下，它提示应主动控制提交、评审与CI的批次粒度，并把语义变更集作为可分别切分给开发者、评审者与CI的工作单元。
作为探索性单案例研究，其发现来自一个闭源工业C++仓库、一名经验丰富的开发者与15天窗口，其他仓库规模、语言、CI配置与团队结构下的表现仍需观察。此外，本文为摘要级材料，未包含具体提交数量、代码行数、CI排队或失败率等数值细节，也未给出不同分批策略的量化对比，因此这些机制在不同设置下的强度仍是开放问题。