公众号名称：程叙架构与AI.

作者名称：AI兴观点

发布时间：2026-06-04 12:32

原文链接：https://claude.com/blog/how-anthropic-enables-self-service-data-analytics-with-claude

✅点击上方🔺公众号🔺关注我✅

做数据分析的 Agent，比写代码的 Agent 难太多了。

这事说出来反直觉。毕竟 Claude 写代码的能力已经卷到飞起——生成 CRUD、写单元测试、重构整个模块，干得不亦乐乎。但你让它去数据仓库里查个”这个月活跃用户有多少”，可能就翻车了。

不是 Claude 不够聪明。是数据分析这件事，跟写代码完全是两码事。

上周 Anthropic 的 Claude 博客发了一篇内部实战分享（作者：Chen Chang、Clement Peng、Justin Leder、Johanne Jiao、Josh Cherry，数据科学和工程团队），讲的就是他们怎么用 Claude Code 做 self-service 数据分析。这文章信息量很大，我把核心内容完整翻译整理出来。

核心成果：95% 的 business analytics 查询通过 Claude 自动化，aggregate 准确率稳定在～95%。 在某些领域甚至能到 99%。

但结果不是天上掉下来的。从 21% 到 95%，中间踩了无数坑。

数据不是软件

这是整篇文章最核心的一个判断。

LLM 写代码能做得不错，是因为代码有天然的安全网：编译器会报错、测试会挂、lint 会警告。代码是一个开放的解空间，创造力是加分项，而文档和测试就是防幻觉的护栏。

但数据分析恰好相反——一个问题的正确答案往往只有一个，而且没有确定性的方法能证明它是正确的。

你问”这个月的营收是多少”，正确的数字只可能有一个。但数据模型里有几百张表、几百万个字段，选错了其中一个过滤条件，答案就不同了。而且你没法像跑单元测试一样，自动验证这个 SQL 对不对。

代码和数据分析的本质差异：代码有天然的安全网，而数据分析没有确定性的正确性验证方法。复杂主要在数据的歧义性上。

Anthropic 团队把这个问题归结为三个失败模式：

概念↔实体歧义——几百个候选字段里，agent 选不准正确的那个。比如”活跃用户”怎么定义？哪些行为算”活跃”？要不要排除虚假用户？回溯窗口用多久？

数据过期——业务定义和 schema 一直在变，agent 的知识很快就会过时。今天管用的过滤条件，下周可能就变了。

检索失败——数据其实在仓库里，文档也写得清清楚楚，但几百万个字段里，agent 就是找不到对的。

这三个问题，对应了三个完全不同的解决方向。

一个四层的 Agent 分析架构

Anthropic 的解法是一个四层架构。每一层主要解决一个或几个上述问题：数据基础层和真相来源层主要对付歧义，Skills 层对付检索失败，验证层负责发现哪层出了问题。

Anthropic 的 Agent 数据分析四层架构：数据基础 → 真相来源 → Skills → 验证

第一层：数据基础——消除歧义的根基

这一层说的就是数据建模本身——维度建模、质量测试、完整性和时效性检查。标准数据工程实践依然重要。

但有一个关键变化：**你的数据模型的最终用户不再是数据科学家，而是 Agent。**终端用户没有能力验证结果对不对，所以你必须在源头上就让 Agent 选不出错的选项。

他们特别强调的做法：

创建”规范数据集”（canonical datasets）。 最普遍的失败模式就是 Agent 没法把”XX 产品的营收”映射到正确的表、列和指标定义——因为总有多个看起来差不多的候选。解决办法很简单：少而精。认真维护一小组规范数据集，明确谁拥有、怎么用、怎么找到它们，然后激进地废弃近似的重复品。

用工具链强制执行标准。 Agent 在结构上必须优先走规范数据集；CI 会拦截任何试图绕过规范数据集的变更；下游团队要么建立在规范层上，要么解释为什么不用。没有执行力的治理，很快会退化回多候选问题。

把所有数据代码放一个仓库。 数据建模、语义层、参考文档、规范仪表盘定义，全在一个 repo 里，CI 保证跨层一致性。一个建模变更如果会破坏下游仪表盘，CI 直接拒绝，修复和变更在同一个 PR 里完成。

把元数据当一等产品来维护。 列描述、表说明、指标定义、取值范围、血缘关系、所有者——这些信息的维护标准，得跟数据转换本身一样严格。

维度建模等标准数据工程实践依然重要——但用户现在变成了 Agent

第二层：真相来源——让 Agent 找到正确答案

数据基础层是仓库本身，真相来源层是引导 Agent 怎么在里面导航的参考面。按可信度从高到低排列：

语义层是第一优先级。 如果一个查询能匹配到已定义的指标，Agent 直接调用函数，得到一个数字——跟公司里其他任何地方查到的数字完全一样。按 Skill 指令的要求，Agent 在结构上必须优先用语义层。

一个有意思的教训：他们试过让 LLM 从原始表和查询日志里自动生成语义层定义。结果看起来不错，但产生的定义里编码了它们本应消除的歧义。净效果在 eval 上是负的。结论是：可以用 Claude 写文档，但定义必须由人来维护。

血缘关系和转换图谱。 当语义层覆盖不到时，血缘关系（lineage）和表排名（基于引用次数）让 Agent 能推理出哪个上游模型喂了哪个概念、哪些已废弃、哪些可以聚合。

查询语料库。 直觉上这个应该很有价值——不就是所有历史正确查询的记录吗？但实验结果是：给 Agent 直接检索几千条历史查询，准确率提升不到一个百分点。 未经结构化的检索无法把新问题和正确的先例关联起来。真正有效的是把这些语料提炼成按领域组织的参考文档。

业务上下文。 大多数团队会跳过这一层，而这也是他们低估最久的一层。不理解业务的 Agent 会回答用户问的问题，但不会回答用户真正想问的问题。它不知道”Q2 发布”指的是哪个产品、两个团队对同一个术语的定义可能不同、对方问这个问题是因为周四有个董事会。

第三层：Skills——Agent 的”过程知识”

如果说真相来源是”声明式知识”（指标是什么意思），那么 Skill 就是”过程式知识”——该找什么来源、按什么顺序、怎么处理歧义数据、一个完整的分析长什么样。

在 Claude Code 里，Skill 就是一组 Markdown 文件。Anthropic 发现 没有 Skill 的时候，Claude 回答数据分析问题的准确率不超过 21%。加上 Skill 之后，准确率稳定在 95% 以上，某些领域能到 99%。

他们的做法：

创建配对 Skill。 一个”知识型”Skill 做顶层路由器，按需加载领域细节。它告诉 Agent：先试语义层，如果覆盖不到这里有大约 30 个参考文件，按领域组织好。这相当于把几百万个字段的搜索空间缩小到几十个经过整理的参考文件。一个”非书型”（unbook）Skill 编码了资深分析师的工作流程——明确问题、查来源（通过知识型 Skill）、跑查询、用对抗性子 agent 审查结果。它还打包了十几个可复用的分析模式（留存曲线、率分解、漏斗分析等）。

写真正适合 LLM 检索的参考文档。 描述表的 grain、范围、排除条件、gotcha 的具体机制。下面是他们用的参考文档骨架：

# [Domain] Tables

## Quick Reference
### Business Context — [this domain in plain words]
### Entity Grain — [what one row represents]
### Standard Hygiene Filter — [the filter every query applies]

## Key Tables
### [table_name]
- **Grain**: ... | **Scope/exclusions**: ...
- **Usage**: [when to use, when NOT to, join keys, required filters]

## Gotchas
- [The wrong-answer modes a senior analyst would warn about]

## Best Practices / Common Query Patterns
- [Default choices, standard cuts, worked patterns]

## Cross-References
- [Neighboring domain docs]

把 Skill 维护当一等公民。 Skill 文档描述的数据模型每天都在变。他们把 Skill Markdown 文件和转换模型放同一个仓库里——改模型的 PR 也必须同时修改描述它的文档。代码审查钩子会拦截任何没有触及 Skill 文件的报表模型变更。大约 90% 的数据模型 PR 现在都附带一个 Skill 变更。

观测数据很有说服力：上线时～95%，一个月后自然衰减到～65%。不主动维护，准确率就是这么掉的。

第四层：验证——怎么知道自己做对了

这一层说的是评估和监控体系。

离线评估。 Dashboard 级 eval 由 Claude 自动生成、人工验证；长尾 eval 则让 Claude 根据业务上下文自己生成合理的提问。每领域几十个 eval 之后收益就开始递减，而且这个天花板随着每代模型升级还在下降。评估结果存进数据仓库，带上 Skill 版本、git SHA、模型 ID、每条断言通过/失败、token 数和耗时。“这个改动有用吗？“变成一条 SQL 就能查的事。

消融实验。 每个结构性决策都拿固定的离线 eval 集验证。最有用的一个结果是负面的——给 Agent 直接 grep 整个仪表盘和查询代码库（几千个文件），准确率波动不到 1%。信息在那里，Agent 也看到了，但它就是不会用。这证明瓶颈不是”获取”先前的知识，而是”结构化”地利用它们。

对抗性审查。 用一个专门的 Skill 去激烈挑战最终答案的所有假设，能在 eval 集上提升 6% 准确率，但代价是 32% 的额外 token 和 72% 的更高延迟。

来源脚注。 每条回复都带脚注：来自哪个来源层（语义层→规范参考→裸探索）、数据有多新鲜、谁拥有这张表。“裸表，时效性未知”这个脚注本身就是个信号——这结果得验证一下再往上递。

主动修正采集。 一个定时 Agent 每隔几小时扫描所有利益相关者的聊天频道，发现有人纠正了 Claude 的回答，就自动起草修复建议、提 PR、分配给领域负责人。修正路径刻意设计得很无脑——改一个 Markdown 文件、合并、自动同步——所以负责人不会花太多时间处理。

他们也没完全解决的问题

有几个问题，Anthropic 自己也没完全搞定：

静默失败。 答案错了，但看起来很有道理，直接被拿去用了没有人质疑。应对方案有来源脚注、给高层报告时必须人工确认、每个领域每天跑一次关键 KPI 和官方仪表盘对账——但没有完美的办法。

成本 vs 准确率的取舍。 对抗性审查能提升 6% 但代价不小，值不值取决于你的场景。

模型本身的进步会让部分基础设施变得多余。 有些公司在当前模型弱点上建了大量基础设施，但模型一升级就白建了。

附录：Skill 文件骨架

下面是 Anthropic 的仓库 Skill 核心结构（内部细节用 [占位符] 替换，不是要你照抄，而是展示值得记录的段落）：

---
name: [warehouse-skill]
version: [x.y.z]
description: "IF the user asks to query [company]'s data warehouse for any
  [business domains] question — THEN invoke this skill."
---

# [Warehouse] Skill Instructions

## Description
Act as a Data Analyst, providing strategic insights and data-driven
recommendations but seek guidance along the way.

## Executing queries
Priority:
1. **[Managed connection]** (if available)
2. **[CLI fallback]** (if installed)
3. **Neither** — ask the user to authenticate

---

# Semantic Layer (REQUIRED first step)
The governed semantic layer is the **mandatory default path** for every
data question. Raw SQL is the **fallback**, used only after the semantic-
layer path is shown not to cover the ask.

## Required workflow
1. **Load** — [how to load the semantic layer]
2. **Discover** — search measures/dimensions by keyword
3. **Compile + run** — build the spec → compile to SQL → execute
4. **Fallback** — only if no relevant metric found

---

# PART 1: MUST KNOW

## Quick Start Workflow
1. **Check for red flags**: restricted/PII, gated domains
2. **Out of scope — escalate**: access requests, pipeline troubleshooting
3. **Clarify the request**: time period, segment, business decision
4. **Check for existing dashboards**
5. **Identify the data source**
6. **Execute the analysis**: required filters + adversarial review
7. **Deliver insights**: show methodology, differentiate observations

## Business Context
### Entity Disambiguation (MUST CLARIFY)
- "[Term A]" can mean: [entity 1] or [entity 2]
- "[Users]" → [which identifier gives accurate counts]

## Data Integrity Requirements
- NEVER: make up data/columns; make speculative assertions
- ALWAYS: use safe division; differentiate observations from interpretations

---

# PART 2: HOW TO DO

## Analysis Best Practices
1. Clarify the ask before querying
2. Show your work (filters, inclusions/exclusions, freshness)
3. Clarify denominators
4. Consider sample bias
5. Connect to business impact
6. **Adversarial SQL review (MANDATORY)** — spawn review sub-agent
7. **Report with provenance footer**

---

# PART 3: DATA REFERENCES

## [Domain A] → `references/[domain_a].md`
- **Use for**: [kinds of questions]
- **Key tables**: [...]
- **Dashboards**: [...]

## Troubleshooting Guide
### When Information Is Missing
- [missing tables / access denied / outdated docs → what to do]

### Field Naming Gotchas
- Use [field_x_v2] NOT [field_x]
- [Two similar tables report same metric at different grains]

如果你想自己试试

从零开始，Anthropic 建议：几个规范数据集、几十个离线 eval、一个薄薄的知识型 Skill——就能 capture 大部分收益。

他们在经验中总结了几个自问的问题：

多在乎答案的正确性 vs 未来的正确性？ 模型进步很快，有时候在当前模型短板上建大量基础设施，模型一升级就白建了。

你的业务复杂度会怎么变化？ 如果你的数据模型比较稳定、消费者也少，有些流程可能没必要。

受众有多懂数据？ 如果终端用户本身就是数据科学家，能识别错误答案，那可以容忍更多误差。

愿意花多少钱换准确率？ 对抗性验证能提准确率，但成本也更高。

我一直在想一个问题：

我们花了太多精力让 LLM 变得更聪明，但很少去想——怎么让数据本身变得更”适合 Agent 消费”？

Anthropic 的做法本质上在回答另一个问题：不是”怎么让 Agent 变聪明”，而是”怎么让数据变清晰”。

从 21% 到 95%，这个差距不是模型能力换来的——是数据治理的力量。

如果觉得这篇文章有帮助，欢迎点赞、在看、转发！有问题也可以在评论区留言，我会尽量回复！

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