Q2 我们用 AI Coding 做了什么 -- 一份数据驱动的复盘|20260704

几个月前, 如果有人跟我说一个 60 人左右的研发团队, 一个季度能在 126 个活跃项目上交付 99 万行有效代码, 我会觉得他在吹牛。但 Q2 的数据让我不得不信: 主干变更 4.64 倍于 Q1, 纯代码量 1.98 倍。这不是线性增长, 是结构性跃迁。

这篇复盘不说鸡汤, 只摆数据: 做对了什么, 还有哪些坑没填完, Q3 准备怎么补。

一、4.64x: 交付规模倒逼 AI Coding 成为生产力

先看一组数据:

52 个全新项目贡献了 cloc 净增的 49.6%, 74 个持续活跃项目贡献了另外 50.8%。新老项目同步推进, 不是"只在新项目上见效"。

核心判断: 如果沿用 Q1 的纯人工模式, Q2 需求客观上不可能完成。AI Coding 不是效率优化, 是产能放大器。

二、做对了第一件事: 先定规则再写代码

很多团队引入 AI Coding 的路径是"先让大家用起来再说", 结果就是泥潭——每个人都有一套 prompt, 每个人生成的代码风格都不一样, 评审靠吼, 维护靠猜。

我们没有走这条路。Q2 从第一天就开始搭架子:

25 个可复用 Skill: BFF 开发流程、gRPC 流程、数据库查询、Code Review、老项目治理、国际化翻译……每个 Skill 都是一个标准化的操作单元, 开发者不需要自己写 prompt, 按流程走就行。

6 个硬性规则: 编码规范、Git 提交规范、Protobuf 编写规范、BFF 开发指南。规则不是写在 wiki 里的文档, 是直接加载进 AI Coding 工具里的约束——AI 写代码前先看规则。

11 期实训, 169+ GoodCase: 从安装配置到提效度量, 每周一期, 把所有人拉到同一认知水位。GoodCase 不是鸡汤案例, 是实打实的代码片段+前后对比, 新人和老手都能从中找到自己场景的解法。

质量门禁: 生成代码必须配套单测 + CR, MR 提交前先过 AI 评审。这听起来增加了流程开销, 但实践中发现: 加上门禁后反而减少了"AI 生成了一大堆但用不了"的浪费。

一个值得说的细节是: 我们投入了大量基建在 统一技术栈上。Q2 结束时, 17 个项目已使用统一技术栈, 核心仓库(bitbff/bizagg/bitadmin/datahub)全部收敛到新架构。为什么这重要? 因为 AI 在统一的技术栈上准确率远高于混用多框架——知识库中的得物实践给出了量化证据: L3 知识治理让 AI 准确率从 52% 提升到 91%, Token 消耗下降 48%。标准化本身就是最大的提效。

三、做对了第二件事: 用数据说话, 不靠感觉

提效不能只讲"感觉快了", 要能量化才有说服力。

BFF 接口开发: 传统 2-3 天 → AI 辅助约 0.5 天, 节省约 70%

数据需求开发: 传统 1 天 → AI 辅助约 0.3 天, 效率约 3 倍

AI 审核准确率 (商业文章): 从 70% 提升到 90%——传统规则引擎爬到了天花板, AI 又往上拉了 20 个点

Token 成本: 月预算从 3000。这不是成本失控, 是"花了钱能看到产出"——模型锁定 DeepSeek / Qwen / GLM 三个主力, 建立周度监控, 不让 Token 变成黑盒。

提效不是每个场景都一样。我们观察到, 标准化程度越高的场景提效越明显: BFF 接口开发有固定范式, 数据需求有明确模式; 而探索性强的任务 (比如跨域治理、老系统重构) 提效幅度没那么大, 但也不差——因为有了 skill 和规则, 至少不用从零开始。

四、做对了第三件事: 正视问题, 不粉饰

37% 的集中度风险: Top 5 开发者贡献了 Q2 净增的 37%, 人均 19.9 万行。这在产能上是好事, 但在组织上是风险——过度依赖少数人。从熵框架的角度看, 这是"填补层熵"过高: 业务知识储存在个人脑中而非系统中, AI 只能辅助那些熟悉业务的人快速产出, 新人需要大量依赖"熟悉业务的人兜底"。

2,135 个 MR 的评审瓶颈: Top 5 评审者合计处理 2,135 个 MR, 人均 427 个。这还不包括未统计的 CR 评论和线下沟通。人肉评审已经跟不上交付速度, AI CR 不是锦上添花而是刚需。

新人涌现 but 业务深水区: 7 位 Q1 零贡献的开发者在 Q2 成为主力, 合计 36.3 万行。这是好消息——证明 AI 降低了新人上手门槛。但同时, 跨仓库、跨域的业务逻辑仍然依赖少数核心人, AI 做不到自闭环。

这也是 Q3 的发力方向。

五、做对了第四件事: 基建投入越早越好

Q2 有一个数据不显眼但很重要: zolin 一个人跨 27 个项目, 466 次提交, 净增 100,197 行——这些不是业务代码, 是 AI Coding 基建: 规则、Skill、模板、流程。

为什么说这是"做对了"的事?

因为 AI Coding 最大的坑是 "先跑起来再说": 每个人用各自的方式写 prompt, 一个月后代码风格五花八门, 三个月后没一个人记得当初的约定。如果在引入 AI 的第一周不把规则建起来, 后面改的成本是指数级上升的。

基建投入的三个原则:

1. Skill 优先于 Prompt: 个人 prompt 不可复用, Skill 才是团队资产。我们的 25 个 Skill 覆盖了从"查数据库"到"做 Code Review"到"生成 remote 客户端"的全链路, 任何一个开发者都不需要从零写 prompt。

2. 规则要加载到工具里, 不是写在 wiki 里: CODING.md、protobuf.mdc、git.mdc——这些文件直接加载进 AI Coding 工具(opencode / codex / Cursor), AI 写代码前自动读规则, 不需要人肉检查。

3. 11 期实训的价值不是教技能, 是拉认知: 11 期实训覆盖了从安装配置到质量底线的完整链路。最重要的是, 它让每个开发者都理解: AI Coding 不是魔法, 是需要工程化配合的产能工具。达成这个共识比学会用工具更重要。

六、Q3 从工具推广转向工程治理

Q2 做对了很多事, 但也留下了一些"做对了但没做完"的事。Q3 不做增量, 做闭环:

四条基建线并行:

质量可观测 -- AI 代码质量仪表盘, 安全 CR 规则, CI 门禁自动化, AI CR 覆盖率目标 80%+。我们对标的是 ECC 的四问门禁设计——AI CR 必须引用行号、描述失败模式、读周围上下文、等级可辩护, 防止 AI 为"显得有发现"而编造问题。

认知基建 -- repowiki 全量覆盖 top 20 核心项目, 代码知识地图, 历史决策归档。对标的 benchmark 是得物 L3 知识治理: 把隐含业务规则写进代码注释, 准确率从 52% 提升到 91%。差距很明显——我们的 repowiki 现在只有表结构和接口描述, 缺少"业务规则层"。

Spec 工程化 -- task 可执行标准, SDD 流程强校验, multi-agent 执行。用 spec 约束代替 prompt 依赖。

记忆飞轮 -- goodcase → 自动 skill → 团队复用, 让经验从个人手中释放到组织层面。

Q3 可量化承诺:

• BFF/后端标杆项目 AI 有效辅助代码占比稳定达到 60%
• AI 生成代码必须通过 单测 + AI CR + 人工 CR
• 重点项目 MR AI CR 覆盖率 80%+
• 核心 top 20 项目完成 repowiki / 知识地图
• 每个开发组至少一个标杆场景和一套可复用 skill

两条红线: AI 生成代码不能绕过单测和 CR, 不能用不可见质量风险换速度提升。

写在最后

Q2 证明了一件事: AI Coding 已经不是未来议题, 它已经成为真实生产杠杆。

但 Q2 也暴露出, 光有工具不够。Q2 我们花了大量时间建规则、做实训、攒 Skill——这些"慢功夫"看起来拖慢了引入速度, 但实际上它们让 Q2 后半段的速度越来越快。标准化 + 可复用资产 + 质量门禁, 三条线齐头并进, 才让 4.64x 的交付跃迁没有崩盘。

Q3 的目标是把 AI Coding 从"几个人会用的工具"升级为"整个产研都能用的组织能力"。不是再建新工具, 是让已有的工具链跑通闭环——可度量、可控制、可沉淀、可复制。