Anthropic内部数据分析被AI接管95%，他们是怎么做到的？一文拆解清楚，Anthropic 数据团队如何使用 Claude 自动化了 95% 的商业分析查询。文章涵盖了如何处理评估、消融实验和在线验证！文后有惊喜，A厂这时候还是很“OpenAI”的，自家的数据仓库Skill的框架全部分享出来了，我附在文章最后了，拿走不谢
让公司里的非技术同事自己查数据，这件事一直很难做。
要么把数据表做宽、做平，方便不懂SQL的人用，结果随着业务增长，各种口径不一致的视图越堆越多。要么给每个团队划出独立的数据环境，结果长尾的业务问题没人覆盖，每个团队各搞一套指标，互相割裂。
大模型的出现给了第三条路。但直接把Claude接到数据仓库上，让Agent自己跑，也会带来一个新问题：表面上很方便，实际上答案未必对。
刚开始觉得解放了，用不着人工处理那些零散的数据请求了。但很快就意识到，这套做法把业务方和底层的数据基础设施、文档、专业知识全都隔开了，而这些东西原本是引导他们找到正确数据集的关键。
Anthropic的做法是：95%的业务数据分析请求由Claude自动完成，整体准确率约95%。 把这些重复性的日常工作交给Claude之后，数据科学团队可以把精力放在因果建模、预测和机器学习这些更有价值的事情上。
他们和几十位重度Claude Code用户交流过，也见过各种各样的分析Agent设计模式，从中沉淀出了一套经验。这篇文章把这套方法拆解清楚了。
数据分析不是写代码
要理解分析Agent的挑战，可以先跟代码Agent对比一下。
写代码是一个开放的解题空间，模型的创造性在这里是加分项，文档和测试天然充当防止幻觉的护栏。分析查询不一样——往往只有一个正确答案，只来自一个正确的数据源，而且没有任何确定性的方式来证明答案是对的。
自助式业务数据分析，复杂性主要来自数据本身的模糊性。核心问题是：能不能把用户的问题准确映射到数据模型里具体的、最新的字段，并且知道怎么正确地使用它们。 如果这一步做对了，后面的SQL执行就是小事。
Anthropic总结出导致错误的三类主要失败模式：
一、概念与字段的映射模糊
数据模型里可能有几百个候选字段（乃至数百万个字段），Agent无法确定哪个最能回答用户的问题。比如统计活跃用户数：什么行为算活跃？要不要把欺诈用户算进去？回溯窗口用多长？
二、数据过期
数据源、业务定义、表结构在不断变化，Agent掌握的知识随之过期，开始给出表面看起来合理、实际上有偏差的答案。
三、检索失败
正确的信息可能就在数据模型里，也有完整的注释，但数据仓库的搜索空间实在太大，Agent就是找不到它。
Anthropic的分析Agent技术栈
针对这三类失败，Anthropic建了一套分层的数据技术栈，每一层专门对付一个或多个问题：
对付映射模糊 → 数据基础和可信数据源，把候选字段的范围收窄到唯一的权威答案
对付数据过期 → 维护和验证流程，让数据不会随着业务变化而腐烂
对付检索失败 → Skill，让Agent可靠地找到并正确使用那个权威答案
数据基础
确保分析Agent准确的最重要因素，是扎实的数据基础，包括数据仓库里的数据模型、转换逻辑、测试、表，以及描述它们的元数据。维度建模、左移测试、关键数据管道的新鲜度和完整性检查，这些传统的数据工程最佳实践依然重要，没有什么变化。
变化的是：数据模型的最终用户不再是数据专家，而是代表不同背景用户的Agent。 这带来一个挑战：结果的正确性无法依赖用户自己去验证，因为用户根本不了解底层。
有几个做法特别有效：
建立权威数据集。 最常见的失败，是Agent无法把一个概念（比如"产品X的收入"）映射到唯一正确的表、列和指标定义，因为往往有多个候选项，实现方式细微不同。解决方法是：维护少量、受强治理的逻辑模型，明确归属、面向消费、可被发现，然后坚决废弃那些近似的重复数据集。物理上的汇总表和缓存表仍然有存在意义，但应该是从权威模型机械派生出来的，不能作为并列的替代选项。目标是：当Agent搜索某个概念时，只找到一个权威答案。
执行标准，不能只靠约定。 只有靠工具强制执行（Agent在结构上被引导先查权威模型）、靠CI强制执行（绕过权威模型的改动无法通过代码审查）、靠规定强制执行（下游团队必须基于权威层构建，否则需要说明理由），数据基础才能真正稳住。没有执行机制的治理，很快就会退回到多个候选数据集共存的问题。
把所有产出放到一个代码库里。 防御不断变化的数据模型和业务逻辑，最主要的手段是把代码放在一起。几乎所有数据代码——建模、语义层、参考文档、权威看板定义——都在一个代码库里，CI检查保护跨层的完整性。如果一个建模变更会破坏下游看板或让某个文档化的指标失效，CI会标记出来，修复在同一个PR里完成。
把元数据当成一等公民的产品来维护。 代码Agent表现好，部分原因是代码库本身是可读的：README、类型签名、注释等等。数据仓库也可以做到同样的可读性，但前提是列和表的描述、权威指标定义、粒度文档、有效值范围、数据血缘、归属信息和模型分级，都要像维护转换逻辑本身一样严格地维护。这不是新洞见，但好的治理确实给Agent提供了选择正确数据集的关键上下文。
可信数据源
数据基础是数据仓库本身，可信数据源是Agent用来在仓库里导航的参考界面。这一层的目标是消除概念与字段之间的映射模糊，把业务方问题里的"周活跃用户"转化成数据模型里一个具体的、受治理的字段。
按照可信程度从高到低，有四类：
1. 语义层
编译好的指标和维度定义。如果一个问题能干净地映射到某个已定义指标，Agent调用一个函数就能得到一个数字，和公司其他所有地方产出的数字一致。Agent被强制要求（通过Skill指令）优先使用语义层。
有一个尝试过但行不通的做法值得记录：用大模型根据原始表和历史查询日志自动生成语义层指标定义。结果是生成了看起来合理的定义，但这些定义把原本要消除的那些歧义都编码进去了。建议：用Claude来生成文档，但定义本身要由人来负责。
2. 数据血缘和转换依赖图
当语义层覆盖不到某个问题时，血缘关系和基于引用次数的表排名，可以让Agent推断哪些上游模型为某个概念提供数据、哪些已经废弃、哪些粒度相同。这把"我不知道这个指标"变成了"我知道应该从哪个受治理的模型里聚合"。
3. 查询语料库
来自看板、Notebook和历史分析的SQL。直觉上这应该很有价值：这是每一个已经被正确回答过的问题的记录。但实际上，直接给Agent访问数以千计的历史查询，准确率的变化不到一个百分点。 非结构化的检索无法把新问题映射到正确的历史案例上。真正有用的做法，是把这些查询语料提炼成结构化的、按领域划分的参考文档和可复用的分析模式，写进Skill。查询历史是用来整理的原材料，不是Agent直接读取的数据源。
4. 业务上下文
这是大多数团队跳过的一层，也是Anthropic自己低估最久的一层。不了解业务的Agent，会回答用户问的问题，而不是用户想要的答案。它不知道"Q2发布"指的是哪个具体产品，不知道两个团队对同一个术语的定义不同，也不知道某个问题是因为周四有董事会会议才被提出来的。Anthropic把公司知识图谱接入进来，包括索引过的文档、路线图、决策记录和组织架构，让Agent能够解析这些隐性引用，提出更好的澄清问题。
这四类来源的共同失败模式和数据基础层一样：文档差或者文档过期。 Claude在弥补这个差距上非常有用（起草列描述、根据查询模式生成指标文档、在CI中标记没有文档的模型），但整理和归属权由人来管理。
Skill
可信数据源是Agent的声明性知识（即指标是什么意思），Skill是它的程序性知识：按什么顺序查哪些数据源、如何处理模糊的数据、一个完整的分析应该是什么样子。
在Claude Code里，[Skill]是一个Agent按需读取的Markdown文件夹。
Anthropic自己的经验是：不加Skill，Claude回答数据分析问题的准确率在评测集上不超过21%。加了Skill之后，整体准确率稳定在95%以上，某些领域能达到99%左右。
几个关键做法：
成对创建Skill。 知识型Skill作为顶层的轻量路由器，根据需要加载更多领域细节。它告诉Agent：先试语义层，如果没有覆盖，这里有大约30个参考文件，描述了该领域的相关表、列、JOIN关系和注意事项。这个路由器本质上是对检索失败问题的解答：不让Agent搜索一个有数百万字段的仓库，而是在写任何查询之前，先把范围收窄到几十个经过整理的文件。
行动手册型Skill（Unbook）则编码了资深分析师会遵循的流程：澄清问题、找到数据源（通过知识型Skill）、跑查询、然后把结果交给对抗性审查子Agent循环检验。它还打包了十几个可复用的分析模式（留存曲线、增长率分解、漏斗分析），让常见需求不必每次从头来过。
写好参考文档。 参考文档是面向大模型检索写的。描述表的粒度、范围和排除条件；描述注意事项的具体机制（比如：排除已知的免费邮件域名，但保留像anthropic.com这样的自定义域名）；加入明确的路由触发条件（比如：如果问题涉及实验提升效果，不要用原始事件计数）。不要写成容易过期的操作步骤。
下面是Anthropic用来创建大多数参考文档的模板框架：
# [领域] 数据表
## 快速参考
### 业务上下文 — [用大白话描述这个领域是什么]
### 记录粒度 — [一行记录代表什么]
### 标准过滤条件 — [该领域每个查询都需要应用的过滤器]
## 维度说明
- [关键维度的编码方式，以及同一个概念在不同表里的不同命名]
## 关键数据表
### [表名]
- **粒度**：[...] · **范围/排除**：[...]
- **使用场景**：[什么时候用、什么时候不用、JOIN键、必须应用的过滤器]
[... 每个受治理的表写一个小节 ...]
## 注意事项
- [资深分析师会提醒你的那些容易踩坑的地方]
## 最佳实践与常见查询模式
- [默认选择、标准维度、查询形式本身就是难点的典型模式]
## 交叉引用
- [负责相邻问题的其他领域文档]把Skill维护当成一等公民的工程任务。 Skill文档描述的是每天都在变化的数据模型，不主动维护，几周内就会出错。Anthropic曾经亲眼看到：上线时离线准确率约95%，一个月后跌到约65%，才意识到这是个工程问题需要认真对待。解决方案是：把Skill的Markdown文件和转换模型放在同一个代码库里，改模型的PR就是更新描述文档的PR。代码审查钩子会标记任何改动了报表模型但没有同时改动Skill文件的PR。现在约90%的数据模型PR都在同一个diff里包含了Skill的变更。
在所有界面保持一致。 同一个Skill必须在Slack、IDE、看板工具和独立的Agent会话里给出同样的答案。做到这一点的方式是：保持单一的权威来源（数据代码库），Skill变更自动同步。合并之后，Skill会同步到插件市场（供IDE用户使用）、云存储Blob（供读取单个文件的托管应用使用），并直接通过MCP以资源形式提供服务。
验证
验证是用来发现三类失败模式中哪个还在泄漏的机制。
离线评测
一个常见的现象：数据团队搭建了精心设计的分析环境，却没有任何流程来评估分析Agent的准确性。
离线评测是解决这个问题的方式，本质上就是简单的问答对。可以把它类比成机器学习模型的离线测试，不能告诉你在线系统的表现，但能让你发现明显的盲区。
Anthropic部署了两类离线评测。基于看板的评测：由Claude自动生成（再经人工校验），覆盖最常见的业务方问题。长尾评测：把业务上下文（路线图、表文档）喂给Claude，让它生成该领域其他合理的问题。每当业务方在某个对话线程里纠正Agent，这个纠正就成为候选评测用例，持续积累。
其他最佳实践：
固定基准值，防止漂移。 针对实时数据写的评测，在底层数字变动的瞬间就会过期。把每个评测固定到一个快照日期，针对稳定的事实表写，或者让评分器评判Agent生成的查询而不是它给出的数字。把评测套件接入CI，任何改动了依赖项的PR都会重新跑相关评测。
像存储监控数据一样存储评测结果，不要只留测试日志。 每次运行的结果都写进数据仓库的一张表，包含Skill版本、git SHA、模型ID、每个断言的通过或失败、Token数量和运行时间。这样，"这次改动有没有效果"这个问题变成了一个可以查询的问题，同时能得到时序数据，用来发现单次CI运行看不出来的缓慢退化。
按领域设置上线门槛。 某个领域的负责人，只有在他们那片评测集达到某个通过率阈值之后（最初设定的是约90%），才能向业务方宣布Agent可以使用。这强迫大家在用户看到失败之前先修好参考文档。
评测数量要合适。 合适的数量取决于业务领域的复杂度和底层数据模型的复杂度。校准方法是追踪离线准确率对在线准确率的预测效果：每个主题（比如增长）超过几十个评测用例之后，边际收益递减；而且随着新模型版本的迭代，这个上限还在下降。
离线评测的准确率应该接近100%。 每一个正确答案也应该能通过语义层得到。这个精度不代表系统不会产生错误答案，只是代表没有明显的盲区——前提是评测覆盖范围是合适的。
消融实验
每一个关于Skill结构的决策（暴露哪些数据源、某个子Agent的延迟是否值得、要不要把两个Skill合并），都通过固定离线评测集、只改变一个变量来做出，比较通过率的变化。每次运行只需要一个小时，能替代大量口头讨论。
1）把负面结果当成有价值的结论。 Anthropic最有用的一次消融实验，结论是负面的。他们给Agent开放了对整个看板、转换模型和分析Notebook SQL的直接grep访问（数千个文件），在对话记录里验证了Agent在每次回答之前确实读了这些文件，但准确率的变化不到一个百分点。然后检查了显而易见的混淆因素：对于那些答错的问题，答案在语料库里有没有？约80%的情况下有。知道答案在语料库里，能不能预测它接下来会答对？不能，回答正确率没有变化。信息就在那里，Agent也看了，就是用不上。
这一个实验告诉他们：瓶颈不在于能不能访问已有的工作，而在于结构（能不能把问题映射到正确的实体）。这个洞察重新调整了好几个月的工作优先级。
2）在PR粒度上做消融。每一次有意义的Skill改动，都在相关的评测切片上跑一次改前改后的对比，把差值写进PR描述里。这让"我改进了文档"变得可验证，也能捕捉到那种善意的改动反而让事情变差的情况。
3）记录一份有什么没用的清单。比如：在某个节点之后继续叠加文档打磨轮次（连续三轮净负面：文档越来越长，但并没有变得更好）；把对抗性审查器换成更便宜的模型来降低延迟（准确率的提升大部分消失了，速度却没有真正提升）。负面结果记录成本很低，能防止别人重复同样的实验。
在线验证
1）对抗性审查。部署一个Claude Skill来激进地质疑每个潜在最终答案的底层假设，在评测集上准确率提升了6%，代价是Token消耗增加32%，延迟增加72%。
2）来源标注页脚。每个回答都带一个页脚，注明数据来自哪个层级（语义层、权威参考文档还是原始表）、底层数据的新鲜程度以及模型的归属团队。这不会让答案变得更准确，但帮助使用方判断可信程度。"原始表，新鲜度未知"这样的页脚是一个提醒：在向上汇报之前先核实。这是目前为数不多的针对静默失败问题的缓解手段之一。
3）数据质量检查。Agent可能在用法上完全正确，但数据本身是错的。对被引用字段做基本的数据质量检查，确认它是最新的、完整的、没有异常，是基本的卫生要求。
4）被动监控。持续追踪两个生产信号：Agent查询通过语义层解决的比例，以及回答中出现纠正语言的比例（比如"那是错误的表"、"你没有应用欺诈过滤"）。两个信号都汇入一个看板，每周和离线通过率一起Review。
5）主动收集纠正案例。一个定时Agent每隔几小时扫描业务方的沟通渠道，发现类似的纠正语言后，起草对相关参考文档的一行修复，发起一个PR并@到对应的领域负责人。修复路径被故意设计得无聊：改一个Markdown文件，合并，自动同步到所有地方，不占用领域负责人太多时间。同样的纠正案例也会回流到离线评测集中。
6）没有完全解决的静默失败问题：答案是错的，但看起来合理，没有人提出异议就被直接用了。现有的缓解措施包括来源标注页脚、对发给高层的任何内容要求人工确认，以及为每个领域的核心KPI设置固定评测，每天与权威看板做对比检查。但Anthropic承认目前还没有一个完善的解决方案。
从零开始怎么做
如果是从零开始，几个权威数据集、几十个离线评测用例，加上一个轻量的知识型Skill，就能拿到大部分收益。本文介绍的其他内容，都是在这些基础上逐步叠加的。
在采用这套方法之前，可以先在组织内部对齐几个关键问题：
今天的准确性和未来的准确性，哪个更重要？ AI模型在快速进化。很多公司会为了弥补当前模型的短板而搭建大量基础设施，但这些设施可能在模型升级后就用不上了。了解模型的短板在哪里，然后等模型升级来填补这个空缺，基础设施负担要小得多，但不一定符合公司的风险偏好。
业务的复杂度以后会怎么变化？ 如果数据量不大、输出的消费方不多、数据模型大概率保持简单，有些流程就是过度设计。
输出结果的使用者有多懂技术？ 如果受众是数据科学家，他们能识别错误答案，那容错空间就大一些。如果受众完全不了解底层数据模型，要求就要严格得多。
愿意为提高准确率花多少钱？ 对抗性验证这样的流程能显著提升准确率，但通常意味着更高的成本和延迟。
对访问权限控制和内部数据隐私的底线在哪里？ Agent拥有的上下文越多，表现往往越好；但宽泛的数据访问权限与大多数公司的治理立场相冲突。这决定了是构建一个统一的Agent还是多个权限受限的Agent。
无论选择哪条路，Anthropic取得最大收益的地方始终是解决那三类失败：把模糊性收拢为唯一的权威答案，让这个答案容易被找到，以及在两者过期时发出信号。
附录：Skill File Skeleton
以下是Anthropic主要的数据仓库Skill的框架，真实文件的结构保留了下来，内部具体内容替换成了占位符。这份框架的目的是展示值得写下来的内容类型，不是用来直接复制的，但是参考性还是很强的，希望对你有用。
---
name: [warehouse-skill]
version: [x.y.z]
description: "如果用户询问与[公司]数据仓库相关的任何[业务领域列表]问题，
则调用此Skill。不要在[相邻工程任务]或没有数据仓库组件的问题上调用。"
---
# [数据仓库] Skill 说明
## 描述
安全有效执行[数据仓库]查询的唯一权威来源。
被其他列出的Skill引用，用于查询执行指导。
以数据分析师身份行动，提供战略洞察和数据驱动的建议，但在过程中寻求指引。
**职责范围外的决策**：[产品领域等] → 只提供数据，
声明"该决策属于[负责团队]的职责范围"，不表态也不编写代码修复。
## 执行查询
优先顺序：
1. **[托管连接]**（如可用）：[查询工具] / [Schema工具]
2. **[CLI备用方案]**（如已安装）：[默认项目，备用项目]
3. **两者均不可用** — 请用户进行身份验证，然后停止
---
# 语义层（必须的第一步）
受治理的语义层是每个数据问题的**强制默认路径** — 与[BI工具]产出相同的数字，
JOIN关系、粒度和过滤器都已内置。只有在语义层路径无法覆盖需求时，
才通过以下参考文档使用原始SQL作为**备用方案**。
## 必须遵循的工作流
1. **加载** — [在每种运行时环境中如何加载语义层，附备用方案]
2. **发现** — 按关键词搜索指标/维度；**务必检查分群**
（命名的权威人群过滤器 — 手写WHERE子句是最主要的错误来源）
3. **编译并运行** — 构建规格 → 编译成SQL → 执行
4. **回退** — 只有在发现阶段找不到相关指标或编译失败时
→ 通过`references/*.md`使用原始SQL（见下方第3部分）
> **不要过早放弃。** 不得以下列理由回退到原始SQL：
> - "[自定义日期过滤/队列]" → [已被时间维度规格覆盖]
> - "[需要JOIN]" → [指标层已封装其JOIN关系]
> - [3-4个Agent常用来跳过语义层的借口及其反驳]
### 日期窗口与时区 — 查询前先确定
- **截至日期与过去N天的对比**：[每种情况的约定]
- **"上周/上月"** → 最近一个完整的日历周/月，不是过去7/30天
- **默认时区**：[时区]；[某些报表汇总的例外情况]
- **数据新鲜度延迟**：[部分]表更新较晚 — 以MAX(date)为基准，不要用"昨天"
---
# 第1部分：必须了解（每次请求先读）
## 🚀 快速开始工作流
1. **先检查红色警报**：[受限/PII请求、受门控领域、需要额外验证的高风险请求]
2. **超出职责范围 — 上报，不要猜测**：[访问请求、管道故障排查、
过期看板、根因断言、产品/定价建议] → 引导至[负责团队]，不要回答
3. **澄清请求**：时间段、细分维度、该问题服务的业务决策
4. **检查现有看板**：[按领域划分的看板目录]
5. **识别数据来源**：[以下导航图；优先使用受治理/聚合表]
6. **执行分析**：[必须应用的过滤器 + 对抗性审查]
7. **交付洞察**：展示方法论，区分观察结论和解读性结论
## 🏢 业务上下文
### 实体消歧义（必须澄清）
- **"[术语A]"可能指**：[实体1]或[实体2] — 必须澄清是哪个
- **"[术语B]"可能指**：[实体1] → [实体2] → [实体3]（一对多链）
- **"用户"**：[哪个标识符能得到准确计数，哪个会虚高]
### 业务术语
- [当前产品名称与已废弃的别名，这些别名仍以冻结值出现在数据层中
— 用新名称写，用旧名称过滤]
- [关键内部缩略词]
- **[核心指标]计算**：[月度/默认窗口/领先指标]
- **遇到不熟悉的术语 — 搜索[内部文档]，不要猜测**
### 数据完整性要求 ⚠️
- **禁止**：编造数据/字段；做出超出数据所示范围的推测性断言
- **必须**：使用安全除法；区分观察结论（"数据显示X"）
和解读性结论（"这表明Y"）；标记数据局限性
---
# 第2部分：操作方法（执行过程中遵循）
## 🔧 技术执行指南
- [托管连接工具和CLI调用详情]
- **PII保护**：对于受限数据，将SQL返回给用户自行运行
— 不要返回查询结果
## 📊 分析最佳实践指南
1. 查询前先澄清需求
2. 展示工作过程（过滤条件、包含/排除项、数据新鲜度）
3. 说清楚分母
4. 考虑样本偏差
5. 关联到业务影响
6. **对抗性SQL审查（必须执行）** — 在每次最终回答前生成[sql-reviewer]子Agent；
阻塞性问题必须修复并重新审查；不能自我认证
7. **带来源信息地汇报** — 每个回答末尾附上脚注：
> **来源**：[语义层 | 受治理表 | 原始探索] ·
> **可信度**：[级别] · **已审查**：[审查方 ✓，第N轮] ·
> **数据新鲜度**：[数据中的最大日期] · **归属**：[负责团队]
---
# 第3部分：数据参考资料与资源
## 📚 知识库导航
### [领域A] → `references/[domain_a].md`
- **适用**：[哪类问题]
- **关键表**：[...]
- **看板**：`references/[domain_a]_dashboards.json`
### [领域B] → `references/[domain_b].md`
- **适用**：[...]
[... 每个业务领域一条 — 总计约数十条 ...]
## ⚠️ 故障排查指南
### 信息缺失时
- [表不存在/访问被拒绝/文档过期/枚举值未知 → 该怎么做]
### 字段命名注意事项
- 使用`[field_x_v2]`，不要用`[field_x]`
- [两个名称相似的表以不同粒度报告同一指标 — 应该用哪个]
- [哪个来源是核心指标的权威数据源]
- [… 更多来自实战经验的简短说明 …]