FDE 交付实战营

Appearance

第四章 数据诊断与 demo ​

4.5 案例：米兰零售商供应链 Agent ​

承前：本章的方法论讲完了——诊断三动作、四种脏数据模式、demo 内循环、MVA 承重结构。最后用一个完整案例收束：一位供应链数据科学家出身的 FDE，在米兰一家时尚零售商的物流部门部署了延误归因 Agent。AI 部分 5 天搞定；为了定义数据口径，开了几周的会、十几场工作坊，光一个"是否准时装车"的布尔字段就磨了五场。这个案例是本章所有内容的一手注脚，还附赠一个国内广告数据真实性的番外篇。

4.5.1 案例背景：35% 的延误无法解释 ​

案例的作者 Samir Saci 是一位供应链数据科学家，后来以 Forward Deployed Engineer 的方式工作。项目落在一家总部位于米兰的时尚零售商（作者按惯例匿名）的物流部门。

业务场景：12 名计划员（planner）管理门店库存，向仓库下订单并跟踪到店交付。一批货从米兰仓库出发，经卡车、机场、清关，最终抵达上海门店——链条上的每一步都可能延误。物流总监的原话是："超过 35% 的晚到交付无法解释（More than 35% of late deliveries are not explained）"。

更麻烦的是组织问题：每次复盘会开成甩锅会，仓库怪运输、运输怪仓库、空运代理怪清关。分析团队用 Excel 手工拉数据解释延误，报告出来时已经太晚，来不及定位根因。于是需求来了：要一个不带偏见的 Agent，直接从数据里做根因归因。

4.5.2 "AI 部分只用了 5 天" ​

先看让所有工程师心态失衡的部分：Agent 本身的搭建非常快。方案是 Claude 连接 MCP server 查询数据：把从订单创建到门店交付的所有时间戳汇成一张宽表，给 Agent 提供带业务语义描述的查询工具，让它用自然语言回答计划员的归因问题。

作者自己总结的时间分配大概是这样：编排和接入（AI 部分）以天计；数据定义与对齐以周计、以工作坊场数计。上线后的效果：分析师用几秒钟生成管理层报表、5 分钟内完成一次深度根因分析，6 名分析师产出的归因分析数量比过去更多、且及时到能采取行动。

这个 5 天 vs 几周的对比，就是 4.4 节"数据链路是第一承重柱"的最硬实证。接下来看"几周"里到底发生了什么。

4.5.3 无文档系统里的字段侦探 ​

第一类工作：读懂没有文档的系统。ERP、WMS（仓库管理）、TMS（运输管理）各自有 schema、字段定义和格式，从来没有为" harmonised data"（和谐一致的数据）设计过。

一个典型情节：作者问 IT 基础设施经理"订单创建日期在哪张表"，被指向规划工具的一张表，里面有两个长得都像日期的字段 HEUR_DTS 和 MANU_DTS——出自一位四年前就已离职的工程师的自定义开发。没人说得清该用哪个。

解法是把用户和基础设施团队拉到同一张桌子上，拿真实订单对比：规划员屏幕上看到的 vs 表里的数据。最后破案：order_creation_date 是个公式——CRIND='A'（自动创建）时取 HEUR_DTS，CRIND='M'（手工创建）时取 MANU_DTS。没有任何文档记录这个规则，确认它花了好几天。 这正是 4.1 节"数据字典比对 + 三角验证"的实战版：IT 说不上来、文档不存在、真相在一线用户的肌肉记忆和数据本身里。

4.5.4 五场工作坊定义一个布尔值 ​

案例里最著名的一段：定义"是否准时装车（loaded on time）"这个布尔字段。

听起来是最简单不过的字段：装车完成时间 ≤ 截止时间，就完了？仓库经理给的定义确实是两条：卡车到了货没备好 → 仓库负责；货备好了卡车没到 → 运输负责。

但作者多问了一嘴运输经理，得到第三种没人提过的场景："如果卡车是货代派来的，准时装车就不归我管。"——货代提货场景下，仓库是"连坐受害者"，卡车晚到不是仓库的错。于是这个布尔字段要同时处理三种责任场景，还得从 WMS 和 TMS 两套系统里各取数据拼出判定逻辑：

python
LOAD_ONTIME = LOAD_END <= 19:00        # 里程碑事实，三种场景共用

# 只有 LOAD_ONTIME 为 False 时才判责任归属：
if CTRL == 'SHP':                       # 场景1：自有车辆，车总在
    CAUSE = 'WAREHOUSE'                 # 仓库对备货和装车全责
elif CTRL == 'FWD':                     # 场景2：货代提货
    if PACK_END <= PU_ETA:              # 货在预约时段前已备好
        CAUSE = 'FORWARDER'             # 车晚到，仓库是连坐受害者
    else:
        CAUSE = 'WAREHOUSE'             # 货没备好，锅在仓库

跟两个团队开了五场工作坊，才对这个公式达成一致——光达成一致就花了一周。 作者的总结值得抄在工位上：Do not accept the first definition you are given. Ask the same operational question until every team gives you the same answer, then write it down. Definitions are part of the deliverable.（不要接受别人给你的第一个定义。同一个运营问题反复问到每个团队给出相同答案为止，然后写下来。定义本身就是交付物的一部分。）

这就是 3.4 节口径五要素的现实重量：一个布尔字段尚且如此，"复购率"这种分子分母型指标的口径会议要开三场，毫不奇怪。

4.5.5 用户验收测试：让使用者来"考"Agent ​

最后一段和 4.3 节的 demo 军规严丝合缝。作者的原话："A demo proves the builder can make the tool work. It proves nothing about whether the team can."（演示证明做的人能让工具跑起来，证明不了用的人能不能。）

所以验收方式是：请计划员带着他们每周真实在做的分析来考 Agent——比如"帮我分析上周因航班时段导致的延误"。这些计划员手工做了多年同样的报表，Agent 说出答案之前他们就知道正确答案长什么样；Agent 编数字、漏细节，会被当场识破。作者点破了这个设计精髓："我能验证工具返回的行数对不对，但只有他们能告诉我答案有没有用。" ——技术正确性和业务有用性的验收权，要交给不同的人。

4.5.6 番外：真实广告数据的 234 与 77 ​

再讲一个"数据真实性"的番外案例（国内 FDE 从业者转述的实践轶事，未见于公开报道，仅作教学警示）：某广告投放数据审计中，系统显示234 个在投的广告系列，人工核查后发现只有 77 个是"真的"——其余的或者是早已停投但状态未更新、或者是测试系列、或者是批量创建后从未真正投放的空壳。

近七成"数据"是幽灵。这个比例和青禾的诊断结论遥相呼应（虚假注册 1.1 万/新增 3.2 万，约三分之一）。如果 Agent 直接基于这 234 个系列做投放分析与预算建议，结论会全面失真，而且失真的方式极难察觉——每个数字单看都"合理"。

两个案例合起来给 FDE 的教训是同一句话：在把数据交给 Agent 之前，先问一句"这数据真的吗"——分布探针抓统计异常，样本抽查抓幽灵数据，两者都做，才敢开口。

4.5.7a 案例的方法论延伸：为什么"不带偏见"本身就是卖点 ​

值得补一笔案例里容易被略过的一个细节：物流总监的原话是"要一个不带偏见的根因分析"。这不只是修辞——在多方互相甩锅的组织里，"归因权"本身就是权力。谁来定义"是否准时装车"，谁就在甩锅会上占据高地；所以五场工作坊吵的不只是数据定义，是各方对归因规则的否决权。

FDE 在这类会议里的中立价值因此格外值钱：你既不属于仓库也不属于运输，你定义的公式双方都能接受（因为是你主持着把三种场景全部摆上桌面）。Agent 由此获得的信任红利——"AI 说的"比"对方团队说的"更容易被接受——是这类组织场景独有的催化剂。很多供应链、财务、质检场景的 AI 项目，真实卖点不是"更聪明"而是"更中立"：把归因从人际冲突变成数据问题，这本身就是巨大的组织价值。 你在售前识别这类场景时，听的关键词不是"我们要 AI"，而是"每次开会都在吵这个数字"。

4.5.7b 把案例钉回方法论 ​

米兰案例情节                ↔   本课程对应章节
──────────────────────────────────────────────
35%延误无法解释、甩锅会      ↔   3.1 北极星（可归因）
字段侦探（HEUR_DTS）         ↔   4.1 诊断动作三（三角验证）
五场工作坊定一个布尔         ↔   3.4 指标口径五要素
WMS/TMS 同一单字段不一致     ↔   4.2 双轨ID/格式不统一
计划员拿真实分析考Agent      ↔   4.3 demo军规四（用户走查）
AI 5天、定义几周十几场       ↔   4.4 数据链路是第一承重柱

方法论不是从案例里归纳出来的漂亮话，是无数个"5 天 AI + 几周定义"堆出来的血泪结构。你以后每接到一个"两周出 demo"的排期，都先想想那张图：你的 5 天在哪，你的几周又在哪——第二部分要是没排进去，到期日到了哭的就是你。

4.5.8 要点总结 ​

  • 米兰时尚零售商案例（Samir Saci 一手复盘）：Agent 编排以天计，数据定义以周和十几场工作坊计；一个"是否准时装车"布尔字段磨了五场才收敛，光达成一致就花一周。
  • 不要接受第一个定义：同一个运营问题问到每个团队答案一致为止，然后写下来——定义是交付物的一部分。
  • 无文档系统里的真相藏在一线用户的肌肉记忆和数据本身里，三角验证（IT/用户/数据）是唯一的破案手法。
  • 验收分两层：技术正确性你可以验，业务有用性只有真实用户能验——demo 证明的是 builder，不是 team。
  • 广告数据 234 个在投系列只有 77 个真的（从业者转述轶事）：幽灵数据比脏数据更危险，因为每个数字单看都合理。

参考资料 ​

（注："234 个在投系列只有 77 个真实"为国内 FDE 从业者转述的实践轶事，未检索到公开来源，仅作数据真实性教学警示；米兰案例所有细节以作者原文为准。）