第 21 章 · 把方向盘交出去
离不开的「专家」,是失败的交付
有个项目我做得挺得意:上线后跑得很稳,业务方很满意。得意了大概两个月,我发现不对劲——业务方隔三差五就找我:「想加一类新问题的回答,你帮忙调下」「这个阈值想改改,你来弄」。每一次都得我上手,因为整套东西只有我调得动。
我成了这个系统离不开的「专家」。听着像是被需要,其实是交付失败。因为业务天天在变,而我不可能永远待在这个项目上。真正成功的交付,不是「我一直在」,而是「我走了它照样转」。
FDE 的终点不是做出一个好用的智能体,而是把方向盘交到业务方手里,让他们能自己开。 这一步,对应成熟度从 L4 到 L5 的跨越——从「我带着交付」到「他们自主运营」。这一章讲怎么把方向盘交出去,而不是永远自己攥着。
为什么交不出去
先想清楚:为什么系统总离不开 FDE?几乎都是因为「怎么调」这件事,只存在于 FDE 的脑子和手上。
- 想加一类新回答?得改提示词——而提示词只有 FDE 懂怎么改、改完怎么验。
- 想调个阈值?得动配置——而配置藏在代码里,业务方碰都不敢碰。
- 效果变差了?只有 FDE 会看评估集、会定位问题。
根子是:系统的「可调部分」没有对业务方开放,全锁在技术黑箱里。 交接的本质,就是把这些「常改的旋钮」从黑箱里拆出来,做成业务方也能安全操作的东西。
三样东西,让业务方自己开
要让业务方自主运营,至少交付这三样。
一、配置化界面——把常改的旋钮搬到台面上。 把业务方最常要调的东西——分类口径、预警阈值、回答话术、知识库条目——从代码里抽出来,做成一个他能点、能填、能保存的界面。他不需要懂提示词,只需要在界面上「加一条口径」「把阈值从 0.7 调到 0.8」。判断哪些该配置化,就看第 12 章那个变更池:被反复提的「优化类」变更,就是该做成旋钮的。
二、规则模板——让他照着填,不必从零想。 光给界面还不够,业务方常常不知道「该怎么填才对」。给他模板:新增一类问答长什么样、一条预警规则该包含哪些字段、话术要避开哪些雷区。模板 = 把 FDE 的经验固化成填空题,降低他自己动手的门槛和出错率。
三、反馈机制——让系统能从使用中继续变好。 交出去不等于撒手不管质量。要给业务方一个简单的反馈通道:AI 答错了,他能一键标记「这条不对」。这些标记自动沉淀成新的失败样本,喂回 Golden Dataset(第 16 章)。这样即使 FDE 退到幕后,系统仍能靠日常使用持续进化——这正是第 12 章那个「闭环」在交接之后的延续。
| 交付物 | 让业务方能 | 替代了原来谁的活 |
|---|---|---|
| 配置化界面 | 自己调口径/阈值/话术 | FDE 改代码 |
| 规则模板 | 照着填,不出错 | FDE 手把手教 |
| 反馈机制 | 标记错误、喂回评估集 | FDE 人肉收集失败样本 |
交接不是甩手,是换挡
把方向盘交出去,不是一脚下车走人,而是换个位置继续在。参照第 11 章那四个阶段,交接大致这么换挡:
- 先并排开:FDE 调、业务方看,边做边讲「为什么这么调」。
- 再让他开、你盯着:业务方上手用配置化界面调,FDE 在旁边兜底、纠偏。
- 最后你退到幕后:业务方独立运营日常,FDE 只做两件事——监控(盯成本、质量、失败率有没有异常)和阶段性升级(重大能力迭代)。
到了最后这一步,你和这个项目的关系,就从「司机」变成了「4S 店」——平时他自己开,定期回来保养,出大问题才找你。这才是 L5 的样子:你的价值不再靠「在场」证明,而靠「系统在你不在时依然良好运转」来证明。
一份简单的交接说明要配齐:怎么用配置界面、常见问题怎么处理、出大问题找谁怎么关(呼应第 20 章的回滚)。第 18 章那个案例,Week 4 就给运营留了这么一份「怎么自己调」的说明。人机边界与自主运营的对接,可对照附录 B 的介入点图。
交出去以后看什么
自主运营不是没人管，而是换一组指标看盘。最小运营仪表盘可以包含：
| 指标 | 用来发现什么 |
|---|---|
| 调用量 / 活跃用户 | 业务方是不是真的在用 |
| 采纳率 | AI 输出是否有用 |
| 人工复核量 | 人审是否过重，是否吃掉效率收益 |
| 失败率 / 超时率 | 工具、接口、模型是否稳定 |
| Top 失败类型 | 下一轮优化该改哪里 |
| 成本 / 次 | 是否出现调用膨胀 |
| 高风险拦截数 | 风险控制是否在工作 |
交接也要验收。不是发一份说明文档就算，而是让业务方现场完成一次独立操作：
- AIBP 自己新增一条分类口径或调整一个阈值。
- 系统自动跑 Golden Dataset 回归。
- 回归不退化后发布到试用环境。
- FDE 只旁观，不代操作。
- 发布后看运营仪表盘，确认采纳率、失败率、成本没有异常。
这五步走完，才说明方向盘真的交出去了。
支持机制也要分层：业务方能自助处理的，不要找 FDE；AIBP 能处理的，不要找平台；只有工具故障、权限问题、重大退化，才升级给 FDE 或平台团队。否则交接以后，FDE 仍然会被所有小问题拖回一线。
常见坑
- 把自己做成离不开的专家。 所有调整只有 FDE 会,系统绑死在一个人身上,交付名成实败。
- 可调部分锁在代码里。 常改的旋钮不做配置化,业务方碰不了,只能次次找你。
- 只给界面不给模板。 业务方对着空界面不知道怎么填,还是得依赖 FDE。
- 交接=撒手。 一交了之,不留监控和反馈机制,系统慢慢跑偏无人察觉。
- 没写交接说明和关停预案。 业务方不知道出事找谁、怎么关,一遇故障就抓瞎。
本章产出
往交付包里放一份「自主运营交接包」:
列出业务方日常最常要调的 3–5 个「旋钮」,为每个设计出配置化的操作方式和填写模板;设计一个「标记错误 → 喂回评估集」的反馈通道;再写一页交接说明(怎么调、出事找谁、怎么关)。这套东西交出去,你才算真正完成了从 L4 到 L5 的跨越。介入点与人机边界可对照 附录 B,关停回滚对照 附录 F。
成熟度自检
- [ ] 我能把常改的能力做成配置化界面 + 模板,让业务方自己调(→ L5)
- [ ] 我能建立反馈闭环并退到监控/升级角色,让系统在我不在时持续运转(→ 巩固 L5)