# 从《FDE案例100》提炼的分析经验与做事方法

整理：白牙 · Baiya Lab｜2026年10月4日

[返回FDE专题](https://baiyalab.com/topics/fde)

## 阅读范围与结论边界

来源为Datawhale《FDE案例100》（[本次分享版本](https://baiyalab.com/downloads/fde/datawhale-fde-cases-20260906.pdf)），前言日期为2026年9月6日。文件共246个PDF物理页，正文使用1—243的印刷页码。**当前文件实际收录24个编号案例，并非100个。**本文覆盖这24个案例的正文，页码均指书内印刷页码，PDF阅读器中的物理页码通常需加1。

这是一份实践访谈集。文中的收益和效率数据属于受访者或项目方报告，部分项目尚处原型、POC或早期上线阶段；它们适合帮助形成判断和设计验证，不能视为所有企业都可复现的因果结论。下面的通用流程、检查表和计算口径，是基于案例的综合提炼，不是原书提供的一套统一标准。

最核心的认识是：一项技术能力要形成业务价值，必须经过问题定义、流程重组、数据与规则整理、现场执行、组织采纳和效果验证。项目中任何一个环节断开，都可能让一个技术上正确的方案无法产生实际结果。

## 一、分析问题：从别人说的话，走到实际发生的事

### 1. 把抱怨展开成因果链，追到经营后果

案例8中，客户最初抱怨“ERP不好用”。继续观察发现，问题不是笼统的体验差，而是：

> 物料找不到 → 重复录入 → 数据更脏 → 错误或重复采购 → 库存积压 → 报废损失。

此时，语义检索才有了清楚的价值：减少本可避免的采购浪费。搜索速度、召回率只是中间指标。（案例8，77—85页）

可复用的分析顺序：

1. 现象：具体哪件事做不下去？
2. 行为：人现在怎么应付？
3. 机制：为什么会这样做？受什么条件限制？
4. 后果：影响了哪个下游环节？
5. 损失：最终增加了什么成本，错失了什么机会？
6. 验证：修复这个环节后，下游损失是否真的下降？

不要把“增加一个搜索功能”直接当作问题定义。先形成一个可以被验证、也可能被推翻的因果解释。

### 2. 用现场操作验证访谈，尤其观察等待、交接和例外

制造业培训案例通过跟随员工工作，发现访谈里说不出的高频问题。消防维保案例发现，一线人员在老板面前回答问题，容易偏离真实工作状态。跨境库存案例通过录屏演示，才把“接两个系统”的需求展开为物流、补货、供应商下单和广告联动。（案例1、13、22）

有效的调研问题应当具体到一笔业务：

- 请拿最近一次真实任务，从收到需求开始演示。
- 哪一步要等人、找资料、切换系统、复制粘贴？
- 上一次返工是为什么？谁发现的？
- 什么情况必须请教某个资深同事？
- 做到什么程度，下游才愿意接收？

老板、中层和一线员工各掌握一部分事实。需要把他们的说法与操作记录、业务样本放在一起核对。

### 3. 先理解旧办法为什么有效，再找它失效的条件

书中许多旧流程曾经有效：少量订单可以靠老板判断，少量SKU可以靠Excel，少量新人可以靠师徒带教。随着规模、复杂度、人员流动或市场压力变化，原来的方法才成为瓶颈。

案例22保留了客户原来的补货公式，只改造人工搬运数据的环节；案例4保留GIS工具和地图工作台；案例20保留原有ERP，重新组织经营信息。

这提醒我们：调研应同时问“哪里不好”和“哪些东西不能丢”。要保留经过业务验证的规则、专业工具和操作习惯，把改动集中在真正失效的部分。

### 4. 从整条链路定位瓶颈，区分操作慢、等待长和判断难

案例5的达人履约慢，不仅因为运营催得不够，还因为达人不知道怎么拍。提供拍摄脚本，才直接帮助对方完成任务。案例19将包装的基础检查前移，减少材料进入正式审核后再返工。案例17的图纸解析必须连到工艺、物料、成本和报价，才能影响售前响应。

因此，不能只统计某个动作节省了几分钟。应拆开观察：处理时间、排队时间、往返沟通、返工，以及下游是否仍被另一个瓶颈卡住。

**一个局部更快的系统，未必让整件事更快完成。**

### 5. 先判断问题类型，再选工具

案例18首先补CRM、数仓和BI；案例13先解决流程记录与数据沉淀；案例4和6把精准空间计算交给专业工具或算法。

据此可以先做以下分类：

| 实际缺口 | 优先考虑的工作 |
|---|---|
| 没有记录，资料散落 | 建立业务记录、标识和数据归属 |
| 数据存在但口径不一 | 统一定义、单位、关联关系与数据来源 |
| 规则明确，操作重复 | 公式、脚本、工作流、RPA或现有软件 |
| 图片、文本等输入难以结构化 | OCR、多模态模型、信息抽取 |
| 需要理解表达、检索经验、生成初稿 | 大模型配合知识与上下文 |
| 需要专业责任、关系判断、利益取舍 | 人负责决定，系统提供依据 |

分类可以混合使用。一个项目是否值得做，与其中用了多少AI没有必然关系。

## 二、推进事情：把不确定性逐步换成可观察的结果

### 6. 第一单同时是价值验证和合作验证

零售对账案例在客服、竞品分析、对账等需求中，优先选择价值容易计算、涉及人员较少、能快速看到结果的对账。城市规划从全市收缩到一个具体单元和两条业务流。海外快消先做中国一条产品线，跑通之后再扩展到越南。（案例10、4、24）

选择第一个场景时，应同时考察：

- 痛点是否真实、高频，是否占用稀缺人才或影响收入成本。
- 数据能否取得，结果能否进入现有系统。
- 谁愿意试用，谁能协调资源，谁确认效果。
- 能否较快完成从输入到实际使用的完整链路。
- 出错能否发现、接管和修正。
- 交付与维护成本是否可承受。

第一轮的目标不是证明覆盖面，而是获得一组可信事实：问题成立、方案有效、有人愿意用、双方能协作。

### 7. 缩小范围，但保留完整结果

小范围试点仍应包含真实输入、处理、确认、交付和反馈。只做“识别成功”的Demo，却让员工继续抄结果、补上下文、重新录入，无法验证业务价值。

案例4要求核心成果“一文、一图、一表”能够形成；案例24要求数据能进入、数字可追溯、结论能进入周会。两者都在保留最终交付的完整性，同时收缩地区、数据或场景范围。

可采用的原则是：**横向少覆盖一些对象，纵向跑完一件真实工作。**

### 8. 把专家判断拆成条件、依据和例外

案例1梳理老师傅的知识地图；案例3把律师的分析框架转成流程节点；案例17还原物料映射、工艺选择和报价逻辑；案例19保存包装驳回记录和整改经验。

仅收集最终文档不够。更有用的知识记录包括：

| 要素 | 要追问的内容 |
|---|---|
| 触发条件 | 什么情况下需要这个判断？ |
| 必要输入 | 缺哪些信息就不能判断？ |
| 判断依据 | 看哪些证据、规则、历史记录？ |
| 决策理由 | 为什么选A，为什么排除B？ |
| 例外边界 | 什么情况下这条经验不成立？ |
| 处理结果 | 后来是否有效，谁确认？ |

这套方法同样适用于团队培训、业务交接和复盘。要沉淀的不只是“答案”，还包括得出答案的条件。

### 9. 按错误代价分工，同时设计人工接管

城市规划中，模型理解任务，GIS完成计算，人作最终决定；装车中，算法计算摆放，工人依据指导图执行；非标报价中，模型抽取信息，企业物料和规则库支撑报价，人工校准后对外输出。

案例5保留重要达人的人工商务沟通，因为错误沟通可能损害核心关系。案例21保留设计师调整专业参数的入口，因为最终责任仍由设计师承担。

“人在回路中”必须具体：由谁检查、检查哪些项目、何时升级、看什么原始依据、如何撤回或修正。仅在流程图上放一个“人工审核”节点，还不足以证明风险和工作量可控。

对低风险、易撤回的任务，可以先实验再收缩自动化范围；对外报价、专业设计、重要客户沟通等任务，应先明确边界和责任，再逐步增加自动化。

### 10. 交付形态由现场决定

案例3把聊天框改成案件工作台，解决反复解释案件背景的问题。案例4围绕地图设计交互。案例6放弃让工人频繁操作三维界面，改成编号、截面和装载顺序指导图。案例9把入口放进员工已有的钉钉使用流程。

产品是否好用，应检查：它有没有减少步骤？是否保留长期任务的上下文？结果能否被下游直接使用？现场是否具备使用设备、网络和界面的条件？

先进的内部实现，可以对应非常朴素的外部交付。

### 11. 把组织参与当成实施条件

案例4指出，高层发起人与实际能够协调多个部门的人，可能不是同一人。案例14经历技术底座建好却没人使用后，增加知识萃取、培训及人事参与。案例17在立项时讨论释放的人力如何安排，随后调整职责和KPI。

至少要明确四类角色：

- 业务负责人：决定目标、取舍并确认收益。
- 执行协调者：推动数据、接口、试用和跨部门合作。
- 业务专家与使用者：提供规则、检查结果、持续反馈。
- 运营维护者：上线后处理故障、更新知识和规则。

同时问清：谁受益，谁增加工作，谁感到利益或地位受影响。员工不配合，有时是方案给他增加负担，或者收益分配没有说清。

这些案例不意味着每个小项目都必须由老板亲自推动。需要协调的权限，应与实际流程和组织改动的范围相匹配。

### 12. 用真实使用形成改进循环

案例1把调研中发现的高频问题直接变为测试集；案例2持续补充真实异常材料；案例17把人工校准结果回填；案例24收集正常、异常和边界样本。

建议每次错误都记录：输入、当时规则与版本、预期结果、实际结果、错误原因、修正方式以及复测结果。人工修改也需要经过确认，不能未经校验就全部当作正确知识回灌。

这样，项目的下一版建立在具体证据上，交付团队和客户也能逐步学会自己定位问题。

## 三、评价效果：证明工作改变，而非只证明系统运行

### 1. 在开始时定义基线、目标和确认人

案例8从历史采购数据建立基线，由客户业务人员确认节省的价值。案例22交付后失去完整效果追踪，无法完整获得营收、广告成本和利润数据，这是很明确的反面经验。

建议区分三层指标：

| 层次 | 要回答的问题 | 示例 |
|---|---|---|
| 技术表现 | 组件是否可靠？ | 关键字段错误率、检索命中、执行失败率 |
| 工作流程 | 实际工作是否改善？ | 含人工复核的总耗时、返工率、实际使用率、积压量 |
| 经营结果 | 改善是否转成价值？ | 错误采购减少、净差异追回、有效订单增加、预算调整质量 |

评价时保留相同任务边界。不能把原来“完整交付时间”与现在“生成初稿时间”直接比较，也不能把试点最好的样本当作长期平均。

### 2. 节省时间、释放产能与实现收益要分别核算

案例10的对账除了省时间，也可能找回过去被忽略的差异；案例23尝试承接老板无暇处理的长尾客户；案例18关注销售省下的时间是否转向客户拜访。

可采用以下核算思路，作为项目测算框架，而非本书的原始公式：

> 净业务收益 = 已实现的成本节约 + 可归因的新增毛利 + 有依据的损失减少 − 新增建设与运行成本。

建设与运行成本需要包括数据整理、系统集成、培训、人工复核、维护和模型调用等。节省工时可以先记作释放产能；只有确实减少支出或转化为额外产出，才进一步确认经济收益，避免重复计算。

FDE团队也需要核算自己的交付和维护成本。案例20特别提醒：客户觉得有价值，不代表一个需要长期重度定制的项目对服务方就可持续。

### 3. 区分报告事实、预期和未验证部分

| 案例 | 原文报告的状态或结果 | 应怎样使用 |
|---|---|---|
| 2 车管所 | 单件全流程审核约15分钟降至3—5分钟，日均办件约七八百件增至1100件 | 项目方报告的业务变化；不能直接推广为其他机构的预期 |
| 4 城市规划 | 已跑通试点流程中，报告生成约10—20分钟 | 保留“试点流程”与后续推敲、交付边界 |
| 6 装载优化 | 完成原型验证；装车约5小时降至约2小时使用了“预计”表述 | 不应把预计现场效率当作已验证收益 |
| 7 研发转型 | 主案例未披露完整ROI；另一制造业客户三个小组有几天的短期统计 | 不能把不同客户、短期数据并成主案例长期结论 |
| 10 零售对账 | 上海个位数门店试点；差异同时有少收、多收 | 需核算净差异，不能把发现差异直接当作新增利润 |
| 11 外贸资料 | 仍在第一阶段，交付未全部完成 | 可讨论方法和已发生的使用变化，不宜宣称完整ROI |
| 12 电商素材 | POC、内部试用和持续迭代阶段 | 重点看可用性与一致性，规模化成效尚待验证 |
| 13 消防维保 | 持续推进，尚无大规模指标变化；报告避免一项约10万元采购 | 避免无效投入也是价值，但不能混同长期运行收益 |
| 20 经营透明 | 上线较短，尚不能证明利润和成本发生量化提升 | 信息更透明与经营收益应分别描述 |
| 21 建筑图纸 | 约30分钟生成初步结果，仍需设计师调整确认 | 不能说30分钟完成最终专业交付 |
| 22 跨境库存 | 物流照片处理报告由每日4—5小时降至1小时以内；后续财务数据不完整 | 时间改善可参考，完整经营ROI尚未证实 |
| 23 工程租赁 | 实践时间较早，商业模式仍在探索 | 增收是目标和价值方向，不应补造已实现规模 |
| 24 海外快消 | 数字经过脱敏；图示为demo数据 | 不把图示当生产证据，不把异常发现比例当整体准确率 |

书中不同案例不是统一抽样、统一口径的评估，不能把效率提升数字直接平均，得出“AI通常提升多少”的结论。

## 四、一套可直接使用的推进流程

以下是综合案例整理的实用流程，各步可以根据反馈返回重做。

| 步骤 | 具体行动 | 留下的成果 | 进入下一步的条件 |
|---|---|---|---|
| 1. 还原现状 | 跟随一笔真实任务，访谈上下游，收集成功与失败样本 | 当前流程、角色和等待点 | 能解释问题具体在哪里发生 |
| 2. 定义问题 | 画出原因到后果的链路，核对经营影响 | 一句话问题定义与价值假设 | 业务方认可问题及其优先级 |
| 3. 验证前提 | 试取数据、验证接口、对齐口径，确认资源与权限 | 数据清单、限制和依赖 | 核心数据可用，结果能被接收 |
| 4. 确定边界 | 选择少量对象或一条流程，划分AI、规则和人 | 试点范围与责任分工 | 能完成最小但完整的交付 |
| 5. 约定验收 | 记录当前耗时、质量、成本，确定测试样本和确认人 | 基线、测试集和验收标准 | 双方知道怎样判定有效或无效 |
| 6. 真实试用 | 先由业务骨干使用，再到小组；保留接管办法 | 使用记录、错误及反馈 | 输出达到业务标准，复核负担可承受 |
| 7. 持续评估 | 观察使用、返工、成本与业务指标，检查收益归因 | 效果记录与下一轮问题 | 改善持续存在，且投入合理 |
| 8. 扩展和移交 | 扩大覆盖，明确维护职责，培训内部负责人 | 规则、流程、样本和维护文档 | 客户能够继续运行与改进 |

暂停或收缩范围的合理信号包括：无法取得关键数据、没有人愿意试用、业务规则仍无法对齐、人工复核抵消了效率收益、错误代价难以控制、或持续投入超过可以证明的价值。此时应重新定义问题或调整方案。

### 一页立项模板

```text
我们准备改善的问题：
谁在什么情况下遇到它：
最近一次真实实例：
目前处理方式、频率、总耗时与返工情况：
问题造成的下游影响：
我们认为的根因及证据：

第一个试点覆盖哪些对象和环节：
这次明确不覆盖什么：
数据从哪里来，谁解释口径：
哪些用现有系统/规则，哪些用AI，哪些由人决定：
输出交给谁，以什么形式使用：
异常由谁发现、接管和修正：

上线前基线：
成功标准与评估周期：
谁确认效果、怎样持续取得数据：
新增建设、运行及人工复核成本：
什么情况下扩大、返工或停止：
上线后谁维护，给团队留下什么能力：
```

## 五、24个案例的经验索引

下表提炼每个案例的主要方法，不表示每个项目都已经完成或取得长期收益。

| 编号 | 场景 | 最值得迁移的经验 | 印刷页码 |
|---|---|---|---|
| 1 | 制造业经验传承 | 跟随工作建立知识地图；高频问题直接成为测试集；嵌入培训并陪跑 | 6—13 |
| 2 | 车管所材料审核 | 从驻场运维发现需求；串起识别、审核和执行；业务规则冲突交负责人取舍 | 14—23 |
| 3 | 诉讼律师协作 | 萃取专业思维；长期任务需要持续上下文；工作台承载真实交付 | 24—32 |
| 4 | 城市规划研判 | 缩范围、保完整结果；专业计算交工具；找到实际协调者 | 33—45 |
| 5 | TikTok达人业务 | 沿完整漏斗找瓶颈；帮助合作方完成任务；重要关系保留人工经营 | 46—54 |
| 6 | 跨境物流装载 | 优化须包含现场可执行性；方案呈现适配工人；算清业务计费机制 | 55—66 |
| 7 | 企业研发转型 | 个人熟练不等于团队能力；现场验证水平；共同设计协作文档与分工 | 67—75 |
| 8 | 工业物料与采购 | 从抱怨追到根因和财务损失；提前定义ROI；业务方确认价值 | 76—85 |
| 9 | 央企财务流程 | 区分判断与执行；监督、风险识别与RPA协作；从小场景争取支持 | 86—94 |
| 10 | 零售对账 | 按反馈速度选第一单；识别过去因核对成本过高而放弃的价值 | 95—104 |
| 11 | 外贸资料管理 | 网络、权限、文件关系影响落地；适配客户环境；让企业逐步独立 | 105—117 |
| 12 | 鞋服电商素材 | 个人工具转为组织生产流程；商用验收看商品一致性；沉淀公司资产 | 118—127 |
| 13 | 消防维保数字化 | 先识别监管系统约束；轻量改造；避免无效采购同样创造价值 | 128—134 |
| 14 | 国企工作流程 | 技术底座不等于采纳；知识萃取、培训、激励和内部建设者需要共同推进 | 135—144 |
| 15 | 本地生活脚本 | 把经验转为输入字段；针对商户参数化；生成、审核、反馈和回退形成流程 | 145—156 |
| 16 | 电信网络分析 | 按业务系统设计Agent；重视可重复性、数据正确性、成本和规模管理 | 157—164 |
| 17 | 非标制造报价 | 围绕稀缺专家减负；结构化输入连接企业规则；校准回填；分阶段推广 | 165—176 |
| 18 | 生物科技经营与销售 | 先补数据基础；把培训与上岗标准连接；让释放时间回到销售；建设内部团队 | 177—184 |
| 19 | 消费品研发与包装 | 记录决策上下文；让业务定义AI职责；基础审核前置；经验持续沉淀 | 185—195 |
| 20 | 制造企业经营透明 | 保留ERP，重组经营关系；异常主动提醒；方法可复用，数据语义需重做 | 196—205 |
| 21 | 建筑消防图纸 | 专用解析与规则引擎结合；初稿可调整；专业人员保留控制权与责任 | 206—214 |
| 22 | 跨境库存、补货与广告 | 用录屏澄清需求；实际验证API限制；打通后形成业务联动；提前设计效果追踪 | 215—224 |
| 23 | 工程租赁报价 | 按订单价值与复杂度分层；承接未被服务的长尾；底层复用、业务适配 | 225—232 |
| 24 | 海外快消动销 | 先统一业务口径；数字可追溯；窄范围贯穿决策；用异常与边界样本评估 | 233—243 |

## 六、值得保留的几组张力

**深入调研与快速试错。** 案例8有较长的问题诊断，案例7强调快速原型。两者可以结合：对不可逆承诺、关键依赖和规则先查清，对界面、交互和假设用低成本原型尽快验证。小实验用于学习，不能替代上线所需的可靠性。

**适配现状与改变流程。** 保留现有工具可以降低采纳成本，但跨系统搬运、反复等待和重复录入仍需要改造。可保留熟悉的入口，把后台职责、信息流和异常处理逐步调整。

**标准化与因地制宜。** 可优先复用诊断方法、验证流程、通用组件、评估工具；客户自己的数据口径、业务规则、责任关系需要重新确认。案例8、19、20、23共同支持这种分层复用思路。

**业务理解与技术能力。** 书中经常强调业务、组织比模型更难，但不能因此推断技术不重要。案例16的稳定性与成本、案例21的专用图纸解析、案例22的接口限制，都说明工程能力决定方案能否长期运行。

对个人能力建设而言，可以把这些经验落实为六项反复练习：观察真实工作、追查因果与价值、拆解流程和判断、做小范围验证、协调使用者与负责人、用结果复盘并沉淀方法。每次项目都留下这六类记录，经验才有机会变成下一次可以复用的能力。