用数据说话：贴吧 AI CR（小码哥）落地 10 周，bug密度下降 66.87%

导读

本文记录了贴吧 Server 团队将小码哥 AI CR 规模化落地的 10 周实践，将评审占比从 33% 提升至 84%，bug 密度下降；全套方法论与工作流可直接迁移，少走弯路。

01 一个让我们坚持做下去的数据

bug密度 -66.87%。

这是贴吧 Server 团队，在持续推进小码哥 AI CR（AI Code Review）10 周后交出的成绩单。数据走势清晰地展示了：使用量上来、bug 率就下来。评审占比从 33% 稳步爬升至 84%，评审icafe数量从 3 次/周增长到峰值 85 次/周，而bug密度从 0.332 降至 0.11。

△ 团队评审次数和bug密度对比

这篇文章，将这 10 周的经验、数据和踩坑完整分享出来，供有意推广 AI CR 的团队参考。

02 小码哥是什么？我们为什么做？

小码哥（iCode AI CR）只做代码评审，不参与代码编写。 它的核心价值是：把重复性、规范性的代码检查交给 AI，让研发同学和人工评审者可以把精力聚焦在更有价值的地方------架构设计、业务逻辑正确性、扩展性。

贴吧团队的痛点很典型：

代码库多、提交频率高，人工评审质量参差不齐
新人规范问题重复出现，老同学 review 疲劳
review占用时间较高

这些问题终将导致非预期的线上问题漏出。

我们的目标是：在 26 年 Q1，让 AI CR 成为团队开发流程的自然环节，覆盖 80% 的日常 CR 请求，显著减少常见问题发生。

说明：小码哥入口位于icode评审页（如下所示）

△ 手动触发入口

△ 自动触发结果入口

03 时间线：从 kickoff 到常态化

小码哥在贴吧的落地不是一蹴而就的，经历了完整的节奏演进：

04 如何开启这场酣畅淋漓的AI CR之旅

4.1 快速上车

目前小码哥已全量开放权限，仅需负责同学为代码库开启自动评审即可 ，在 iCode 提交代码时，AI CR 自动触发，无需额外操作。

△ 评审开启入口（icode提交规则-智能评审，支持实时+夜间评审配置）

4.2 CR流程规范

AI CR 的评论分三个严重级别：

高/中（必须关注/需要关注）：必须处理，阻塞合入
优化建议：评估处理，拒绝时需说明原因（支持多轮对话让 AI 重新评审）
低优先级观察：可选参考

△ 高风险

△ 较低优先级

△ 低优先级-右侧展示

完整的 CR 流程规范大体分为四步：

开发者提交代码，小码哥 自动触发 AI 评审
AI 生成行间评论和总结报告，标记严重级别
开发者处理评论------点击采纳和拒绝，采纳的高中风险强制修改，建议级可多轮对话驳回；拒绝的进行反馈
评审者确认评论，评审通过后合并代码，AI 评审记录沉淀为团队经验

说明：开发者在收到评论后，可以直接在评论区与 AI "对话"------"这里的背景是XXX，你的建议是否还适用？"这个多轮对话能力极大提升了 AI CR 的精准度，避免简单粗暴的一刀切。

4.3 配置规则集

我们的规则体系分为两层：通用规则 + 定制规则。

在不做任何修改，直接推进小码哥的情况下，默认采用通用规则，但无法适配业务特异性，需要定制规则补充这部分。

4.3.1 通用规则（平台预置）

小码哥平台预置了覆盖 3 大类维度的通用规则，覆盖面广、开箱即用：

4.3.2 定制规则（团队经验，从历史问题中沉淀）

这是贴吧团队自己沉淀 的核心资产。我们将 25/26 年历史线上问题和日常 CR 中发现的典型问题，提炼为 AI CR 可识别的规则，目前共沉淀 14 条定制规则（分语言 22 条），覆盖 P0/P1 优先级。

规则不是一次性配好就完了。我们的经验是：初期配置 → 跑一两周 → 收集误报/漏报 → 反馈闭环 → 迭代规则，我们正是这样把规则质量不断打磨到位的。

补充：入口如下：

△ 规则入口1-评审

△ 规则入口2-知识方舟

4.3.3 自动化评测工作流

这套自动化评测体系是贴吧团队在 AI CR 落地过程中最核心的基础设施建设 。它不仅是方法论，更是一套完整的工程资产------Sub-agent、Skills、工作流全部模板化，其他团队直接迁移就能跑出自己的 AI CR 规则。

整体评测流程（6 步）

生成规则 → Case 构造 → 数据集上传 → 任务创建（工作流） → 通用标注 → 汇总报告

生成规则 + Case 构造：两种方式可选

生成规则和 Case 构造是评测流程的前两步，根据团队情况有两种实现方式：

方式一：传统手动分步法

1. 生成规则 ：通过自然语言描述规则需求，让 Ducc 或 Zulu 生成可被小码哥识别的 rules prompt：生成后人工确认、人工发起反馈调优。规则文件保存在代码库 baidu/tieba-xxx-xxx/smart-cr/rules/ 下，按语言（php/go）和模块组织。

go 复制代码

prompt：词表不得拉取全量数据（自然语言描述规则，替换用户输入的规则），
帮我产出可以 go 和 php 智能 cr（小码哥）识别的 rules prompt；
参考 xx 目录/文件里的写法，按照知识库规则重新调整下规则

2. Case 构造：拉取指定的 iCode 评审代码库到沙箱环境，用 Ducc/Zulu 生成正例/反例代码片段，插入到现有代码类的 private 方法中，独立提交每个 case 到评审系统，最后产出 Excel（含评审 URL + 评论）。

方式二：Agent/Skills 一站式自动化（推荐）

我们搭建了 Comate Skills （路径 ./comate/skills/smart-cr-benchmark）和 Sub-agent 双引擎，实现了"一句话生成全套评测 case和标准答案"的能力。规则生成和 Case 构造由 Agent 自动完成，无需分步操作：

Sub-agent ****personal-cr-benchmark****：7 大核心能力------规则生成、代码库管理、测试用例生成、代码集成、Git 工作流、评论生成、CSV 汇总。一个 agent 搞定从规则到评测的全流程。
典型使用方式：或：

完整 case：/smart-cr-benchmark 用这个 skills，生成完整 case 代码库 patchset：git fetch ssh://... && git checkout FETCH_HEAD

sql 复制代码

规则已确定不用生成：/smart-cr-benchmark 基于这个 rules，直接开始生成 case
规则直接用这个 @full_fetch_rules L1-82，代码库：git fetch ...

数据集上传 → 工作流任务 → 标注 → 报告

平台：ComateStack 工作流（tieba_AICR/automation/workflow-detail/2703）
数据集：上传前两步产出的 case 数据集
工作流：推理->评估->标注->报告
推理算子：配置 rules + 环境类型（DEV/PRO），自动执行 AI CR 评审
评估算子：配置模型（默认千问，可替换为 GLM/Claude 等），自动比对预期结果
人工标注（可选）：人工审核 AI 评估结果，标注通过/不通过
评估报告：自动生成包含准确率、召回率的评测报告

4.4 协同机制：反馈群 + iCafe + 周会，三道防线

如何保障问题落地解决、需求落地，我们建立了****三层闭环机制，****促进CR效果的提升、为团队定制规则赋能：

第一层：反馈群实时响应

贴吧团队和小码哥团队共建了专属反馈群，开发者在日常 CR 中遇到误报、漏报等问题，可以直接在群里反馈。双方明确了接口人，确保问题有响应、有跟踪，不石沉大海。

第二层：iCafe 卡片跟踪

对于需要系统跟进解决的问题，通过 iCafe 卡片录入，明确 SLA（服务等级协议）和升级通道，确保定期闭环。每一条反馈的处理结果都会沉淀下来，好的场景和方法反哺到规则库中，形成正向积累。

第三层：周会评审需求

每周四例行周会，对齐进展、评审新需求、同步问题（如规则冲突、效果波动）及应对方案。需求的流转路径为：贴吧日常提需求卡 → 周会评审 → 小码哥开发，确保每一条有价值的规则需求都能进入迭代 pipeline。

通过这三层闭环，规则集持续优化------误报率逐步下降，准确率稳步提升。这套反馈机制本身也已成为贴吧和小码哥团队合作的标准化流程。

05 现在，是轮到更多团队上车的时候了

贴吧server团队的经验已经趟出了一条路：

先上量：在推广初期，要有人主动带节奏，形成团队习惯，不依赖自发
定制规则从 case 提炼：从历史线上事故和日常 CR 问题中沉淀自己的规则，这是 AI CR 效果最深层次的护城河
自动化评测必须跟上：利用 agent/skills 工作流，让规则迭代形成"配置→评测→优化→再评测"的飞轮
协同机制做扎实：反馈群实时响应 + iCafe 卡片跟踪 + 周会评审需求，三层反馈闭环机制让小码哥变得更强大

我们的目标是让 AI CR 成为贴吧研发流程里不需要想起来、自然存在的一环。 就像 CI 检查一样理所当然。

如果你的团队还没用起来，现在是最好的时机------有前人踩坑经验，有规则库可以借鉴，有自动化工作流可以直接复用，有问题可以实时反馈。

欢迎找我一起沟通交流，一起把这件事做到位。