看完24个企业AI案例，我发现：最难的工作发生在写代码之前
从Datawhale的24个企业AI案例里，提炼问题分析、现场调研、小范围试点和交付验收的方法。附原PDF、阅读笔记与项目分析单。
最近读了 Datawhale 的《FDE案例100》。名字里有100，但我手上这个版本实际收录了24个案例，涉及制造、物流、律师、城市规划、零售等行业。
我更想弄清楚的是：同样能调用模型、搭工作流，为什么有的方案能进入日常工作，有的只能停在演示里？
这24个案例给了我一个判断：AI项目里很难、也很容易被跳过的一段工作，是先把问题看清楚。它通常发生在写代码之前，后面还要靠真实使用继续验证。
一句“系统不好用”，背后可能是另一件事
工业采购的案例里，客户一开始抱怨ERP不好用。
顺着这句话，很容易想到改善界面、加个搜索框。继续往下看，问题才变具体：物料找不到，就重新录入；重复数据越来越多，又影响采购判断，最后变成积压甚至报废。
搜索只是其中一个环节。要改善的是这条链路造成的损失。
这让我觉得，接到一句需求，值得先追问：最近一次发生在什么时候？当时怎么应付？谁接着处理？最终多花了什么钱，或者耽误了什么事？
把这些问清楚，才有条件决定做什么功能，也才知道以后该拿什么证明它有用。
请对方做一遍，往往比再聊一小时有用
制造业经验传承的案例，通过跟随员工工作，找到了访谈里不容易说出来的高频问题。跨境库存的案例，则通过录屏演示，把“接两个系统”展开成物流、补货、下单和广告之间的协作。
人对熟悉的工作常常会省略解释。每天都在查资料、切系统、等同事，久了就把这些当作正常步骤。
所以我从中提炼了一种调研办法：请对方拿一笔刚发生的业务，从头走到尾。
重点看哪里在等人，哪里反复搬数据，哪里必须找某个资深同事，哪里做完后还会被退回来。这些地方，往往比一张功能清单更能说明问题。
算出了好结果，还要有人用得起来
物流装载案例里，系统需要计算货物怎样摆放。但到了装车现场，工人不方便频繁操作三维界面，交付最终转向了编号、截面和装载顺序指导图。
律师案例也有类似变化。长期案件需要保存背景和工作进展，反复在聊天框里解释上下文不够方便，于是改成了案件工作台。
读到这里，我会把“交付”理解得更具体一些：输出给谁？他在什么环境里使用？拿到以后，能否直接完成下一步？
模型生成了一份答案，只是流程里的一个节点。后面如果还要重新整理、补背景、抄回旧系统，真正的工作可能并没有减少多少。
第一版可以很小，但要做完一件事
城市规划案例把范围从全市缩到具体单元和两条工作流，同时保留了文、图、表的成果交付。海外快消案例先从中国的一条产品线开始，再考虑扩展。
这给我的启发是：试点可以少覆盖一些人、地区和业务，但要让输入、处理、确认和使用接得起来。
然后，在开始前约定怎样验收：原来完整处理一次要多久？人工复核算不算？谁确认结果？上线以后还能不能持续拿到效果数据？
跨境库存案例后来未能取得完整的经营效果数据，这个遗憾很值得记住。项目结束后再想证明价值，可能已经缺少条件了。
我想留下的一张分析单
把这些经验压缩一下，下次接到一个AI需求，可以先写清五件事：
1. 谁遇到了什么具体问题，最近一次实例是什么。
2. 当前流程卡在哪里，最终造成什么影响。
3. 第一版覆盖哪一段，哪些判断仍然交给人。
4. 输出由谁使用，异常由谁接管。
5. 上线前的基线是什么，谁来确认实际改善。
这些问题也适用于做工具、改团队流程。先知道要改变哪件事，再决定用什么技术。
原书是访谈案例集，效果来自项目方的报告，各项目所处阶段也不同。例如装车时间从约5小时降到2小时是预期，建筑图纸约30分钟指初步结果，还需要设计师调整确认。读的时候，最好把已经发生的变化和未来的设想分开。
我把原PDF、24个案例索引、完整阅读笔记和一份可复制的项目分析单，整理到了网站。可以从自己熟悉的行业开始读，再拿一个手头的问题试着填一遍。
原始案例：Datawhale《FDE案例100》，前言日期2026年9月6日。本文为白牙的独立阅读整理；主要参考案例1、3、4、6、8、22、24。