《FDE案例100》方法论特辑 · No.09｜数据优先：先数据后 Agent

别把脏数据喂给模型#

很多人以为“上 AI”就是接个大模型，把数据喂进去，它自己会理解。但案例给的答案恰恰相反：数据地基没打好，Agent 只会加速产出错误。 原来人工处理时，脏数据一处一处暴雷；换成模型自动跑，脏数据会被批量放大，错得更快、更整齐。所以顺序不是“先做 Agent，再补数据”，而是先把数据清理、标准化、治理好，再去谈模型和 Agent。

国企那位 FDE 说得更直接：很多企业知识根本没被沉淀、没被结构化。法务以前审核过很多合同，最后只留一份修改后的合同，中间为什么改、哪些条款关键，全在法务脑子里。“不能简单地告诉模型：你自己理解一下这个业务然后去做。”

数据清洗：从来就没有“标准”的数据#

现实数据永远不标准。制造业报价那个案例讲了另一面：客户发来的图纸有 PDF、有 CAD、各种扫描件，清晰度参差不齐。模型在干净样例上效果不错，一碰到手写标注、特殊符号、非标准图框，抽取字段就经常出错。

报价是对外的，一个尺寸抽错直接影响成本。他们的办法是给识别加一道人工校准兜底：业务人员只审模型把握不大的字段，审完把修正结果回填到模型和数据里。于是识别准确率随真实数据越滚越高，人工要审的部分越来越少。真实的异常样本，才是数据质量真正的磨刀石。

那位 FDE 还提到，很多中小制造企业的数据基础薄弱，各种资料、历史报价、物料和供应商信息，很少能天然直接给 AI 用。他们花了大量时间做数据清洗和结构化，更麻烦的是——要从这些数据里重新还原企业真实的业务逻辑。这些不解决，模型再强也没用。

数据治理：口径不统一，比数据脏更隐蔽#

如果说“脏”是看得见的敌人，那“口径不一”就是看不见的那个。澳洲乳企那个案例简直是教科书级：企业通过经销商进入中国和越南市场，总部在澳洲，货一出国境就成了黑箱。这里有两个概念：SellIn（品牌方把货卖给经销商）和 SellThrough（消费者最终从渠道买走多少）。总部真正想要的是 SellThrough。

可过去总部问一句“销售情况怎么样”，不同角色理解都不一样——有人按卖给经销商算，有人按消费者购买算。业务理解不到位，数据口径从一开始就可能错。

更扎心的是他们上过 BI。那位 FDE 的点评我特别喜欢：“BI 解决的是把数画成图，解决不了两个市场口径不一样——把两份不可比的数据画成漂亮的图，只是让不可比这件事更隐蔽了。”

所以他们的重点是从数据源头就把口径对齐：先在业务上把口径谈清楚，再谈技术怎么抽取。

制造业那个案例也一样。供应商发来 5000 个扳手，实际只发了 4980 个。按 ERP 逻辑，数量没到 5000，这笔单可能没法正常入库；可现实是仓库里实实在在多了 4980 个扳手。系统表达不了“实际发生了、但标准流程没完整结束”这种事。那位 FDE 花大量时间做的，就是数据清理、数据治理和口径整理。也因此他很清醒：即便同行业、规模差不多的企业，底层的数据基础、数据口径、业务流程都可能差很多——方法论可以复用，但底层数据和业务逻辑未必能直接复制。

数据中台/底座：有 ERP，不代表数据可用#

这是我最想纠正的一个误区：很多企业一觉得自己有 ERP、有数据中台，数据就不是问题了。但案例反复打脸。

国企那个案例，客户是省属国企一级子公司，业务覆盖服装、美妆、3C 等十多个电商业务线，有 OA、有 ERP、有数据中台，也有自己的信息化部门。结果 FDE 进去发现：仍然有大量业务没有结构化沉淀。很多新业务、内控业务和人工操作环节，数据可能根本不存在；即使存在，也未必按 AI 需要的方式总结归纳。他的结论是：“不能因为客户有 ERP、有数据中台，就默认它已经做好了 AI 的准备。”

那正确姿势是什么？汽车供应链那个案例给了答案：保留原来的 ERP，把必要的数据拿出来重新组织。 他们没有推翻重开发一套 ERP，原有系统继续承担原来的业务，他们在它的数据基础上做二次加工。因为真正的问题不是“没有数据”，而是“系统里的数据没有按照老板的经营逻辑串起来”。

建立统一的数据底座，不是推翻老系统，而是把必要的数据拿出来重新组织。

工具孤岛：每个系统只管一段#

还有一种新瓶颈：工具孤岛。

物料查找那个案例，客户是工业企业，跟 ERP 打交道的团队大概有 15 个：录入、采购、合同、仓储各管一块。几乎所有部门都在抱怨同一件事：ERP 不好用。拆开看是两个问题：数据不干净，搜索能力非常弱。

业务人员经常说：“我明明知道这个部件数据库里有，我上次还用过，但现在就是找不到。” 背后的损失链是：找不到 → 重新录入 → 重复数据 → 数据更脏 → 更难找到 → 买错、买重、搞错单位。

到工业采购这就牵扯真金白银了。消费者买错能退款，工业采购往往退不了，买错的东西留在仓库里，一放可能就是几年，最后只能按规则处理掉。企业真正损失的钱，藏在这里。

海外那家乳企也是同一个病：数据有的来自 Excel，有的来自 PDF，有的甚至是图片或手写凭证；字段名称、销售单位、促销规则都不统一。ERP、SaaS、BI、Excel 各管一段，只记结果，不记上下文。

API“有”和“能用”是两回事#

假设数据你拿到了，也洗干净了，还有一个坑等着你——写不回去。 物料那个案例里，FDE 评估用例时会从七八个维度打分，其中一条特别关键：数据处理后能不能重新写回业务系统。 有时候老系统不允许你把处理结果写回去；有时候技术能实现，但业务部门不愿意自己的系统被碰；还有时候业务人员根本不相信 AI 输出。

所以“接口存在”和“接口能用”完全是两码事。接口限制、Key 机制、写回权限，必须在动手前验证清楚。 否则模型算得再准，结果也只能躺在屏幕上，进不了业务流程。

数据留在企业，把能力送进去#

最后说一个特别聪明的思路。

外贸礼品那个案例，老板电脑里的合同、客户资料、产品文件是公司最核心的资产，有些连其他员工都不给看，更不可能打包发给外部 FDE。传统做法是把数据拿回来开发，但到现场才发现这条路走不通。

于是他们换了个方向：先把一套框架、原则、规范和 Demo 打包，部署到客户自己的开发环境里，让客户本地的 AI 按规范，在他的电脑和文件环境里继续完成开发。 前期花了几十个小时把框架做好，客户侧又跑了大约 40 个小时。

数据不需要离开企业，开发和适配却仍然可以继续。 这背后是一个很关键的认知：数据留在企业，把开发能力送进去。 在数据敏感、安全要求高的场景里，这往往不是可选项，而是必选项。

一句话总结#

先数据后 Agent——先把口径理清楚、把脏数据洗干净、把老系统的边界摸清楚，结果才精准，用户才敢信。

我最认同的定调来自报价那个案例：数据治理不是项目的前置条件，它本身就是项目的一部分。 把它当成“等你把数据准备好我再来做 AI”，你就低估了它、也做不成它。

这是《FDE案例100》方法论特辑的第 9 篇，也是“构建”这一辑的重点篇。下一篇，我们聊一个同样反直觉的话题：复用优于重建——为什么别急着推翻客户已有的东西。