我以前很怕一种会。
会议室里投着一张经营看板，左边是 GMV，右边是转化率，下面还有一排渠道和地区筛选器。数据同学坐在角落，手里拿着电脑，等着有人问：“这个数怎么来的？”
很多时候，没人问。
老板看了两眼，转头在群里问：“上周新客为什么掉了？”
业务同学开始翻自己的 Excel，运营同学说可能是活动节奏，数据分析师打开 SQL，会议室里的看板像一块安静的背景板。它明明做得很认真，却没有进入决策现场。
过去我们会说，这是报表没人用。
现在事情稍微变了。
报表以后可能仍然没人点开，但它背后的指标、语义模型、权限和解释，会被 AI 调用。
这不是一句科幻话。
Power BI 6 月更新里提到 Fabric Apps for Semantic Models，Databricks 在 Data + AI Summit 后继续推 Unity Catalog 和治理台，MIT CISR 也专门讨论企业为什么要给 GenAI 建 semantic layer。几件事放在一起看，方向很清楚：
报表正在从“给人看的页面”，变成“给人和 AI 都能调用的业务接口”。
报表以前解决的是展示问题
我们先把话说朴素一点。
过去很多 BI 项目，本质上是在解决展示问题。
业务要看销售额，数据团队就把销售额放到看板上。业务要按渠道、地区、商品筛选，就加筛选器。领导想看趋势，就加折线图。月会要截图，就把颜色调得清楚一点。
这件事当然有价值。
没有报表的时候，大家靠临时 SQL、Excel 和微信群问数。报表至少把常见问题固定下来，让数据有一个稳定入口。
但它也有一个天然限制：报表假设使用者是人。
人会看标题，会读图例，会记得上个月开会时改过口径。人如果看不懂，还会找数据同学问一句：“你这里的新客，是首购还是注册？”
AI 不会自动知道这些。
它要么从系统里拿到定义，要么自己猜。
所以当 AI 开始进入问数、分析、报告生成和业务助理场景时，报表后面的东西比报表页面本身更重要。
一个折线图对人来说是结果。
对 AI 来说，它更像一个调用入口：这个指标是什么，来自哪张表，能按哪些维度拆，哪些用户能看，什么时候不能回答。
如果这些东西没有写清楚，AI 调用报表和人截图报表没有本质区别。
只是截图的人变成了模型。
AI 不是来读图的，它要读懂报表背后的约定
很多公司一听 AI 问数，第一反应是给报表加一个聊天框。
页面右下角放一个输入框，业务问“上周新客为什么下降”，模型自动生成 SQL，再返回一段解释。
演示时很顺。
可是真实公司里，问题不会这么干净。
“新客”可能有三种定义：注册新客、首购新客、首次支付新客。
“上周”可能按自然周，也可能按活动周期。
“下降”要看同比、环比，还是和预算比。
“为什么”更麻烦。它不是一个 SQL 问题，而是要把渠道、活动、库存、版本、价格、埋点和数据质量放在一起看。
这时候，AI 需要的不只是图表截图，还要有一份业务约定。
这份约定至少包括五件事。
第一，指标口径。销售额、毛利、新客、留存、复购，都要有明确边界。
第二，数据来源。这个指标来自哪张事实表，哪些维表参与计算，哪些字段是核心字段。
第三，权限规则。谁能看汇总，谁能看明细，哪些字段不能被普通问数暴露。
第四，更新时间。数据是实时、小时级、T+1，还是人工补数后才可靠。
第五，拒答条件。样本太少、口径冲突、权限不足、数据质量异常时，系统应该提醒，而不是硬编一个答案。
这些东西过去也重要，只是过去常常靠人兜底。
资深分析师知道哪个口径不能乱用，老数仓同学知道哪张表周一早上会晚到，业务负责人知道哪个活动周期不能按自然周切。
AI 不知道。
除非我们把这些经验写进系统。
这会改变数据分析师的交付物
如果报表以后会被 AI 调用，数据分析师的工作就会发生一个细微但重要的变化。
你交付的不再只是一张页面。
你交付的是一套可被复用的判断。
过去交付看板，大家关心的是：
- 页面有没有；
- 数字准不准；
- 筛选好不好用；
- 领导会不会点。
以后还要多问几句：
- 这个指标能不能被自然语言准确引用；
- AI 调用时能不能知道适用边界；
- 用户问错问题时，系统能不能提示；
- 结果出错时，能不能追溯到口径、表和版本；
- 后续业务改口径，旧报表和 AI 回答会不会一起更新。
这听起来像把 BI 工作做重了。
但换个角度看，这是把数据分析师从“做页面的人”往“设计业务语义的人”推了一步。
以前你做一张报表，价值主要发生在页面被打开的那一刻。
以后你整理好一个指标，它可能出现在报表里，也可能被 AI 助手调用，可能进入自动周报，可能成为异常解释的一部分，可能被另一个团队复用。
报表只是出口之一。
更耐用的资产，是背后的语义。
这也是为什么最近语义层又重新被提起来。它不是一个新概念，但 AI 让它突然有了更硬的使用场景。
没人愿意为“写文档”付太多账。
但如果这份文档决定 AI 能不能答对、能不能拒答、能不能被审计，它就不再只是文档。
它变成系统的一部分。
指标字典以前没人看，可能是因为它没有进入工作流
很多公司不是没做过指标字典。
做过。
还做得很认真。
字段说明、口径定义、负责人、更新时间、血缘关系，全都在一个平台里。问题是业务同学很少主动打开它，数据同学也只有在口径吵起来时才翻。
于是指标字典变成了一个很尴尬的东西：存在，但不在现场。
AI 可能会改变这一点。
不是因为 AI 会让所有人突然爱看文档，而是因为 AI 可以把文档带回工作流里。
业务问“这个月复购为什么掉了”，系统先判断“复购”有几个版本，然后提示用户选择口径；用户问一个没有权限的问题，系统直接拒绝；用户要求拆到门店明细，系统知道当前角色只能看区域汇总。
这时候，指标字典就不再是给人翻的资料库。
它变成 AI 回答问题时必须经过的一道门。
这件事也会反过来逼数据团队提高文档质量。
以前写得含糊一点，人还能靠经验补。现在写得含糊，模型就会把含糊放大。
一个字段说明写“订单金额”，看起来没问题。可它到底含不含退款？含不含运费？按支付时间还是下单时间？跨境订单汇率按哪一天？这些不写清楚，人会吵，AI 会错。
而且它错得很安静。
别把报表做成 AI 的截图工具
这里有个坑。
很多团队会把“AI 调用报表”理解成：让模型看报表截图，或者把图表结果喂给模型，让它生成一段解释。
这可以做，但不要把它当终点。
截图只能告诉模型“结果长什么样”，不能告诉模型“这个结果为什么可信”。
更有价值的调用，应该发生在语义层和数据模型上，而不是停在视觉层。
也就是说，AI 应该能拿到：
- 指标定义；
- 查询约束；
- 权限边界；
- 质量状态；
- 口径版本；
- 变更记录。
然后再去生成解释、图表或建议。
如果只是把报表截图交给模型，它可能会写出一段漂亮的分析。那段话读起来很顺，但一追问来源，下面是空的。
这和过去有些日报的问题很像。
日报写得很完整，原因、影响、建议都有。可是一问数据从哪来，口径谁确认，异常有没有排除，就开始发虚。
AI 不能帮我们绕过这些问题。
它只会把这些问题带到更多场景里。
下一张报表，可以多留五样东西
如果你明天还要做报表，不用突然把自己变成平台架构师。
可以先从很小的地方开始。
做下一张核心报表时，除了页面本身，多留五样东西。
第一，指标说明。别只写“GMV”，写清楚时间口径、订单状态、退款处理和币种处理。
第二，使用场景。这个指标适合经营日报、活动复盘，还是只适合趋势观察。
第三，权限边界。哪些人只能看汇总，哪些角色能看明细，哪些字段不能出现在自然语言回答里。
第四，异常说明。什么时候这个指标可能不可靠，比如埋点改版、补数、迟到数据、系统迁移。
第五，拒答规则。哪些问题现在不能答，必须补时间范围、选择口径，或者找负责人确认。
这些东西不一定一开始就进平台。
先写在报表旁边、指标文档里、需求卡里，都可以。
关键是你要把“报表给人看”这件事，慢慢改成“报表背后的语义能被系统调用”。
这一步做完，AI 来了，你不是被动等它替代页面。
你是在给它铺轨道。
最后
很多数据同学会担心：如果以后业务都直接问 AI，那 BI 和报表是不是就不重要了？
我反而觉得，报表不会立刻消失。
但报表的价值会变。
以前一张好报表，是让人看懂数据。
以后一张好报表背后的模型，要让人和 AI 都能正确使用数据。
前者偏展示，后者偏约定。
展示做得好，别人看一眼觉得清楚。
约定做得好，很多系统在你不在场的时候也不会乱答。
这可能是数据分析师接下来几年最容易被低估的一件事。
你不是只在做报表。
你是在给公司留下一套能被反复调用的业务语言。
来源：
