一、自助查数，为什么一直这么难？
做过数据的人都知道，「让业务自己查数」听起来很美，落地却很痛。
常见有两条路：
第一条：把表做得又宽又全。
一张大宽表、一堆反规范化视图，非技术同事至少能点一点。但业务一长大，同名不同义、同义不同表就越来越多。「收入」「活跃用户」到底指什么，十个人可能有八个答案。
第二条：给每个团队单独做环境。
Finance 一套看板，Growth 一套看板，各管各的。短期能用，长期是指标膨胀、看板堆砌，长尾问题还是回到数据团队手里。
大模型出现后，第三条路来了：让 AI 直接连数据仓库查数。
初看很解放人力------再也不用回「帮我拉一下上周 DAU」。但 Anthropic 自己踩过坑：如果只是把 Claude 指向数仓、让它自由发挥，很容易产生一种**「看起来很精确、实际上口径错了」**的假象。
业务同事看不懂底层逻辑，也没法像数据分析师那样一眼发现「这张表不该这么 join」。解放临时请求的兴奋，很快会变成另一种焦虑：答案出了，但没人敢信。
Anthropic 数据科学和数据工程团队最终把这条路走通了：内部约 95% 的业务分析查询由 Claude 自动化完成，整体准确率约 95%。数据团队从重复拉数里抽身，去做因果建模、预测和机器学习这类更有价值的事。
他们最近把这套做法写成了一篇实践分享。读完最值得带走的，不是某个工具配置，而是一套**把 AI 查数从「能跑」做到「敢用」**的方法论。
二、一个反直觉的判断：查数，和写代码不是一回事
很多人第一反应是：AI 写 SQL 已经很强了，接个数仓不就行了吗？
Anthropic 的核心判断恰恰相反：
分析准不准，主要不是代码生成问题，而是上下文和验证问题。
写代码时，解法可以多样，测试、文档、类型系统天然是护栏。模型可以「创造性地」解决问题。
查数不一样。同一个业务问题，往往只有一个正确答案、一套正确口径，而且很难像单元测试那样自动证明「一定对」。
所以他们把问题拆得很清楚：
用户问的「Q2 上线后收入怎么样」------「Q2 上线」指哪个产品？
「活跃用户」------什么行为算活跃？要不要排除异常账号？看 7 天还是 30 天？
这些问题搞对了，后面的 SQL 反而变得简单。
真正难的，是把自然语言问题，准确映射到数据模型里具体、最新、治理过的实体上。
三、三类错误，占了绝大多数
Anthropic 把分析 Agent 的失败模式归纳成三类。理解这三类，比背任何提示词模板都重要。
1. 概念对不上表
数据仓库里可能有几百张「看起来都能用」的表、几百万个字段。用户问「收入」，Agent 可能在十几个候选里选错一个------每个都「有点像 revenue」，但过滤条件、粒度、是否含税 subtly 不同。
这是最常见的错误来源。
2. 信息过期了
表结构在变、业务定义在变、字段含义在变。Agent 读到的文档、操作手册里的说明，如果没人维护，几周后就开始返回「语法正确、口径错误」的答案。
他们有过真实经历：上线时离线准确率约 95%，操作手册不维护一个月后，掉到约 65%。
3. 该用的资料没找到
有时候正确答案其实已经在仓库里了------列描述写清楚了、参考文档也有------但搜索空间太大，Agent 就是没检索到、没用上。
这三类问题，也对应他们后来搭系统的三个设计目标：
→ 每个概念只对应一个标准答案
→ 变更和文档同步维护
→ 别让 Agent 在百万字段里裸搜
四、四层架构：从数据底座到持续验证
Anthropic 的解法不是更大的提示词，而是一套 Agent 分析栈。可以把它理解成四层：
数据底座 → 标准答案来源 → 操作手册 → 持续检验第一层：先把数据底座整理好
这一层主要解决「概念对不上表」。
几个关键做法：
建立少量「官方标准表 / 标准指标」。
「收入」只能指向一个治理过的数据集，而不是四十个看似合理的候选。物理汇总表、缓存可以有，但必须从标准模型机械派生，不能和标准层并列存在。
治理要能被强制执行。
靠自觉不够。要靠工具路由（Agent 结构上优先走标准层）、持续集成拦截（绕过标准层的改动过不了审查）、组织规定（下游必须基于治理层开发，否则要说明原因）。
代码、文档、看板定义放同一个仓库。
改模型的合并请求，必须同步改描述它的文档。如果建模变更会破坏下游看板或使某个指标定义失效，持续集成要拦下来，修复和模型变更同一个合并请求合入。
元数据要当正经产品维护。
列描述、一行代表什么、有效取值范围、血缘、负责人、模型分级------这些和转换逻辑本身一样重要。代码库之所以对编程 Agent 友好，是因为说明文档、类型、注释让代码「可读」。数仓也可以同样可读，但前提是有人持续维护。
第二层：告诉 AI「标准答案从哪查」
如果数据底座是仓库本身，这一层就是 Agent 查数时查阅的「参考书目」。
按可靠程度，大致有四类：
指标层（语义层）------首选。
如果问题能干净地映射到一个已定义指标，Agent 调函数拿数，和 BI 工具、看板是同一个数字。他们的 Agent 结构上被要求必须先走语义层。
这里有个重要反例：他们试过用大模型从原始表和查询日志自动生成指标定义，结果产出一堆「看起来合理、实际把歧义编码进去了」的定义，评测结果是净负面。文档可以让 Claude 起草，定义必须人定。
血缘和转换图------语义层覆盖不到时的备选。
帮助 Agent 判断：哪些上游模型支撑这个概念、哪些已废弃、哪些共享同一粒度。
历史 SQL 语料------直觉上很有价值，实际直接检索几乎没用。
他们做过对照实验：给 Agent 直接搜索全公司看板、转换脚本、笔记本里的 SQL（几千个文件），并验证它确实读了。准确率变化 不到 1 个百分点。
更关键的是：错题里约 80% 的正确答案其实就在语料里，Agent 也读到了，还是用错。瓶颈是结构（映射），不是访问（权限）。
正确用法：把历史 SQL 提炼成按领域组织的参考文档和分析模式，放进操作手册，而不是让 Agent 直接搜原始语料。
业务上下文------最常被低估的一层。
Agent 不懂业务，就会答「用户字面问的」，而不是「用户实际想问的」。不知道「Q2 上线」指哪个产品、不知道两个团队对同一术语定义不同、不知道这个问题是因为周四有董事会会议。
他们接入了公司知识图谱：文档、路线图、决策记录、组织结构，用来消除模糊指代，问更好的澄清问题。
第三层：给 AI 写「操作手册」------这是最大的杠杆
在 Claude Code 里，Skill（技能）本质上是一组按需读取的 Markdown 文件。
没有 Skill 时，他们评测上的准确率不超过 21%。
加上 Skill 后，整体稳定到 95% 以上，部分领域接近 99%。
Skill 分两类，配合使用：
知识型 Skill------顶层路由。
不让 Agent 搜索百万字段仓库，而是先缩到几十个精选参考文件。「先尝试语义层；如果没覆盖，这里有约 30 个本领域参考文件，描述相关表、字段、关联和常见坑。」
流程型 Skill------资深分析师的工作流。
澄清问题 → 通过知识 Skill 找来源 → 跑查询 → 结果过对抗审查子 Agent。还打包了常用分析模式（留存曲线、率分解、漏斗分析），避免每次从零发明。
参考文档是专门为 LLM 检索写的，不是给人扫一眼的知识库：
一行代表什么、适用范围和排除项
常见坑的具体机制（「排除已知免费邮箱域名，但保留 anthropic.com 这类自定义域名」）
明确的路由触发（「如果问题关于实验提升... 不要用于原始事件计数」）
不写容易过期的逐步配方
Skill 维护必须是一等公民。
Skill 描述的数据模型每天都在变。他们的解法是：Skill 文档和转换模型同仓库，改报表模型的合并请求如果不改 Skill 文件，代码审查钩子会标记。现在约 90% 的数据模型合并请求包含 Skill 变更。
还要保证 Slack、IDE、看板工具、独立 Agent 会话同一 Skill、同一答案。单一标准来源，合并后自动同步到插件市场、云存储、MCP 资源服务。
第四层：持续检验------知道系统还在不在线
离线评测
没有评测，再完善的分析环境也是盲飞。
两类评测：
：Claude 自动生成常见业务方问题，人工校验
：喂业务上下文，生成覆盖长尾的合理问题
用户在线纠错（「表用错了」「漏了欺诈过滤」）也会收集成评测候选。
几个实践：
，别对着实时数据写评测------数一变就过期
，不是测试日志------Skill 版本、代码版本、模型 ID、通过/失败、令牌数、耗时都可查
：业务域负责人的评测切片没过阈值（他们初期约 90%），不能对业务方宣布上线
------不是说线上不会错，而是说没有明显缺口
对照实验：用实验代替争论
每个结构性决策------暴露哪些来源、子 Agent 是否值得额外延迟、两个 Skill 要不要合并------都固定评测集，只变一个组件，比通过率。
最有价值的实验之一是否定结果：全量 SQL 搜索几乎无效。这改变了他们数月的路线图。
还有两个「明确记录的不奏效方案」：
文档精炼堆过三轮后连续净负面（文档变长，没变好）
对抗审查换更便宜的模型省延迟------准确率收益丢大半，速度提升也不明显
在线验证
：评测上 +6% 准确率，但 +32% 令牌、+72% 延迟------取舍要算清楚
：每个回答带来源层级（语义层 / 治理表 / 原始探索）、数据新鲜度、负责人------不使答案更对，但帮助使用者判断可信度
：语义层命中比例、用户纠错语言比例，每周审查
：定时扫业务方频道，起草一行参考文档修复，开合并请求给业务域负责人------修复路径故意简单：改 Markdown、合并、自动同步
仍未稳健解决的：静默错误。
答案错，但看起来合理，没人提出异议。现有缓解措施：来源脚注、面向管理层的结论需人工签字、核心指标每日与权威看板对照检查。
五、如果从零开始，最少做什么？
Anthropic 的建议很务实：
少量官方标准数据集 + 几十个离线评测 + 一份薄的知识 Skill，就能拿到大部分收益。本文其余内容，是这些建好之后逐步加的。
落地前，他们还建议团队先对齐五个问题：
------是否为当前模型短板建大量基础设施，还是等模型进步填缺口？
------数据少、消费者少、模型简单，很多流程可能是过度设计
------数据科学家能识别错误，容忍度更高
------对抗验证有效但贵且慢
------一个广域上下文 Agent，还是多个分权限 Agent？
六、给数据团队和 AI 实践者的几点启示
Anthropic 这篇分享，本质上是在回答一个问题：
大模型时代的自助分析，核心工程问题是什么？
不是提示词工程，不是 SQL 生成，而是：
-
把歧义收成单一治理答案
-
让 Agent 可靠找到这份答案
-
及时发现答案过期了
几个数字值得记住：
（图）
最后一句话：
数据治理没有因为 AI 而变不重要，反而更重要了。
因为现在的「终端用户」，不再只是会 SQL 的数据分析师，而是代表各种业务同僚做决定的 Agent------他们没法自己验算底层对不对。
如果你正在考虑用 Claude、Cursor 或其他 Agent 做内部查数，别从「接仓库」开始。
从三个标准数据集、一份操作手册、几十个测试问题开始。
那才是真正能「敢用」的起点。
本文基于 Anthropic 官方博客 How Anthropic enables self-service data analytics with Claude 整理解读。原文作者为 Chen Chang、Clement Peng、Justin Leder、Johanne Jiao、Josh Cherry 等数据科学与数据工程团队成员。
原文地址：
https://claude.com/blog/how-anthropic-enables-self-service-data-analytics-with-claude