第 18 章 · 小队怎么搭
老板先看这一句： AI 转型卡住，多半不是技术不行，而是组织还停在部门墙里——业务、数据、算法、工程各管一段，一个需求传三个月就走样了。你要做的第一件事，是把跨职能的人凑成一支三五人的「作战小队」，直接扎到业务现场，而不是开个项目组让各部门派代表「对齐」。你本人得当这个项目的 Sponsor，并亲自指派一个真正懂业务、能拍板的业务搭档——没有他，技术再强也造不出业务认的东西。
从「串行接力」到「同桌开工」
先说一个几乎所有大公司都上演过的失败剧本。
业务部门提了个 AI 需求，写成文档，扔给产品；产品排期，转成 PRD，扔给数据团队要数据；数据团队排期，清完数据，扔给算法；算法调完模型，扔给工程；工程做完，回过头找业务验收——这时距离立项已经过去三个月，业务方看完第一句话是：「这不是我当初想要的。」
问题不在任何一个环节，而在这个结构本身。它是一条串行的接力赛,每一棒之间都有一次「翻译」和一次「排队」。而 AI 项目最怕的就是翻译和等待——因为需求本来就模糊，越往后传，失真越严重；因为效果本来就要快速试错，越排队，反馈越迟。
Agent 落地工程师的交付不用接力赛的结构，用的是作战单元的结构：一支三到五个人的小队，坐在一起（物理上或线上），围着同一个业务目标，短周期、高频率地把事情推完。对做跨境家居的老陈来说，这种串行接力在选品、质检、客服上天天上演——一个痛点从运营传到 IT 往往排好几轮，等做出来早已不是当初要的，破局第一步就是把人拉成一支同桌开工的小队。
这支小队里有谁
一个能打的最小作战单元，通常有这么几个角色。注意，这里说的是角色，不是人头——一个人可以戴多顶帽子，尤其在小项目里。
| 角色 | 负责什么 | 一句话职责 |
|---|---|---|
| Agent 落地工程师 | 智能体搭建、调优、集成、评估 | 「技术上怎么把好结果稳定交出来」 |
| 业务搭档（AIBP） | 定义好结果、提供真值、拍业务板 | 「业务上什么才算好结果」 |
| 业务一线 | 提供真实流程、真实样本、异常案例 | 「现实里到底是怎么跑的」 |
| 数据工程（按需） | 数据供给、打通、质量、权限 | 「让能用的数据到位」 |
前两个角色——Agent 落地工程师和业务搭档——是任何 AI 项目都不能少的一对，他们的配合是下一章（第 19 章）的主题。业务一线保证 PoC 不脱离现实。数据工程则是「按需」——只有在数据依赖特别重的场景（比如要打通好几个业务系统）才专门拉进来，轻场景里这份活 Agent 落地工程师自己就兼了。
关键原则：能三个人干的，别拉五个人。 小队的战斗力来自沟通成本低、决策快。每多一个人，协调开销就上一个台阶。宁可让一个人多戴一顶帽子，也不要为了「配置齐全」把队伍撑大。
为什么是「全功能」
作战单元的灵魂，是全功能——这支小队自己就能闭环完成「业务、数据、模型、工程、验收」的全过程，不需要把任务甩出去等别的部门。
这带来两个直接的好处：
- 没有翻译损耗。 业务搭档就在旁边，Agent 落地工程师有疑问当场问，不用写文档隔空对话。模糊需求在小队内部就被澄清了，不会带着误解往下走。
- 反馈是分钟级的。 Agent 落地工程师改完一版，业务搭档当场看、当场提意见，一天能迭代好几轮。而串行结构里，一次反馈往往要等一个排期周期。
你可以把这支小队想象成一个「特种小组」：麻雀虽小，五脏俱全，能独立完成一次完整的突击。这也正是 Agent 落地工程师里那个「Forward Deployed（前置部署）」的含义——不是坐在后方等需求传过来,而是整支小队直接扎到业务现场去。
怎么把小队搭起来
搭一支作战单元，实操上是四步：
- 先定业务搭档。 找那个真正懂业务、且愿意为结果负责、还能提供真值数据的人。这个人比 Agent 落地工程师还关键——没有他，你连「什么叫做对」都定义不了。
- 明确谁戴哪几顶帽子。 用第 4 章的四副面孔，盘一遍小队里每副面孔谁来担。发现某副面孔没人担、又绕不过去，才考虑加人。
- 约定协作节奏。 定好一起开工的时间、周会时间、演示时间（下一章和第 20 章会细讲节拍）。
- 划清决策权。 谁能拍业务板（通常是业务搭档），谁能拍技术板（通常是 Agent 落地工程师），避免每个决定都上升到老板。
用 RACI 防止「大家都参与，没人负责」
企业项目里，最常见的组织风险不是没人参加，而是参加的人太多、责任却不清。建议小队成立时就写一张 RACI 表：
| 事项 | Agent 落地工程师 | AIBP | 一线业务 | 数据/平台 | 安全/法务 | 高层 Sponsor |
|---|---|---|---|---|---|---|
| 场景选择 | R | A | C | C | C | A |
| 业务指标定义 | C | A/R | C | C | ||
| 数据授权 | C | R | C | A/R | C | A |
| Golden Dataset | R | A/R | C | |||
| 上线门禁 | R | A | C | R | A/R | C |
| 回滚决策 | R | A | C | R | C | C |
| 自主运营 | C | A/R | R | C |
R 是负责执行，A 是最终负责，C 是需要咨询。表可以很粗，但一定要有。没有 R，事情没人做；没有 A，事情没人拍板。
📍 场景示例：老陈的最小全功能小队
老陈之前做 AI 是「串行接力」：运营提需求 → IT 排期 → 外包做，一个客服 Agent 传了三轮，做出来 FR/ES/JP 时差缺口根本没 cover。这回 FDE 拉起一支 3 人小队同桌开工：运营负责人当 AIBP（定义好结果、拍业务板）、FDE 当 Agent 落地工程师（搭建调优）、运营负责人兼治理运维（后期盯成本/质量）。没有数据工程专人——轻场景 FDE 自己兼了。3 人闭环，分钟级反馈。
| 维度 | 改造前 | 改造后 |
|---|---|---|
| 组织结构 | 部门串行接力 | 3 人全功能小队同桌 |
| 决策路径 | 小事也上报老板 | AIBP 当场拍业务板 |
| 反馈速度 | 一个排期周期 | 当天迭代几轮 |
| 角色覆盖 | 业务/IT 两截 | AIBP + FDE + 治理（一人多角） |
老板决策点： 你亲自指派 AIBP——必须是真懂业务、敢拍板的人，挂名的等于小队没大脑。 ——对应 → L3
常见坑
- 按部门凑人，而不是按角色凑人。 结果是每个部门派一个代表来「对齐」，人多、话多、没人真干活。要的是能闭环的角色，不是各方代表。
- 业务搭档是挂名的。 业务方派了个不懂业务、也不敢拍板的人来，小队就等于没有大脑，Agent 落地工程师只能自己脑补业务，回到了「凭感觉做」。
- 小队没有决策权，凡事上升。 每个小决定都要等老板拍板，分钟级反馈的优势荡然无存。
- 一开始就追求「标准配置」。 三个人能启动的事，非要等齐五个角色、六个部门签字，项目还没开始就凉了。
📎 技术深读：当小队要把「一个智能体」拆成「多个协作的智能体」（比如一个采集、一个分析、一个审校）时，那是技术层的多 Agent 编排——见 Harness Agent Book · Part 5。本章讲的是人的小队，那一章讲的是智能体的小队，两者是一个道理的两层。
本章产出
老板行动点： 你亲自指定项目 Sponsor（最好是你自己或一位懂业务的 VP），并拍板业务搭档人选——记住，业务搭档不能是挂名的，必须是真懂业务、敢拍板的人，否则小队就是没有大脑。
往交付包里放一张「小队花名册」：
列出你这个项目的四个角色分别由谁担（可一人多角），标出业务搭档是谁、决策权怎么分。如果「业务搭档」这一栏填的是「暂无」或一个挂名的人——那就是你开工前要先解决的头号问题。
成熟度自检
- [ ] 我能说清作战单元和串行接力在结构上的区别（→ L3）
- [ ] 我能为一个真实项目搭出一支三到五人的全功能小队，并落实业务搭档（→ 迈向 L4）