全量清洗听起来彻底，往往也最容易失去边界
客户名称有多个写法、历史订单缺字段、共享盘文件没人维护，这些问题确实存在。但如果项目目标只是让销售生成跟进摘要，就没有必要先修完十年前所有财务数据。
把数据治理变成 AI 项目的前置大工程，团队容易陷入“再准备一下”。业务看不到结果，数据部门也不知道哪些问题最重要。半年后表格更整齐了，任务仍然没有跑起来。
从输出倒推真正需要的数据
先定义一个任务的合格输出，再问每项结论依赖什么字段。销售跟进可能需要客户名称、联系人、最近沟通、需求阶段和下一步；不参与判断的数据先不纳入。
然后检查字段是否存在、谁填写、多久更新、错误会造成什么后果。高影响字段优先治理，低影响字段允许在试点中补充。这样资源用在会改变结果的地方。
- 每个字段都能对应具体判断或输出。
- 先处理缺失、冲突和过期的高影响数据。
- 明确字段来源、负责人和更新频率。
用真实样本发现隐藏的数据问题
抽取几十份近期任务，不只看平均情况，还要包括资料不全、客户改名、跨部门移交和异常订单。让 AI 跑一遍，再记录失败是因为模型、规则还是数据。
这种方式能发现数据库检查表看不到的问题。例如字段有值但含义不一致，备注里混着多次历史状态，最新联系人仍指向离职员工。质量不是“非空”就够了，而是能否支持当前任务。
局部治理也要留下可复用规则
试点中确认的字段定义、校验方式和负责人应写进数据字典。第二个任务如果用到相同字段，可以直接复用，而不是重新争论“有效客户”或“已成交”是什么意思。
随着任务增加，治理范围自然扩大。这样形成的数据基础来自真实使用，优先级更清楚，也更容易获得业务配合。不是拒绝系统性治理，而是用项目价值推动治理。
什么时候才需要更大范围的数据工程
如果多个高价值任务都被同一数据问题阻断，或核心系统无法提供稳定接口，就需要提升到企业级治理。此时已有试点证据能说明问题影响，不再只是抽象的“数据很乱”。
企业 AI 落地不应等待完美数据，也不能忽略数据质量。先把一个任务需要的字段弄准、责任定清，再逐步扩大，是更能看到进展、也更容易长期坚持的路径。
要点总结
- 可以，但要先识别任务关键字段和高风险错误，不能把已知问题直接交给系统。
- 从合格输出和业务判断倒推，只有会影响结果的字段才优先进入治理范围。
- 数量取决于任务复杂度，重点是覆盖正常、边界和失败情况，而不是只追求数量。
参考来源说明
本文围绕“做企业 AI 前要先清洗全部数据吗？先把一个任务需要的字段弄准”展开，结合 5 份公开资料及一路凯歌在“企业 AI 服务”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。