最近看到 Anthropic 写他们怎么用 Claude 做自助数据分析。
吸引我的不是”Claude 能不能写 SQL”，也不是他们内部自动化了多少分析查询。是他们说了一句很到位的话：把 Claude 直接接到数仓上，让它自己查数据，会制造一种虚假的精确感。
在企业里，SQL 能跑，数字能出来，页面上也能展示成一张很漂亮的表——但这不代表答案就是对的。
这个问题我最近在做数据治理报表系统时也感受很深。我们现在也在规划让 AI 参与报表构建，比如用户描述自己想要什么报表，AI 帮他推荐模板、数据集、字段映射和配置草稿。这个方向我觉得是对的，因为很多业务用户并不知道自己该选哪张表、哪个模板、哪些字段。
但越往下想，越觉得真正难的不是 AI 怎么生成配置。
是另一个问题：企业有没有把数据讲清楚。
很多企业不是没有数据，是有太多差不多的数据
做数据治理的都知道，企业里最难处理的往往不是”没有数据”。
很多时候是数据太多了。
一个项目，在这个系统里有一个编码，在另一个系统里又是另一个编码；组织架构看起来应该是统一的，但实际可能有好几套；同一个地盘，在不同业务系统里的名称、归属、状态、启停口径都不完全一样。
再往上，还有指标。
本月收入、累计收入、已收款、计划完成率、开工人数、在建项目数，这些词看起来都很普通。但真正落到表和字段上，每个部门可能都有自己的理解。有人按财务口径，有人按项目口径，有人按最新组织架构，有人还在用历史归属关系。
这时候如果让 AI 来查，它可能真的能查出来。
它会选一张看起来很像的表，找几个看起来很像的字段，写一段能跑的 SQL，然后给你一个数字。
这个数字是你真正想问的那个问题的答案么？
这比报错更麻烦。
报错至少会让你停下来。
一个看起来合理的错误答案，反而最危险。
组织越往后走，数据治理越难
数据治理难，不仅是技术问题、业务口径问题，很大程度上也是组织问题。
一个组织发展到中后期，部门会越来越专业，也会越来越有自己的系统、自己的流程、自己的指标和自己的历史包袱。每个部门维护自己的数据，本身并不奇怪，甚至在某个阶段是合理的。
但很多数据不是部门级的。
项目信息、组织架构、人员、地盘、合同、收入、产值，这些数据最终都要在组织层面被拉通。只要底层主数据没有统一，后面做多少报表、多少驾驶舱、多少 AI 查询，都只能在上面不断补丁。
现实里最常见的情况：大家发现了不同，也知道有不同，但要推动统一很难。
因为统一数据不是改一个字段名那么简单。它会牵动系统、流程、权限、历史数据、部门责任，甚至牵动某些部门一直以来的工作方式。
沟通成本太高以后，数据治理就容易变成”发现问题、记录问题、局部修一下”，很难真正往根上走。
这也是为什么很多企业都说自己在做数据治理，但效果并不明显。
大家不是没意识到问题。问题是刚好卡在组织协作最难的地方。
语义层不是给字段起中文名
Anthropic 那篇文章里提到语义层，这个概念很重要，不是表面看到的那么简单。
一个常见的第一反应是字段中文名映射。比如把 site_name 展示成”项目名称”，把 contract_amount 展示成”合约金额”。用户不用直接看数据库字段就能理解这是什么数据。
但语义层不止是这件事。
它更像是在回答：当用户说”我想看项目收入”时，系统到底应该理解成什么。
用哪张表？ 哪个字段才是收入？ 按哪个时间口径？ 是否包含变更？ 是否按当前组织架构归属？ 是否受用户数据权限过滤？ 历史项目怎么处理？ 同一个项目跨系统编码不一致时，以哪个为准？
这些问题如果没有在系统里被定义清楚，AI 就只能猜。
它猜得越流畅，越容易让人相信。
所以AI构建报表，不能只是一个自然语言入口，也不能只是让 AI 从很多表里挑字段。前面必须有一层被治理过的数据和语义。
不然用户问的是业务问题，AI 回答的是数据库问题。
两件事可能不是同一件。
Skill 的价值，是把分析路径沉淀下来
Anthropic 还提到 skills，这点很有启发。
之前我们说 AI 查数，容易把重点放在”给它更多表结构、更多文档、更多历史 SQL”。但这些东西堆在一起，不一定会让 AI 更懂业务。信息太多，反而让它在一堆相似答案里绕。
Skill 的价值在于，不光是告诉 AI 某个字段是什么意思，而是告诉它遇到某类问题应该怎么做。
比如用户问一个项目类报表，不应该一上来就全库搜索字段。先判断业务域，再找权威数据集，再看这个数据集是否适用组织/地盘数据权限，再匹配报表模板，再做字段映射，再把不确定的地方暴露给用户确认。
这更接近一个有经验的数据分析师或产品经理的工作路径。
他不会看到一个字段名像就直接拿来用。
他会先问：这张表是不是权威来源；这个字段是不是当前口径；这个指标有没有历史版本；这个数据能不能被当前用户看到；这个报表是明细、汇总，还是时间展开。
如果把这些路径沉淀成 skill，AI 才不是每次都从零开始猜。
对我们正在规划的报表编辑器来说，这也是一个方向。AI 可以帮用户推荐模板和配置，但它不应该直接决定结果，更不应该绕过权限和治理规则。它应该在系统允许的边界里工作，把推荐理由、不确定项、字段匹配关系都展示出来，让用户能看见它是怎么来的。
这比单纯生成一个漂亮的配置结果更重要。
最后还是要验证
不要轻易相信那种”一问就有答案”的数据产品。
尤其是企业数据。
一个结果出来以后，系统最好能让人继续往下看：用了哪个数据集，哪些字段，什么口径，数据更新时间是什么，是否按当前用户的数据权限过滤，有哪些字段是 AI 不确定但强行匹配的。
如果这些都看不到，AI 查数就会变成一个更聪明的黑盒。
这对数据治理不是好事。
过去人工做报表，至少大家知道去问谁：这个口径谁定的，这张表谁维护的，这个字段为什么这么算。
到了 AI 自助报表，如果所有东西都被包装成一句自然语言回答或一个自动生成的报表，责任链反而更模糊。
所以，AI 构建报表之前，企业要先把数据讲清楚。
讲清楚哪些表是权威来源；指标怎么算；组织、项目这些基础对象怎么统一；字段能不能用、什么时候用、不能怎么用；结果怎么验证，错了以后谁来修。
AI 能让报表构建更快，这一点我不怀疑。
但如果底层数据和语义没治理好，它也只是更快地给出一个看起来像答案的答案。