AI 编程助手团队落地

1客户嘴上要的

「给 300 个研发都开通 AI 编程助手，年底研发效率提升 30%。」

这是症状或现成方案，不一定是真问题。下面看两种做法。

2照字面做，会怎么烂

3好 FDE 的实际走法

共 6 周，分 5 个阶段。带三角标记的是这一步最容易踩的坑。

1. 1

   第 1 周找真问题（看需求从提出到上线的时间花在哪里）

   • 跟研发 VP、3 个团队的技术负责人、质量和安全负责人坐，从项目管理和代码平台导出近两个季度的数据：需求交付周期、PR 从提交到合并的时间、评审轮次、线上缺陷。发现：一个需求平均 18 天，写代码只占 4 天；等评审 3 天、等测试环境和联调 5 天、需求澄清反复 4 天。
   • 真问题是「效率瓶颈不在写代码，而且现在没法度量」。成功标准改成：「两个试点团队的需求交付周期比对照团队缩短 20%，线上缺陷率不上升；源代码不出公司网络。」
   • 踩坑别用「代码采纳率」「生成行数」当效果。这些指标和交付结果没有直接关系。
2. 2

   第 2 周定范围 + 定安全边界

   • 选两个试点团队：一个做业务后台（Java），一个做前端，另外两个类似团队做对照组。
   • 安全：和安全团队一起确定部署方式（私有部署或签了数据协议的企业版），配置敏感文件排除规则，代码平台开启密钥扫描。
   • 踩坑别让试点团队自己选「最强的人」。用整个团队，结果才有代表性。
3. 3–4

   第 3–4 周补上下文 + 改流程

   • 给工具补上团队的上下文：编码规范、目录结构说明、常用组件的用法，写成仓库里的说明文件，让生成的代码符合团队习惯。
   • 不只用在写代码上：用 AI 生成单元测试、在 PR 中做第一轮自动评审（检查规范和常见缺陷）、从需求文档生成接口草稿供评审。瓶颈在评审和联调，就把工具用在那里。
   • 定评审规则：AI 生成的代码同样要人评审，评审人对合并负责。
   • 踩坑自动评审的提示太多，评审人会全部忽略。只保留高置信度的问题。
4. 5

   第 5 周度量 + 并肩改

   • 每周和试点团队负责人看数据：交付周期、评审等待时间、测试覆盖率、缺陷。前端团队反馈：「生成组件很快，但要改样式适配设计规范」——把设计规范的组件库说明加进上下文。
5. 6

   第 6 周交接 + 推广决策交接

   • 交给研发效能团队的负责人：维护度量看板、仓库说明文件模板和安全配置。推广时每个新团队先补上下文文件，再开通。
   • 用试点数据给 CTO 一页决策材料：效果、成本、风险和推广节奏。没有度量和效能团队接手，推广后又会回到「开了账号、说不清效果」。

4这个案例教给你的可复用判断