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