需求挖掘

需求挖掘为了什么，又会怎样失败

随交付一起到来的需求，几乎总是一个解决方案：“一个聊天机器人”“一个处理客服队列的智能体”“给核保员弄点生成式 AI”。解决方案是关于某个问题的假设，而且还没人检验过它。需求挖掘就是这场检验。当你能用客户自己的数字写下什么慢、什么贵、什么错，它发生在哪里，归谁负责，改善之后会撬动业务的哪根杠杆，需求挖掘就结束了。

证明交付死在这里的最有力证据，来自 FDE 领域之外。RAND 在 2024 年的一份报告中，基于对 65 位资深数据科学家和工程师关于 AI 项目为何失败的访谈，列出了五个根本原因，第一个是“行业干系人常常误解或误传需要用 AI 解决的是什么问题”（RAND RR-A2680-1，T1）。报告自己的建议说得更直白：对“项目意图和目的”的误解“导致失败的 AI 项目比任何其他因素都多”。

对此要仔细评级。RAND 独立且是一手来源，所以本书把它归为 T1；但它测量的是从业者在访谈中认为什么导致了失败，对象是一般的 AI 和机器学习项目，而不专指大语言模型部署。由领导层导致的失败（其第一种形式就是问题选错）和数据问题，是被“超过一半受访者主动提及”的两类原因。这是现有最好的证据，但它不是测得的失败率；谁要是引用“RAND 说 80% 的 AI 项目失败”，引用的其实是 RAND 转述的一个《财富》估计，而不是 RAND 的发现。

RAND 关于选错问题的例子值得记住，因为它太平常了。领导者“可能会说，他们需要一个机器学习算法告诉他们产品该定什么价，但他们真正需要的，是利润率最高的价格，而不是卖得最多的价格”。没有人撒谎，也没有人犯傻。团队造出了被要求的东西，而这类错误“只有在数据科学团队交付完整的 AI 模型、并试图把它融入日常业务运营之后才会变得明显”。需求挖掘存在的意义，就是把这个失败提前几个月：从集成阶段（在那里它会毁掉交付）提前到第一周（在那里它只花一次谈话）。

同一发现的 FDE 版本证据更软，但离这份工作更近。OpenAI 前线部署工程负责人 Colin Jarvis 对 Pragmatic Engineer 说，“客户在范围界定时描述的东西，常常与现场的数据和系统现实不符”（Pragmatic Engineer，2025-08-12，T3：二手报道中引用的从业者原话）。销售前线部署服务的咨询公司 Tryolabs 把它写成了一条规则：要造什么“必须从内部去发现”，并且“大多数时候，没有人能在第一天就把它交给你”（Tryolabs，2026-06-30，T4：供应商观点）。

需求挖掘的失败有三种可辨认的方式。一是被跳过，因为需求看起来很清楚，合同也写明了交付物。二是在错误的高度上做，在会议室里和高管谈，于是团队了解到的是领导层以为工作是什么样子，而不是它实际的样子。三是做得很好却没有写下来，于是观察到的问题只存在于 FDE 的笔记里，第一次有干系人重复原始需求时，构建就会漂回客户说出的那个问题。本 wiki 关于失败分类与分诊的页面对智能体说过同样的话：标出出错的第一步，因为那一步才有解法。在一次交付里，出错的第一步通常就是这一步。

这家保险公司，第一周和第二周

贯穿全书的合成案例从“交付开始之前”停下的地方接着讲：一个 30 天的付费试点，一个由首席运营官负责的 KPI，以及一项仍写着“客服聊天机器人”的交付物，因为销售当初就是这么写的。

注意 FDE 在第一周没有做什么：没选模型，没做任何演示，也没为聊天机器人争论。重新定义问题之所以能被接受，是因为理赔周期本来就是首席运营官的 KPI。需求挖掘很少推翻发起人；它是让发起人看到，她本就在意的那根杠杆，位于需求所指方向之外的别处。

从业务杠杆出发，而不是从 AI 出发

第一次谈话根本不应该谈 AI。据 TNW 对 2026 年一场演讲的报道，OpenAI 的每一次交付都“从一次为期两天的拜访开始”，团队“请业务领导者先把 AI 放在一边，说出他们业务中最大的杠杆”（TNW，2026-09-23，T3：对一位从业者描述自身做法的二手报道）。取其要义，不必照搬形式。原则是：发起人先说出杠杆，然后才有人说出技术。

杠杆是一个业务已经在盯着、并且有高层拿着薪水去推动的数字：周期时间、单件成本、单客户收入、赔付率、招聘周期、报废率。如果需求连不上其中任何一个，那就是一项技术在找用途，RAND 的第三个根本原因（看重“最新最炫的技术”而非真实问题）正在等着你。RAND 的受访者还描述过一些领导者，他们为那些“用几条简单的 if-then 规则就能很快解决”的问题，硬要上机器学习。从杠杆出发，就是为了尽早发现你面对的是不是这种情况。

招聘 FDE 的公司在招聘启事里也要求同样的习惯。Palantir 告诉应聘者，它的项目“往往从一个开放式问题开始，比如‘为什么我们有这么多航班延误？’或者‘我们怎样才能更好地识别洗钱案例？’”（Palantir FDSE 招聘启事）。Glean 的创始 FDE 招聘启事写道：“在写下一行代码之前，你要深入业务。哪里存在结构性的问题？未被解决的价值最集中在哪里？”（Glean 招聘启事）。作为交付实际如何进行的证据，两者都是 T4；但作为雇主要求什么的证据，它们是一手的，而它们要求的，是一个关于业务的问题，而不是关于模型的问题。

实际操作中，先向发起人提三个问题，并用她自己的话记下答案：

• 今年你最想推动的是哪个数字？如果她说了好几个，问她向上汇报的是哪一个。
• 你认为这个数字损失在哪里？这是她的假设。记下来，先不要争论。
• 你会接受什么作为它确实变了的证据？这是“划定范围与首个成果”要定下的成功指标的种子，也是你必须测量的基线。

然后把原始需求翻译成杠杆。“一个聊天机器人”变成“更少的进度查询电话”，再变成“理赔要等太久才得到首次处理”。每一步翻译都是一个你现在要去核实的假设。

到工作发生的地方去

杠杆告诉你什么重要，只有一线才能告诉你它损失在哪里。关于这种区别，最好的公开 FDE 例子是 OpenAI 与一家未具名的欧洲半导体公司的交付，Jarvis 在 Altimeter 的播客里讲过它（Altimeter，2025-11-26，T2：供应商描述自己的交付，客户未具名）。客户的需求是刻意开放的：审视整条价值链，“拿下最大的那些浪费”。团队“驻扎在现场，花了大概几周时间非常细致地了解他们的业务”，范围覆盖设计、验证和出货后的性能测量。他们选择了验证，在那里工程师“要花大概 70%、80% 的时间去修 bug”，还要维护与老芯片的兼容。让它具体起来的细节是：测试在夜里跑，每个工程师早上一到，就面对几百个 bug。

要准确理解这个案例证明了什么。客户并没有交给 OpenAI 一个错误的问题；它交出的是一个开放的问题，这更少见，也更容易。这个案例展示的是方法：在现场待几周，摸清整条链，按工程师的时间实际花在哪里来选目标，而不是按什么最好演示来选。报告的结果，即首批部门效率提升 20% 到 30%（目标是 50%），是自报的，没有说明方法，所以作为“这个选择得到了回报”的证据很弱。同一场演讲的一份二手摘要说驻场持续了“几周”（ZenML，T3）；录音里说的是“一两周”。以一手为准。

为什么是一线而不是会议室？前 Palantir FDE Nabeel Qureshi 在 2015 年到 2023 年间供职于该公司，他说去现场是为了捕捉“他们如何工作的隐性知识”，而不是“企业软件通常依赖的那种扁平化的‘需求清单’模式”（Qureshi，2024-10-15，T4：一位前员工的个人叙述）。隐性知识就是没人写进需求里的那部分，因为没人知道它是一项需求：团队在记录系统旁边另外维护的电子表格、结案前必须转发的那封邮件、大家遇到怪案子都会去问的那位资深理赔员。你只有靠观察才能看到它。

据 Pragmatic Engineer 报道，OpenAI 自己描述的早期范围界定从“在客户现场待几天”开始：“和用户坐在一起，梳理他们的流程”“找出最大的价值领域”“用合成数据做原型”，然后“在白板上列出想法并排出优先级”（Pragmatic Engineer，T3）。Palantir 的部署策略师招聘启事用一句话提出了同样的要求：“前往现场，与客户的分析师会面，理解他们需要回答的关键问题，并找到他们最大的痛点”（Palantir 招聘启事，就实际做法而言是 T4，就雇主要求而言是一手）。

要预期一线比组织架构图更乱。Sierra 在描述它的智能体策略师时说，这份工作是“梳理工作流程，收集正确的信息（标准作业流程、通话记录、流程文档、通话录音）”，并举了一家全球旅游公司的例子，那里有“20 多个内部干系人、没有 API”（Sierra，2026-05-19，T2：供应商自报）。20 个干系人意味着 20 种对“更好”的定义。没有 API 意味着数据问题已经是需求挖掘的问题，而不是以后的问题；“数据接入与集成”会从那里接着讲。

观察什么，问什么

需求挖掘有五项任务，每一项都有比直接提问更有效的方法。

跟随观察工作流程。坐在做这份工作的人旁边，每人至少看几个小时；如果工作因班次或团队而异，就覆盖不止一个班次或团队。请他们边做边讲，记下他们碰到的每个系统、每次复制粘贴、每次等待、每次向同事求助。根据你看到的画出工作流程，再把图拿给你观察过的人看，让他们纠正。只靠访谈画出来的工作流程，是组织架构图版本的工作。

用区间来获取数量和时间。问“一天多少件，清闲的日子和糟糕的日子各是多少？”以及“一件要多久，简单的和难的各是多久？”区间如实反映了人们知道多少，也正是你判断这根杠杆是否大到值得去撬所需要的。然后拿可计数的东西核对这些区间：队列长度、日志、你访问期间自己的统计。如果找不到任何可计数的来源，就把这一点写下来。这意味着基线必须在划定范围阶段从零开始测量，而这会改变计划。

找出谁拥有数据，谁拥有决定权。对工作流程中的每个系统，写出能批准只读权限的人，以及能批准改变工作流程做法的人。这两者很少是同一个人，也很少是发起人。Qureshi 说数据集成是“公司所做之事的核心”，而它的第一步是“与‘数据所有者’谈判”；你要在第一周就拿到他们的名字，而不是第四周。

弄清“更好”对每个干系人意味着什么，以及每个人害怕什么。向每个干系人问同样两个问题：什么会让这件事对你来说更好？如果让机器来帮忙，最坏可能发生什么？答案会互相冲突，而这正是关键：单个干系人对“更好”的定义会默认成为成功指标，其他人的定义则会在以后以反对意见的形式出现。最怕的那种失败通常是访谈指南里最重要的一行。它告诉你什么绝不能发生，这会成为构建中的硬约束，以及安全审查中的一个问题。

找出组织架构图和真实流程之间的差距。流程上说归别人做的工作，实际上是谁在做？哪一步在纸面上存在、实践中却被跳过？谁是大家都会去问的非正式分派人？这些差距正是 AI 系统最先失败的地方，因为它会按文档化的流程来构建。

需求挖掘中听到的大部分话，都可以归入几种反复出现的形态。下表给出它们通常的含义，以及要做的核实。

第五行值得多说一句。请专家评判同一小批案件，成本很低，能暴露“正确”到底有没有共识，而这些案件会成为“评测：证明它真的有效”一章所扩充的评测集的第一批条目。在需求挖掘阶段就开始评测并不算早。它是现有最便宜的需求挖掘工具。

把客户说出的问题和观察到的问题并排写下

当一页纸上有了四个框，需求挖掘就完成了：客户说出的问题、你观察到的问题、支持观察版本的证据，以及它撬动的业务杠杆。客户说出的问题要留在纸上。删掉它，发起人就会去捍卫它；把它和观察到的问题并排放着，发起人才能看出两者的联系并做出选择。

证据框是让这页纸有说服力的地方。它应当包含发起人不必信任你也能核实的东西：做这份工作的人给出的区间、来自队列或日志的计数、来电原因中的规律、一线人员的一句原话。RAND 的定价例子在这里是个警示：那个例子里的领导者想要一个价格并没有错，他们错在要的是哪一个价格。证据框就是你说明是哪一个的地方。

然后请发起人在观察到的版本上签字。这个签字比看上去更重要。划定范围会把观察到的问题变成一个指标、一个阈值和一份“暂不做”清单，而每一项都会被更喜欢原始问题的人质疑。一页签过字的纸，能一次性平息这场争论。RAND 建议领导者让一个团队“至少一年”专注于一个问题，这份承诺就从这里开始：承诺的对象是观察到的问题，而不是原始需求。

如果发起人不肯签字，你学到的东西比问题本身更重要。要么她并不掌管你找到的那根杠杆，要么她不相信证据，要么这次交付被买下的原因没有人说出口。每一种都需要现在就和负责人谈，赶在写下任何一行代码之前。如果解决不了怎么办，“当交付失败时”会回到这个话题。

模板：需求挖掘访谈指南

每个干系人群体用一份指南，最后合并到汇总框里。用区间，不用精确数字。给每个数字标明出处：口述、计数还是测量。

DISCOVERY INTERVIEW GUIDE
Engagement: ____________   Interviewer: ____________   Date: ________
Stakeholder (role, team): ______________________________________

1. BUSINESS LEVER
   Which number would you most like to move this year? ____________
   Who reports it, and to whom? _________________________________
   Where do you think it is lost? (their hypothesis) ______________

2. CURRENT WORKFLOW (observed, step by step)
   Trigger: ______________________________________________________
   Steps (system touched / wait / handoff at each): ______________
   Workarounds seen (side sheets, inboxes, "ask X"): ______________

3. PEOPLE AND HANDOFFS
   Who does each step: ___________________________________________
   Unofficial experts / routers: _________________________________

4. VOLUMES AND TIME (ranges; source: said / counted / measured)
   Cases per day (slow day - bad day): ___________________________
   Time per case (easy - hard): __________________________________
   Share of cases that are hard: _________________________________

5. DATA
   Where it lives (system, format): ______________________________
   Owner who grants read access: _________________________________
   Owner who approves changes to the workflow: ___________________
   How to get access, and how long it usually takes: _____________

6. WHAT "BETTER" MEANS TO THIS STAKEHOLDER
   ______________________________________________________________

7. THE FEARED FAILURE
   Worst thing that could happen if a machine helped: ____________

SUMMARY BOX (complete once, across all interviews)
   Stated problem:   ____________________________________________
   Observed problem: ____________________________________________
   Evidence:         ____________________________________________
   Lever it moves:   ____________________________________________
   Confirmed by sponsor (name, date): ___________________________

按合成案例填好的版本。这些区间属于合成案例，而非某家真实的保险公司。

DISCOVERY INTERVIEW GUIDE (merged)
Engagement: P&C insurer, 30-day paid pilot   Interviewer: FDE
Stakeholders: COO, claims director, adjusters (auto FNOL),
contact-centre head, claims-platform IT, model risk

1. BUSINESS LEVER
   Number to move: claims cycle time (COO; reported to the board)
   Stated request (IT, via sales): chatbot for policyholders

2. CURRENT WORKFLOW (observed, auto first notice of loss)
   Trigger: documents arrive in shared inbox + scanning queue
   Steps: open -> identify type -> match to claim -> route to team
          -> first action by assigned adjuster
   Workarounds: personal tracking sheets; senior adjuster asked
                about unclear documents

3. PEOPLE AND HANDOFFS
   Adjusters sort their own intake; misroutes bounce between teams
   Unofficial router: one or two senior adjusters per team

4. VOLUMES AND TIME
   Share of adjuster day spent sorting: about 30-50%
     (said, then counted during the visit)
   Status calls tied to claims with no first action: most of a
     sampled set (counted from call reasons)
   Time-to-first-action: not reported; derivable from the week-1
     claims-system timestamps (said, then checked)

5. DATA
   Claims system (on-prem); document store (separate)
   Read-access owner: claims-platform IT lead
   Change approver: claims director; model risk for any automation
   Access route: replica requested; expected to take weeks

6. WHAT "BETTER" MEANS
   COO: shorter cycle time      Claims director: fewer misroutes
   Adjusters: less sorting      Contact centre: fewer status calls
   IT: nothing writes to claims  Model risk: nothing decides alone

7. THE FEARED FAILURE
   An injury or litigation-flagged claim routed to the wrong team

SUMMARY BOX
   Stated problem:   "A customer chatbot"
   Observed problem: FNOL documents wait to be sorted and routed by
                     hand; claims sit with no first action
   Evidence:         30-50% of adjuster day on sorting; status calls
                     cluster on claims with no first action
   Lever it moves:   time-to-first-action -> claims cycle time
   Not now:          chatbot; property claims
   Confirmed by sponsor: COO, mid week 2

填好的指南里有三行撑起了接下来的三章。“not reported; derivable from the week-1 claims-system timestamps”（未纳入报表，可从第 1 周的理赔系统时间戳推算）是“划定范围与首个成果”必须变成一个数字的基线。“replica requested; expected to take weeks”（已申请副本，预计需要数周）是“数据接入与集成”的开局。“nothing decides alone”（不能独自做决定）和最怕的那种失败，是“安全、治理与模型风险”的第一批输入，它们会变成一条在模型之外由代码强制执行的规则。

失败信号

这些信号出现得早，在第一周修正的成本很低。到第四周，每一个都已经变成了返工。

证据上的一个缺口应该直说。目前没有关于 FDE 需求挖掘本身的独立研究：它应该花多久、哪些方法能找到真正的问题、观察到的问题有多常被证明是对的。本章在 RAND 之后的所有内容，都是从业者和供应商的证词，T2 到 T4。它们彼此一致，这有一定价值，但这是推销这套方法的人之间的一致。附录 A 给本章的案例评了级。

进入下一阶段

当下面每一行都成立，就进入划定范围。如果有一行不成立，这个缺口就带着负责人和日期进入范围文件的风险清单。

• 观察到的问题已和客户说出的问题并排写下，附有证据，并且发起人已书面确认观察到的版本。
• 工作流程是通过观察画出来的，你观察过的人已经纠正过这张图。
• 工作流程中每个系统的数据所有者都已写明，第一份权限申请已经发出。
• 基线可以测量：你知道要数什么、在哪里数、谁会允许你数。
• 每个干系人群体对“更好”的定义和最怕的失败都已记录，冲突已摆给发起人看。
• 原始需求有了归宿：要么在观察到的问题之内，要么在“暂不做”清单上。