过去一年，很多企业数据团队都在做同一件事：把报表、图卡、指标结果，通过 MCP、API、聊天助手之类的方式开放给 AI。这个动作完全能理解。大家都在用 Cursor、Claude Code，业务同学也越来越习惯“问一句就给答案”的交互方式。既然如此，数据平台顺着这个方向往前推一步，看起来再自然不过。
但真正用起来以后，问题也会很快暴露出来。只要提问稍微开放一点，比如“昨天的业务指标怎么样”“为什么这个漏斗掉了”“哪个渠道是主要拖累”，原来那套把报表结果透出去的方案就开始卡壳。它不是完全不能用，而是只能回答那些已经被事先组织好的问题。说得更直白一点：它能帮你取数，不能帮你判断。
我这次做完调研后，一个判断越来越明确：AI 不是来替你查报表的，它是在逼企业数据平台重写自己。
真正断裂的，不在接入层，在语义层
很多团队一开始把重点放在接入层，这很正常。先做 MCP，先把 dashboard、report、card 暴露出来，先让 Agent 能调起来，看起来是最顺手的路径。但问题在于，这种做法默认继承了旧 BI 时代的对象模型。它开放的是页面、图卡、筛选器和结果集，这些东西本来就是给人看的，不是给 Agent 做判断的。
人看报表的时候，会自动补上下文。你知道“昨天”默认是自然日还是交易日，知道“业务指标”通常指哪几类，知道某个口径最近刚改过，知道哪张图虽然还能看，但其实已经不该拿去汇报。可 Agent 不知道。你如果没把这些上下文显式做成机器可读的资产，它就只能在海量字段、图卡和长得很像的指标名里自己猜。
“the semantic layer is the critical component to build a bridge between AI and structured data.”
dbt 这句话我觉得非常准确。它点出了一个经常被低估的事实：AI 和结构化数据之间，缺的从来不是连接器，缺的是翻译层。Looker、Snowflake、Databricks 这几条产品线虽然路径不同，但都在强调同一件事：不要让 AI 直接面对物理表，而要让它面对受治理的业务语义。
所以如果今天还把问题理解成“我们要不要开放 MCP”，其实已经偏了。真正的问题不是开不开 MCP，而是 MCP 后面到底接什么对象。如果接的仍然是旧时代的展示对象，AI 最终只是把旧 BI 的局限，用更方便的方式重新暴露了一遍。
AI 时代的数据字典，已经不是说明书了
最近很多人重新开始讨论数据字典，我觉得方向是对的。但如果还是按传统思路去补，最后大概率只会得到一份更完整、却依然主要给人看的文档。
传统数据字典最像设备说明书。字段名、口径、来源、处理逻辑，写得越细越好。对人来说，这当然有价值。可对 Agent 来说，它天然缺一个层次：它没有直接回答“你为什么应该选这个字段，而不是那个也很像的字段”。
真正 AI-ready 的数据字典，不仅要告诉 Agent “这是什么”，还要告诉它“什么时候该用、默认怎么用、不能怎么用、谁对这个结果负责、最近有没有失效、别人通常怎么问它”。
这也是为什么现在不少 metadata 平台都在补 glossary、synonyms、quality、lineage、policy、usage history、verified queries 这些能力。它们不是在做装饰性元数据，而是在做一层机器判断的基础设施。
我觉得这里最容易被低估的，反而是那些看起来没那么“硬核”的能力。比如 synonyms、example questions、reference queries。技术团队天然更重视 lineage、schema、权限，因为这些东西工程味更重。但从 Agent 的真实使用角度看，最容易出错的恰恰是术语映射。业务说“主站赎回金额”，表里可能根本不叫这个名字；一个地方说“新增”，另一个地方说“首贷用户”；一个团队口中的“活跃”默认按天算，另一个团队默认按周算。人能靠经验补齐，Agent 补不齐。
所以我现在更愿意把 AI-ready 数据字典理解成一句话：不是字段说明书，而是企业分析语境的机器化表达。
这轮变化真正被产品化的，不是查数，而是可信答复
这次调研里，一个特别强烈的信号是：行业领先产品已经不再把“自然语言查数”当成核心卖点本身，而是在不断产品化“可信答复”。Snowflake 在做 verified queries，Power BI 在做 human-approved verified answers，ThoughtSpot 在做 analyst coaching。说法不同，但都在指向同一个现实：正确答案不是模型自己悟出来的，而是组织把自己的标准问题、标准答案、标准 SQL、标准语义，持续回灌给系统之后形成的。
这一点很重要，因为它把很多人的直觉反过来了。很多人默认觉得，只要模型越来越强，最终它总会学会这些东西。但企业数据问题不是互联网问答。互联网问答答错一次，最多体验差；企业数据问错一次，可能影响的是经营会、预算决策、风控判断，甚至组织信誉。所以在这个场景里，答得像远远不够，关键是答得可追责。
这也是为什么我越来越不认同“让 AI 自由探索数据库，然后再逐步调优”的路线。这个路径在 demo 阶段看起来很性感，因为它最像真正的智能。你随便问一句，它就能现场拼 SQL、现场出图表，感觉特别聪明。但企业里真正需要的，往往不是这种即兴表演，而是可复用、可审计、可回放、可纠错的标准化答复系统。
真正稀缺的能力，不是多答，而是知道什么时候不该答
我这次最强烈的一个感受是，很多团队在谈 AI 的时候，默认目标还是“尽量多答”。可如果站在企业数据平台的角度看，真正稀缺的能力恰恰不是多答，而是知道什么时候不该答。
以前数据平台面对的是人。人会自己做风险判断。一个资深运营看到一张图不更新，可能会先去问是不是任务挂了；一个分析师发现某个指标突然跳变，知道要先排除埋点或口径问题；一个懂业务的人看到结果离谱，天然会留个心眼。Agent 没这个体感。它没有“感觉不对”，除非你把“不对”的信号做成它能读懂的对象。
所以我越来越认为，未来企业数据平台的核心能力之一，不是智能问答，而是智能拒答。
什么情况下应该拒答？口径未认证，freshness 超过 SLA，质量告警还没消除，结果依赖涉敏字段但当前身份无权访问，语义层没有覆盖到这个问题，只能退回原始 SQL 猜测。真正成熟的平台，不会把“什么都能答”当能力，而会把“在不该答的时候及时停下来”当能力。因为后者才体现出系统已经开始拥有组织判断，而不是单纯拥有语言能力。
数据平台真正该升级的，不是前台，而是控制面
如果把这一轮变化压缩成一句更工程化的话，我会说：数据平台的重心，正在从前台产品迁移到后台控制面。
前几年大家最重视的是前台。报表好不好看，分析平台顺不顺手，自助取数方不方便，主题分析能不能拖出来。这些仍然重要，但 AI 时代的新变量在于，前台不再只有人，Agent 会变成新的主要用户之一。它不会抱怨按钮难点，但会无限放大底层语义和治理的缺陷。
于是，真正稀缺的东西开始变了。以后最值钱的，不一定是谁做出了最酷的问答入口，而是谁先做出了稳定的 Agentic Data Control Plane。这套控制面至少要统一四类对象：语义对象、元数据对象、可信对象和策略对象。只有这些东西统一起来，Agent 才可能在运行时做出像样的判断。否则它永远是在不同系统之间拼 patch。
从这个角度看，很多传统数据平台团队并不是要“转型成 AI 团队”，而是要把自己重新定义成企业判断基础设施团队。你们提供的不只是数据，而是带边界的数据判断力。
哪些东西该先做，哪些东西别急着做
如果把这件事落回现实，我反而不建议一开始追求“大而全的 AI 数据中台”。那很容易变成又一个方向正确、交付很慢、大家都知道重要、但半年后还是只能演示的工程。
更合理的路径，是从高价值主题域开始，先把少量但关键的东西做深。我会优先挑三到五个主题域，比如交易经营、用户增长、投放、风险、资金流转。每个主题域先补齐认证指标、关键实体关系、默认问法、verified queries、freshness 和 quality 信号、policy 和 owner 边界。只要这几个主题域做深了，系统就会开始出现一个很重要的质变：它不再只是到处都能查一点，而是在关键问题上开始稳定可靠。
相反，有些东西不需要太早做。比如一开始就追求通用自治分析，或者一开始就想让 Agent 直接面对全量数据仓库 schema。我觉得这些动作都太像“技术上很过瘾，组织上很危险”。数据平台一旦把风险边界开得太早，后面不是创新跑得快，而是事故来得快。
收束
我越来越觉得，很多团队今天看待 AI 调数的问题，还是太温和了。大家总觉得是在原有平台上补一层能力，给原来的报表体系加一个更自然的入口，给原来的分析平台多一个对话面板。这样理解不能说错，但它低估了这轮变化真正改写的东西。
真正被改写的，不是入口，而是责任。
以前数据平台的责任，是把数算出来，把工具搭出来，把报表发出去。以后这套责任还在，但外面会多一层更难也更值钱的责任：让机器知道什么时候能信，什么时候不能信，什么时候该继续分析，什么时候必须停下来。
一旦机器开始代替人提问，平台就不能只提供数据，它必须开始提供判断的边界。所以我对这件事最后的判断很明确：AI 不是来替你查报表的，它是在逼企业数据平台重写自己。真正要做的，不是把旧系统接给 Agent，而是把企业分析里那些原来只存在于资深分析师脑子里的语义、经验、规则和边界，全部工程化、产品化、机器化。
谁先做到这一点，谁的数据平台才真正进入了 AI 时代。