数据底座先行：为什么数据准备比 Agent 还费时

很多 AI 项目慢，不是 Agent 不行，是喂它的数据没备好——数据准备才是隐形大头。

某家连锁门店准备上 AI 客服，选型、部署、测试都顺，结果上线第一周就翻车：Agent 给顾客推的套餐，库存里已经断货三个月；报了一个配件的价格，比现行价格低了 30%。数据没联通，Agent 越聪明，说错的越自信。最后花两周把 AI 下线，花三个月重整数据，才重新上线。

这种事不是个例。在很多企业 AI 落地项目里，真正花时间的不是写代码、不是调 Agent，而是把数据搞清楚。数据准备常占整个项目工时的 60%—80%，但在项目启动阶段，大多数人低估甚至忽视了它。

---

为什么数据准备最费时

数据问题不是"有没有数据"的问题，是"数据能不能被 AI 用"的问题。两者差的很远。

数据散在各个系统，没有一个统一入口。

多数企业的数据分布是这样的：客户信息在 CRM，订单记录在 ERP，售后工单在另一套系统，操作手册是 Word 文档，产品介绍是 PPT，历史对话记录在企业微信或钉钉——每个数据源格式不同，接口不通，有的根本没有接口只能靠人工导出。Agent 要回答"这个客户最近三单都在哪个地区发货"，你得同时打通 CRM、ERP、物流系统。这三套系统能不能被统一查询，本身就是一个工程问题。

格式乱，AI 没法直接用。

图片里的表格、扫描件里的合同、语音录音转的文字稿、Excel 里靠颜色区分状态的报表——这些数据人看了能懂，AI 看了要么读不进去，要么解读出错。清洗这类数据，每一条都要人工判断或专门写处理脚本，工作量比预期大一个量级。

质量差，缺值/重复/矛盾到处都是。

有企业梳理内部知识库，发现同一个产品型号，三个文档里有三种描述，其中一个还是两年前已经停产的规格。客服知识库里的"标准答案"，有 40% 以上已经过时。这种数据直接喂给 AI，等于让 AI 照着错误资料答题，怎么也对不了。

权限没理清，数据没法给 AI 用。

很多敏感数据——财务数字、客户隐私、内部合同——即使格式整齐、质量不错，也不能随便让 AI 访问。但权限边界没有提前设计，就会有两种情况：一是 AI 拿不到需要的数据，功能打折；二是 AI 拿到了不该拿的数据，合规风险暴露。权限治理本身是一件细活，比大多数人想的复杂。

这四件事叠在一起，就是数据准备费时的真实原因。

---

AI 到底要什么样的数据

搞清楚"AI 要什么"，比泛泛地"提高数据质量"更有用。AI 对数据的要求，可以归结为四条：

可访问：AI 能读到。数据在某个格式可被程序读取的地方，有接口、有 API，或者至少能导出成结构化格式。PDF 里的文字得能被提取，图片里的表格得被 OCR，音频得有文字版本。

结构清晰：AI 知道这是什么。每条数据有明确的字段标签，知道这一列是"产品名称"、那一列是"库存数量"。对于非结构化文档，至少要有清晰的标题和分段，让 AI 能定位到它在说什么。

质量够用：不是要完美，是要"够这个任务用"。客服知识库用于回答常见问题，就要保证常见问题对应的内容是准确的、没有过时。财务助手要查费用，就要保证费用字段没有空值和重复条目。质量的底线由任务决定，不是全量治理。

有权限设计：AI 能访问它该访问的，不能访问它不该访问的。权限边界在数据准备阶段就要设计，不能等到 Agent 上线后再补。

这四条对照一下自己的数据，能打几分？如果哪条明显低，那就是项目的风险点。

---

数据底座要做哪几件事

数据底座不是一套大系统，是四件有优先级的事。

打通数据源

先做最关键的几个数据接口。AI 项目要用的数据，通常来自 2—4 个核心系统，先把这几个系统的接口打通，能实时读取或定期同步数据。不需要一次把所有系统都接上，先接覆盖 80% 使用场景的那几个。

接口不通的地方，退而求其次用定期导出 + 自动同步脚本过渡。关键是数据能流动，别让人工搬运成为瓶颈。

清洗数据

清洗不是把所有数据都整理一遍，是针对 AI 要用到的数据做专项清洗：

• 修掉明显的错误值（停产产品的现行价格标注、地址字段里夹杂的备注文字）
• 去重（同一客户、同一产品的重复条目）
• 补关键缺值（影响业务逻辑的字段，不能为空）
• 统一格式（日期格式、单位格式、分类标签的写法）

清洗要做文档记录：改了什么、为什么改、改之前的原始值留档。这不是繁文缛节，是将来 AI 给出奇怪答案时，你能追溯问题出在哪里的保障。

建可被 AI 检索的知识库

这是很多企业在做"AI 知识库"时最容易走错的地方。

把文档扔进去不等于建了知识库。 AI 知识库的核心是检索质量——AI 在回答问题时能不能找到正确的那段内容。这取决于：文档切块方式（太长的文档要拆成合理的段落）、标题和元数据（让 AI 知道这段内容属于哪个产品/哪个场景）、以及向量化索引的质量。

建知识库的基本动作：

• 内容过期检查：入库的文档必须是当前有效的，过时的版本要么更新要么标注废弃
• 合理切块：每个 chunk 只覆盖一个主题，有上下文锚点（比如"以下是 X 产品 Y 型号的退货规则"而不是直接开始列规则）
• 测试检索：用 5—10 个真实的用户问题测一遍，看 AI 能不能检索到正确的内容，不能的话调整切块策略

对于企业内部文档，知识库的维护机制比建库本身更重要。谁负责更新、更新频率是多少，上线前就得定好。

权限治理

把数据分级：哪些数据所有人都能查（产品目录、公开政策）、哪些只限内部员工（内部操作规范）、哪些只限特定角色（财务数据、客户详细信息）。

AI 访问数据的权限，跟人访问数据的权限应当一致，不能因为"反正是 AI 在查"就绕过权限控制。

具体实现上，可以先用简单方案：不同权限级别的内容放在不同知识库，AI 根据用户角色只能查对应的知识库。技术成本不高，但能避开大多数合规风险。

---

别等数据完美才动

很多团队在数据准备阶段陷入完美主义：要把所有历史数据都清洗完才上线、要把所有系统都打通才能测试、要把权限体系全设计完才能给 AI 用数据。

这个想法合理，但在实践里会导致项目拖成两年。

正确的节奏是：关键数据先备好，其余边做边补。

先问自己：这个 AI 功能，最依赖哪 20% 的数据？把这 20% 的数据做到可访问、质量够用、权限清晰，就可以上线测试，收集真实反馈。剩下 80% 的数据，根据真实使用中暴露的问题，按优先级补。

这不是降低标准，是把有限的数据治理资源用在刀刃上。数据是永远治理不完的，没有哪家企业的数据是完美的。AI 落地的艺术，是在数据够用的情况下先跑起来，在跑的过程中持续改进。

---

上 AI 前数据就绪检查清单

在正式启动 AI 功能之前，过一遍这张清单。打不了勾的项目，就是风险点。

#	检查项	是/否/待办
1	已确认 AI 功能需要哪些核心数据，列清楚了
2	这些核心数据有技术接口或可导出格式，AI 能读到
3	数据字段有明确标签，知道每列/每段是什么含义
4	关键字段做了缺值和重复检查，主要问题已修复
5	内容类数据（文档/知识库）已做过期检查，当前有效
6	知识库做了检索测试，用 5+ 真实问题验证过检索准确率
7	数据访问权限已分级，AI 不会触及超权限数据
8	有人负责数据更新维护，频率已确认
9	数据清洗记录存档，改动可追溯
10	非核心数据准备不足已列出待办，不阻塞上线但有计划

这张清单不是要全部打勾才能上线，而是让你对风险点心里有数。第 1—7 项如果有多个"否"，建议先补数据再上线；第 8—10 项是过渡期可接受的，但要有明确计划。

---

反面教训

买了个 Agent 工具，以为部署完就能用

这是最常见的误判。Agent 工具开箱确实能运行，但运行的质量完全取决于喂给它的数据。工具的演示是在干净数据上跑的，实际生产环境里，数据乱七八糟，Agent 给出的答案也会乱七八糟。买工具之前，先评估自己的数据就绪程度，这比研究工具功能更重要。

数据没准备好，急着上线，效果差

某项目团队为了赶业务节点，在数据问题没解决前强行上线 AI 客服。前两周接连出现报错答案——推荐了已下架的产品、给出了失效的活动链接、对同一个问题给不同用户答了不同的内容。用户投诉增多，业务部门对 AI 失去信心，后来花比当初数据准备更多的时间做公关和修复。数据没就绪，强上线的代价不只是效果差，还会消耗组织对 AI 的信任。

一次性想把数据全治理完

数据治理本身是个好事，但把它变成 AI 项目的前置条件，会把项目变成无限期推延。数据治理没有终点，总有可以改进的地方。正确做法是聚焦 AI 功能的关键数据做专项治理，其他数据根据业务优先级逐步推进。全量治理的雄心，常常以"AI 项目先暂停等数据治理完"告终，而数据治理本身也因为缺乏业务场景锚定而变成了拉锯战。

---

常见问题

数据在各个部门手里，推不动，怎么办？

数据打通的阻力，很少来自技术，更多来自部门边界和利益：这个部门的数据被另一个部门用，谁来负责维护质量？出了问题谁担责？推动数据打通，需要管理者介入，把数据共享纳入部门协作机制，而不是让技术团队自己去找数据。先从"数据共享对哪个部门有好处"下手，找到愿意先行的支点部门，用成果说话。关于这类高频数据 ROI 判断，可参考 高优先级矩阵：哪些数据值得优先治理。

历史数据量很大，清洗周期太长，项目等不起，怎么办？

不要全量清洗。只清洗 AI 功能覆盖的核心场景涉及的数据，其他历史数据打标"可用但未验证"，让 AI 在使用时给出更低的置信度即可。清洗要聚焦"AI 会答错的"那些数据问题，而不是所有数据缺陷。这是数据准备里优先级判断的核心技巧。

小公司没有专门的数据团队，数据准备谁来做？

数据准备不一定需要专职数据工程师。小规模项目，可以是业务人员 + 技术人员搭档：业务人员知道哪些数据字段关键、哪些内容已经过时，技术人员负责接口和格式处理。关键是有人对数据质量负责，而不是默认"数据是现成的"直接交给 AI 用。对应的角色设计，可参考 Agent 优先的流程设计：人在关键节点把关。

知识库建好了，但 AI 回答还是经常检索不到正确内容，怎么排查？

先用 5—10 个典型问题做检索测试，看 AI 召回的内容段落是不是对的那段。如果不对，通常是切块粒度问题（太长，一段里混了多个主题）或者标题/元数据不够清晰。调整切块方式，给每个 chunk 加上"这段内容覆盖 X 场景 Y 产品"的前缀，往往能明显改善。检索质量是可以测试和迭代的，不是一次性决策。关于知识沉淀的系统方法，见 知识沉淀：让专家经验变成组织资产。

---

小结 · 你现在该做什么

• 知道数据准备费时的四个真实原因：数据散/格式乱/质量差/权限没设计
• 明白 AI 对数据的四条要求：可访问/结构清晰/质量够用/有权限
• 掌握数据底座的四件事：打通数据源 → 清洗 → 建知识库 → 权限治理
• 拿到了"上 AI 前数据就绪检查清单"，10 项覆盖上线前的主要风险点
• 知道了完美主义陷阱：关键数据先备好，边做边补，别等完美才动

下一步：数据准备的基础打好了，Agent 流程设计才有意义。见 Agent 优先的流程设计：人在关键节点把关。更上游的数据优先级决策，见 高优先级矩阵：哪些数据值得优先治理。沉淀到知识库里的内容，如何从个人经验变成组织资产，见 知识沉淀：让专家经验变成组织资产。

👉 看看 AI 时代的组织与管理 专栏，或了解 AI 时代管理者认知课。需要定制落地与陪跑，欢迎聊 企业服务。