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有想进「编程一生」用户交流群的朋友吗