腾讯 × 长安「AI 火箭班」拆解：34 人 FDE 混编团队，把 Agent 从试点推到组织级交付

2026 年 8 月 5 日，腾讯与长安汽车宣布组建一支 34 人的联合 FDE 团队——长安选拔 24 位业务骨干脱产两个月，腾讯派驻 10 位专家，基于 WorkBuddy 与 CodeBuddy，围绕软件研发、合同智审、智能客服等七大场景落地 Agent，内部代号「AI 火箭班」。

这件事的信号意义大于新闻本身：车企的 Agent 应用从「试点」进入了「组织级交付」阶段。过去两年企业上 AI 的典型姿势是「买个工具、发个账号、看谁自己用起来」，结果大多沦为僵尸许可证。FDE 这套打法给出了另一条路。

🚀 本教程适合：负责企业 AI 落地的技术负责人、数字化负责人、以及正在被要求「把 AI 用起来」的中层管理者。不讲工具操作，只讲组织打法——这恰恰是大多数落地失败的真正原因。

Step 1：先理解 FDE 是什么打法

1 前线部署工程：把厂商专家塞进你的业务现场

FDE（Forward Deployed Engineer，前线部署工程师）不是售后，也不是培训。它的核心是厂商工程师驻场，和客户业务骨干混编成一个团队，在真实业务现场共同交付。

模式	厂商角色	客户角色	典型结局
卖工具发账号	提供产品	自己摸索	低活跃，僵尸许可证
做培训讲课	讲师	听众	听懂了，回去不用
外包定制开发	接需求做交付	提需求验收	能力留在厂商，客户不会改
FDE 混编	驻场专家	脱产骨干	能力沉淀在客户内部

关键差别在最后一列。外包定制的问题是「能力留在厂商」——项目一结束，客户还是不会自己迭代。FDE 的设计目标是让客户骨干在协作过程中长出能力，专家撤了之后队伍还在。长安选 24 位骨干、腾讯派 10 位专家，这个 2.4:1 的配比就是为此设计的。

Step 2：抄作业——「脱产」两个字是真正的胜负手

2 兼职搞 AI 等于没搞

长安这次最值得抄的细节：24 位骨干脱产两个月。不是「每周抽半天」，不是「业余时间研究」，是完全从原岗位抽离。

为什么必须脱产？

兼职模式的真实情况：
  周一  排产会占掉一天
  周二  客户投诉救火
  周三  终于摸了两小时 Agent
  周四  上周的坑忘光了，重新捡起
  周五  月度汇报
  → 两个月过去，进度约等于零

脱产模式：
  连续投入 → 形成肌肉记忆
  → 跨过「初期笨拙期」
  → 真正产出可复用资产

💡 组织落地经验：AI 工具的学习曲线有个明显的「先变慢再变快」阶段。兼职投入的人永远卡在变慢那一段就放弃了，因为他们没有连续的时间跨过去。宁可少派人、也要让派出去的人真脱产，这是投入产出比最高的一个决定。

Step 3：选场景——七大场景的共同特征

3 别从最难的开始，也别从最没价值的开始

公开信息中提到的场景包括软件研发、合同智审、智能客服等七大方向。拆开看，这类首批场景通常满足四个条件：

筛选维度	合格标准	反例
频次	高频重复，每天/每周都发生	一年做两次的年报分析
规则性	有相对明确的判断标准	纯创意、纯战略决策
容错空间	有人工复核环节兜底	直接对外不可逆的操作
可量化	能算出省了多少工时	「提升了品牌形象」

用这四条自查你的候选场景：

  软件研发   高频✅ 有规范✅ 有 code review✅ 可测工时✅
  合同智审   高频✅ 有条款库✅ 法务复核✅ 可测条款数✅
  智能客服   高频✅ 有知识库✅ 转人工兜底✅ 可测解决率✅

  → 四项全绿才进首批，缺两项以上放到第二批

最常见的错误是从「最能体现技术含量」的场景开始。首批场景的首要任务不是炫技，是在组织内部建立「这玩意儿真能省事」的共识。选一个又难又不可量化的场景，做半年拿不出数字，第二期预算就没了。

Step 4：搭建你自己的混编团队

4 三种角色，缺一不可

34 人不是随便凑的。对照到中小规模组织，最小可行编制是这样：

【业务骨干】（主力，占比约 70%）
  来自要改造的那条业务线
  必须是真懂业务流程的人，不是最闲的人
  职责：定义任务、判断产出质量、沉淀 Skill

【技术专家】（占比约 30%）
  厂商驻场 或 内部平台团队
  职责：工具链打通、系统对接、疑难攻坚

【一个能拍板的负责人】（1 人，全职）
  有权调资源、有权砍需求、直接向高层汇报
  职责：防止项目退化成「大家有空看看」

最小可行编制：6-8 人
  业务骨干 4-5 + 技术 2 + 负责人 1

🎯 派谁去，比派多少人重要。选人标准建议：① 在业务线里有威信（后续推广要靠他）；② 对现有流程有真实痛感（有动力改）；③ 学习意愿强。千万别派「反正他手上没活」的人——那等于宣告这个项目不重要。

Step 5：定验收——从「用了没」到「省了多少」

5 指标设计决定项目生死

Agent 项目最容易死在「说不清效果」上。验收指标必须在启动时就定死，分三层：

层级	指标示例	用途
过程指标	周活跃人数、任务发起次数、Skill 沉淀数	早期判断死活
效率指标	单任务平均耗时降幅、人工复核通过率	中期证明有效
业务指标	节省工时折算、错漏率下降、交付周期缩短	拿去要预算

一个可直接套用的记录模板：

场景：合同智审
  改造前：单份合同人工审核  90 分钟
  改造后：Agent 初审 + 人工复核  25 分钟
  降幅：72%
  月合同量：400 份
  月节省工时：400 × 65 分钟 ≈ 433 小时
  复核通过率：94%（低于 90% 需回炉调优）

务必在改造前先测「改造前基线」。这是被跳过最多、后果最严重的一步——项目做完了才想起来算收益，没有基线数据就只能拍脑袋，最后汇报时说服力归零。第一周什么都别干，先测基线。

Step 6：两个月之后——防止能力随专家一起撤走

6 沉淀成组织资产，而不是个人技巧

FDE 模式的终点不是「专家帮你做完了」，而是「专家走了你还能继续」。撤场前必须完成三件事：

① 把跑通的流程沉淀为「组织级 Skill」
   资深员工调好的 Agent 流程存成可复用配方，
   新人调用即可产出同质量结果。
   （这正是当下主流企业级 Agent 平台都在做的能力）

② 建立内部教练梯队
   24 位脱产骨干中至少选出 5-8 人，
   回到原业务线后承担「本线教练」角色，
   一对多带教，形成二级扩散。

③ 固化迭代机制
   每月一次场景复盘会：
   哪些 Skill 被高频调用 → 加固
   哪些没人用 → 下线或重做
   新暴露的痛点 → 进下一批场景池

📌 第①条是最硬的资产。个人技巧会随人员流动流失，沉淀成 Skill 的流程才是组织能力。判断一个 AI 项目是否真的成功，就看专家撤场三个月后，Skill 调用量是在涨还是在跌。

落地节奏参考

阶段	时间	关键动作	交付物
准备期	第 0 周	选场景、选人、测基线	场景清单 + 基线数据
共创期	第 1-4 周	混编攻坚，跑通首个场景	1 个可用流程
扩散期	第 5-8 周	复制到其余场景，沉淀 Skill	Skill 库 + 效率数据
移交期	第 8 周	教练梯队就位，专家撤场	迭代机制 + 复盘报告

一句话总结：Agent 落地失败，九成不是工具不行，是组织方式不对。FDE 这套打法的本质，是用「脱产 + 混编 + 可量化验收 + 能力沉淀」四件事，把 AI 从「个人效率玩具」变成「组织级生产力」。工具可以换，这套方法论是通用的。

📚 更多教程 📰 智能体资讯

← 返回教程中心