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

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

原文作者：Chen Chang、Clement Peng、Justin Leder、Johanne Jiao、Josh Cherry，均为 Anthropic 数据科学与数据工程团队成员。作者还感谢 Michael Segner 的贡献。

本文为原文的完整简体中文翻译。

正如许多数据科学和数据工程团队都能证实的那样，让业务分析做到自助，历来是一桩苦差事。

通过又宽又反规范化的表，把数据模型变得对技术没那么强的同事更易上手，往往会随着业务规模扩大而催生出一堆定义彼此矛盾、相互重叠的视图（而且对那些压根不想学 SQL 的员工，几乎起不到弥合鸿沟的作用）。换一条路，为用户搭建更多圈起来的独立环境，又往往照顾不到业务问题那条长尾，并且随着各团队把工作各自割据，导致指标和看板泛滥成灾。

大语言模型的兴起，为自助分析提供了一条能绕开这些难题的新路径。然而，把 Claude 指向一个数仓、放手让 agent 去执行，可能会制造出一种虚假的精确感。

从临时取数请求中解放出来的最初那份狂喜，会在你意识到这套做法把利益相关方和底层基础设施、文档与专业知识隔开之后，变成一种忧虑——而正是那些基础设施、文档和专业知识，此前一直在引导他们走向那些精心策划过的数据集。

在 Anthropic，95% 的业务分析查询都由 Claude 自动完成，整体准确率约为 95%。 把这些往往机械、重复的工作交给 Claude，我们的数据科学团队就能专注于更具战略性的工作，比如因果建模、预测和机器学习。

在和数十位 Anthropic 顶级 Claude Code 用户深入交流、并见识了形形色色的分析 agent 设计模式之后，我们为其他与大模型打交道的数据团队沉淀出了一些最佳实践。在这篇文章里，我们会分享这些把 Claude 驱动自助式业务洞察的能力发挥到极致的技巧与方法，包括：

• 为什么分析准确性是一个上下文与验证问题，而非代码生成问题；

• 导致大部分错误的三种失败模式；

• 我们为应对这些错误而搭建的 Agent 分析技术栈；

• 我们如何度量有效性；以及

• 我们创建大多数技能时所用的一个基础模板（见附录）。

数据不是软件

大模型的生成能力是一把双刃剑：那些能为复杂问题想出创造性解法的机制，同样可能幻觉出错误的输出。要充分理解分析 agent 面临的挑战，把它们和编程 agent 做个对比会很有帮助。

编程是一个开放式的解空间，奖励模型的创造力，与此同时，文档和测试提供了对抗幻觉的天然护栏。相比之下，在分析的场景里，往往只有一个正确答案、对应一个正确来源，而且没有确定性的办法去证明其正确性。

对于自助式的 Agent 业务分析来说，复杂性主要在于数据的模糊性。核心问题归根结底，在于我们能否把用户的问题映射到数据模型里那些具体且最新的实体，并知道与它们打交道的正确方式。如果我们能做到这一点，那么随之而来的执行和 SQL 就变得无足轻重了。

我们识别出了这个问题的三个属性，它们解释了绝大多数不准确回答的成因：

• 概念 ↔ 实体的模糊性：在一个数据模型里有数百个可行选项（出自可能多达数百万个字段），agent 没法挑出最能回答用户问题的那个正确字段。比如，在统计活跃用户数时：哪些行为才算“活跃“？要不要把欺诈用户算进去？用多长的回看窗口？

• 数据陈旧：数据源、业务定义和 schema 时刻在变；资产和 agent 的知识会过时，开始返回那种微妙错误的答案。

• 检索失败：正确的信息也许确实在数据模型里、也做了恰当的标注，但鉴于搜索空间之浩瀚，agent 就是找不到它。

我们的 Agent 分析技术栈

在 Anthropic，我们把这三类错误降到最低的主要手段，就是我们的 Agent 数据栈。每一层的存在，主要都是为了攻克其中一个或多个问题：

• 实体模糊性：数据地基和真相来源把可信实体的空间收缩，直到只剩一个受治理的答案。

• 陈旧：维护与验证流程让一切不随业务变化而腐烂。

• 检索失败：技能确保 agent 可靠地找到并正确使用那个答案。

在这一节里，我们会讲讲每一层是怎么搭起来的。

数据地基

确保分析 agent 准确，最重要的一环是靠扎实的数据地基，它包括数仓里的数据模型、转换、测试和表，以及描述它们的元数据。维度建模、左移测试（shift-left testing）、对关键管道做新鲜度和完整性检查等标准的数据工程与数据质量实践依然全部适用（这些我们就不再赘述了）。

真正发生改变的是，你数据模型的最终用户不再是数据专家（比如数据科学家），而是代表用户行事的 agent，而这些用户对数据的专业程度、对底层基础设施的理解千差万别。这种转变带来了一个挑战：结果不能要求用户去验证其底层的正确性，原因很简单——最终用户根本不懂。

数据地基这一层主要瞄准的是模糊性：举例来说，如果“营收“能解析到一个受治理的数据集、而不是四十个看似都行的候选，那么这个问题在 agent 还没开始搜索之前就基本消失了。这也是第一道抵御陈旧的防线所在之处，因为定义规范模型的那个仓库，天然就是强制它们保持最新的地方。

我们见过几种做法效果尤其好：

• 创建规范数据集（canonical datasets）：到目前为止最常见的失败，是 agent 没法把一个概念（“产品 X 的营收”）映射到那张唯一正确的表、列和指标定义上，通常是因为存在多个看似都行、但实现上有微妙差异的候选。解法是更少、治理更重的逻辑模型：精心策划出一小批规范的、单一真相来源的数据集，它们归属清晰、开箱即用、易于发现，然后大刀阔斧地弃用那些近似重复的版本。物理上的汇总表和缓存对成本和性能仍然重要，但它们应当从规范模型机械地派生出来，而不是作为替代品和规范模型并列存在。目标是：当一个 agent 去搜索一个概念时，它找到的是一个受治理的唯一答案。

• 强制执行你的标准：我们发现，只有当规范模型和指标定义被工具（agent 在结构上被首先路由到它们，后面会细说）、被 CI（绕过它们的变更会通不过评审）、被强制要求（下游团队要么基于受治理的那一层来构建，要么解释为什么不这么做）所强制时，地基才稳得住。没有强制执行的治理，会很快退化回那个“多个候选“的问题。

• 把产物放在一起（colocate）：我们抵御数据模型和业务逻辑不断变化的主要防线，就是放在一处。几乎所有的数据代码（即建模、语义层、参考文档、规范看板定义）都住在同一个仓库里，并配有保护跨层完整性的 CI 检查。如果一个建模变更会破坏某个下游看板、或让某个有文档记录的指标失效，CI 就会标记出来，修复也会在同一个 PR 里发出去。（关于这套机制，我们在下面的“技能“一节会再回来讲。）

• 把元数据当成一等产品来对待：编程 agent 表现好，部分原因在于代码库是可读的：README、类型签名、docstring 等等。你的数仓也可以一样可读，但前提是：列和表的描述、规范的指标定义、粒度文档、合法取值范围、血缘、归属、模型分层，都得和转换本身投入同等的严谨去维护。这虽不是什么新洞见，但好的治理提供了关键上下文，帮助 agent 选对数据集。

真相来源（Sources of truth）

如果说数据地基就是数仓本身，那么真相来源就是 agent 为了导航这个数仓而去查阅的那些参考界面。这一层减少了概念 ↔ 实体的模糊性，把利益相关方问题里的“周活跃用户“变成数据模型里一个具体的、受治理的实体。大致按可信度从高到低排列：

• 语义层（Semantic layer）：编译好的指标和维度定义。如果一个问题能干净地映射到一个已定义的指标，agent 就调用一个函数、拿到一个数字——和公司里其他每个界面产出的数字一模一样。我们的 agent 在结构上（通过技能指令）被要求优先利用语义层（见附录）。有个我们试过但行不通的点子：让一个大模型从原始表和查询日志里自动生成指标定义，以此来给语义层做冷启动。它产出了一堆看似合理的定义，却把我们正想消除的那些模糊性给编码了进去，并且在我们的评测上相比一个更小的、人工策划的层是净负面的。因此我们建议：用 Claude 来生成文档，但让人来拥有定义。

• 血缘与转换图：当语义层覆盖不了某个问题时，血缘和表排名（基于被引用次数）让 agent 能推断出哪些上游模型喂养了某个概念、哪些已被弃用、哪些共享相同粒度。这把“我不知道用哪个指标“变成了“我知道该从哪个受治理的模型去聚合“。它也是我们在下文线上验证中所暴露的新鲜度和溯源信号的骨干。

• 查询语料库（Query corpus）：来自看板、notebook 和此前分析的历史 SQL。直觉上，这应该很有价值：它是每一个已被正确回答过的问题的记录。但实践中，我们发现给 agent 对数千条历史查询的原始检索访问权，对准确率的提升不到一个百分点（我们会在后文的一节里走一遍那个消融实验）。无结构的检索没法把一个新问题映射到正确的先例上。真正管用的，是把那个语料库提炼成结构化的、按领域划分的参考文档，以及在技能里描述的可复用分析模式。把查询历史当作供策划的原材料，而不是 agent 直接去读的真相来源。

• 业务背景（Business context）：这是大多数团队跳过的一层，也是我们最久地低估了的一层。一个不理解你业务的 agent，会回答用户问了什么，却答不出他们真正想问什么。它不会知道“Q2 那次发布“指的是某个具体产品、不会知道两个团队对同一个术语定义不同、也不会知道某个问题之所以被提出，是因为周四有个董事会。我们接入了一张公司知识图谱，由被索引的文档、路线图、决策日志和我们的组织架构构成，好让 agent 能解析那些隐含的指代、并提出更好的澄清问题。

这四者共通的失败模式，和数据地基那一层是同一个：糟糕或陈旧的文档。Claude 在弥合这一鸿沟上格外有用（起草列描述、从查询模式中提议指标文档、在 CI 里标记没有文档的模型），但策划和归属由人来管理。

在接下来的两节里，我们会讨论如何把这份“归属“的成本压到足够低，以至于它真的会发生。

技能（Skills）

如果说真相来源是 agent 的陈述性知识（即一个指标意味着什么），那么技能就是它的程序性知识：该按什么顺序查阅哪些来源、如何在模糊的数据里导航、以及一份完成的分析长什么样。

在 Claude Code 里，一个技能就是一个 agent 按需读取的 markdown 文件夹。在 Anthropic，我们开发的这些技能价值巨大。没有技能时，Claude 准确回答分析问题的能力在我们的评测上不超过 21%。加上技能后，这些数字整体稳定在 95% 以上，在某些领域还经常达到 99% 左右。 我们创建大多数技能所用的一个骨架见附录。

一些最佳实践：

创建成对的技能（pairwise skills）：一个知识技能充当一个薄薄的顶层路由器，让额外的领域细节按需加载。它会说：“先试语义层，但如果没有覆盖，这里有约 30 个该领域的参考文件，描述了相关的表、列、join 和坑点。“这个路由器，实际上就是我们对检索失败的回答：与其让 agent 在一个百万字段的数仓里搜索，不如在任何查询动笔之前，就把空间收窄到几十个精心策划过的文件。unbook 技能把一位资深分析师会遵循的流程编码了进去：澄清问题、找来源（经由知识技能）、跑查询，然后把结果循环过一遍对抗式审查子 agent。它还打包了十几个可复用的分析模式（留存曲线、比率分解、漏斗分析），让常见的请求不必每次都重新发明。

创建合格的参考文档：写的时候就是为了让大模型来检索。我们的参考文档描述表（粒度、范围和排除项）、坑点的机理（比如“排除已知的免费邮箱域名，但保留像 anthropic.com 这样的自定义域名“）、以及显式的路由触发条件（比如“如果问题是关于实验提升量……那就不要用它来做原始事件计数“），而不写那种会过时的处方式食谱。下面是我们创建参考文档所用的一个骨架。

markdown# [领域] 表

速查

业务背景 —— [用大白话说明这个领域是什么意思]

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

标准清洗过滤 —— [这个领域里每条查询都要加的过滤条件]

维度

• [关键维度是怎么编码的，以及同一个概念在不同表里如何被命名得不一样]

关键表

[table_name]

• 粒度：[…] · 范围/排除项：[…]
• 用法：[何时用、何时不要用、join 键、必需的过滤条件] [… 每张受治理的表配一小节 …]

坑点

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

最佳实践 / 常见查询模式

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

交叉引用

• [负责相邻问题的邻近领域文档]

把技能维护当成一等公民来对待：技能文档描述的是一个每天都在变的数据模型，所以没有主动维护，它们几周内就会变错。我们眼睁睁看着自己的离线准确率从上线时的约 95% 在一个月里漂移到约 65%，之后才把它当成一个工程问题来处理。这意味着把技能 markdown 文件和我们的转换模型放进同一个仓库，这样改动某个模型的 PR，就是更新描述它的那份文档的同一个 PR。一个代码审查 hook 会标记任何没有触及技能文件的报表模型变更。如今，我们大约 90% 的数据模型 PR 都在同一个 diff 里包含了一处技能改动。随着模型变强、此前的失败模式不再适用，我们也会定期修剪技能里的脚手架。

在所有界面上创造一致而无缝的体验：同一个技能，对 Slack 里、IDE 里、看板工具里、独立 agent 会话里的问题，都必须给出同样的答案。我们做到这一点的办法，是确保只有一个规范来源（数据仓库），并让技能改动自动同步。一旦合并，技能就会同步到一个插件市场（给 IDE 用户）、同步到云存储 blob（给那些读取单个文件的托管应用）、并通过 MCP 直接作为资源提供。我们从一开始就为可移植性做了设计，避免硬编码的仓库路径和特定界面的命名空间。

验证（Validation）

最后，验证是你用来搞清楚这三种失败模式里还有哪一种在漏过去的手段。

离线评测

我们常见到一种模式：数据团队会搭起精巧的分析环境，却没有任何流程去了解他们分析 agent 的准确率。

弥补这个空缺的一种办法是离线评测，它就是简单的“问题 / 答案“对。你可以把离线评测类比成对一个 ML 模型做离线测试：它们不会告诉你线上 agent 的表现，但确实能让你大致心里有数——你会不会有什么关键的空白。

我们在 Anthropic 部署了两种离线评测。基于看板的评测由 Claude 自动生成（再经人工校验），覆盖最常见的利益相关方问题。长尾评测则是我们把业务背景（路线图、表文档）喂给 Claude，让它在该领域剩下的部分里生成看似合理的问题。我们还会持续地把每一次利益相关方在讨论串里纠正 agent 的情形收割下来，因为那个纠正就是一个候选评测。

其他最佳实践包括：

• 把基准答案锚住，别让它漂移：一个针对实时数据写的评测，会在底层数字一变动的那一刻就过时。把每个评测钉到一个快照日期上、针对一张稳定的事实表来写、或者让评分员去评判 agent 的查询而非它给出的数字。把这套评测接进 CI，这样一个触及某个依赖的 PR 就会重跑受影响的评测。

• 像存遥测数据那样存结果，而不是像存测试日志：每一次运行都落进一张数仓表，带上技能版本、git SHA、模型 ID、逐条断言的通过/失败、token 数和墙钟时间。“那个改动到底有没有帮助？“就变成了一条查询，而且你拿到了时间序列，能逮住单次 CI 运行抓不到的缓慢回归。

• 按领域设置发布门槛：一个领域负责人在他那一片评测集清过某个阈值（我们最初用约 90%）之前，不能向他的利益相关方宣布这个 agent 可用。这逼着在用户看到失败之前，先把参考文档修好。

• 创建数量恰当的评测：你该有多少评测，取决于业务领域的复杂度和底层数据模型的复杂度。校准的办法是追踪离线准确率对线上准确率的预测有多准：我们发现，每个主题（比如“增长“）超过几十个之后就会收益递减，而且这个天花板会随着每一代新模型的到来而下降。

• 离线评测准确率应当约为 100%；每一个正确答案也都应当命中你的语义层（如果你有的话）。再强调一遍，这种程度的准确率并不告诉你你的系统不会产出错误答案，只是说——在你有合理评测覆盖的前提下——没有明显的空白。

消融技术

每一个关于技能的结构性决策（比如暴露哪些来源、某个子 agent 值不值它带来的延迟、要不要把两个技能合成一个），都是通过固定住我们的离线评测集来做出的。

我们每次只改动恰好一个组件，比较通过率。每次运行只花一个小时，却能替代大量的争论。方法论比任何单个结果都更重要：

• 为零结果（null results）而设计：我们最有用的一次消融是个否定性的。我们给了 agent 对我们全部看板、转换和分析师 notebook SQL（数千个文件）的直接 grep 访问权。我们随后在转录里确认它在每次回答前确实读了它们。准确率朝任一方向的变动都不到一个百分点。我们接着检查了那些显而易见的混淆因素：对于它答错的问题，答案到底在不在语料库里？大约 80% 的时候，在。那“答案存在“能不能预测“现在答对了“？不能，翻转率是平的。信息就在那儿，agent 也看见了，可它还是没用上。那一个实验告诉我们，我们的瓶颈不是对过往工作的访问权，而是结构（即把一个问题映射到正确的实体上）。那个洞见重定向了好几个月的路线图。

• 以 PR 为粒度做消融：每一处有意义的技能编辑，都会在相关的评测切片上跑一次前/后对比，并把差值写进 PR 描述里。这让“我改进了文档“这句话保持诚实，也逮住了那种出人意料地常见的情形——一个出于好意的补充反而把事情搞糟了。

• 保留一份“什么没奏效“的简短清单：我们的两条：把文档精修又叠了几轮、过了某个点之后（我们连续撞上三次净负面的迭代：文档越来越长，而不是越来越好）；以及把对抗式评审员换成一个更便宜的模型以削减延迟（它丢掉了大部分准确率收益，却没换来真正的提速）。否定性结果记录起来很便宜，而且它们能防止下一个人再跑一遍同样的实验。

线上验证

最后一步，是确保实际的线上系统表现尽可能准确。我们采取的一些手段包括：

• 对抗式审查：我们发现，用一个 Claude 技能去激进地挑战一个潜在最终答案背后的所有底层假设，在我们的评测集内把准确率提高了 6%，但代价是多花 32% 的 token 和高出 72% 的延迟。

• 溯源页脚（Provenance footer）：每一个回答都带一个页脚，注明它来自哪个来源层级（语义层 › 策划过的参考 › 原始表）、底层数据有多新、以及谁拥有这个模型。它不会让答案变得更正确，但确实帮消费者判断他们能在多大程度上信任这个回答。一个“原始表、新鲜度未知“的页脚，就是一个在往上转发之前先去核实的信号，也是我们对付静默失败为数不多的缓解手段之一。

• 数据质量检查：有可能 agent 用对了字段、也用对了方式，但数据本身是错的。加上一些基本的数据质量检查，确保被引用的字段是最新的、完整的、没有异常，总体上是良好的卫生习惯。

• 被动监控：我们持续追踪的两个生产信号是——agent 查询中经由语义层解析的占比，以及回答中使用了纠正性措辞（“那是错的表”、“你漏了欺诈过滤”）的占比。两者都喂进一个每周和离线通过率一起评审的看板。

• 主动收割纠正：这是闭环的那一环。一个定时 agent 每隔几个小时扫描一遍利益相关方的频道，寻找类似的纠正性措辞，对相关参考文档起草一行修复，并开一个 @ 给领域负责人的 PR。修复路径被刻意做得很无聊——编辑一个 markdown 文件、合并、自动到处同步——这样领域负责人就不用在这件事上花太多时间。同样这些纠正会反哺到离线评测集里。

这一切都没能完全逮住的那个失败模式，是静默的那种：答案是错的，但看起来合理，而且没人提出异议就被用了。我们的缓解手段是溯源页脚、对任何要送到领导层的东西都做显式的人工签字、以及为每个领域的头部 KPI 设一个常驻评测，每天拿它对认证过的看板做合理性检查——尽管我们目前还没有一个稳健的解法。

上手开始

如果你是从零起步，那么一小撮规范数据集、几十个离线评测，加上一个薄薄的知识技能，就能捕获到大部分收益；这篇文章里其余的一切，都是我们在那些东西建好之后才加上去的。

我们也分享了许多最佳实践，但并非每一条都适合每一个数据团队。和你的组织在几条会影响你做法的原则上对齐，方法是问自己：

• 一个正确答案，今天有多重要，相对于将来？ AI 模型正在飞速进步。我们经常看到一些公司构建大量基础设施去弥补模型当下的不足，可一旦那些模型变好，这些基础设施就变得无关紧要了。知道模型在哪里不行、并等待模型改进来填补空白，开销要小得多，但可能不符合你公司的风险容忍度。

• 你预期你的业务复杂度会随时间如何变化？ 我们讨论的某些流程可能是杀鸡用牛刀——比如，如果你产出的数据不多、你输出的消费者只有寥寥几个、或者你的数据模型很可能会保持简单。

• 你输出的目标受众有多技术？ 换个说法，如果你是在为那些能识别出答案何时不对的数据科学家构建这套分析系统，那么相比受众对底层数据模型一无所知的情形，你对错误的容忍度可能会更高。

• 为了提升准确率，你愿意花多少钱？ 我们发现像对抗式验证这样的某些流程能显著提升准确率，但往往以更高的成本和延迟为代价。

• 你对访问控制和内部数据隐私的接受度如何？ agent 拥有的上下文越多，往往表现越强；然而，宽泛的数据访问权和大多数公司的治理姿态是相悖的。这决定了你是在构建一个 agent，还是许多个权限受限的 agent。

无论你走哪条路，我们最大的收获都来自应对那三种失败模式中的每一个：把模糊性收拢成一个受治理的唯一答案、让这个答案易于发现、并在两者中任何一个变陈旧时发出警示。

附录

技能文件骨架

下面是我们主数仓技能的骨架：真实文件的结构，内部细节用 [方括号占位符] 替换。它并不是用来逐字照抄的；它是用来展示我们发现值得写下来的那些章节类型的。

markdown— name: [warehouse-skill] version: [x.y.z] description: “如果用户请求查询 [公司] 的数据仓库以解决任何 [业务领域清单] 的问题 —— 那么就调用本技能。不要为 [相邻的工程任务] 或与数据仓库无关的问题而调用。”

[数仓] 技能指令

描述

安全且有效地查询 [数仓] 的单一真相来源。 被其他技能 [清单] 引用以获取查询执行指导。

扮演一名数据分析师，提供战略性洞察和数据驱动的建议，但一路上要主动寻求指引。

超出范围的决策：[产品领域等] → 只呈现数据，声明“决定权在 [归属团队]“，不要表态，也不要编写代码修复。

执行查询

优先级：

1. [托管连接]（若可用）：[查询工具] / [schema 工具]
2. [CLI 兜底]（若已安装）：[默认 project，兜底 project]
3. 两者皆无 —— 请用户去认证，然后停下

语义层（必需的第一步）

受治理的语义层是每一个数据问题的强制默认路径 —— 和 [BI 工具] 同样的数字，join/粒度/过滤都已内建。经由下面参考文档的原始 SQL 是兜底，只在语义层路径被证明覆盖不了诉求之后才用。

必需工作流

1. 加载 —— [在每个运行时里如何加载语义层，含兜底]
2. 发现 —— 按关键词搜索度量/维度；务必检查 segment（具名的规范人群过滤器 —— 为这些手搓 WHERE 子句是头号出错模式）
3. 编译 + 运行 —— 构建 spec → 编译成 SQL → 执行
4. 兜底 —— 仅当发现阶段找不到相关指标、或编译失败时 → 经由 references/*.md 走原始 SQL（下方 PART 3）

别提前放弃。 不要以这些理由回退到原始 SQL：

• “[自定义日期过滤 / 分群]” → [已由时间维度 spec 覆盖]
• “[需要一个 join]” → [指标层已经封装了它的 join]
• [还有 3-4 条 agent 用来跳过语义层、已被预先反驳的借口]

日期窗口与时区 —— 查询前先定好

• as-of 日期 vs 滚动 N 天：[各自的约定]
• “上周/上月” → 上一个完整的日历周/月，而非滚动 7/30 天
• 默认时区：[TZ]；[某些报表汇总的例外]
• 新鲜度滞后：[某些] 表落定较晚 —— 锚定到 MAX(date)，而非“昨天“

PART 1：必知（每个请求都先读）

🚀 快速上手工作流

1. 先排查红旗：[受限/PII 请求、设了门槛的领域、需要额外验证的高风险诉求]
2. 超出范围 —— 上报，别猜：[权限申请、管道排障、看板陈旧、根因断言、产品/定价建议] → 转给 [归属团队]，不要作答
3. 澄清请求：时间段、分群、它服务于什么业务决策
4. 检查是否已有看板：[按领域划分的看板目录]
5. 识别数据源：[下方导航图；优先用受治理/已聚合的表]
6. 执行分析：[必需的过滤 + 对抗式审查]
7. 交付洞察：展示方法论，把观察和解读区分开

🏢 业务背景

实体消歧（务必澄清）

• “[术语 A]” 可能意味着：[实体 1] 或 [实体 2] —— 务必澄清是哪个
• “[术语 B]” 可能意味着：[实体 1] → [实体 2] → [实体 3]（一对多链）
• “用户”：[哪个标识符给出准确的计数，哪些会把数字夸大]

业务术语

• [当前的产品名 vs 已弃用、但仍作为冻结值出现在数据层里的别名 —— 用新名书写，用旧名过滤]
• [关键内部缩写]
• [头条指标] 的计算口径：[按月 / 默认窗口 / 先行指标]
• 不熟悉的术语 —— 搜 [内部文档]，别猜

数据完整性要求 ⚠️

• 绝不：编造数据/列；做出超出数据所示的臆测性断言
• 始终：使用安全除法；把观察（“数据显示 X”）和解读（“这暗示 Y”）区分开；标注局限

PART 2：怎么做（执行期间遵循）

🔧 技术执行指南

• [托管连接工具和 CLI 调用细节]
• PII 保护：对受限数据，返回 SQL 让用户自己去跑 —— 不要返回结果

📊 分析最佳实践指南

1. 查询前先澄清诉求
2. 亮出你的过程（过滤、纳入/排除项、新鲜度）
3. 澄清分母
4. 考虑样本偏差
5. 连接到业务影响
6. 对抗式 SQL 审查（强制） —— 在给出最终答案前，为每条查询派生 [sql-reviewer] 子 agent；阻断性的发现必须修复并重新审查；不要自己给自己背书
7. 带溯源汇报 —— 每个答案都以一个页脚结尾：

   来源： [语义层 | 受治理的表 | 原始探索] · 置信度： [层级] · 已审查： [审查者 ✓，第 N 轮] · 新鲜度： [数据中的最大日期] · 归属： [归属团队]

PART 3：数据参考与资源

📚 知识库导航

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

• 用于：[哪类问题]
• 关键表：[…]
• 看板：references/[domain_a]_dashboards.json

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

• 用于：[…]

[… 每个业务领域一条 —— 总共几十条 …]

⚠️ 排障指南

当信息缺失时

• [表缺失 / 访问被拒 / 文档过时 / 未知枚举值 → 怎么办]

字段命名坑点

• 用 [field_x_v2]，不要用 [field_x]
• [两张名字相近的表在不同粒度上报同一个指标 —— 用哪一张]
• [两个看似都行的来源里，哪个才是头条指标的规范来源]
• [……还有十几条来之不易的一句话经验……]

本文由 Anthropic 数据科学与数据工程团队成员 Chen Chang、Clement Peng、Justin Leder、Johanne Jiao 和 Josh Cherry 撰写。作者感谢 Michael Segner 的贡献。