第 19 章 · 业务和 AI 怎么配合
老板先看这一句： AI 项目最危险的不是技术缺人，而是业务方「没人真负责」——业务部门把需求一扔就等验收，结果做出来的东西业务不认。你要保的是：业务侧必须有一个人真为效果负责，这就是业务搭档（AIBP）。他不一定是你最忙的高管，但必须是懂流程、能给真值、能拍板的人。你作为老板要替他扫清「拍不了板、事事要上报」的障碍，让他和技术在小队里真正共创。
一对搭档，两个问题
上一章说，Agent 落地工程师和业务搭档是任何 AI 项目都不能少的一对。这一章专门讲这对搭档怎么配合——因为这对关系处理好了，项目成功一大半；处理砸了，前面所有方法都白搭。
先把两个人的分工用一句话钉死：
业务搭档回答「业务上什么才算好结果」，Agent 落地工程师回答「技术上怎么把这个好结果稳定地交出来」。
这两个问题，缺一个项目都跑不动。只有 Agent 落地工程师，没有业务搭档，你会造出一个技术上很漂亮、但业务方不认的东西；只有业务搭档，没有 Agent 落地工程师，你会有一堆美好的期望，但没人能把它变成能跑的系统。
业务搭档到底是干嘛的
「业务搭档」这个角色（有些团队叫 AIBP，AI Business Partner），常常被误解成「提需求的人」。不是的。他的职责比提需求重得多，核心是三样东西：
一、定义「好」。 AI 输出到底怎样算合格？差评分类分到什么粒度算对？周报写成什么样运营才愿意用？这些标准，Agent 落地工程师定不了，只能由懂业务的人定。这是搭档最重要的贡献。
二、提供真值（Ground Truth）。 光有标准还不够，得有「标准答案」。搭档要从真实业务里，给出一批「这条应该这么判、那条应该那么答」的样本。这批真值，是后面做评估、调优、验收的全部依据（它会变成第 22 章的 Golden Dataset）。
三、拍业务板。 遇到业务上的取舍——这个场景要不要做、这个边界怎么划、这轮范围到哪——搭档要能当场拍板，而不是「我回去问问」。
一句话：Agent 落地工程师负责「怎么做对」，搭档负责「什么是对」。 后者定义不清，前者再努力也是在错误的靶子上打靶。
一个合格的业务搭档，至少满足三条：
| 标准 | 说明 | 不满足时的症状 |
|---|---|---|
| 懂流程 | 知道一线今天怎么做、异常怎么处理 | 只能讲愿景，讲不出真实操作 |
| 给真值 | 能提供样本、标准答案、判定理由 | 只说「不太对」，说不出应该怎样 |
| 能拍板 | 能决定边界、优先级、人审规则 | 每个问题都要「回去问老板」 |
如果这三条都不满足，Agent 落地工程师要先补搭档，而不是硬开工。没有业务搭档的 PoC，本质上是在缺少靶子的情况下练枪。
这不是「交接」，是「共创」
传统项目里，业务和技术的关系是「交接」：业务写好需求交给技术，然后等着验收。这种模式在 AI 项目里会死得很惨——因为需求本身是模糊的、要靠不断试错才能逼近，一次性交接必然失真。
Agent 落地工程师和搭档的关系必须是共创：两个人围着同一个目标，高频率地一起打磨。具体长这样：
| 维度 | 交接模式（❌） | 共创模式（✅） |
|---|---|---|
| 需求 | 一次性写清、扔过来 | 一起边做边澄清 |
| 频率 | 立项时对一次、验收时对一次 | 每周甚至每天对 |
| 真值 | 「你们看着办」 | 搭档持续供给、Agent 落地工程师持续消化 |
| 出问题 | 互相甩锅 | 一起看失败样本、一起改 |
| 心态 | 「这是你的活」 | 「这是我们的结果」 |
共创的标志性动作，是两个人一起对着同一批样本干活：搭档说这条 AI 判错了、应该这样，Agent 落地工程师当场理解、当场改、当场再跑给他看。这种分钟级的来回，就是 AI 项目质量爬升最快的方式。
Agent 落地工程师要有意识地「退出」
这里有一个容易被忽略、但极其重要的点：Agent 落地工程师不应该长期替业务方手工调 Prompt。
项目早期，Agent 落地工程师亲自调提示词、改规则，是合理的——快。但如果三个月后还是每次要改个话术都得找 Agent 落地工程师，那这个项目就永远断不了奶，Agent 落地工程师也永远脱不了身。
成熟的 Agent 落地工程师从一开始就带着「怎么让搭档以后能自己调」的意识做事：把常改的东西（分类口径、预警阈值、周报模板）逐步做成配置化的、搭档自己就能改的界面或规则。这样 Agent 落地工程师才能一步步退到只做监控和升级的位置——这正是第 24 章「把能力交出去」要展开的,也是从 L4 走向 L5 的关键一跃。
换个说法：Agent 落地工程师的终极目标，是让自己在这个项目里变得越来越不必要。
两个人一起定的那几样东西
Agent 落地工程师和搭档在项目里，要共同定下这几样东西（很多会落到前面讲过的场景卡上）：
- 场景卡：一起填，不是 Agent 落地工程师独自脑补（第 6 章）。
- AI 介入点：哪步 AI 做、哪步人工确认，一起划（第 6 章、附录 B）。
- 验收指标与真值样本：搭档给标准和真值，Agent 落地工程师落成可跑的评估（第 22 章、附录 D）。
- 上线节奏与变更规则：什么时候上、变更怎么管，一起定（第 21 章）。
最小协作约定可以写成这样：
| 约定 | 内容 |
|---|---|
| 样本共创 | 每周至少一起看 10–20 条真实样本 |
| 真值响应 | Agent 落地工程师标记的争议样本，AIBP 在 1 个工作日内给判定 |
| 周五 Demo | AIBP 必须参加，现场确认哪些进变更池 |
| 边界变更 | 涉及对外发送、权限、验收指标变化，必须重签场景卡 |
| 交接目标 | 从 Week 1 开始识别哪些口径、阈值、模板要配置化 |
📍 场景示例：老陈的运营和 FDE 每周对着样本共创
老陈的多语客服 Agent 上线 Beta 后，运营负责人（AIBP）不写需求文档扔给 FDE，而是每周五和 FDE 一起看 15 条真实工单：AIBP 说「这条 FR 咨询 AI 判成 EN 了、该转人工」，FDE 当场改分类口径、当场重跑给她看。营销素材也同理——运营给「高转化长什么样」的真值，FDE 落成可跑的评估。三个月后，常改的分类阈值做成配置化界面，运营自己就能调，FDE 逐步退到监控。
| 维度 | 改造前（交接模式） | 改造后（共创模式） |
|---|---|---|
| 需求传递 | 一次性写清、扔过去 | 边做边澄清、每周对 |
| 真值供给 | 「你们看着办」 | AIBP 持续给标准答案 |
| 出问题 | 互相甩锅 | 一起看失败样本改 |
| 依赖度 | 改句话术找 FDE | 阈值配置化，运营自调 |
老板决策点： 盯紧 AIBP 给没给真值——只说「不对」不给「该怎样」，等于浪费了这个角色。 ——对应 → L3
常见坑
- 把搭档当「需求传声筒」。 只找他要需求，不找他要「好的定义」和真值，等于浪费了这个角色最大的价值。
- 搭档不给真值，只给评价。 他只会说「这个不对」，却不给「那应该是什么」。没有真值,你无法评估,也无法改进——要坚持向他要标准答案。
- Agent 落地工程师大包大揽，从不做配置化。 图一时快，自己把所有 Prompt 都攥在手里，结果项目永远离不开你，你也永远交不出去。
- 共创变成开会。 「高频」被误解成「天天开会」。共创的核心是一起对着样本干活，不是一起坐着讨论。
本章产出
老板行动点： 你点名业务搭档（AIBP）人选，并公开赋予他「定义好结果、提供真值、拍业务板」的权责——别让业务方以为派个人来提需求就算参与了，谁为真值负责你要盯紧。
往交付包里放一份「搭档协作约定」，写清三件事：
① 谁是业务搭档、他负责提供哪些真值；② 我们每周在什么时间、以什么形式一起对样本；③ 这个项目里，哪些东西计划做成搭档能自己调的配置化能力。
成熟度自检
- [ ] 我能向业务搭档讲清「定义好结果」和「提供真值」是他的核心职责（→ L3→L4）
- [ ] 我在项目一开始就规划了哪些能力要做成配置化、好让自己将来退出（→ 迈向 L5）