第 5 章 · 从痛点到 AI 用例
老板先看这一句： 业务方跟你说的“做个 AI 写文案”“搞个智能客服”，十有八九是方案不是问题。真问题是藏在后面的——上架太慢、差评发现晚、多语种回复跟不上。老板要会这一招：别人提 AI 想法时，追问“现在没 AI 你怎么做的、最怕出什么错、做成了哪个数字会变好”。答不上“成功长什么样”，就先别批钱，免得被一句漂亮话忽悠。
一句话需求背后的坑
有个做母婴电商的运营总监找我，开口第一句是：「我想做个 AI，自动帮我写商品详情页。」
听上去很清楚，对吧？我要是当场点头，回去就能搭个生成文案的 bot，一周交付。但我多问了一句：「你们现在详情页是谁在写、卡在哪儿？」——真相立刻不一样了。原来他们真正头疼的，不是「写不出来」，而是新品上架要等三天：文案得等设计出图、出图得等选品定稿、定稿又卡在采购确认。文案本身两个小时就能写完，写文案根本不是瓶颈。
如果我按他说的做，交付一个「自动写文案」的 AI，功能上完全能跑，演示会上他也会鼓掌——然后闲置。因为它解决的是一个不疼的问题。
这就是 Agent 落地工程师要过的第一关：客户说出口的是「方案」，藏在后面的才是「问题」。 你的活儿不是照着方案施工，而是把问题挖出来。戴上业务咨询师这顶帽子，从第一句话开始。
跨境卖家同理：把“写商品详情页”换成“把某 SKU 的多语种 Listing、独立站与社媒文案一键生成并过合规审查”，客户说方案、你挖问题的逻辑完全一致。
为什么客户总说方案、不说问题
这不是客户的错，是人的本能。业务方每天泡在自己的活儿里，脑子里早就把「我遇到的麻烦」翻译成了「我以为的解法」。他说「做个 AI 写文案」，其实是「我觉得上架太慢，而 AI 好像能写字」这两个念头挤成的一句话。
麻烦在于，他的翻译往往是错的——他不懂 AI 能干什么、不能干什么，凭直觉猜了一个解法。你要是接住这个解法直接做，等于把一个外行的技术猜想当成了需求。
所以 Agent 落地工程师要做的，是把这句话倒着翻译回去：从「他要的方案」倒推回「他真正的问题」，再由你——懂 AI 的人——重新给出解法。
三个追问法
倒推靠追问。我常用的有三个方向，一层层往下钻。
第一追：向下追到场景。 把抽象的名词钻到具体的人、具体的时刻、具体的动作。
- 「这个功能，是谁、在什么时候、点了什么之后会用到？」
- 「你能描述一遍上次它派上用场的完整过程吗？」
「帮我写文案」被追下去，变成「选品定稿后，运营小张要在后台一个个填详情页字段」——一下就具体了。
第二追：向后追到痛点。 追现状怎么做、慢在哪、错在哪、代价是什么。
- 「现在没有 AI，这件事是怎么做的？」
- 「最怕出什么错，或者最怕漏掉什么？漏了会怎样？」
追下去才发现，瓶颈根本不在写字，在流程等待。真痛点是「上架周期长」，不是「文案产能低」。
第三追：向前追到成功。 逼出「怎样算帮上忙了」——没有这条，项目永远无法验收。
- 「假如这事做成了，哪个数字会变好？现在多少、你想要多少？」
- 「三个月后你拿什么向老板证明这笔钱花得值？」
这一问最关键，也最常被跳过。第 12 章那个案例里，业务方对「怎样算帮上忙」的回答是「……没想过」——那句「没想过」，就是项目最大的风险所在。
把愿望翻译成可验证假设
三追之后，你手里就有了料，可以把一句模糊愿望，收敛成一个能被验证的假设。用第 3 章给过的那个固定句式：
如果我们把 ___（哪个环节）交给 AI，业务上的 ___（哪个指标）应该会从 ___ 变到 ___。
母婴那个例子，翻译完是这样的：
- 客户原话：「做个 AI 自动写文案。」
- 真问题：新品上架周期长，卡在多环节串行等待。
- 可验证假设：如果把「选品定稿后的详情页字段填写与素材整理」交给 AI，新品上架周期应该会从平均 3 天缩短到 1 天以内。
看出区别了吗？后者可以拉数据验证、可以定验收线、可以判断值不值得做。前者只能「做出来看看」——而「做出来看看」正是无数 AI 项目烧完预算的方式。
一次追问，通常会挖出不止一个假设。把它们都列出来，下一章（场景卡）和第 8 章（PoC 选型）会教你怎么从里面挑第一个动手的。
先定义经营结果，再谈 AI 指标
经营结果与模型指标不能混为一谈。准确率、召回率和响应时间只能说明 AI 表现，不能单独证明项目值得继续。每个用例至少要建立五层指标：
| 层级 | 要回答的问题 | 跨境客服示例 |
|---|---|---|
| 经营结果 | 业务最终改善了什么 | 客户满意度、复购、服务成本 |
| 流程结果 | 工作流变快、变稳了吗 | 首次响应时间、一次解决率、升级时长 |
| AI 质量 | AI 的判断和输出是否可靠 | 意图识别准确率、答案采纳率、事实错误率 |
| 风险与治理 | 有没有越权、泄露或错误执行 | 高风险拦截、人工复核、敏感信息泄露数 |
| 成本与采纳 | 用得起、有人用吗 | 单次处理成本、活跃用户、人工接管比例 |
访谈时先记录当前基线，再讨论目标。没有基线，就无法区分“AI 带来的变化”和业务自然波动；没有责任人，再漂亮的指标也不会有人持续追。
访谈要留下证据
需求追问不是聊完就算。企业项目里，后面一旦出现争议，最有用的不是你记得什么，而是当时留下了什么证据。建议每次访谈至少沉淀下面这张表：
| 项 | 记录什么 | 示例 |
|---|---|---|
| 业务原话 | 对方最初怎么表达愿望 | 「能不能搞个 AI 帮我盯竞品」 |
| 当前流程 | 今天谁在什么系统里怎么做 | 运营每天打开 6 个平台手动巡检 |
| 痛点证据 | 慢、错、漏、贵的证据 | 周报要 4 小时，差评集中爆发常滞后 2 天发现 |
| 业务代价 | 不解决会损失什么 | 价格反应慢、差评扩散、运营复盘靠记忆 |
| 成功定义 | 什么数字变好算成功 | 周报 15 分钟内生成，高风险差评漏报为 0 |
| 待确认 | 还缺什么事实 | 平台采集限制、评论数据授权范围 |
这张表的价值，是把「客户说过」变成「项目证据」。后面填场景卡、做 PoC 选型、定验收指标时，都从这里取数，而不是靠回忆。
📍 场景示例：客服小妹的「AI 自动回消息」愿望
老陈的客服主管提了个想法：“能不能搞个 AI，自动回复客户消息？” 听着像需求，其实是方案。FDE 没接话就做，而是追问：现在谁回、卡在哪儿？真相是——2 名客服覆盖 EN/DE 为主，FR/ES/JP 因时差常 T+1 才回，真正疼的不是“写不出回复”，而是“时差导致首响 18–24h、一次解决率仅 60%”。
| 维度 | 改造前（被提的方案） | 改造后（挖出的真问题） |
|---|---|---|
| 首响时效 | FR/ES/JP 常 T+1 | 7×24 自动首响草稿 |
| 真瓶颈 | 以为“写不出” | 时差覆盖 + 人审兜底 |
| 成功定义 | 没想过 | 首响 < 数小时、一次解决率↑ |
老板决策点： 别人提 AI 想法时，追问“现在没 AI 怎么做的、最怕出什么错、做成了哪个数字会变好”，答不上“成功长什么样”就先别批钱。 ——对应 → L2
常见坑
- 把方案当需求，照着施工。 客户说做什么就做什么，交付一个功能正确、却没人用的东西。
- 只追第一层就收工。 问到「谁用、干嘛用」就停，没追到痛点和成功定义，验收时才发现没标准。
- 替客户脑补答案。 追问变成诱导——「你是不是想要 XX」，客户顺口说「对对对」。要让他自己讲现状，你只负责问。
- 一次只认一个需求。 客户一句话里常裹着好几个问题，别急着锁定第一个，先摊开再挑。
本章产出
老板行动点： 下次有人跟你提 AI 点子，先别点头批预算，逼他讲清“做成了哪个指标会从多少变到多少”。讲不出的，让他先回去填需求追问记录——这能帮你挡掉一大批伪需求。
往交付包里放一份「需求追问记录 + 可验证假设清单」：
挑一个你手边有人跟你提过的 AI 想法，用三个追问方向各写下你会问的 2–3 个问题；把访谈答案整理成一到三条「如果把 X 交给 AI，指标 Y 会从 A 变到 B」的假设。这份清单，就是下一章场景卡的填充原料。
成熟度自检
- [ ] 我能分清客户嘴里的「方案」和背后的「问题」，不直接照方案施工（→ L2）
- [ ] 我能用三个追问方向，把一句模糊愿望收敛成可验证假设（→ 巩固 L2）