贴吧 Server 团队 10 周落地小码哥 AI CR：评审占比提至 84%，bug 密度降 66.87%！
一个让我们坚持做下去的数据
bug 密度 -66.87%。这是贴吧 Server 团队，在持续推进小码哥 AI CR（AI Code Review）10 周后交出的成绩单。数据走势清晰地展示了：使用量上来、bug 率就下来。评审占比从 33% 稳步爬升至 84%，评审 icafe 数量从 3 次/周增长到峰值 85 次/周，而 bug 密度从 0.332 降至 0.11。这篇文章，将这 10 周的经验、数据和踩坑完整分享出来，供有意推广 AI CR 的团队参考。
小码哥是什么？我们为什么做？
小码哥（iCode AI CR）只做代码评审，不参与代码编写。它的核心价值是：把重复性、规范性的代码检查交给 AI，让研发同学和人工评审者可以把精力聚焦在更有价值的地方----架构设计、业务逻辑正确性、扩展性。贴吧团队的痛点很典型：代码库多、提交频率高，人工评审质量参差不齐；新人规范问题重复出现，老同学 review 疲劳；review 占用时间较高。这些问题终将导致非预期的线上问题漏出。我们的目标是：在 26 年 Q1，让 AI CR 成为团队开发流程的自然环节，覆盖 80% 的日常 CR 请求，显著减少常见问题发生。
时间线：从 kickoff 到常态化
小码哥在贴吧的落地不是一蹴而就的，经历了完整的节奏演进。
如何开启这场酣畅淋漓的 AI CR 之旅
快速上车：目前小码哥已全量开放权限，仅需负责同学为代码库开启自动评审即可，在 iCode 提交代码时，AI CR 自动触发，无需额外操作。
CR 流程规范：AI CR 的评论分三个严重级别：高/中（必须关注/需要关注）：必须处理，阻塞合入；优化建议：评估处理，拒绝时需说明原因（支持多轮对话让 AI 重新评审）；低优先级观察：可选参考。完整的 CR 流程规范大体分为四步：开发者提交代码，小码哥自动触发 AI 评审；AI 生成行间评论和总结报告，标记严重级别；开发者处理评论----点击采纳和拒绝，采纳的高中风险强制修改，建议级可多轮对话驳回；拒绝的进行反馈；评审者确认评论，评审通过后合并代码，AI 评审记录沉淀为团队经验。
配置规则集：我们的规则体系分为两层：通用规则 + 定制规则。在不做任何修改，直接推进小码哥的情况下，默认采用通用规则，但无法适配业务特异性，需要定制规则补充这部分。通用规则（平台预置）：小码哥平台预置了覆盖 3 大类维度的通用规则，覆盖面广、开箱即用。定制规则（团队经验，从历史问题中沉淀）：这是贴吧团队自己沉淀的核心资产。我们将 25/26 年历史线上问题和日常 CR 中发现的典型问题，提炼为 AI CR 可识别的规则，目前共沉淀 14 条定制规则（分语言 22 条），覆盖 P0/P1 优先级。规则不是一次性配好就完了。我们的经验是：初期配置 -> 跑一两周 -> 收集误报/漏报 -> 反馈闭环 -> 迭代规则，我们正是这样把规则质量不断打磨到位的。自动化评测工作流：这套自动化评测体系是贴吧团队在 AI CR 落地过程中最核心的基础设施建设。它不仅是方法论，更是一套完整的工程资产 ----Sub - agent、Skills、工作流全部模板化，其他团队直接迁移就能跑出自己的 AI CR 规则。整体评测流程（6 步）：生成规则 -> Case 构造 -> 数据集上传 -> 任务创建（工作流） -> 通用标注 -> 汇总报告。生成规则 + Case 构造：两种方式可选。方式一：传统手动分步法：生成规则：通过自然语言描述规则需求，让 Ducc 或 Zulu 生成可被小码哥识别的 rules prompt：生成后人工确认、人工发起反馈调优。规则文件保存在代码库 `baidu/tieba - xxx - xxx/smart - cr/rules/` 下，按语言（php/go）和模块组织。Case 构造：拉取指定的 iCode 评审代码库到沙箱环境，用 Ducc/Zulu 生成正例/反例代码片段，插入到现有代码类的 private 方法中，独立提交每个 case 到评审系统，最后产出 Excel（含评审 URL + 评论）。方式二：Agent/Skills 一站式自动化（推荐）：我们搭建了 Comate Skills（路径 `./comate/skills/smart - cr - benchmark`）和 Sub - agent 双引擎，实现了“一句话生成全套评测 case 和标准答案”的能力。规则生成和 Case 构造由 Agent 自动完成，无需分步操作。
协同机制：反馈群 + iCafe + 周会，三道防线：如何保障问题落地解决、需求落地，我们建立了三层闭环机制，促进 CR 效果的提升、为团队定制规则赋能。第一层：反馈群实时响应：贴吧团队和小码哥团队共建了专属反馈群，开发者在日常 CR 中遇到误报、漏报等问题，可以直接在群里反馈。双方明确了接口人，确保问题有响应、有跟踪，不石沉大海。第二层：iCafe 卡片跟踪：对于需要系统跟进解决的问题，通过 iCafe 卡片录入，明确 SLA（服务等级协议）和升级通道，确保定期闭环。每一条反馈的处理结果都会沉淀下来，好的场景和方法反哺到规则库中，形成正向积累。第三层：周会评审需求：每周四例行周会，对齐进展、评审新需求、同步问题（如规则冲突、效果波动）及应对方案。需求的流转路径为：贴吧日常提需求卡 -> 周会评审 -> 小码哥开发，确保每一条有价值的规则需求都能进入迭代 pipeline。通过这三层闭环，规则集持续优化 ---- 误报率逐步下降，准确率稳步提升。这套反馈机制本身也已成为贴吧和小码哥团队合作的标准化流程。
现在，是轮到更多团队上车的时候了
贴吧 server 团队的经验已经趟出了一条路：先上量：在推广初期，要有人主动带节奏，形成团队习惯，不依赖自发；定制规则从 case 提炼：从历史线上事故和日常 CR 问题中沉淀自己的规则，这是 AI CR 效果最深层次的护城河；自动化评测必须跟上：利用 agent/skills 工作流，让规则迭代形成“配置 -> 评测 -> 优化 -> 再评测”的飞轮；协同机制做扎实：反馈群实时响应 + iCafe 卡片跟踪 + 周会评审需求，三层反馈闭环机制让小码哥变得更强大。我们的目标是让 AI CR 成为贴吧研发流程里不需要想起来、自然存在的一环。就像 CI 检查一样理所当然。如果你的团队还没用起来，现在是最好的时机 ---- 有前人踩坑经验，有规则库可以借鉴，有自动化工作流可以直接复用，有问题可以实时反馈。