企业 AI 落地开会，最容易出现的分歧是：数据团队说先治理，业务团队说先上线。
两边都没错。错的是把“先后”当成部门立场，而不是项目顺序。
两种做法，各自适合谁
先洗全量数据。 适合数据错误会直接影响资金、合规或对外报表的项目。好处是底座干净，坏处是周期长，而且很难定义什么叫“洗完”。
先跑单场景。 适合业务问题清楚、数据分散但可获取的项目。好处是很快能看到真实问题，坏处是前期答案可能不稳定，需要边跑边补。
| 维度 | 先洗全量数据 | 先跑单场景 |
|---|---|---|
| 首次可见结果 | 慢 | 快 |
| 数据问题暴露 | 靠盘点 | 靠真实提问 |
| 返工风险 | 规则不清时高 | 场景扩散时高 |
| 适合情况 | 强合规、核心报表 | 单点流程、知识问答 |
为什么我倾向先跑场景
全量数据治理最大的问题，不是难，而是没有清晰的终点。
什么叫干净？字段完整、口径统一、历史数据补齐，这些都对，但业务部门很难判断什么时候可以开始用。项目容易在“再治理一轮”里停住。
场景能给出优先级。把真实问题丢给系统，哪一类问题答不上来，哪几张表缺字段，很快就暴露了。数据团队不用猜哪些数据重要，业务已经在用问题投票。
这不是绕过治理，而是让治理有业务顺序。
先跑场景，不等于先上生产
先跑场景，不等于跳过验收。
第一版仍然要限定问题范围、记录答不上来的问题、设置人工确认。否则场景会变成没有边界的试错，数据问题也会被答案掩盖。
还有一点：先跑场景需要业务负责人参与。数据团队不知道哪些问题最常出现，业务团队不知道字段从哪里来。两边每周对一次问题清单，比开一次大型启动会更有用。
最小数据集怎么定
先回答四个问题：
- 这个场景要回答什么问题；
- 答案来自哪几张表、哪几份文档；
- 哪些字段必须有，缺了就不能答；
- 哪些信息可以人工补，哪些必须系统里有。
四问答完，再决定清洗范围。第一版只清洗这个场景真正用到的数据，不顺手做全公司的主数据项目。
什么情况下必须先治理数据
有些场景不能边跑边治：
- 对账、报表、结算，错一个字段就会带来资金风险；
- 涉及监管报送、合同义务或对外披露；
- 多个系统里的客户、订单、物料编码对不上；
- 错误答案会被直接当成正式结论使用。
这些情况下，先治理，再上线。拿场景去试错，代价可能比项目本身还大。
一个可执行的顺序
先选一个窄场景，列出最小数据集，用真实问题跑一遍。把答不上来的问题记下来，每周把高频缺口补回数据源，再决定要不要扩第二个场景。
这个顺序不漂亮，但能让数据治理跟着业务问题走。企业 AI 落地不是等数据完美才开始，也不是带着脏数据硬上。先用场景界定最小数据，再用真实问题反推治理清单。