第 2 章 · 上线了却没人用
老板先看这一句： 大多数 AI 项目不是败在技术，是死在落地：需求是句糊的愿望、数据用不了、嵌不进流程、没人说得清准不准、出错没人兜底，最后没人负责。老板要避的坑，就是立项前先问“这事谁对结果全责、准不准怎么算、错了谁兜”，三问答不上就别批预算。
鼓掌之后
AI 项目有个残忍的规律：演示会上的掌声，和三个月后的使用率，几乎没有关系。
我见过太多这样的场景——评审会上大屏一放，问答流畅、生成惊艳，领导点头、业务鼓掌，当场拍板推进。然后呢？然后就没有然后了。原型被放进一个文件夹，慢慢没人再打开。
这不是因为团队不努力，而是因为大家把力气全花在了「做出一个好 Demo」上，却没人管「让它真正用起来」这件事有多难。这一章，我们把 Demo 到上线之间那道看不见的坎，拆成六个具体的、你几乎一定会撞上的原因。看清它们，是 Agent 落地工程师的第一堂必修课。
六个真实的死因
一、需求从一开始就是糊的
业务方说「我想要个智能客服」「帮我做个知识库」「上个 AI 分析」。这些都不是需求，是愿望。愿望没法验收——你做完了，对方一句「感觉不太行」，你连反驳的依据都没有，因为从没人定义过「行」长什么样。
糊的需求，做出来的一定是糊的东西。
二、数据看着有，用起来没有
立项时大家都拍胸脯「数据我们有的是」。真开工才发现：手册是扫描件、格式五花八门、字段对不上、权限没人给、还夹着一堆过期和重复。「有数据」和「有能用的数据」之间，隔着一整个项目的工作量。
三、嵌不进现有流程
AI 能力再强，如果它是个孤岛——要用户额外打开一个新系统、额外复制粘贴、额外记一套操作——它就不会被用。真实业务是有惯性的，能力必须长在人本来就在走的流程上，而不是要求人为它改道。
四、没人说得清「准不准」
这是最隐蔽的一条。项目跑起来后，业务方说「感觉 AI 不太准」，你问哪里不准、错在哪类、错多少算不能接受——没人答得上来。因为从头到尾就没建立过一套「怎么算对」的标准。没有标准，就没有验收，也没有改进的方向，项目只能在「感觉不行」里原地打转。
五、概率性没人兜底
大模型会出错，这是它的天性，不是 bug。可如果没人设计「出错了怎么办」——哪些结果必须人工复核、错了走什么补救、高风险动作怎么拦——那么第一次出岔子，往往就是整个项目被叫停的时候。业务不怕 AI 会错，怕的是错了没人管。
六、根本没人对结果负责
前面五条叠加起来，最终暴露的是第六条：一个 AI 项目里，常常没有任何一个人，是对「这东西最后到底有没有用」负全责的。开发管代码、算法管模型、业务提需求，中间那一大片模糊地带——需求翻译、数据打通、流程嵌入、效果评估、上线兜底——是三不管地带。
把死因翻过来，就是 Agent 落地工程师的活
有意思的是，把这六条倒过来看，正好就是本书后面五个部分要教你的事：
| 死因 | 对应的解法 | 在本书哪里 |
|---|---|---|
| 需求是糊的 | 需求挖掘 + 场景卡 | Part 2 |
| 数据用不了 | 数据盘点纳入 PoC 范围 | Part 2 / Part 3 |
| 嵌不进流程 | 画 AI 介入点图 | Part 2 |
| 说不清准不准 | 评估驱动、Golden Dataset | Part 5 |
| 概率没兜底 | 人审门、上线门禁、回滚 | Part 5 |
| 没人负责 | Agent 落地工程师 + 业务搭档共创机制 | Part 4 |
这也是为什么本书不按「技术难度」组织，而按「交付旅程」组织——因为项目不是死于技术不够强，是死于这条旅程上某一段没人走完。
一张死因体检表
真正开工前，Agent 落地工程师可以用下面这张表做一次 30 分钟体检。每项打红黄绿，红灯就是本轮 PoC 必须先处理的风险。
| 体检项 | 绿灯 | 黄灯 | 红灯 |
|---|---|---|---|
| 需求 | 有场景卡、指标、边界 | 有方向但指标含糊 | 只有一句「想做个 AI」 |
| 数据 | 已授权、格式清楚、能持续更新 | 数据能拿到但质量未知 | 数据来源、权限、字段都不清楚 |
| 流程 | AI 介入点和人审点已画出 | 大致知道插在哪 | 需要用户额外打开新系统、复制粘贴 |
| 评估 | 有 Golden Dataset 和验收线 | 有样本但没有门槛 | 只靠「感觉准不准」 |
| 兜底 | 有人审、日志、回滚 | 有人工复核想法但未机制化 | 出错后不知道谁处理、怎么关 |
| 责任 | Agent 落地工程师和 AIBP 明确 | 有负责人但不能拍板 | 多方参与但没人对结果负责 |
这张表不是为了吓退项目，而是为了决定先补哪块。比如数据红灯，就别急着调模型；评估红灯，就别急着上线；责任红灯，就先找业务搭档，否则后面每一步都会靠猜。
📍 场景示例：客服机器人演示很炫，两个月后零使用
老陈曾让顾问搭了个多语种客服 Demo：英文问答丝滑，会上一片掌声，当场决定“上”。可两个月后，2 名客服依旧手动回邮件，FR/ES/JP 咨询还是 T+1，首次响应仍卡在 18–24h，一次解决率停在约 60%。原因不难找：没人定义过“准不准”、它没接进现有工单系统（客服得多开一个后台）、出错了也没人兜。六个死因，它至少中四条。
| 维度 | 改造前 | 改造后（该有的样子） |
|---|---|---|
| 首次响应 | 18–24h（FR/ES/JP 常 T+1） | 7×24 自动首响，人工只接复杂单 |
| 使用率 | Demo 后归零 | 嵌入工单流，天天在用 |
| 准不准 | 没人说得清 | 有 Golden Dataset 与验收线 |
老板决策点： 立项前逼团队过“死因体检表”，只要“没人负责对结果”是红灯，先指派 AIBP，否则预算打水漂。 ——对应 → L2
本章产出
老板行动点： 别只看 Demo 鼓掌。立项前逼团队过一遍「死因体检表」；只要“没人负责对结果”这一条是红灯，就先指派业务效果负责人（AIBP），否则预算大概率打水漂。
往交付包里放一份「死因体检表」：
拿你手上的项目，逐条过这六个死因，给每一条打个红黄绿灯。红灯最多的那一条，就是你这个项目当前最大的上线风险，也是你读完本书后第一个该动手的地方。
成熟度自检
- [ ] 我能说出「愿望」和「可验收需求」的区别（→ L1→L2）
- [ ] 我能对一个具体项目做完六条死因体检，并指出最大的红灯（→ 迈向 L2）