一个把项目卡住的理由
企业里讨论上 AI 问数，十个有八个会听到同一句话：我们数据太脏，得先把治理做完。这句话听起来有道理------数据不准，AI 答的数就不准，那不是白搭。于是治理立项、清洗数据、统一编码，一做一年半载，AI 问数排到二期三期，最后不了了之。
但把这句话拆开看，会发现两个被忽略的事实。一是"数据脏"没有统一标准------脏到什么程度算脏，谁来判定，判定的依据是什么，多数企业答不上来。二是"治理做完"没有终点------口径在变、系统在加、业务在调，治理是持续的事，不是一次性能收尾的工程。拿一个没有终点的工程当另一个项目的开工条件，等于永远不开工。
数据脏和上 AI 问数，到底谁先谁后，值得重新算一笔账。
脏数据的三类，各有各的处理法
先说清楚"脏"指的是什么。企业里常说的脏数据，细分下来是三类。
第一类是"叫法不一"。同一个产品，ERP 里叫编码，销售系统里叫款号，仓库里叫料号。数据本身没坏，但同一个实体在不同系统里是三个名字，跨系统对不上。
第二类是"口径不一"。同一个"回款"，销售按合同额算，财务按到账额算；同一个"在库"，仓库按实物算，财务按账面算。数都没错，但同一个词在不同部门是两个定义。
第三类才是真正的"错数"。单据录重了、库存账实不符、客户信息过期。这类是实打实的数据质量问题，需要修。
把三类分开，问题就清楚了一半：前两类占企业"脏数据"的大头，而它们不是数据坏了，是数据之间的关系没定义。第三类错数才需要修，但修复有优先级------影响经营的先修，边角的可以放。一上来把三类混在一起说"数据脏，得先治理"，是把可定义的关系问题和不紧急的质量问题捆在一起，捆住了 AI 问数的手脚。
边用边治：让使用反推治理
传统的治理思路是"先治后用"------数据干净了再用。这个思路在报表时代有它的道理，因为报表是固化口径，做表之前必须先把口径定死。但 AI 问数的工作方式不一样：它是即问即答，每次提问都是一次口径的现场应用。这带来一个传统治理没有的机会------使用本身会暴露问题。
问一次"华东区回款"，如果销售和财务两个系统的数对不上，这次提问就暴露了一个口径问题；问一次"某产品的库存"，如果仓库和 ERP 对不上，就暴露了一个实体映射问题。问的人越多，暴露得越快。这些暴露出来的问题，就是治理清单------比坐在会议室里凭空列清单，准得多，也快得多。
所以更现实的路径是"边用边治"：先把最关键的几个场景接进来用起来，问题暴露一个，治理收敛一个；能用的数先用，暂时对不上的标出来。治理清单跟着使用逐步收敛，而不是等一个想象中的"全部干净"。
脏不脏是相对概念，看给谁用
还有一层认识要摆正：数据的干净程度是相对的，取决于用它做什么。
给监管报送的财务数据，口径要求严格，错一条都是事------这类数据该按高标准治。给老板看经营大盘的汇总数，量级对了趋势对了就有参考价值------容忍度可以放宽。给一线员工查日常进度的数，快比全更重要------实时性优先于完备性。
AI 问数落地的正常姿势，是先从容忍度高的场景切入：管理者临时起的、长尾的、要快不要精的查数需求。这些场景对"脏"的容忍度高，边用边暴露问题、边收敛治理。等关键场景跑顺了、口径逐步统一了，再往严格的场景走。一上来就冲着最严的报送场景去，是用最难的题考最不熟练的系统。
平台怎么帮这件事
这个"边用边治"的路径，对平台有一个具体的要求：它得能承接口径的定义和收敛。数据接进来之后，同一个实体的多个叫法能归到一处，同一个指标的多个口径能挂上定义并标明当前采用哪个，暂时对不上的数据能标记出来而不是混在一起。
JBoltAI本体语义平台是新一代智能数据中台，在这件事上的做法是把"关系和口径"作为一等公民------实体怎么映射、指标怎么算、哪些数可信哪些存疑，都定义在平台里，AI 答数的时候按定义走，存疑的数明确标出来。治理不再是平台之外的一项独立工程，而是使用过程中在平台里持续收敛的动作。答的每个数旁边挂着口径和来源，可信度自己会说话。
三条落地建议
第一，别把"数据脏"当挡箭牌。下次再听到"先治理再上 AI"，先问一句：脏的是哪一类，影响的是哪个场景，能不能先从容忍度高的场景用起来。
第二，把治理清单从会议室挪到使用现场。让业务先问起来，问不上的、答错的、对不齐的，自动变成治理任务，按影响排序去修。
第三，接受数据治理没有终点。它和业务一样是活的，口径会变、系统会加。平台选型时重点看能不能承载这种持续的变化------关系和口径改起来费不费劲，直接决定"边用边治"能不能跑下去。
一句话收尾
数据脏不是不上 AI 问数的理由，是上 AI 问数的起点。先分清脏的是叫法、口径还是错数，再从容忍度高的场景用起来，让使用反推治理逐步收敛------这条路比"等治理做完"务实得多。数据永远不会完全干净，但答案可以越来越可信。