95% 的业务分析交给 AI 后，Anthropic 数据团队做对了什么？

一、自助查数，为什么一直这么难？

做过数据的人都知道，「让业务自己查数」听起来很美，落地却很痛。

常见有两条路：

第一条：把表做得又宽又全。
一张大宽表、一堆反规范化视图，非技术同事至少能点一点。但业务一长大，同名不同义、同义不同表就越来越多。「收入」「活跃用户」到底指什么，十个人可能有八个答案。

第二条：给每个团队单独做环境。
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