Anthropic 如何用 Claude 实现自助数据分析

在很多数据科学和数据工程团队眼里，要真正把“自助分析”做起来，一直都挺折腾的。

一种常见做法，是为了让不懂技术的同事也能查数，就在数据仓库里建一堆又宽又杂的表，把各种字段都堆在一起。业务一旦变复杂，这些表就会越来越多，口径略有不同、含义又有重叠，很容易出现“同一个指标在不同地方数字对不上”的情况，而且对那些根本没兴趣学 SQL 的人帮助也有限。
另一种做法，是把不同团队隔离开来，各自有自己的一套分析空间。但这又覆盖不了大家真正关心的“长尾问题”，最后变成指标和仪表盘泛滥，每个团队都在重复做类似的东西，互相之间又难以对齐。

大模型的兴起，为“自助分析”提供了一条新路，能够避开不少传统方案的坑。但如果只是把 Claude 接到数据仓库上，让它自动生成并执行查询，看起来虽然很智能，其实很容易给人一种“准确无比”的错觉。

一开始大家会很兴奋，因为终于不用被各种临时数据需求淹没了。可慢慢就会发现：这种做法把业务同事和底层的数据基础设施、文档，以及原本能帮他们“避坑”的数据专家隔开了。过去，正是这些东西在默默保障：大家用的是“经过精心挑选、定义清晰”的那几份数据，而不是随手哪张表都能拿来算。

在 Anthropic，如今大约 95% 的业务分析类问题，都是由 Claude 自动完成的，并且整体准确率也在 95% 左右。把这些重复、机械、却又必须做好的工作交给 Claude，我们的数据团队就能把精力集中在更有价值的事情上，比如：建立因果模型、做业务预测、或者构建更复杂的机器学习模型。

我们和几十位最重度的 Claude Code 使用者聊过，也见过各式各样的“分析代理”设计。基于这些一线经验，我们总结出了一套适合其他数据团队借鉴的做法。接下来，我们会用相对“非技术”的语言，讲清楚怎么用 Claude 来推动自助分析，包括：

为什么“分析结果准不准”，更多是“理解上下文 + 结果校验”的问题，而不是“SQL 写得漂不漂亮”的问题；
会导致错误的三大典型原因；
我们在 Anthropic 内部搭建的一整套“代理化分析体系”，是如何应对这些问题的；
我们是怎么评估这套体系是否好用、是否可靠的；
以及一个我们平时创建分析“技能”时使用的标准模板（见文末附录）。

数据不是软件

大模型擅长“生成内容”。这既是优势，也是风险：它可以对复杂问题提出新颖解法，但也可能一本正经地“胡说八道”。要真正理解分析代理的挑战，把它和“写代码的代理”对比会很有帮助。

写代码这件事，本身有很大的发挥空间。模型可以尝试不同写法，哪怕第一版不完美，也可以通过测试来验证、再逐步修正。也就是说，代码世界里本身就有一整套“防幻觉”的机制：文档、类型检查、单元测试、集成测试等等。

但商业分析就不一样了。很多业务问题，其实只有一个合理的答案，而且必须来自某一个合适的数据源。更麻烦的是，你往往没有一个“自动判分器”能告诉你：这个答案 100% 正确。

在用代理做自助分析时，真正复杂的地方，其实不在 SQL 语法本身，而在于数据的含义。
如果要把问题概括成一句话，那就是：我们有没有能力，把用户用自然语言提的问题，准确映射到数据模型里“具体、最新、而且用法正确”的那几个字段/表上？
如果这一点做对了，后面的执行和 SQL 反而变成“小事”。

我们分析过系统里的很多错误案例，发现大多数问题都可以归结到下面三类：

概念和数据实体之间的歧义
表里到处都是“看起来差不多”的字段和表，代理很难知道应该选哪一个。
比如：要统计“活跃用户数”，到底什么行为算“活跃”？要不要排除欺诈用户？统计的是最近 7 天？30 天？还是自然周？如果这些没有一个统一的、被大家接受的定义，即使 SQL 写对了，也很容易“答错问题”。
数据和定义“过期”了
数据表会调整，业务口径会变化，表结构会重构。如果底层数据源和相关说明没有及时更新，代理就会开始给出那些“看上去合理、实际上已经不符合最新口径”的答案。
检索失败，没找到正确信息
有时候，正确的字段、表和说明，其实已经整理得挺好了，就放在仓库和文档里。但由于整体信息量太大，代理就是没能正确地把“问题”对上“那几份关键资料”。

在 Anthropic，我们通过一个分层的“代理化分析体系”来分别应对这三类问题。可以简单理解为：

先从源头上减少“歧义”；
再通过一整套流程防止“内容过期”；
最后再用技能和工具，帮助代理“稳稳地”找到并用好正确的答案。

我们的“代理化分析体系”

在 Anthropic，我们用一套分层结构来构建分析代理。每一层，都是围绕刚才那三类问题来设计的：

减少歧义：通过统一的数据基础和“唯一真相源”，让某个业务概念尽量只对应一套定义；
防止陈旧：通过工程化的维护和校验机制，避免数据和文档悄悄过期；
避免检索失败：通过“技能”等方式，把海量信息变成一个“易于导航”的结构，让代理能稳稳找到关键内容。

下面，我们按层来讲。

一、数据基础：把“地基”打稳

想让分析代理的回答可靠，第一步还是要把“数据这栋楼的地基”打好。这包括：

仓库里的核心数据表和模型；
数据加工和清洗的流程；
基本的质量检查（例如：数据有没有按时更新、有没有明显缺失或异常）；
以及对这些内容的清晰说明（元数据），比如每个字段代表什么、有哪些取值、有哪些注意事项等。

这些听上去都挺“传统数据工程”的：维度建模、提前测试、质量监控等等。这里有一个关键点是：在有大模型的世界里，这些“老活儿”不仅没过时，反而更重要了，因为代理完全依赖这些地基来判断“该用哪份数据”。

真正发生的变化在于：
过去这些东西主要是为数据专家（如分析师、数据科学家）服务的；
而现在，数据的“直接使用者”变成了跑在背后，为不同业务同事“代劳”的代理。
很多业务用户并不熟悉底层是如何搭建的，也没办法轻易看出一个答案到底是不是靠谱。所以，“地基”是否清晰、一致、可读，就显得格外重要。

我们在这层有几条特别关键的做法：

只保留少量“权威数据集”
最常见的错误之一，是同一个业务问题在仓库里能找到好几组“看着都挺像”的数据表或字段。
解决方式是：选择一小撮**“权威版本”**，明确标注为“这就是大家统一使用的版本”，并强烈鼓励所有新需求基于这几套来建设。
其他相似但不再推荐使用的表，要么废弃，要么明确标记“慎用”或“历史数据，仅供参考”。
通过工具和流程“强制执行”这些标准
比如：
- 在代理的“使用说明”里，明确要求它优先选择这些权威数据集；
- 在代码检查和评审中，如果有人新建了一个“看起来和现有权威表功能重复”的表，会被提醒或拦下；
- 对下游团队有要求：如果不在权威层之上建设，需要给出理由。
  简单说，治理不是“建议”，而是“默认和规范”。
让模型、文档和看板“共用一个家”
我们会尽量把描述同一块数据的所有东西（比如：建模代码、语义层配置、表的文字说明、关键仪表盘定义等）都放在同一个代码仓里。
这样一来：
- 如果某个表的结构有调整，影响到了下游的某个看板，系统可以在提交代码时就提示出来；
- 修改模型的同时，就能顺手更新文档，而不是等“有空再说”。
把元数据当“产品”来对待
什么是元数据？可以简单理解为：一份“人能看懂的说明书”，告诉你每个表、每个字段到底代表什么、应该怎么用、有哪些坑。
对于编码代理来说，文档、注释、类型信息，都极大提升了“可读性”；
对分析代理来说也是一样：如果字段描述清晰、口径定义明确、责任人和用途都标明了，它就更容易选对数据、更少踩坑。
因此，我们把维护元数据这件事，当成和写数据处理逻辑一样重要的工作来要求。

二、真相源：让代理知道“去哪儿找正确答案”

如果说“数据基础”解决的是“仓库里到底有什么东西”，那“真相源”解决的是：代理遇到一个业务问题时，应该先去哪儿查答案。

我们大致把这类“真相源”分成四种：

语义层：统一定义的指标和维度
你可以把它理解成：“公司内部所有报表约定俗成的那套指标口径，被统一收在一个地方”。
如果一个问题能直接对应到某个已经定义好的指标，比如“月活用户”“收入”“转化率”，那代理只需要调用相应的“指标计算函数”，就能得到和其它系统一模一样的结果。
在我们的设置里，技能明确写着：必须先问语义层。
我们曾经试过用大模型“自动帮我们从原始表和历史 SQL 中总结指标定义”，结果发现这是一个坑：看起来引用了大量历史做法，实际上却把很多“历史遗留歧义”也一并封装进来了，反而更乱。
所以我们现在的做法是：可以让 Claude 帮忙写指标说明文档，但真正的指标公式和口径，必须由人来定稿。
血缘关系和数据加工流程图
当语义层没有覆盖到某个问题时，我们会借助“哪张表是由哪张表加工而来”的血缘图，帮助代理定位：
- 哪些表是用来支撑这个业务概念的；
- 哪些表已经不再推荐使用；
- 多张表之间的粒度是否一致。
  这样，代理可以从“我不知道这个指标怎么定义”退一步，变成“我知道该基于哪张整理好的表做聚合统计”。
历史查询记录：曾经别人是怎么查的
直观上看，这一块应该是个“宝库”：里面记录了无数分析师、产品经理、财务同事过去问过的问题，以及他们是怎么查的。
但我们的实验结果很有意思：
只要把这些历史 SQL 原封不动交给代理自由检索，对整体准确率的提升非常有限。很多时候，即便正确答案就在那里，它也不一定能“对上号”。
真正有效的方式，是把这些历史查询“提炼”成按业务模块划分的说明文档和通用分析套路，再作为技能的一部分提供给代理，而不是指望它从几千条 SQL 里自己翻。
业务上下文：让代理理解“问题背后的意图”
这是很多团队会忽略的一层。
一个不太了解你业务的代理，往往只会机械地理解问题表面的含义。
它不知道“Q2 那次发布”指的是哪个功能，不知道不同团队对同一个术语的理解略有差异，也不知道提问人到底是为了哪个会议、哪次汇报在做准备。
我们会把公司内部的一些关键信息整理成一个“业务知识图谱”，包括：组织结构、路线图、重要决策记录、关键文档等，让代理在回答问题前，先对“问题所处的背景”有个大致认识，这样提的澄清问题也会更有针对性。

这些真相源有一个共同点：离不开高质量、及时更新的文档。
Claude 在“补文档”上很好用，比如：

帮你为字段生成初稿说明；
帮你根据查询模式提炼出某个指标的文档；
在 CI 检查中自动发现那些“还没有任何说明”的表。

但最后“怎么写进系统、由谁负责维护”，还是需要有明确的人工所有权。

技能：让代理“像经验丰富的分析师那样办事”

如果说“真相源”解决的是“知道什么”，那“技能”解决的是“怎么做”。

在 Claude Code 里，一个技能本质上是一组 Markdown 文档。代理在处理相关问题时，会在需要的时候自动去读。
在 Anthropic，我们内部构建的技能，对分析质量的提升非常明显：在没有技能的情况下，Claude 在我们自家的分析评测里，准确率最高也就 20% 出头；
加入技能之后，整体准确率能稳定达到 95% 以上，在某些熟悉的业务领域，甚至经常能接近 99%。

我们在设计技能时，有几个关键经验：

1. 把技能分成“知识技能”和“执行技能”

知识技能
可以把它想象成一个“导航目录”。
它会告诉代理：
这样代理就不用在整个仓库里海搜，而是先缩小到一个合理的范围。
- 先去语义层找答案；
- 如果语义层里没有覆盖，再去看这一领域下那几十个“精心整理”的参考文档。
  这些参考文档会具体说明：
- 哪些表是干什么的；
- 常用字段在哪儿；
- 哪些组合很容易踩坑；
- 碰到什么样的问题，应该用哪份文档。
执行技能（例如我们内部叫“unbook”的技能）
这类技能更偏流程，类似把一个资深分析师的工作方式写成了“步骤说明”：
- 先和提问人确认问题想得到的是什么结论、要用来支持什么决策；
- 再根据知识技能指引，选择合适的数据源；
- 然后生成并执行查询；
- 最后再把结果交给一个“挑错子代理”做第二轮审查。
  同时，我们还把一些常见分析套路（如：用户留存、转化漏斗、环比拆解等）事先封装成模板，减少重复工作。

2. 写给“模型看得懂”的参考文档

我们的参考文档会重点回答下面这些问题：

这张表是干什么用的？一行数据表示的是什么对象、什么时间粒度？
这个领域有哪些常见的业务概念？它们在不同表里分别是用什么字段表示的？
有哪些典型的“坑”？例如：
- 算用户数时，要不要去重？
- 要不要排除内部账号或异常账号？
- 要不要统一转换时区？
碰到某类问题时，这张表适合用来干什么，又不适合用来干什么？

我们会用一个统一的骨架来写这些文档，包括“业务背景”“粒度说明”“关键表简介”“常见坑”“常用查询套路”等，让代理更容易通过检索找到对应信息。

3. 把“维护技能”当成一项正式工作来安排

数据表会变，业务逻辑会变，如果技能不更新，很快就会开始“教错知识”。
我们一度在这方面吃过亏：刚上线时，离线评测准确率能到 95%，结果放着一个月没管，就掉到了 60% 多。

后来我们把这件事完全当成工程问题来解决，比如：

技能文档和数据建模代码放在同一个代码库；
修改某个核心模型的 PR，如果没有相应的技能文档改动，会被标记出来；
现在约 90% 的数据模型变更 PR，都会同时更新至少一份技能文档。

同时，随着数据基础打得越来越牢，有些最初用于“兜底”的技能内容反而可以删除，避免文档越堆越厚，反而难以使用。

4. 确保“所有入口的体验一致”

我们希望，不管业务同事是：

在 Slack 里问问题；
在 IDE 里写分析；
还是在一个 Web 界面上和代理交互；

只要问题本质相同，技能给出的答案就应该是一致的。
为此，我们会：

只保留一个“技能的权威版本”（放在数据代码库里）；
每次合并更新之后，自动同步到各种插件、托管服务和代理接口。

这样不管从哪个入口用 Claude，背后看的都是同一套“说明书”。

校验：怎么知道“哪里还在漏错”

前面讲的是“让系统尽量少犯错”，但现实世界里，再好的设计也不可能完全没有问题。所以还需要一整套**“发现问题、修问题、不断变好”**的机制。

我们分为三种方式来做这件事。

一、离线评测：提前“打样”

可以把离线评测理解成：“事先准备好一批典型问题及其标准答案，让系统在不影响真实用户的情况下反复练习”。

在 Anthropic，我们主要做两类离线评测：

基于已有仪表盘自动生成的问题
我们用 Claude 去扫描现有仪表盘和报表，让它帮忙先起草一批“业务方最常问的问题”，再由数据团队校对和补充。这些问题，通常覆盖了一个领域中最常用的度量和视角。
长尾问题
对于那些不常被报表直接覆盖，但在业务上可能会出现的提问，我们会给 Claude 一些业务背景材料（比如：路线图、表文档、历史讨论记录等），让它自己构造一批“听上去合理”的问题，再同样由人工筛选。

此外，每当业务同事在对话里纠正了代理的错误回答，我们也会把这些“现场纠错”当成候选评测样本，一起纳入评测库。

在使用离线评测时，有几件事特别关键：

固定“标准答案”，防止悄悄漂移
如果直接拿实时数据来写评测，那么只要底层数据有更新，原来的“正确答案”就不再正确，这样评测本身也会不断过期。
解决方式包括：
- 给每条评测标记一个具体的“数据日期”；
- 或者只评估“代理写出的查询是否合理”，而不是它返回的具体数字。
把评测结果当作“运营数据”来分析
每次评测的结果，我们都会以结构化数据形式存入仓库，包括：
- 哪个技能版本；
- 哪个代码提交；
- 使用了哪个模型；
- 每一道题是否通过；
- 花了多少 Token、多少时间等。
  这样团队只需要写个简单的查询，就能看出最近的一次改动到底有没有提高整体表现，或者某条业务线是否频繁出现回退。
按业务领域设置“上线标准”
某一块业务领域的负责人，只有当这块领域相关的问题在离线评测中达到一个预设的通过率（比如 90% 以上），才能正式对外说“这套自助分析已经可以用了”。
这可以有效避免用户一上来就踩一堆明显的坑。
控制评测数量，在“够用”处收手
评测题目不是越多越好。我们自己的经验是：
- 每个大主题做到几十道题，基本就能把主要情况覆盖得比较好；
- 随着模型能力提升，所需的题目数量反而可以逐渐减少。
离线评测追求接近 100% 的正确率
特别是那些能映射到语义层的题目，理论上应该全部能够得出正确答案。
如果在这里还有明显错误，多半说明“真相源”或“技能文档”本身还有明显短板。

二、消融实验：搞清楚“什么真的有用”

我们在迭代分析体系时，每一项结构性的决定（比如：要不要新增某个子步骤、要不要给代理更多上下文、要不要合并两个技能）都尽量通过“消融实验”来验证。

所谓“消融”，就是只改系统里的一个因素，其他都保持不变，然后看这次改动对离线评测的总体通过率有什么影响。

一个实际例子：

我们曾经给代理开放了对所有历史 SQL 的直接搜索能力，包括仪表盘脚本、数据转换代码、分析报告中的查询等等；
然后我们确认，在回答每道题之前，它的确调用了这些搜索功能；
但最终发现：整体准确率的变化非常有限。
进一步深入分析后，我们意识到：
问题的关键不是“有没有查到之前有人写过的 SQL”，而是**“能不能用结构化的方式，帮代理缩小搜索范围”**。
这一发现，大幅调整了我们后续几个月的产品路线。

通过这种方式，我们可以：

把“我觉得这样会更好”变成“数据证明这样更好或更差”；
把一些“听上去很酷、但其实没什么用”的想法，早一点排除。

三、在线校验：在真实环境中持续“看着它”

即便离线评测做得很好，真正上线以后，还是会出现各种意想不到的问题。
因此我们还有一整套“在线监控和修正”的机制，包括：

对抗性复核
在准备给出最终回答之前，我们会再让 Claude 以“挑刺者”的角色，站在批判视角审查一次：
- 查询写得是否合理；
- 数据源选得是否正确；
- 有没有漏加关键过滤条件；
- 有哪些可能的解释是“过度解读”。
  这一环节在我们的评测中，能平均提升 6 个百分点左右的准确率，但代价是延迟和成本都会明显上升。
溯源说明（Provenance Footer）
每个回答的最后，我们都会附上一段简单说明，包括：
- 这次回答是基于语义层、治理过的分析表，还是较原始的工作表；
- 相关数据最新更新时间；
- 哪个团队是这块数据的负责人。
  这可以帮助阅读者判断：自己是否可以直接转发这个结论，还是应该再多问一句。
基础数据质量检查
有时代理选对了表和字段、逻辑也没问题，但底层数据本身出了状况（比如：某天数据没更新、或者被错误覆盖）。
因此我们会对关键数据源定期做一些基础检测：
- 是否按预期频率更新；
- 是否突然出现大面积缺失或异常波动。
  这些检测本身就是“好数据治理”的一部分，也顺带保障了分析代理的可靠性。
持续监控“在线表现”
比如我们会重点看两个指标：
- 代理回答中，有多少比例是通过语义层完成的（越高一般越好）；
- 在实时对话中，业务方用来纠正代理的“反对语句”（例如“这不是我们现在用的口径”“你漏掉了某个过滤条件”）出现的频率。
  这些数据会定期被整理成内部看板，和离线评测结果一起审查。
主动收集并利用“现场纠错”
每隔一段时间，我们会让一个“运维类代理”自动去扫描公司内部的沟通频道，寻找那些明显是在纠正代理错误的话语。
对于每一个这样的案例，它会起草一条简短的技能或文档修改建议，发起一个改动请求（PR），并标记给对应数据领域的负责人。
整个修正流程被设计得尽量简单直接：
- 修改一段 Markdown；
- 合并；
- 自动同步到所有相关的代理和界面。
  这样，领域负责人可以用最小的时间成本，持续帮助系统“涨经验”。

当然，再怎么做，也无法完全消除所谓“静默错误”——也就是：

回答看起来合理；
没有人及时指出问题；
最后被直接用到了对外场景。

我们目前的应对方式主要有：

对重要汇报场景要求有人类最终确认；
对关键指标设置自动日常比对，确保和权威仪表盘的结果始终保持一致；
在界面上明确标明数据来源和新鲜度，让使用者在做重大决策前更加谨慎。

如果你现在还是“从零开始”，可以怎么动手？

如果你所在的团队还处在比较早期的阶段，不必一上来就把上面所有内容都搭全。
从实践经验看，只要先做好下面三件事，就能拿到很大一部分收益：

打造少量但清晰的“权威数据集”；
为几个关键业务领域整理出几十道离线评测问题；
写一个简单的“知识技能”，告诉代理遇到某类问题先去看哪几份文档。

在此基础上，后面提到的那些更复杂的机制（比如对抗性审查、自动收集纠错、跨入口统一体验

原文：How Anthropic enables self-service data analytics with Claude