口径没统一就上模型
同一个指标在财务、销售与运营各有一套算法，模型只能挑一个回答。业务方发现数字对不上，第一反应是不信任系统，项目从此进入质疑循环，每次会议都要先花时间解释口径，讨论很难推进。这类循环一旦形成，后面每加一个场景都要重演。
数据质量默认已解决
缺失、重复与口径变更无版本，模型会把这些噪音当成业务信号。上线前应做一次字段级体检，把已知问题写进使用说明，而不是等业务方踩过坑再解释，那时信任已经很难挽回。写进使用说明，比事后解释有效得多。
只做问答不做闭环
问了、看了、没改流程，下一次会议仍用旧表。分析结果要绑定到具体动作与责任人，否则再准的答案也不会产生价值，团队还会觉得又多了一个需要维护的系统，慢慢就不登录了。绑定动作与责任人，分析才会改变决策。
权限与合规后置
数据不能出域、明细不能下放，这些约束若在选型后才出现，架构要重做。项目启动时就应确认部署方式与分级要求，把安全与合规人员拉进首次评审，比事后补救便宜得多。把安全与合规拉进首次评审，能省掉一次返工。
一次错数导致停用
早期没有双人复核与灰度范围，一个错数被高层看到，系统就会被贴上不可靠标签。先在小范围建立可信记录，再逐步扩大，比一次性全员推广稳妥，也更容易争取到下一次预算。
适用与不适用
适合谁
- 已采购分析工具但使用率偏低的企业
- 数据分散在多个系统、口径长期有争议的集团
- 准备把分析问答开放给一线的团队
不适合谁
- 尚无稳定数据源、只能做演示的团队
- 希望一次上线覆盖全部分析场景的企业
典型场景
某集团上线分析问答后使用率一直不高。复盘发现销售与财务的成交口径不同，模型按财务口径回答，销售认为数字错误。团队用两周统一三个核心指标，再限定试点范围，使用率才逐步回升。试点范围限定在一个事业部，问题也更集中。
可执行步骤
- 上线前统一核心指标定义，形成一份可引用的口径清单并发布
- 做一次字段级数据质量体检，把已知问题写进使用说明并标注
- 把分析结论绑定到具体动作与责任人，定期回看是否真正落地
- 先确认部署方式与数据分级要求，再选型与安排排期，避免上线后返工。
常见坑
- 用技术指标代替业务验收：查询成功率很好看，但业务方仍用旧表，投入等于没有产生效果。
- 隐瞒已知数据问题：业务方踩坑后发现，信任修复的成本远高于提前说明与标注，还会拖累其他场景。
- 范围一次放开：错数在小范围可控，在全公司传播就变成事故，收场要花数月，负责人也会被追责。
自检与验收清单
- 核心指标定义是否统一发布，各处引用同一份
- 已知数据问题是否书面说明，并标注在结果旁
- 每条分析是否指向具体动作与责任人
- 是否有灰度范围与双人复核，并指定执行人
常见问题
先治理数据还是先上 AI？
两条腿走：先统一少量核心指标并做质量体检，同时用干净的业务域试点。等全部治理完再上，往往等不到那天，团队也会失去耐心，试点还能反过来暴露治理重点。
错一次就没救了吗？
不是，但要看处理方式。公开复盘、明确修正与责任、缩小范围重建信任，比私下改数有效得多；掩盖问题会让团队在同一个地方反复踩，最后没人敢用。
要不要上大模型？
取决于问题类型。固定报表与规则清晰的指标用传统 BI 更稳；开放式探查与自然语言问答适合大模型，两者常配合使用，不必二选一，先解决口径再谈模型。