FDE 理需求：九个常见陷阱

过去几个月的 FDE 实践里，理需求阶段反复出现同一类问题：问题定义没写清，机会方案从第一步就偏了，方案做出来不达预期，最后没能成为客户决策时的依据。现在以 X 科技服务公司 Staffing 为例，来复盘一下、总结一下这些常见陷阱及规避方法。

1. Agentic Enterprise 转型和 AI-Native 机会

从 2024 年人和 AI 的「Co-intelligence」到今年的人和 AI 的「Co-existence」，企业和 AI 的关系变了一层：AI 从「帮你把活干得快一点的工具」，变成「在流程里替你把这段活干完的人」。当前的 Agentic Enterprise 转型做的正是这件事——按人和 AI 共存的思路重排业务流程里的人机分工，让业务模式真正长在 AI 上，成为 AI-Native 的业务模式。

如图所示，上面那一版是 AI 在做点状辅助，人执行每一步；下面那一版是 AI 进流程干活，人只做交接和大单策略。右边两行小图把这两种做法抽象了一遍：一个五步照旧、只在一格上挂个 AI；一个把流程重排成四步，中间留一道人工检查。前者产能被人力卡住，后者按 AI 的产能重排。企业已经不再验证 AI 能不能做，而是希望通过 AI 尽快拿到业务结果。

2. FDE 理需求的方法

Inspire 团队在过去一年的实践中沉淀出一套 FDE 四步法：理需求、挖知识、建本体、生智能。理需求是起点，也决定了能不能找到 AI-Native 的机会。

理需求的三段流程，和每一步容易踩的坑，合成一张图看：

看着是熟悉的流程——这套方法本身不新鲜，难的是每一步做到什么程度。真正落地时问题也往往出在细节，而且不是个别 FDE 才会踩：工作十年的伙伴一样会掉进去。

接下来以 X 科技服务公司 Staffing 业务为例，逐条看看这些陷阱，以及怎么避开。

3. 九个常见陷阱

陷阱 1 · 方案跑在理需求前面

表现：第一轮沟通，听完客户对业务的原始想法，客户一强势、一施压，就当场开始想 Agent 技术方案，答应立刻启动 POC。

后果：方案照着客户第一句话搭起来，范围和验收标准也跟着那句话走；真去调研，需求一变，方案推倒重来。更常见的是方案做完才发现瓶颈在另一段流程，POC 验收过了，进不了生产。

反例：

销售带着 FDE 小李跟客户线上沟通。客户是 X 科技服务公司的 Staffing 负责人。

客户：“我们公司人很多，售前和项目机会也多，每次项目需要人，Staffing 团队就开始各种找人，有时候好几天找不到合适的，业务方抱怨我们找人太慢，耽误项目进度。现在 AI 技术已经成熟了，就是想让 AI 来帮我们找人，我自己私下试做了个简单的 skill，还挺有效果。请你们来，希望能帮我们快速落地。”

FDE 小李：“好的，没问题。我们可能需要先做个调研，仔细了解下业务的痛点，再出解决方案……”

客户：“我们公司也不大，Staffing 团队很小，我刚说的就是我们的痛点和问题了。目标也很明确，就是想用 AI 帮我们找人，希望你们下周就能拿出方案。”

FDE 小李：“哦……好的。那我们内部尽快讨论一下，尽快准备个方案，下周再约您……”

正例：

FDE 小李：“明白，目标是让找人这件事快起来，别再耽误项目。不过我想先花两天做一次业务摸底，不占您团队太多时间。”

客户：“两天？情况很简单，刚才都说了。”

FDE 小李：“您说的我记下来了，但可能有些拿不准：一个岗位从提出来到人到位，现在平均多少天；每次要安排人的需求大概有多少，我们找人的时候匹配依据都是什么，这些信息都在哪里如何利用？当前找人的卡点到底是没人、没合适的人，还是排期定不下来？这些问题搞不清楚，方案容易做偏，做完也用不起来。”

客户：“那你两天想干什么？”

FDE 小李：“看三样东西：最近三个月的排期表、岗位需求单、找人时的沟通记录，再找负责调配的同事、相关的业务负责人分别做些深度沟通。两天后我们会把问题定义、可落地的框架方案、一期范围、预期成效都在方案里说明。然后，我们再探讨下一步，您看如何？”

客户：“行，那就两天。”

避法：我们的做法是见客户之前先把桌研做掉，三件事查清楚：谁提的需求、背什么指标；这家公司靠什么赚钱，可计费人月乘人月单价；要素从商机到进场怎么转。见面时我们一般不跟客户争「要不要调研」，而是直接说这两天能拿到什么——业务桌研、价值流、现状泳道图、8 要素问题定义、场景画布、To-be 流程走一遍，方案页放到最后写。

先争取 2 天换一版不会返工的问题定义，这个账客户算得过来。等真正深入了解客户现状之后，往往会冒出更多他们原来没想清楚的问题，这时候再争取进一步的分析讨论，直到问题完全定义清楚，再进方案阶段。

陷阱 2 · 忽略业务模式差异、忽视识别核心业务 KPI

表现：不先判断这家公司靠哪条业务线挣钱，直接按行业模板、或者按客户自己最熟的那条线画一版价值流，就往下推方案。同一个客户身上常常并存两条：自有顾问为主的高端咨询，和外包为主的人力池。整份材料也没有一条能挂到收入上的北极星，指标都停在过程阈值。

后果：版本选错，链条的起点、重心和 KPI 全跟着错。自有为主的价值流从人才能力建设起步，走到客户经营与复购，问的是「我们的能力值多少」；外包为主从人力池溯源起步，走到回款核销，问的是「能多快把人对上、守住多少毛利、多快把钱收回来」。闲置怎么算、毛利由什么决定、风险落在哪，也是两套。机会点最后会落在不是主业务的那一段上。

反例：拿人力池那套套在客户身上：价值流从供方准入和人力池溯源起步，KPI 用人月净毛利额、自有员工计费利用率、外部人力转化率、关键岗齐套率、账期回款率。可这家客户的核心业务是自有顾问为主的高端咨询，客户结构是 130 家五百强，命门在交付质量、客户复购和能力资产的厚度，不在这几点上。

正例：先分清业务线，按这家客户为主的自有咨询那版画：价值流从人才能力建设起步，走到客户经营与复购，KPI 换成年度可计费收入、人月毛利率、客户复购与增购收入占比、项目按期交付率；再把交付链上的四个环节圈成聚焦范围——可行性与资源预判、团队配置与角色定义、项目成员评价与能力回写、能力盘点与画像维护。

避法：现在见客户之前，我们会先用行研把业务线摸一遍：战略大客户还是覆盖性市场，电商直营还是商业分销，大货代直客还是中小型电商，一家公司往往几条并行。按公开信息先排一个主次假设——收入占比、客户结构、招聘口径都看得出来——再拿这版假设去现场验证：哪块为主、占多少、增长押在哪条线上。验证完再决定按哪条线画价值流、KPI 落在哪一段。

陷阱 3 · 现状流程过细，一下跳入到了 L4/L5 层

表现：拿到一段访谈或一段群聊，直接把系统操作当成流程画下来——打开哪个系统、导出哪张表、翻哪个文件夹，格子填得满满的，却没有价值段和阶段这一层。

后果：泳道图成了操作截图，能看到的只有「谁在点哪个系统」。从这一层往上找机会点，找到的也只能是「把这个操作做快一点」——AI 停在给个人配助手的层面，替他把某一步点完。供需信息不在同一个窗口、占用没有统一记录、结项没人回写，这些真正卡住业务的瓶颈在图上根本看不见，也就谈不到按 AI-Native 的方式重构流程。跨部门协作同时消失，所有格子都长在一个人身上。

反例：同一个 Staffing 找人场景，画成了 13 个操作动作：群里口头提需求 → 手抄进自己的 Excel → 人才库按岗位名搜 → 翻共享盘找「v3-终-改」→ 飞书私聊问档期 → 逐份打开简历 PDF → Excel 手工核证书 → HR 系统查在职 → 排期表填色占位 → 发邮件等确认 → 群里回一句。五条泳道里还有一条叫「系统与台账」，人和系统混在一起。读完知道谁在点什么，但说不出堵在哪。

正例：同一个场景，站在组织整体看：对着价值流圈出的四个聚焦环节展开，拆成 5 个 L3 环节、5 条跨职能泳道——客户与销售、项目 PM、资源经理 RM、顾问、People Partner，15 个业务动作。每张卡写清判断依据和交给谁：「销售给交付假设 → 交 PM 与 RM」「RM 给可行性结论 → 交 PM 与销售」「PM 定义角色边界 → 交 RM 组队」，结项后 PM 的评价再回流成能力更新。整张图里没有系统，也没有「谁点了什么」，但每一格都是一个能拿去做决策的点。

避法：这类图我们现在的做法是先把 L3 做完，不急着下钻：泳道按角色分，不按系统分；每个环节写清谁做判断、交给谁，让整条链路先立得住。L4/L5 并不多余，理解实际业务场景和痛点，还是得下到那一层，区别在于它是按需展开的——哪一段要判断能不能交给 AI、要估算耗时、要找卡点，再往下钻，一格一格问「这一步为什么慢、慢在哪」。顺序反了，骨架就立不起来了。

陷阱 4 · 痛点只有简要的定性描述

表现：调研回来几张速记表，每条痛点一句展开描述，加个访谈对象就算完。表里不是没有数字——654 人的池子、3 人的团队、核对一个人要开五六个入口——但这些是组织和工作量的口径，不是痛点本身的频次、占比和耗时。

后果：痛点没有量，优先级只能拍脑袋，也说服不了客户。到收益测算时全是形容词，一问基线就答不上；方案做完没有可验收的口径，AI 上线后只能说一句「感觉快了些」。

反例：一份按访谈顺序整理的速记表——痛点简述、展开描述、访谈对象、备注，四栏齐全，看着挺扎实。可每条痛点都没有量化：一次匹配到底多久、一周发生几次、返工一次损失多少，备注栏写的是「感受值，未计时」「未统计」「为印象值」。表底下的结论，直接跳到「引入 AI 智能匹配助手」。

正例：同一批访谈重做一遍，先按角色收现象，再按环节分四组——

岗位需求侧：只有角色和 grade；岗位快启动才通知 HR，窗口被压到 2–3 周；员工看不到在招岗位，也没渠道表达意愿
人员能力侧：标签静态且只增不改、可上岗时间不准、出差驻场意愿没字段、动态判断只在 RM 记忆里、简历与标签靠结项后手动更新
匹配与排布侧：15–20 个岗位 × 1000 人 × 技能、驻场、档期、外招多种约束，只能靠脑子一起盘；需求问清后仍要跨五六处翻；人找到了被别的项目抢；错配后中途挪人找更优解
产能运营健康度：Q1 闲置集中、旺季仍有用不满的产能且看不见；健康度要到周期结束复盘才发现；Q3–Q4 紧张期需求与 bench 对不上

每条都写清「什么情况下才会发生」，再分三档记数据：这类场景占全部场景多少（跨技术栈岗位 40–50%、需驻场岗位 30–40%、每 5 岗 1 次≈20%）、在场景里发生多频繁（每岗 3–5 轮、季度 150–225 次）、单次和累计影响多大（单岗 0.5–4 小时、年 300–3,600 人时）。15 条现象、每条 8 列，才排得出先后，也才敢写进收益测算。

避法：我们现在的做法是先把类型分清，不把三件事混成一个「忙」——高负荷是量与时间不够（3 人撑 700 人、窗口只剩 2–3 周），加人能缓解；高耗时是单件事本身步骤多（一个岗位翻 3–8 份简历、开五六个入口），加人也不变；高认知负荷是换个人做不了、要在脑子里同时装很多信息（十几个岗位的优先级、谁快释放、谁得外招、错配后从哪几个人里重排）。三者解法不同：加人、改流程、把隐性判断和多维权衡写进系统。

访谈也别只找 RM。客户与销售、PM、员工本人、HR、管理团队各问一遍，同一件事在不同角色嘴里是不同的现象；先把现象收全，别急着归因，再按类型量化——高负荷问人均扛多少、一年几个季度紧张；高耗时问哪个场景、占多久、占多少；高认知负荷问一次要同时权衡多少变量、换人还能不能做；来回往复问几轮、每轮多久；系统瓶颈问它逼出了多少次人工二次核实。管理团队那一路要问「哪部分产能没被用满、损失多少、谁看得见」，别只问「忙不忙」。数字要么来自系统导出，要么标「待访谈回填」。

陷阱 5 · 围绕表面痛点开始做方案

表现：根因一栏写成「靠人、靠经验、靠手工」，或者写成「缺乏 XX 化」，方案就顺理成章变成把手工自动化。

后果：方案把手工作业搬进系统，手工背后的口径缺失、机制缺失原样留着；上线后错配照旧，只是错得更快。根因停在现象，也排不出谁是真源头——下一节挑主攻方向时，只能凭哪个角色喊得响。

反例：不拆段，从「定一个人要一周」直接往下问五层。第一层答「流程太长、环节太多」，把现象换了个说法；第二层答「大家都忙，没人及时处理」，把锅扣到人身上；问到系统，答「让大家填，大家不填」；问到需求，答「客户改来改去」；最后落到「多招两个 RM」。四张卡轮流出现，共同点是每一层都问不出下一层。具体说法见下图左列。

正例：先按段时间拆开——澄清需求 1–2 天、找人并反复沟通 1–2 天（难岗 3 天以上）、确认与定人 3–4 天。每段单独往下问，每层都要掏出一个上一层没看到的客观事实，三段各问出各的落点。完整问法见下图右列。

避法：反例的问题不在措辞，在链条断在现象层。某一层的答案如果是重说现象、把锅扣到人头上、归到验证不了的外因，或者干脆给个对策，下一问就接不下去了——我见过的几次，链条都是这么断的，最后落在「加人、培训、拉群」这类不动系统的地方，钱花了，缺口还在。

要问对，四步：

先拆段。一周不是一个问题能问完的，澄清、找人、定人各算各的。
每层要新事实。答完这一层，手上应该多了一个上一轮不知道的客观情况；没有，就是没问到。
四张卡退回。出现甩锅、复读、玄学、绕路，退回上一层换问法。
落点先写「缺什么」，别写「做什么功能」。问到「系统里没有这条信息」或「没有人做这一步」就到头；落点写成「缺一步转换」「缺一个维护机制」「缺一张能看全局的承载」，具体用什么补，等方案阶段再谈。

陷阱 6 · 把个人痛点当成业务痛点

表现：访谈里 RM 说「我最大的问题就是找人麻烦」，这句话被当成结论。方案定义成「输入岗位名和职级，AI 快速给出候选人名单」，范围只覆盖「找人」这一个动作。

后果：两条。一是把症状当源头——找人耗时，很大一部分不是这一步造成的，是上一节的根因没挖到，把下游环节当成了病灶；只优化找人，等于在堵住的路上给最后一段加宽车道。二是账算不过来——单点提效按年折算只有几个人月，投一两百万回收期十年以上；形态也退回「给个人配助手」。

反例：RM 的原话是「有个岗位需求，我找人特别麻烦，最好能让我找得更轻松」。方案就照这句话写：

范围：一个对话框，输入岗位名和职级，输出候选人名单
价值：单岗筛选从 0.5–4 小时压到 10 分钟

按年 600–900 次排布算，一年省 200–3,400 人时，折合 1–19 人月；客户自己按更保守的口径算，一年约 3 个人月。按 3 万元/人月粗算，一年省不到 10 万，项目投 100–200 万，回收期十年以上 [推断]。更要紧的是名单出来还得人工核：岗位需求还是只有角色和 grade，能力标签还是上一代，可上岗时间还是不准——核的功夫一点没少。

正例：根因挖出来之后，还要在几条之间挑主攻。按「影响面 × 频度 × 累计」排一遍：

需求侧缺能力要求：占新岗位 60–70%，每岗 3–5 轮澄清，前置拉长 3–5 天
供给侧标签不可用：跨技术栈岗位 40–50% 对不上，核心角色返工 3–5 次

这两条覆盖的岗位最多、返工最贵，才够当主攻。方案因此改成动这几处：需求进来先按能力项、等级、硬约束结构化；结项自动回写能力；匹配按能力项而不是岗位名。

价值口径也不再只算省时间：一次匹配到位率 50% → 75%，首月调整率 20% → 10%，一年约 300 个进场岗位里，返工从 14–28 人月降到一半；澄清与找人的工时按 3.1 那份定义算，合计 9–41 人月/年。同样的钱，买到的不是一个动作省 3 人月，是一整段流程少返工。

我们后来的做法，是三件事同时往前推，缺一件都容易选偏。

先把调研范围打开。如果一开始做现状流程只围着一个角色转，他嘴里的「繁琐」就只是他那一段的繁琐。Staffing 是多部门、多岗位协作的一条链，从 L3 看下来，各角色痛点的密度和影响面都不一样——RM 觉得最痛的，未必是整条链上最值钱的。这一步花的时间，通常比后面挖根因还多。
访谈横向铺开，再往下挖。同一件事问客户与销售、PM、员工本人、HR、管理团队。挖下来常会发现，某个角色在自己环节感到的痛点，源头在上游；这种时候我们一般先动上游，因为它同时解释了好几处现象。
落点写成问题定义，⑧看整体业务。按八要素写，累计影响算的是整条业务，不是单个角色省了多少时间。如果算出来跟项目一开始盯的业务目标和 KPI 关联很弱，我们一般会退回去重挑，而不是硬凑一个数字。

陷阱 7 · 没理解 AI 能力边界，幻化「X Agent」解决一切

表现：一句「上一个 Agent，这个问题就解决了」。哪一段是数据的事、哪一段要改流程、哪一段交给模型、哪一段得靠预测这类决策 AI、哪一段必须人拍板，全没写。

后果：数据还没齐就上模型，输入是空的；流程缺门禁，AI 算完没人认；证书、驻场、语言这类硬条件交给模型，错一次就是交付事故；该拍板的地方没设闸门，责任落不到人。最后方案既验收不了，也讲不清价值。

反例：一句「我有 1 个 Staffing Agent，前面说的那些问题它都解决了」。黑箱一盖，四个问题全问不出来：哪一段是数据的事、哪一段要改流程、哪一段模型能做、哪一段必须人拍板。方案于是既没法报价，也没法验收。

正例：同一批根因，先按类型分手段再谈模型——数据缺失是数据治理，单列待办，它常是 AI 的前置依赖；流程不合理先改流程、加门禁，AI 只能在合理流程上放大；依赖少量专家经验的交给模型增强；操作量大又没法自动化的做替代；人力不足的让人往上做判断。落到机会点，方案假设要分四层写：前置的非 AI 动作、生成式模型做什么、决策 AI 算什么、人在哪儿拍板。

拿画像更新这条链路说：飞书的文档与证书变化能被监测到，项目结项自动触发，画像跟着更新——但更新完得有人 review，不然错标签会被当成事实带到下一个项目上。让 RM 来 review 不现实，他未必了解这个人，于是改成 People Partner 每阶段复核一次，这里多出来的是流程动作，不是模型能力。模型干的是解析 SOW 生成岗位能力要求、从证书、博客、项目总结里抽能力项回写标签；等级判定和冲突计算交给规则与决策 AI；确认与复核留给人。

避法：我们现在写机会点，会先做这三件事。

按根因类型分手段，再谈模型。数据缺失和流程不合理这两类，我们不会写进 AI 能力清单——它们往往是模型能跑起来的前提，不是模型能干的事。
方案假设拆成四行：前置的非 AI 动作、生成式模型做什么、决策 AI 算什么、人在哪儿拍板。四行写不齐时，我们通常先不排期，因为那多半说明这一段还没想清楚。
拿模型的能力清单逐个对任务（上图底那一排）。对不上的先放着——硬塞进去，验收时最容易被问住。

陷阱 8 · 方案只考虑近期落地机会，忘了初衷是重构流程

表现：立项时的说法是「让 RM 找人快一点」，方案就停在「输入岗位需求，输出候选人名单」。最初想做的那件事——把 staffing 整条流程按 AI-native 重排——ship 的时候没人再提。

后果：流程一点没变，只是某一格快了几分钟；人的动作一个没少，AI 在旁边多站了一步；更麻烦的是没有路线，一期做完不知道二期该干什么，第二年回头看还是同一个问题。

反例：和陷阱 1 那类是一回事，只是发生在交付阶段——需求方说「岗位需求来了，你直接帮我把人找出来」，我们做了个对话框：输入岗位和职级，输出名单。等于只在这条链的第 3 个环节挂了个东西，商机侧没有输入、建档还是空字段、抢人还得群里协调、复盘依旧不回填，四段原样没动。

正例：拿陷阱 3 那张泳道图的五个 L3 环节，一段一段问「这段在 To-be 里还需要这样吗、由谁来干」。问下来不是把五段平移成五段：原来的「找人」和「组队」并进 S5，「协调冲突」变成 S6 疑难坑位，「写总结」变成 S7 自动回流；另外新长出两段——S1 需求梳理和 S3 画像周更，因为原来根本没人做预测、也没人周更画像。每一段都是 Agent 先算一遍、人在自己那道闸门上做判断，一期只占中间四段。

一期不做全，但路线要写清。近期先在两个大客户的项目和一部分顾问上试点，把两件事做出来：proposal、SOW 和客户提的交付要求能自动落到每个客户项目的每个岗位上，以及基于新能力标签体系做画像的初始化和增量提取；中期把供需匹配做成沙盒，全部项目、全体员工铺开；远期把滚动预测接进来，四个场景连成一条完整流程，覆盖全公司。每一期都是数据、AI 能力、流程三条一起走，缺一条这期就白做。

避法：复盘这类项目，我们看三处。

To-be 是重排还是加挂。对着 As-is 逐段问「这段还需要吗、谁来干」，能删的删、能合并的合并——重排之后阶段数跟原来不一样，可能更少，也可能多出原来没有的两段。
每段有没有标执行主体：Agent 自动、人机协同、人做判断。数一下人还占几格，占得多的那几段基本没重构。
有没有路线。一期只交付一条能验收的窄链，二三期按依赖往两边扩；每期带范围和验收口径，写不出口径的那一期，我们一般先不排。

陷阱 9 · 方案价值没有量化，也没有对齐业务 KPI

表现：价值写成动作，或者写成形容词——「0.5–4 小时缩短到十分钟」「员工不用再手动更新简历和能力标签」「RM 不用主动找人，登录就能看」。都没有说清今年省了多少、哪个指标动了。

后果：这里有两层坑。第一层是根本没量化，立项评审说不清投入产出。第二层更隐蔽：方案做对了、四个场景都铺开了，价值还是停在「不用再干了」——听着都对，但说不出量，也没法在过程中盯 KPI，转型到底成没成，最后仍是一笔糊涂账。

反例：方案做没做对是一回事，价值这一栏还有四种掉进去的方式——

单点 + 只有动作：「0.5–4 小时缩短到十分钟，先找到几个 candidate」，次数没算、人月没折
单点 + 量错了对象：「一年省 3 人月」——就是陷阱 6 里算的那笔账，公司就三个 RM，管理团队没有感觉
全案 + 还是形容词：「员工不用再手动更新了」「RM 登录就能看」，方案对了，价值仍然是定性
全案 + 只量过程：「画像周更率 95%、需求填写完整率 80%」，业务方听完还是不知道公司哪里变好了

正例：方案铺开之后，把四个场景的价值合并成一套口径，再一路推到北极星——动作层是单岗筛选 0.5–4 小时 → 10 分钟；过程层是 600–900 次/年 ≈ 25–70 人月/年；业务层是一次匹配到位率 50% → ≥75%、签约到进场 3–4 周 → ≤10 个工作日、首月调整率 20% → ≤10%；顶层是「关键岗准时到位率」——基线待定，目标较基线提升 20%。合并的依据是前面两份问题定义各自的量化影响，指标口径取自产品概念设计里已经定下的那套。这里 25–70 人月是澄清、找人、换人三项合并后的数；陷阱 4 里那个 300–3,600 人时只算「找人」一项，两个口径别混着用。

避法：这三条是我们现在报收益时的做法。

收益写成一条链：动作 → 次数 × 单次 → 人月或钱 → 业务 KPI → 北极星。中间缺哪一段就补哪一段，补不出来先标待测，评审时如实说这一环还没数。
搭方案时，把几个高度相关的机会场景并成一个完整方案。单独一个很具体的机会，多半只是点状改进，做完对业务 KPI 没什么影响，业务方也感知不到；并成一条端到端的流程改进，才谈得上动业务。并完之后价值口径也要跟着并，不能几个场景各报各的。
每条 KPI 带基线、目标值和出处。基线没统计过就写「待测」——把目标值当结果报上去，第一轮评审就会被问回来。

最后

理需求做到位的标志，是能交出一份有深入洞察、有体系的产品概念设计与落地路线：问题定义、机会点、To-be 流程和分期路线能串成一条线，客户看完能据此做决定。

回顾这九个坑，我们自己在 FDE 训战营里都踩过，在不同企业的训战营里也见过不少类似的事例。不知道大家手上的材料中过哪几个，一起聊聊。

#FDE #理需求 #AI场景挖掘 #企业AI落地 #问题定义

[注：文中材料已脱敏，公司名与人员信息已隐去；文中的频次、耗时、人月、KPI 基线等数值均为脱敏后的虚拟数据，仅用于说明方法，不代表任何一家公司的真实指标。]