我在很长时间里都对“AI代码审查”持保留态度——静态分析工具我用了不少Cppcheck、Clang Static Analyzer、Clang-Tidy都上过效果是有的但误报率能把人逼疯。一个千行级别的模块跑完能给你刷出几百条告警让开发去逐条确认最后多半是不了了之。所以这次在合作单位的研究所里做22万行C/C代码审查试点的时候我本来预期是“AI帮忙把告警排序然后大家照着看”结果实际跑完我反而对整个链条有了新的判断AI在代码审查里的核心价值不是替你逐行读代码而是把“哪里值得花时间看”这件事的效率从周级拉到了小时级。这篇内容就是这次22万行C/C代码审查试点的数据复盘和操作过程记录。标题里说的“试点数据公开”我在这里会把口径统一、脱敏之后的结果展开来写。如果你正在评估要不要把AI审查引入自己的C/C工程或者手头也有一个规模不小、历史包袱很重、堆了好多年没敢动的代码库那这篇你可以直接作为评估参考。我会尽量少讲抽象概念多讲流程、数据、踩坑和可复用的方法。1. 为什么把审查目标定在22万行C/C规模效应与选点逻辑1.1 22万行代码量级对审查意味着什么先算一笔账。22万行C/C代码拆开来看大概是两千多个源文件每个文件平均一百来行不算特别大但预处理展开之后就完全不是一回事了。按常见的宏和模板展开率22万行源码展开后能到五六百万行如果中间夹着数据表和自动生成的协议代码这个数字还会更夸张。人工审查速度是多少我按经验丰富的工程师、认真逐行审、每小时200到300行来估算22万行需要800到1100个小时。一个人全职干不吃不喝也要一两个月而且这是在理想情况下——没有会议、没有上下文切换、没有“这个模块当年不是我写的所以得先花半天读懂”这种现实障碍。放到实际项目里单靠人肉全量审查三个月能出结果就算快。但很多团队真正的问题不是“审查慢”而是压根没做全量审查。大家习惯的节奏是每次合入前看看diff或者抽查几个高危模块其余代码基本靠运行时测试去兜底。22万行的存量代码里有没有隐藏的空指针、越界、错误处理缺失没有人能给一个确切的答案。这种“不知道有没有问题”的状态比“知道有问题”更危险。另外一个容易被忽略的点是模块耦合。22万行代码的模块依赖已经不是人脑能完全记住的了改A模块的buffer大小可能会影响很远的地方B模块的读取逻辑人工审查只能看到眼前这一个函数跨函数、跨文件的数据流分析靠人眼去追非常容易漏。这就是规模效应的本质——问题单看局部都合理放到全局才暴露。1.2 试点范围如何划块而不失控第一次跑这么大代码量最忌讳的就是把22万行一次性丢给工具去扫。工具跑不跑得完先不说就算跑完了几万条告警堆在一起任何团队看了都会头皮发麻。我们的做法是把代码库切成6个批次按依赖关系从底层往上层递进第一批通信协议层处理报文收发、序列化、解析属于外部输入的第一道关口第二批数据采集与存储模块涉及文件、数据库、内存缓存资源生命周期长第三批计算算法库包含数字信号处理和矩阵运算重点关注越界和内存布局第四批控制逻辑模块状态机、任务调度的分支非常多第五批平台工具与公共组件日志、配置、内存池、任务队列属于被大量复用的底层设施第六批测试辅助代码优先级最低但也扫一遍防止测试代码里的工具函数漏问题。划分批次的标准不只是“按目录切”更核心的是按编译单元和依赖边切。我们先用构建系统导出的依赖关系做了分层保证相邻批次之间接口稳定前一批扫出来的问题类型可以作为后一批的参考。这样做的好处是每批代码量控制在3到4万行左右工具单次运行的时长在可接受范围内AI分析的上下文窗口也能吃得下出问题的时候定位也快。另一个关键点是“基线先行”。在正式审查前我们先对整个代码库跑了一次Clang-Tidy的常规检查把所有“本来就存在、和AI审查无关”的告警做成基线数据。后面AI产出的报告要和基线做对比才能知道哪些问题是增量发现哪些只是存量告警被重复报了一次。这个步骤看起来不起眼但少了它数据分析阶段会非常痛苦。1.3 审查规则怎么定先抓大后抓小工具扫出来的问题有很多类但资源有限规则不能一开始就贪多。我们和研发、测试负责人一起开了两次评审会把规则收敛到7大类按“发生频率高、修复成本低、安全隐患大”三个维度做了排序内存生命周期问题泄漏、重复释放、悬空引用、析构函数遗漏空指针与可空性外部输入未判空、返回值未检查、回调数据可能为空缓冲区边界数组越界、memcpy/strcpy长度失控、字符串截断整数运算溢出、截断、有符号无符号混用导致的问题并发竞争共享变量未加锁、锁顺序不一致、条件变量误用异常安全性抛出异常后资源未释放、部分构造对象泄露错误处理缺失返回值被忽略、错误分支为空。这7类不是说其他规则不重要而是试点阶段必须控制噪音。如果你把命名规范、死代码、性能建议全部塞给AI它会把注意力分散到大量低价值问题上真正要紧的内存和越界反而会被埋没。我们明确告诉模型只关注这里列出的规则其他风格问题不要提。这个约束对后续数据质量的影响非常大。2. AI代码审查的完整工作流从环境准备到产出报告2.1 工具链组合静态分析器负责查AI负责判先说清楚我不是只用“大模型看代码”这一种方式而是组合了传统静态分析器与AI研判两段式流程。为什么这么设计因为单一工具各有硬伤。传统静态分析器很擅长做语法级、路径级的精确判断。Cppcheck和Clang Static Analyzer能模拟执行路径从alloc到free从memcpy的长度到数组的索引它们能给出具体的告警位置和过程描述。缺点是噪音大稍有复杂度的工程几千条告警里可能只有20%是真问题。而且它们只能报“这里可能有风险”不能结合业务语义判断“这段代码实际上会不会被外部输入触发”。纯靠AI模型直接审代码也不行。LLM在处理单个函数时表现不错但一旦涉及大范围代码库它会面临上下文窗口限制还会出现“重复发明同一个问题”的现象——同一个缺陷在多处调用点被反复报告因为没有全局去重机制。更麻烦的是AI有时会基于“看起来像”给出很高的置信度但实际上根本没有走到那条执行路径。所以我的流水线是Clang Static Analyzer、Cppcheck、Clang-Tidy先做一轮底层扫描输出一个标准化的JSON告警文件然后写一个脚本把每个告警对应的函数体、所在文件的关键上下文、以及调用关系提取出来组装成待分析单元最后把这些待分析单元交给AI模型做语义预判输出“是否真实风险、风险等级、修复建议”。传统静态分析器负责“广撒网”AI负责“捞真鱼”两者各干各擅长的事。工具选型上有几个细节值得提Clang系列工具强烈依赖compile_commands.json如果工程构建系统不是CMake需要用bear或compiledb这类工具把编译命令导出来Cppcheck的--enablewarning,style,performance,portability选项建议全部打开但后续过滤规则要在脚本层做不要为了减少输出而调整分析器参数否则容易漏问题告警输出统一转成JSON而不是文本格式因为后面AI处理时结构化字段远比人阅读友好。2.2 审查上下文与提示词的组织方式好多人用AI看代码就是直接把函数贴给模型让它“帮我看看有没有问题”这种方式效果波动很大核心原因是模型缺少上下文。一个CDN函数单独看可能是安全的但如果你告诉它这个函数的输入来自socket解析结果而且长度字段是网络字节序它马上就会意识到缺校验的严重性。我们设计了一套固定的提示词模板每次审查都会带上同一个前缀里面包含代码所属的模块、函数所在路径、相关数据结构定义、前后关键函数、静态分析器的原始告警内容。提示词里明确要求模型按JSON格式输出是否存在风险、属于哪条规则、严重程度打分1到5、修复建议、以及它的判断依据。格式固定的好处是后处理方便而且模型在同一个格式约束下输出的稳定性会更高。下面是一个简化版的提示结构示意你是一名资深C/C代码审查专家。现在给出一个代码片段和对应的静态分析告警。 请仅依据给定代码和以下规则判断问题 规则列表内存生命周期、空指针、缓冲区边界、整数运算、并发竞争、异常安全、错误处理。 判断要求 1. 该告警是否可能真实发生不考虑极端且不可能出现的输入 2. 如果可能发生会导致什么具体后果 3. 给出修复建议 4. 对修复紧急程度打分1-55为最高。 输出格式JSON数组字段包括 severity, rule_type, is_real, reason, fix_suggestion。c // 上下文input 来自外部网络报文解析结果len 是报文头中的字段 static void process_frame(uint8_t *buf, uint32_t len) { char out_buf[512]; // 静态分析器报告缓冲区可能越界 memcpy(out_buf, buf HEADER_SIZE, len); ... }如果你只是把这段代码丢给模型它可能会说“需要看调用方传入的len是否受控”但给了上下文之后模型就能明确判断len来自网络数据未校验就用于memcpy的拷贝长度这是高优先级越界风险。这就是上下文的价值。 ### 2.3 结果去重、分级与可追溯性 静态分析器输出的原始告警数量会非常惊人。我们这22万行代码库第一轮扫描得到的原始告警数接近2万条——注意这里还没有算AI预判光是工具产生的就这么多。如果直接把这些告警交给人工等于没做AI审查。 去重是第一步。基本原理是把告警按照“文件路径 所在函数名 告警类型 触发变量”做聚合同一个变量引发的多次告警归并成一个案例。例如p在malloc之后有12个调用点静态分析器会报12次“可能的空指针解引用”但内核问题只有一个——没有判p是否为空后续所有调用点都属于同一个案例不该按12次重复计算。 聚合之后我们给每条告警分配一个唯一ID格式类似MEM-0182、NULL-0355并记录它对应的提交哈希、分析时间、所属批次。这个可追溯性设计后面发挥了很大作用——当开发人员修复了问题之后我们可以回到报告系统里做闭环确认而不是靠肉眼在几百个告警里找哪条解决了。 分级规则我也明确一下严重程度5分代表“必须本轮修复不修就存在明确的安全或稳定性风险”4分代表“建议本轮修复但如果有合理的缓解措施可以延期”3分是“可能存在问题需要人工确认后再决定”2分以下直接进观察清单不进入人工确认流程。这个分级不是AI自由发挥的结果我们在提示词里对每个等级的判定标准做了明确定义防止模型自己发挥。 ## 3. 这次试点公开的数据命中分布与误报率的真实表现 ### 3.1 扫描体量与缺陷维度分布 22万行代码跑完整个流程后得到一套脱敏后的统计口径数据。先说总体数字静态分析器原始告警共19840条经过去重聚合后得到5600个独立案例AI预判筛掉了其中大约三分之一保留了三级别以上严重程度3的告警最终进入人工确认的高优先级案例是1408个。 具体分布如下表。这里说明一下为了让数据可以公开我对案例编号做了脱敏处理但每类缺陷的总量、确认量都是真实的试点数据。不同代码库因为领域差异分布肯定不一样但同类系统之间可以参考。 | 缺陷大类 | 静态分析原始告警 | AI筛出高优先级 | 人工确认存在 | 确认率 | | --- | ---: | ---: | ---: | ---: | | 内存生命周期 | 4236 | 292 | 226 | 77.4% | | 空指针/悬空指针 | 5261 | 376 | 297 | 79.0% | | 缓冲区越界 | 2180 | 154 | 113 | 73.4% | | 整数溢出/截断 | 3156 | 208 | 155 | 74.5% | | 并发竞争 | 1680 | 118 | 72 | 61.0% | | 异常安全 | 2093 | 122 | 66 | 54.1% | | 错误处理缺失 | 3124 | 138 | 51 | 37.0% | | 其他 | 3104 | 0 | 0 | — | 几个关键数字我展开说。空指针类是这次审查里量最大的问题这符合C/C的普遍规律不管是外部输入还是内部返回值大家普遍存在“先用了再判断”的坏习惯。第二个值得关注的点是并发竞争原始告警数不低但高优先级数量偏少因为很多并发问题需要特定调度时序才能触发静态分析器的路径模拟能力有限AI也难以下结论。 内存生命周期类虽然绝对数量不是最高但确认率很高达到77.4%。这类问题一旦确认修复成本通常也很高因为涉及一个资源在多个函数间流动改了释放位置可能引出一串连锁反应。 ### 3.2 高优先级命中里真正需要改的比例 上面表格里的“确认率”指的是人工复核后“确实存在问题”的比例但确认为问题不等于必须马上改。我们还在人工确认时打了一个第二层标签“是否建议立刻修复”。这一层标签会把以下情况排除掉代码确实有风险但只有在极其苛刻的输入下才可能触发而且当前有限定条件可以缓解或者是历史代码里故意为之的兼容性处理。 按这个口径统计下来1408个高优先级案例里人工确认存在问题的有823个约占58.4%。823个问题里建议立刻修复的是576个约占70%。也就是说AI筛选出来的高优先级告警中大约四成是真实风险且值得在当轮版本里处理其余是“风险真实存在但有缓解措施、可以在后续窗口内修复”。 换一个角度看真正有价值的发现其实是那576个“建议立刻修复”的问题。576个问题分布在22万行代码里密度并不高但每一个都经过了“静态分析器命中 - AI语境研判 - 人工复核”三层过滤可信度比直接跑Cppcheck出来的告警高了一个量级。 如果不做这三层过滤直接让人工去面对19840条原始告警说实话大部分人看到一半就放弃了更不要说挑出这576条核心问题。这就是整条流水线的意义不是创造问题发现的能力而是把问题定位的效率提升到人工可承受的范围。 ### 3.3 误报率为什么比想象中高以及怎么压下来的 对外讲AI代码审查大家最关心的永远是误报率。我们这套流程AI筛完后的高优先级告警人工复核确认率只有58.4%也就是说每10条里还有4条多不是问题这个数字和很多人预想的“AI应该能搞定90%”差得很远。 误报主要来自三个地方。 第一调用点与定义点隔离。静态分析器在一个函数内部看到“指针可能为空”但实际调用方在进入这个函数前已经做过判空或者整个程序只有内部模块在调用外部输入无法到达。AI从局部上下文判断有风险但加上调用点信息后风险其实是可控的。 第二宏展开造成的重复路径。C/C里一个宏可能被几十个地方引用每个引用点都会生成一份AST实例。我们在去重时已经按变量维度做了聚合但不同变量通过同一个宏触发的问题仍会被分成多条告警。这些往往都是同一类问题的表现形式不算严格意义上的误报但会拉低确认率的分子。 第三历史设计中的“故意为之”。最典型的是一个旧的I/O模块为了性能直接用固定索引访问一个静态数组并且用编译期断言保证数组大小永远不小于索引上限。这个模式在静态分析器看来就是越界风险在AI看来也像是“硬编码边界不优雅”但实际上是经过性能验证的稳定策略不需要修改。 为了压误报我们在试点中途加了一个反馈回路把人工复核时标记为“非问题”的案例以及标记原因写回一个标注库。AI在做后续批次审查时会先检索标注库中的相似模式并对匹配的告警降级为“低优先级”。这个机制生效后后几批的误报率从最初的42%左右降到了31%左右效率提升非常明显。 ## 4. 一条缺陷报告的确认链路从数据到修复计划 ### 4.1 风险优先级排序先修什么是算出来的 拿到823个确认问题之后不能照着报告挨个改那样会把研发资源浪费在一些“确实有问题但实际几乎不可能触发”的边角上。我们建立了自己的优先级排序公式核心是三个因子相乘再除以修复成本。 风险暴露度 可达性 × 威胁度 × 触发概率。可达性看问题点在代码路径中的位置如果是从外部输入网络报文、配置文件、用户操作可以触达的可达性记5分只有内部静态调用触达的记2分必须靠debug工具才能触达的记1分。威胁度看后果能导致内存破坏、远程执行、数据丢失的记高分只导致日志输出错误的记低分。触发概率看前置条件难易需要特殊构造的报文、罕见的组合条件才触发的记低分。 修复成本则是研发自己预估的——是加两行判空就可以还是需要把整个资源管理模式重做一遍两者差别巨大。最终的排序是先做“外部可达、后果严重、修复成本低”的前三类问题再做“外部可达、后果严重、但需要小重构”的问题最后才处理那些触及核心架构的深水区。 这个方法不一定适合所有团队但至少避免了一个常见的错误看到“空指针”就所有空指针一起改结果把一些低优先级又容易引入回归的问题也卷了进来。 ### 4.2 一条典型缺陷从命中到确认的完整复盘 拿一条真实的缓冲区越界案例来走一遍流程会让你更清楚整个链路长什么样。问题发生在通信协议层的一个报文解析函数 cpp // 模块协议解析 文件frame_parser.cpp uint32_t parse_len_field(const uint8_t *pkt, uint32_t offset) { uint32_t len; memcpy(len, pkt offset, sizeof(len)); return ntohl(len); } void handle_frame(const uint8_t *pkt, uint32_t pkt_len) { char tmp_buf[256]; uint32_t data_len parse_len_field(pkt, HEADER_SIZE); // 此处直接使用 data_len 进行拷贝无长度校验 memcpy(tmp_buf, pkt HEADER_SIZE EXTRA_OFFSET, data_len); process_payload(tmp_buf, data_len); }静态分析器给出告警第203行memcpy的源地址pkt HEADER_SIZE EXTRA_OFFSET加上复制长度data_len可能超过接收缓冲区的界限。这是缓冲区越界的典型告警但仅凭这个告警还不能定级因为工具并不知道data_len有没有可能在进入这个函数前被调用方限制住。AI预判环节给出了关键判断。它看了调用链之后指出parse_len_field从报文字节流中读取长度字段是典型的网络字节序这条路径上没有任何对data_len和pkt_len的比较逻辑只要对方构造一个带超大长度字段的报文memcpy就会直接从pkt后面越界读数据。AI的结论是真实风险严重级别5处于外部网络入口应优先修复。人工复核确认了AI的结论并给修复选型在handle_frame入口增加对data_len的边界判断包括与pkt_len之间的关系以及tmp_buf容量上限的双重检查。修复代码就两行但影响是立竿见影的——这个函数被外部报文高频调用是整套系统防御链路的第一站。整个确认流程用时不到15分钟而如果没有AI预判一个开发人员从在19840条告警里翻到这个函数到理解调用链、再到确认风险至少需要大半天。这才是效率提升最直观的体现。4.3 拦截AI“自信胡话”的三道关口AI在代码审查里最让人头疼的不是不说话而是自信地胡说。它会一本正经地把不安全代码说成安全的或者把一处完全没问题的代码标成高危。为了拦住这种情况我设置了三个关口。第一关是“同案双人复核”。所有AI判定为高风险4分和5分的案例必须由两个人工评审员分别独立判断意见不一致的进入小组会复审。这个规则很重但高风险本来就应该讨论不能省。第二关是“理由可追溯”。提示词里强制要求AI输出判断依据必须引用代码里具体的行号和字段名不允许只写“存在内存安全问题”这种空话。如果AI给不出具体的触发路径那这条告警就会被自动降低优先级。实测下来这条规则能有效过滤掉一些“看个大概”的虚报。第三关是“抽样反查”。每个批次的审查完成后我们会随机抽300条被AI判为“低优先级”或“不存在”的告警交给人工反向复核一遍。这300条的抽样结果用来估算AI的漏报率。虽然抽样规模有限但能看到AI在哪些场景下会误杀真问题然后调整下一轮的提示词上下文。三道关口的成本不低但对50万行以下规模的代码库还在可接受范围内。等后面标注库足够丰富也许可以把第二关再自动化一些但“同案双人复核”这条我建议任何团队都不要省。5. 22万行遗留代码库特有的边界审查问题5.1 宏与模板让静态分析一度“失明”C/C代码审查和Java、Go这些语言有个本质不同宏和模板把真正的逻辑藏在文本替换和编译期实例化里分析工具对它们经常无能为力。试点的代码库里有一段SAFE_ARRAY_INDEX宏翻译过来是“带边界检查的数组访问”但因为底层用了assert在release构建下边界检查会被完全移除。静态分析器扫描的是预处理之后的代码它看到的版本里边界检查并不存在于是报出大量越界风险AI读的是原始源码看到的是带assert的宏做出“有检查、比较安全”的判断。两边一冲突反而错过了真正的问题——release模式下的数组访问是裸奔的。为了解决这个问题我们把所有宏的展开体单独抽出来建立了一个“宏语义表”记录每个宏在debug和release两种构建下的实际行为。后续AI研判时不再只看宏名而是直接去看展开后的代码。模板的处理逻辑类似对实例化深度超过3层的代码暂时降低告警优先级先聚焦在非模板的普通路径上——不是模板问题不重要而是模板枯枝问题一旦处理起来容易把整个设计拉进讨论试点阶段先控范围。这个经验想提醒所有做C/C审查的朋友分析报告里关于宏和模板的告警一定要回到真实编译配置下重新看一遍否则90%的结论都得打折扣。5.2 历史原因造成的“故意不规范”怎么判审查过程中我们发现了一类高频率的误判一段代码看起来非常不规范没有边界检查没有错误处理但它是若干年前为兼容某款老硬件而故意写成的“脏代码”且周边有大量注释解释了原因。AI模型第一次扫的时候会全部标红人工复核时又只能把它们一条条捞回来。最让我印象深刻的是一段对齐处理逻辑为了性能代码直接对一块内存做了16字节对齐访问跳过了严格的边界检查。从现代CPU的角度这没问题但万一硬件状态异常这块内存的对齐属性就会破坏引发崩溃。开发团队对此心知肚明只是迟迟没有重构。AI的报告把这个问题翻出来反而促使团队重新评估了风险——经过测试这块逻辑确实只在新硬件上才安全旧硬件的兼容需要保留双分支处理。所以我的建议是不要预设“AI报告的每一处都是罪证”也不要认为“历史代码就一定没毛病”。正确做法是把这类案例单独立档注明“已知历史限制暂不修改但需持续监控”同时推动专人在合约里加入运行时检测。这样既不冤枉团队也不放过潜在风险。5.3 多人维护场景下审查标准的一致性大库还有一个突出问题是审查标准不统一。在一个团队里A模块负责人觉得“外部输入必须判空校验长度”是铁律B模块负责人觉得“我这个模块只在内部被调用可以靠调用方保证”。两种认知差距在人工审查中就会导致同一个问题两种命运AI运行时也不会自动好转它会学标答。我们针对这个问题做了一个“审查规则一致性清单”挂在每次AI审查的提示词前面。清单里定义了什么叫“外部输入”凡是经过网络接口、配置文件、数据库查询、命令行参数进入的数据一律视为不可信。清单里还定义了“越界校验的条件”只要使用了指针偏移和数据长度就必须有两者关系的显式判断。这样每个批次、每个模块都按同一套标准审查不会因为模块负责人不同而出现松紧不一。同时所有AI报告都按批次版本号归档两周后再遇到相似问题可以直接引用上一批的结论。这个“案例之间可互相引用”的设计让团队内部逐渐沉淀了一份带业务上下文的缺陷知识库后续审查速度只会越来越快。6. 如果我想在别的团队复现这次试点应该怎么落地6.1 不要拿着AI报告直接改代码在这次试点里我最深的体会就是AI报告是一份“侦查情报”不是“处决命令”。拿到AI筛出来的高优先级列表之后一定要走一个“确认-讨论-授权”的流程再让开发进场修改。因为AI给出的修复建议往往是通用模板式的它不会考虑模块历史、调用方约定、性能约束。直接照着AI建议改很可能修掉一个风险引入另一个兼容性问题。举个例子一个整数溢出案例AI建议“把int改成long long”看着很合理。但代码所在的位置是一个高性能波形处理的内层循环改成64位运算会让性能下降20%以上。人工复核的时候发现了这个约束最后选择在输入阶段提前做数值范围裁剪而不是在核心循环里换类型。如果直接自动执行AI方案这个性能回退会在评审会上被批得很惨。所以组织流程上我们的设计是AI报告产出后先由质量小组过一遍把明显不合理的建议打回把合理的建议标注上将对应的测试用例再分配给模块负责人修改。每个修改单都必须附带相关的回归测试不能只改代码不补验证。6.2 把命中模式回灌进编码规范这次试点收获的不只是几百个已修复问题更宝贵的是问题模式的统计。我们在复盘会上把576个“建议立刻修复”的问题做了模式分类归纳出一批高频反模式比如“从报文头取长度字段后未比较就直接memcpy”“申请内存后未判空即使用”“使用strcpy拷贝外部字符串到固定数组”。这些模式每个都能在代码库里找到多个实例。把这些反模式写进团队的编码规范负面清单比单纯修掉这576个问题更有长期价值。后续新代码如果出现类似模式提交评审时可以自动拦截。我们还把这套负面清单转成了Clang-Tidy的自定义插件检查项理论上可以在编译阶段就发出警告把问题挡在合入之前而不是等代码跑上线之后再来大规模审查。这个动作坚持下去22万行代码的“带病存量”会越压越小而不是越积越多。6.3 人工复核节奏与批次安排值得专门讲一下试点过程中节奏安排也踩过坑。最开始我们把2800多个高优先级案例一次性丢给评审组结果前三天大家还能坚持后几天疲劳效应明显确认质量肉眼可见地下降。后来改成“每批约300个案例两天内审完最长不超过三小时/人/天”的节奏质量稳定了很多。具体操作上每批面向的模块相对聚焦评审人员也从其他模块临时借调改为固定模块负责制谁熟悉这块业务谁来当该批次的复核主审。这样可以显著减少阅读代码的认知成本。同时每天上下午各开一次20分钟的站会把前一轮的争议案例消掉不积累待决问题。如果你要复现我的建议是以“每周审一个模块批次、每批次控制在4万行以内、每批次人工复核时间不超过15小时”作为初始基线跑两个批次后再根据团队情况调整。别参考我们一开始那种“一口气审完”的做法那是个负面样本。另外试点前最好在代码库里人工注入一些已知缺陷比如在通信模块里故意塞几个未判空的变量、在算法库里加一个越界索引用来测试AI的回查率。这是一个很好用的校准手段——如果AI连你已经知道的缺陷都没找出来那它对未知问题的发现能力也要打个问号。最后再分享一点我在试点里学到的经验这次22万行C/C的审查走下来我对“AI代码审查”这个方向的判断比开始时要乐观一些但乐观得很具体AI目前最大的贡献是让人工从“大海捞针”变成了“按图索骥”。几千条告警变成几百个需要讨论的问题团队的注意力和精力终于可以花在真正值得判断的地方——这个地方到底是修还是不修、用哪种方式修代价最低。这些判断最终还是得靠人来定。如果让我给一个建议我会说不要试图用一套提示词解决所有模块。不同模块的输入来源、容错策略、性能约束差别很大需要针对业务场景配置不同审查上下文。把AI当成一个新入职的实习生先给它讲清楚业务规则再让它看代码效果远好于直接丢一个全局的“给我审”指令。希望这份数据和过程记录能给正在做代码审查工程化、或者计划引入AI辅助的团队提供一点真实可参考的坐标系。