Anthropic 最新博客：95% 的数据分析，都已经交给了 Claude

公众号名称：AGI Hunt

作者名称：Anthropic

发布时间：2026-06-05 23:51

Anthropic 的数据科学团队昨天发了篇博客：他们内部 95% 的业务数据分析查询，现在都已经由 Claude 自动完成了，准确率大约是 95%。

数据团队也因此能腾出了手来，专注做因果建模、预测和机器学习这些更有价值的工作。

在这篇博客中，Anthropic 公开了整个技术栈的细节，包括踩过的坑、试错的数据……以及一个让准确率从 21% 飙到 95% 的关键发现。

数据不是代码

博客开头指出：让 AI 做数据分析，和让 AI 写代码，是完全不同的事。

写代码是个开放的解空间，模型可以发挥创造力，文档和测试提供了天然的护栏来防止幻觉。

但数据分析的不同之处在于：它往往只有一个正确答案，用的是一个正确的数据源，却且没有确定性的方式来证明结果是对的。

它的核心挑战在于：把用户的问题映射到数据模型中具体的、最新的实体上，并且知道正确的使用方式。

团队总结出了三种典型的翻车模式：

• 概念和实体的歧义：数据仓库里有几百个候选字段，Agent 经常选错。比如「活跃用户」这个概念，背后可能对应十几种不同的定义
• 数据过时：数据源、定义、schema 等一直在变，Agent 的知识很快就落伍了
• 检索失败：正确的信息明明就在那里，但 Agent 在庞大的搜索空间里就愣是没找到

四层架构

针对这三种失败模式，Anthropic 搭了一个四层的 Agentic 数据分析栈。

从下往上看：

1数据基建，解决的是「有没有靠谱数据」的问题。维度建模、数据治理、元数据管理，这些传统数据工程的老本行，在 Agent 时代反而更重要了。

2真相来源，解决的是「Agent 去哪查」的问题。语义层、血缘图、历史查询库、业务上下文，按信任度排好优先级，让 Agent 有路可循。

3Skills，解决的是「Agent 怎么干活」的问题。把资深分析师的工作流程编码成可执行的指令，告诉 Agent 先查什么、后查什么、遇到歧义怎么处理。

4验证，解决的是「怎么知道 Agent 干得对不对」的问题。离线评估、在线监控、对抗性审查、主动纠错，形成闭环。

先打地基

数据工程的老本行依然重要：维度建模、前置测试、数据新鲜度和完整性检查。只不过现在的「用户」变了，不再是写 SQL 的分析师，而是一个替非技术人员跑数的 Agent。

这里的几个关键法是做：

• 建立规范数据集：把多个相似的表合并成少量高度治理的逻辑模型。目标是让每个概念只对应一个确定的答案，而不是一堆候选项
• 强制执行标准：用工具、CI 检查和硬性规定来确保规范模型不会被绕过
• 把所有东西放在一个仓库里：数据建模、语义层、参考文档、仪表盘定义，全部放在同一个 repo，用 CI 检查来保证跨层一致性
• 元数据跟代码一样重要：字段描述、指标定义、粒度文档、血缘关系、所有权、模型分级，都需要跟数据转换采用同等严格的管理

真相在哪

Agent 查数据的时候得有地方查。Anthropic 准备了四层信息来源，按可信度从高到低排列：

语义层是第一优先级。

里面存的是编译好的指标和维度定义，Agent 被要求每次都先来这里找答案。

不过这里有个教训是：团队一开始想偷懒，让 Claude 从原始表自动生成指标定义。结果发现……它只是把已有的歧义原封不动搬进来了，并没有消除歧义。

所以指标定义这件事，还是得人来把关。

血缘和转换图排第二。

这一层负责帮 Agent 搞清楚上游模型的来龙去脉：哪些表已经废弃了，数据应该在哪个聚合层级去查。

历史查询库排第三。

它们来自仪表盘和 notebook 里跑过的 SQL。但直接拿这些 SQL 做检索，准确率只提升了不到一个百分点。真正有效的做法，是把历史查询提炼成结构化的参考文档和可复用的查询模式。

业务上下文排第四。

这一层是公司内部的知识图谱，包括文档、路线图、决策日志、组织架构之类的。帮 Agent 理解那些没人会写进文档、但老员工都知道的业务背景。

这四层有一个共同的软肋：文档写得差，或者，已经过时了。

这你应该比较有经验了，Claude 很擅长起草文档，但后面的维护这事，还是得靠人了。

21% 到 95%

这是整篇博客里最值得关注的数据。

Skills 层编码的是过程性知识：先查哪个数据源、怎么处理歧义、完成的分析长什么样。

没有 Skills 的时候，Claude 在分析问题上的准确率不超过 21%。加了 Skills 之后，整体准确率稳定在 95% 以上，某些领域甚至达到 99%。

从 21% 到 95%，从「偶尔蒙对」到「基本可以信赖」，这个提升靠的是 Skills。

具体怎么做呢？

团队用了「成对 Skills」（pairwise skills）的方法：

一个 knowledge skill 充当路由器，指向某个领域的约 30 个参考文件；一个 unbook skill 编码资深分析师的工作流程，包括澄清需求（clarify）、查找数据源（find sources）、执行查询（run query）、对抗性审查（adversarial review）。

参考文档的写法也非常讲究：描述表的粒度、范围、排除条件、常见陷阱和路由触发器，但不要写死步骤，因为步骤会过时。里面还会打包一些可复用的分析模式，比如留存曲线、漏斗分析、指标拆解之类的。

另外还有一点是：同一个 Skill 在不同入口要给出一样的答案。

不管用户是在 Slack 里问、在 IDE 里查、还是在仪表盘上看，背后用的应该是同一个规范数据源。一个权威来源会自动同步到各个渠道，避免答案打架。

还有一个关键实践是，要把 Skill 的维护当成工程工作来对待。 Skill 文件和数据转换模型放在同一个 repo，代码审查钩子会标记出「改了模型但没改 Skill」的情况。

现在 Anthropic 大约 90% 的数据 PR 都包含 Skill 的变更。

Skill 文件模板

博客附录给了一份完整的 Skill 文件骨架，我也翻译了过来，你可以拿来改改，就能直接使用。结构上一共分为四大块：触发条件和范围定义、语义层优先路径、必知事项（业务上下文 + 术语 + 数据完整性）、执行指南和知识库导航。

下面是完整模板（方括号里的内容，请根据自己的业务进行替换）：

yaml

--- name: [数据仓库-skill] version: [x.y.z] description: “当用户要求查询[公司名]的数据仓库，涉及[业务领域列表] 相关问题时，调用此 Skill。 不要用于[相邻的工程任务]或与数据仓库无关的问题。”

开头用 YAML frontmatter 定义触发条件，明确告诉 Agent 什么时候该用、什么时候不该用。

然后是正文部分：

markdown

# [数据仓库] Skill 指令

说明

这是安全、有效查询[数据仓库]的唯一权威来源。 其他 Skills [列表] 在需要执行查询时会引用本 Skill。

你的角色是数据分析师，提供战略洞察和数据驱动的建议， 但在过程中要主动寻求指导。

**超出范围的决策**：[产品方向等] → 只展示数据， 注明”该决策由[负责团队]做主”，不要表态，也不要写代码修复。

执行查询

优先级：

1. **[托管连接]**（如果可用）：[查询工具] / [schema 工具]
2. **[CLI 备选]**（如果已安装）：[默认项目, 备选项目]
3. **都没有** → 要求用户先认证，然后停止

这里值得一学的是「超出范围的决策」这一段：明确告诉 Agent 哪些决策不归它管，只提供数据，不下判断。制定这个边界后，就能避免 Agent 越权给建议。

接下来是整个模板的核心，语义层优先路径：

markdown

# 语义层（必须优先走这条路）

治理过的语义层是每个数据问题的**强制默认路径**， 和[BI 工具]出的数字一致，join/粒度/过滤条件都已内置。 只有语义层确实覆盖不了时，才退回到下面参考文档里的裸 SQL。

必须遵循的工作流

1. **加载** — [在不同运行环境中加载语义层的方法和备选方案]
2. **检索** — 按关键词搜索指标和维度； **必须检查 segments**（已命名的规范人群过滤器 — 手写 WHERE 子句是最主要的出错模式）
3. **编译 + 执行** — 构建查询规格 → 编译为 SQL → 执行
4. **退回裸 SQL** — 仅在检索不到相关指标、 或编译失败时 → 使用 `references/*.md` 中的裸 SQL

最后还有一条硬性规定，可以说是整个 Skill 里最值得注意的地方：

markdown

> **不要轻易放弃语义层。** 以下理由不构成退回裸 SQL 的借口：

• “[需要自定义日期筛选 / cohort 分组]” → [时间维度规格已经覆盖了]
• “[需要 join]” → [语义层已经封装了所需的 join 逻辑]
• [再列 3-4 个 Agent 常用来跳过语义层的借口，逐一反驳]

团队发现 Agent 会找各种借口绕开语义层去写裸 SQL，比如「这个查询需要自定义日期筛选」「需要 join」之类的。但这些语义层其实都能处理，所以模板里直接把这些常见借口列出来，一一反驳，堵死 Agent 绕路的可能。

手写 WHERE 子句是最常见的出错模式，模板里专门强调了 always check segments，让 Agent 用已有的规范 population filter，不要自己瞎编。

日期和时区的处理方面，也有明确规范：

markdown

### 日期窗口与时区 — 查询之前先确认

• **截止日期 vs 滚动 N 天**：[各自的约定]
• **「上周/上月」** → 指最近一个完整的自然周/自然月， 不是倒推 7 天或 30 天
• **默认时区**：[时区]；[某些报表汇总的例外]
• **数据延迟**：[部分]表的数据会晚到 — 以 MAX(date) 为锚点，不要假设「昨天」的数据已就绪

「上周」到底是自然周还是过去 7 天？这种细节上的歧义，可是分析出错的高发区。模板要求在查询之前就把这些约定定死。

然后是 PART 1：必知事项，每个请求都要先过一遍：

markdown

# 第一部分：必知事项（每个请求都要先过一遍）

快速启动流程

1. **先检查红线**：[涉及隐私/PII 的请求、 受限领域、高风险分析需要额外校验]
2. **超范围的问题，交给别人，不要瞎猜**：[权限申请、 管道故障排查、仪表盘过期、根因断言、产品/定价建议] → 转给[负责团队]，自己不要回答
3. **澄清需求**：时间范围、细分维度、 这个分析支撑的是什么业务决策
4. **先查现有仪表盘**：[按领域的仪表盘目录]
5. **确认数据源**：[参见下方导航地图； 优先用治理过的/聚合好的表]
6. **执行分析**：[必须加的过滤条件 + 对抗性审查]
7. **交付洞察**：展示方法论， 区分观察（「数据显示 X」）和解读（「这可能意味着 Y」）

markdown

## 业务上下文

实体歧义消解（必须先确认）

• **「[术语 A]」可能指**：[实体 1] 或 [实体 2] — 必须先跟用户确认是哪个
• **「[术语 B]」可能指**：[实体 1] → [实体 2] → [实体 3] （一对多链路）
• **「用户」**：[用哪个 ID 字段计数才准确， 哪些 ID 会导致数字虚高]

业务术语

• [当前产品名 vs 已废弃但仍作为冻结值存在于 数据层中的旧名称 — 写报告用新名，查数据用旧名]
• [关键内部缩写]
• **[核心指标]的计算方式**： [月度口径 / 默认时间窗口 / 先行指标]
• **遇到不熟悉的术语 — 去[内部文档]搜索，不要猜**

数据完整性要求

• **绝对不能**：编造数据或字段； 对数据之外的东西做推测性断言
• **必须做到**：使用安全除法（防止除以零）； 区分观察（「数据显示 X」）和解读（「这说明 Y」）； 主动标注数据局限性

实体歧义消解这一节，也尤其关键。比如「用户」到底是指注册用户还是活跃用户？用哪个 ID 字段计数才不会虚高？这些歧义如果不在 Skill 里写死，Agent 就会在每次调用时胡乱猜一个了。

接下来是 PART 2：执行指南：

markdown

# 第二部分：怎么做（执行过程中遵循）

技术执行指南

• [托管连接工具和 CLI 调用方式]
• **PII 保护**：涉及敏感数据时，只返回 SQL 让用户自己执行，不要返回查询结果

分析最佳实践

1. 查询之前先澄清需求
2. 展示你的工作过程（过滤条件、包含/排除规则、数据新鲜度）
3. 确认分母口径
4. 考虑样本偏差
5. 关联到业务影响
6. **对抗性 SQL 审查（强制）** — 每条查询在给出最终答案前， 都必须调用 [sql-reviewer] 子 Agent 审查； 发现阻断性问题必须修复后重审；不能自己审自己
7. **带来源标注的报告** — 每个回答都以这样的 footer 结尾：

   **来源：**[语义层 | 治理表 | 裸表探索] · **置信度：**[层级] · **审查：**[审查者 ✓, 第 N 轮] · **新鲜度：**[数据中的最大日期] · **负责人：**[负责团队]

这里有两个亮点：一是 PII 保护，涉及敏感数据时只返回 SQL 让用户自己跑，不返回结果；二是强制对抗性审查，每条查询都要让一个 sql-reviewer 子 Agent 先审一遍，不能自己审自己。

最后是 PART 3：知识库导航和排障：

markdown

# 第三部分：数据参考与资源

知识库导航

[领域 A] → `references/[domain_a].md`

• **适用问题**：[哪类问题该来这里找]
• **核心表**：[…]
• **仪表盘**：`references/[domain_a]_dashboards.json`

[领域 B] → `references/[domain_b].md`

• **适用问题**：[…] [… 每个业务领域一个入口 …]

排障指南

找不到信息时怎么办

• [表不存在 / 权限不足 / 文档过期 / 遇到未知的枚举值 → 分别怎么处理]

字段命名踩坑记录

• 用 `[field_x_v2]`，不要用 `[field_x]`
• [两张名字相似的表报告同一个指标， 但粒度不同 — 该用哪张]
• [两个都说得通的数据源， 哪个才是核心指标的规范来源]
• [… 还有十几条血泪教训 …]

字段命名踩坑记录这一节，应该是整个 Skill 里最「血泪」的部分了，我估计每一条背后都是真实踩过的坑。

参考文档模板

除了 Skill 文件本身，博客还给了一份参考文档的写法模板。每个业务领域一个参考文件，结构是这样的：

markdown

# [领域名] 数据表

速查

业务背景 — [用大白话解释这个领域是干什么的]

实体粒度 — [一行数据代表什么]

标准清洗过滤条件

— [这个领域下每条查询都要加的过滤条件]

维度

• [关键维度是怎么编码的，同一个概念在不同表里 叫什么名字]

核心表

[table_name]

• **粒度**：[…] · **范围/排除**：[…]
• **用法**：[什么时候用、什么时候不该用、 join key 是什么、必须加的过滤条件] [… 每张治理过的表写一小段 …]

踩坑记录

• [资深分析师会提醒你注意的那些出错模式]

最佳实践 / 常见查询模式

• [默认选择、标准切分方式、 那些查询写法本身就是难点的现成模板]

关联文档

• [相邻领域的参考文档，有些问题归它们管]

这份模板的设计思路是：先给 Agent 一个快速定位的入口（速查），再给每张表的使用说明（什么时候用、什么时候不该用、join key 是什么、必须加的过滤条件），最后是踩坑记录和常见查询模式。

踩坑记录这一节特别重要。

资深分析师会提醒你「这两张表名字差不多，但粒度不同，别用错了」「这个字段已经废弃了，用 v2 那个」。这些知识以前靠口口相传，现在写进了参考文档后，Agent 就能从中学到了。

验证的学问

光有准确率不够，还得能验证、能监控、能持续改进。

离线评估分两类：基于仪表盘的评估（Claude 自动生成，人工验证）覆盖常见问题；长尾评估（Claude 根据业务上下文生成听起来合理的问题）覆盖边缘场景。

最佳实践是把 ground truth 固定到快照日期防止漂移，每个评估结果存储 Skill 版本、git SHA、模型 ID、token 消耗。上线门槛按领域定，大约在 90% 左右。过了几十条评估之后边际收益递减，离线准确率应该接近 100%。

消融实验方面，团队直接给 Agent 访问了数千个仪表盘、转换脚本和 notebook SQL 文件的权限。

结果……

准确率几乎没动，只提升了不到一个百分点。

而且 80% 没回答上来的问题，答案其实就在语料库里，Agent 读到了却没用上。

瓶颈不在于能不能看到数据，而在于能不能把问题映射到正确的实体上。 这也验证了为什么 Skills 的效果那么显著，因为它解决的恰好是映射问题。

在线验证方面有这么几招：

• 对抗性审查：一个专门的 Claude Skill 挑战所有假设，准确率提升了 6%，但代价是多用 32% 的 token 和 72% 的延迟
• 来源标注：每条回复都标注数据来源层级（语义层 > 策展参考 > 原始表）、数据新鲜度和模型负责人
• 数据质量检查：验证引用的字段是否最新且完整
• 被动监控：追踪语义层的解析命中率，以及回复中出现纠正语言的频率
• 主动纠错：定时 Agent 扫描 Slack 频道，发现用户的纠正语言后自动起草参考文档的修复，开 PR 给领域负责人

如何开始

博客最后给了一个务实的建议：从零开始的团队，几个规范数据集、几十个离线评估、一个精简的知识 Skill，就能得到大部分收益。

但在动手之前，团队建议请先想清楚几个问题：

• 当下的正确性要求有多高？未来模型进步了还需要这么高吗？
• 业务复杂度会怎么变？
• 受众的技术水平如何？
• 愿意为准确率提升付出多少成本？（对抗性审查能提升 6% 但增加 32% 的 token 消耗和 72% 的延迟）
• 数据访问控制和隐私有什么要求？

读完这篇博客的最大收获是：把歧义折叠成唯一的确定答案，确保信息能被发现，在信息过时时及时标记、发出警告。

三个失败模式，对应三层解法，而发挥了最大作用的，是 Skills。

如果你做过数据工程或数据分析的工作，应该会知道：数据分析最难的部分从来都不在写 SQL，而在于知道该查哪张表、用哪个字段、那个字段到底是什么意思。

以前这些知识都在资深分析师的脑子里，Anthropic 的做法是，是把脑子里的东西变成 Skill 文件，让 Claude 也能用上。

而现在，Skill 也给出来了，就等你抄作业了！

◇ ◆ ◇

相关链接：

https://claude.com/blog/how-anthropic-enables-self-service-data-analytics-with-claude

---

内容效果不满意？点此反馈