有些 AI 问数 Demo，看起来很顺。
业务在聊天框里问：“上周新客为什么下降？”
模型生成 SQL，查数，画图，再写一段原因分析。页面很安静，回答很完整，甚至还会给出下一步建议。
然后真正上线时，麻烦才开始。
新客是注册新客，还是首购新客？
下降是环比下降，还是低于预算？
上周按自然周，还是按活动周期？
这个业务同学有没有权限看渠道明细？
模型不是不会写 SQL。
它是不知道你们公司这些词到底是什么意思。
AI 不会自动懂公司的黑话
每家公司都有一套自己的数据语言。
销售额、GMV、收入、有效客户、活跃用户、转化率、复购、留存。看起来都是普通词，落到具体公司里，意思经常不一样。
一个老员工听到这些词，脑子里会自动补上下文。
他知道老板说的“收入”其实看的是支付金额，不含退款；知道运营说的“新客”通常是首次支付用户；知道财务那边问的“销售额”要按另一套口径。
AI 不知道。
它只能读系统里留下来的东西。
如果系统里只有表名、字段名和几段历史 SQL，它就只能猜。猜对时大家觉得惊艳，猜错时又会说模型不靠谱。
可很多时候，不靠谱的不是模型。
是公司没有把自己的业务语言写下来。
指标说明书要回答四件事
我觉得“语义层”这个词有点硬。
对很多团队来说，可以先把它理解成一本指标说明书。
这本说明书不用一开始就很大，先回答四件事。
第一，这个指标怎么算。
分子、分母、时间窗口、排除条件，都要写清楚。
第二，这个指标从哪里来。
用哪些表，哪些字段，什么时候更新，哪些数据可能迟到。
第三，这个指标谁能看。
汇总能不能看，明细能不能看，敏感字段能不能出现在自然语言回答里。
第四，这个指标什么时候不能用。
样本太少不能判断，活动没结束不能下结论，口径冲突时要先追问，数据质量异常时要拒答。
这四件事写出来，AI 问数才有基础。
没有这些，聊天框再漂亮，也只是把猜测包装得更像答案。
先别做全公司，先做高频问题
很多团队一听指标说明书，就想做全量治理。
全量指标、全量表、全量字段、全量负责人。
这个方向没错，但太容易拖成大项目。
更实际的做法，是先挑 20 个高频问题。
老板经常问的，业务经常吵的，数据团队经常解释的。
比如：
- 上周新客为什么下降；
- 某个渠道还能不能继续投；
- 这个活动是不是有效；
- 退款率为什么变高；
- 复购到底有没有改善。
先给这些问题配指标说明书。
它们用哪些指标，什么情况下能回答，什么情况下要追问，什么情况下必须拒答。
这比一次性整理几百个指标更有用。
因为这些问题真的会被问。
最后
AI 问数会让很多旧问题重新冒出来。
过去靠老员工记住的口径，过去靠数据同学口头解释的边界，过去靠会议里临时对齐的判断，都会被模型放大。
这不是坏事。
它提醒我们，数据团队以前有很多工作只留在人的脑子里，没有变成系统资产。
如果公司想让 AI 可靠地回答数据问题，第一步不一定是换更强的模型。
先把公司最常问的指标，写成一本机器也能读懂的说明书。
来源：
