从 POC 到全公司铺开：6 个月把 Claude 推进 800 人研发部门的路线图

去年 12 月，某头部车企的 CTO 把我拉进他办公室。他桌上摊着一份 PPT，标题是”AI 辅助研发三年规划”。翻到第三页，我就乐了——那是我半年前给他们画的迁移路线图，被运营部门加了 23 页”愿景”和”赋能矩阵”（这词儿我最讨厌）之后变成了现在这个样子。

他问我：”你帮我看看，到底哪几步是真的要做的？”

我跟他说：”你把我原来那份拿出来，就 6 个月，1 页纸。别搞花的。”

这篇写的就是那份 1 页纸后面的故事。后来他们 800 人的研发部门，从我接手到全员启用，用了整整 6 个月零 11 天。

月 1-2：2 个人的种子组

别上来就搞”集团 AI 战略规划委员会”。先挑 2 个人。

这 2 个人的画像很重要：一个是资深工程师，技术判断力强，在团队里有话语权，平时就爱折腾新东西。另一个是 PM 或 tech lead，会讲故事、会跟不同团队沟通、写 wiki 不嫌烦。

前两个月这俩人只做一件事：跑 3 个小 POC。我当时给他们定的三个是 code review、API 文档生成、客服工单 draft。选这三个不是随便选的，挑的都是”高频、低风险、能直接量化时间节省”的场景。code review 那个我在 industry-code-review-bot 写过完整代码。

这阶段最重要的产出是数字。不是”大家反馈不错”，是”第一周 Alice 的 code review 时间从平均 47 分钟降到 18 分钟”这种。没数字后面一切都白搭。

踩坑提醒：POC 别做超过 6 周。超过 6 周你就在骗自己。两个月做三个 POC，每个两周左右就得出结论。某银行做了 9 个月 POC 还在”完善方案”，最后整个项目没了，原因就是这个。

月 3：度量和讲故事

第三个月的核心动作是把前两个月的数字讲出去。

我当时给那个种子组的建议是：做一个 20 分钟的内部分享会，面向中层技术经理，核心就讲三件事：

• 我们做了什么（3 个 POC 的具体场景）
• 省了多少（具体小时数、具体钱、具体 bug 拦截率）
• 现在还差什么（工具化、治理、培训）

数字要真实。我看过太多的 PPT 写”效率提升 40%”，底下一问怎么算的，说不清。那种 PPT 反而减分。我让他们写的版本是：”3 个开发者连续 6 周使用，code review 时间中位数从 47.2 分钟降到 18.6 分钟，减少 60.6%。样本小、非对照，数字有待更大范围验证。”

诚实是最有说服力的。中层经理不是傻子，你诚实他们会买账。

这个阶段同时要找一个 executive sponsor。就是一个 VP 级别的人，愿意在预算会议上为你说话的人。没有这个人后面推不动。我们那个车企的 sponsor 是研发总监，他当时看到那份数字之后问了一个问题：”800 人如果都能省这么多，一年省多少？” 后面的预算就是这句话打下来的。

月 4：10 人 beta

第四个月放到 10 个人。这 10 个人怎么挑？我给的标准是：

• 3 个是积极派：听说 AI 就兴奋那种，他们会主动找新用法
• 4 个是中间派：给工具就用、不折腾、代表主流人群
• 3 个是保守派：对 AI 有疑虑、要求严格、会提尖锐问题

保守派那三个特别重要。他们提的问题往往是后面规模化时会爆炸的问题。我们那个车企的一位老架构师就在 beta 期间提出：”如果 Claude 建议的代码改动引入了 bug，责任怎么算？”这个问题后来变成了团队的”AI 建议追溯规范”。

beta 期要收集两份东西：吐槽清单和痛点清单。吐槽是”今天 Haiku 又把我的变量名改烂了”这种，痛点是”我们代码规范里的这条，Claude 不知道”这种。吐槽听了笑笑就行，痛点要立刻变成工程 backlog。

这个阶段我建议已经开始搭内部工具链了。参考 skill-team-knowledge-base 那篇，Skill 库这时候就得开始积累。

月 5：工具化

第五个月是最重的。要做四件事：

统一 API 网关。所有业务方不直连 API，都走公司内部网关。网关负责鉴权、限流、预算检查、审计日志。这玩意儿不做，后面成本和治理都是一锅粥。我们那个车企用了 LiteLLM 魔改，加了一层自研的预算控制中间件。

账单平摊机制。每个事业部、每个项目一个 cost center。月底账单自动按 project 标签切分，推送到各部门财务。我当时写了一个小看板，每个 team lead 都能看到自家团队本月花了多少。这个看板上线第一周，研发部门的 AI 花费直接降了 18%，因为大家开始知道自己在花钱了。cost-bill-anatomy 里讲过怎么拆账单。

Skill 和 MCP 治理。团队成员写的 Skill 进一个内部 registry，有 review 流程。重要的 Skill 要做 skill-testing-versioning 里讲的版本化测试。MCP server 的权限严格按 claude-code-permissions-sandbox 的方法隔离，别给过宽权限。

应急预案。API 宕机了怎么办？超预算了怎么办？prompt 泄露了怎么办？这三个预案写出来，在 Confluence 或者飞书上挂着，每次值班轮换都看一遍。

这个月工作量很大，建议至少配 3 个工程师全职投入 4 周。

月 6：全员启用 + 培训

最后一个月是推广月。关键是培训要分角色。

开发者：4 节 45 分钟的录播视频（API 基础 / 工具使用 / MCP 接入 / Agent 模式）+ 1 场现场 workshop。workshop 上我建议做一个”真实代码挑战”，用 Claude 在 30 分钟内完成一个小任务，让人亲眼看到效果。

PM 和产品：2 小时专场，重点讲”什么场景适合 Claude、什么场景不适合、成本是怎么计算的”。别让 PM 动不动要求技术”给我接个 AI”，他们得自己有判断。

运营、客服：1 小时，重点是使用规范和风险。比如”客户个人信息不能直接粘进 prompt”、”AI 的回复要人工 review 之后再发”这种硬规则。

领导层：30 分钟就够。不讲技术，讲 ROI、风险点、未来 12 个月路线图。领导要的是决策依据，不是 API 文档。

培训完了要配套一个东西：champions 计划。每个部门选 1-2 个骨干，给他们稍微多一点权限（比如更高的 API 额度、新功能 beta 优先），换取他们承担”本部门第一响应人”的职责。新员工来了有人问、同事卡住了有人帮。这个机制省下了至少 80% 的中心化支持工作量。

一个失败案例

前面提过那家银行。他们的失败不是技术问题，是组织问题。

具体哪几步出了错：

• 没有 executive sponsor。POC 立项是 IT 部门自己推的，CFO 从头到尾不感冒。
• POC 选的场景太大。他们一上来就挑”自动化生成信贷审批报告”，这是个全链路改造的大活儿，根本不适合 POC。
• 度量是软指标。汇报里写的都是”显著提升工作效率”这种话，没有硬数字。（这里我要吐槽一句，”显著”这种 AI 味的词出现在内部汇报里，我真的是看一次叹气一次。）
• POC 做了 9 个月没结束。每次快要结束就有人提新要求。

他们现在还在做 POC。从 2024 年 5 月到现在，快两年了。

对比之下我们那个车企 800 人的部门，6 个月铺开以后第 7 个月的度量：研发部门 72.8% 的工程师每周至少使用 Claude 3 次以上，code review 平均时长下降 43.1%，PR merge 周期中位数从 4.2 天缩到 2.6 天。这是真金白银的数字。

几个不常说的教训

第一，别让 AI 团队自己铺开。AI 团队负责技术栈和工具链，铺开这事儿得业务线自己扛 owner。不然就变成”AI 团队推、业务线接不住”。

第二，allowance 比禁令管用。与其禁用某些场景，不如给大家明确的 allowlist：”这些场景放心用”。人类在规则不清晰的时候会过度保守。

第三，第一批宣布的成果要是真的。别为了发新闻稿夸大效果。夸大一次，半年内招不回信任。

第四，培训视频录完马上过时。Claude 更新太快了。我们那个车企的视频录完 3 个月，Opus 4.7 出来，Haiku 4.5 出来，Skill 模型改了，整套视频得重录。所以建议录的时候就做好季度更新的预期。

关于具体场景的落地细节，可以看 industry-legal-contract-review、industry-customer-support-agent、industry-bi-natural-language-query 这三篇。