《FDE案例100》方法论特辑 · No.02｜从"一句话愿望"到"真问题"：追到业务损失链

先讲个场景。

一家省属国企的老板，数字化在同类国企里算领先的，有 OA、有 ERP、有数据中台。大模型出来以后，他给 FDE 提的要求就一句话：“既然我们的数字化已经领先了，能不能再往 AI 走一步？”

你试试，这句话能拿来写代码吗？不能。它甚至算不上一个需求，顶多算一句愿望。

客户给的是愿望，FDE 要交付的是可验证的问题定义。 这两者之间隔着的东西，就是这篇要聊的。

愿望说出来很容易，但它不是问题#

上面那家国企，老板嘴上是”往 AI 走一步”。可 FDE 真正进场以后，发现的问题完全不是技术问题。

业务在增长，但国企有编制限制，人不能跟着业务无限加。更典型的是法务：整个团队就两个人，要面对十几条业务线、一堆合作伙伴的合同。真正的问题不是”我们要不要用大模型”，而是”业务要扩张，专业岗位的人却加不了，怎么办”。

你看，老板不会直接说”我希望法务少招一个人”，也不会说”我希望员工少干重复活”。他只会说”我们要拥抱 AI”。把表层愿望和真实需求分开，是 FDE 的第一个动作。

同样的例子我在另一个案例里也见过。一家消费品企业的产品经理提需求，说”我要做一个更脆的产品”。可”脆”是怎么来的？可能来自一次消费者调研，也可能来自和渠道客户聊天时的一句话。到了研发那边，又要把”脆”翻译成配方和工艺。这些”为什么”如果不被追问出来，最后进系统里的只有一个结果，上下文全丢了。

所以第一句结论：客户往往提不出好需求，也说不清好需求。 不是他们不专业，是没人往下追。

那怎么追？案例里有个特别漂亮的方法，我建议你直接背下来。

有个工业 ERP 的案例。15 个部门，几乎所有人都在抱怨同一件事：“ERP 不好用。”

但”ERP 不好用”能交给工程师吗？不能。于是 FDE 继续往下问：哪里不好用？平时怎么操作？问题出在哪一步？

问到最后，落到了一个很具体的点上——搜索太弱。业务人员经常遇到一句话：“我明明知道这个部件数据库里有，我上次还用过，现在就是找不到。”

到这儿还没完。“找不到”本身不是损失，损失在后面。你跟着这条链走：

找不到物料 → 认为数据库里没有 → 重新录入 → 出现重复数据 → 数据越来越脏 → 更难找到 → 买错、买重、搞错单位 → 错误采购留在仓库 → 几年后清理报废 → 真实的财务损失。

这就是我特别想让你记住的业务损失链。它从一句”系统不好用”，一路走到了”企业每年报废多少钱”。

再举一个对账的例子。一家线下零售企业说”对账太费人工了”。听起来是不是特别不值得用 AI？但 FDE 接着追问：对账不彻底会怎样？——有些本来该收的钱就漏掉了。以前总部甚至给门店设过一个”容忍区间”，因为人工对账太麻烦，差异在某个比例以内就干脆不追了。

机器能把差异找出来，那这部分被放弃的钱就有机会重新捡回来。 对账的价值，就从”省几个人天”，变成了实实在在的收入增益。

所以第二句结论：真问题必须能连到钱。连不到钱的问题，多半只是痒点，不是痛点。

顺便说一句，追到钱不光让方案更有说服力，它还有个更大的用处：让你算得清 ROI。ROI 一旦算得清，客户才敢投。这个我们留到 No.05 细聊。

有人会说，追这么细是不是太慢了？我直接开做不行吗？

行，但你要为返工买单。案例里有个学校批改作业加智能推题的项目。需求听起来特别顺：先批改、再给分、再分析、再推题。可真拆开呢？准确率要多少？批改时效要求是什么？哪些科目？推题规则是什么？学生做错一道难题，是该降难度，还是围绕同一个知识点给更难的题？人工在哪个环节介入？

这些问题前期没问清楚，后面就是不停改需求。

注意，这不只是”产品经理没定义清楚需求”的老毛病。到了 AI 时代，返工成本多了一样东西：直接表现为大量的 Token 消耗和交付成本。 代码写错了改一改不值多少钱，但让模型反复跑、反复调，每一次都在烧 Token。

所以第三句结论：把愿望翻译成可验证的问题，不是为了流程好看，是为了省钱。

那什么叫”可验证的问题定义”？案例里给了两个硬标准：边界和口径。

边界就是范围。管到哪儿为止，什么不做。前面那个城市规划的案例，FDE 本来可以讲一个很大的故事：整个市、所有数据、所有场景。但真做起来，是从一个市缩到一个区，再缩到一个具体单元，只挑两条业务流。范围越小，边界越清。

口径就是验收。有个很有意思的做法：前期调研时统计出来的那些高频问题，直接变成后面的测试集。文档解析率到大约 95%、问题召回的片段准确率到 80% 以上，才认为技术路径初步跑通。

你发现没有，验收标准不是 FDE 关起门定出来的，是跟客户一起、基于真实业务问题定的。因为它验证的不是”模型漂不漂亮”，而是”能不能解决真实业务问题”。

还有个细节我很喜欢。工业 ERP 那个案例，FDE 把 ROI 的定义放在了项目最开始：如果这个问题解决了，企业一年能少损失多少？这个数字怎么算？数据从哪来？最后谁来确认？

别等上线了才问”这东西到底值多少钱”。 到那时候，往往已经晚了。

客户给的是愿望，FDE 交付的是能连到钱、能验证的问题定义。 从”我们要拥抱 AI”到”一年少报废多少钱”，中间隔着的就是那条业务损失链。

这是《FDE案例100》方法论特辑的第 2 篇。上一篇我们聊了”先进入现场，再谈 AI”；这一篇聊的是进了现场以后，怎么把愿望追问成真问题。既然知道了什么是真问题，下一篇我们聊更难的一步：手里一堆真问题，到底先做哪一个？ 场景怎么选。