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

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

许多数据科学和数据工程团队都能证明，实现自助式业务分析历来是一项艰巨的任务。通过宽表和反范式化的表让数据模型对技术能力较弱的同事更易用，随着业务规模扩大，往往会导致视图重叠、定义不一致（并且对那些不太想学习 SQL 的员工来说，几乎无助于弥合差距）。另一种方式是，为用户创建更多隔离环境，但这往往会遗漏大量长尾业务问题，并导致指标和仪表盘臃肿，因为团队各自为政。

LLM 的兴起为自助式分析提供了一条避免这些挑战的新路径。然而，直接把 Claude 指向数据仓库并让 agent 执行，可能会造成一种虚假的精确感。最初从即席请求中解放出来的喜悦，很快就会变成恐惧，因为人们意识到这种设置将利益相关者与底层基础设施、文档和曾经引导他们使用精心策划的数据集的专业知识割裂开来。

在 Anthropic，95% 的业务分析查询通过 Claude 自动化，总体准确率约为 95%。通过将这些往往是常规重复的工作交给 Claude，我们的数据科学团队可以专注于更具战略意义的工作，如因果建模、预测和机器学习。

在与数十位 Anthropic 的顶级 Claude Code 用户会面并看到无数分析 agent 设计模式后，我们总结出一些最佳实践，可供其他数据团队在使用 LLM 时参考。本文将分享这些技巧和方法，以最大限度地提高 Claude 驱动自助式业务洞察的能力，包括： - 为什么分析准确性是一个上下文和验证问题，而不是代码生成问题； - 导致大多数错误的三种失败模式； - 我们为解决这些错误而构建的 agentic 分析栈； - 我们如何衡量有效性；以及 - 我们创建大多数 skill 的基本模板（见附录）

数据不是软件

LLM 的生成能力是一把双刃剑：能够创造性地解决复杂问题的机制，也可能幻觉出错误的输出。要全面理解分析 agent 面临的挑战，将其与代码 agent 进行对比很有帮助。

编码是一个开放式的解决方案空间，奖励模型的创造力，而文档和测试则提供了防止幻觉的自然护栏。相比之下，对于分析用例，通常只有一个正确答案，且只有一个正确的数据源，而该数据源没有确定性方法来证明其正确性。

对于自助式 agentic 业务分析，复杂性主要在于数据的歧义性。核心问题在于我们能否将用户的问题映射到数据模型中特定且最新的实体，并知道正确处理它们的方法。如果我们能做到这一点，那么后续的执行和 SQL 就变得微不足道了。

我们发现了这个问题的三个属性，它们导致了绝大多数不准确的回答： - 概念与实体的歧义：数据模型中有数百个可行选项（潜在数百万个字段），agent 无法选择最合适的字段来最好地回答用户的问题。例如，在衡量活跃用户数量时：什么行为构成“活跃”？是否包含欺诈用户？使用什么回溯窗口？ - 数据过时：数据源、业务定义和模式不断变化；资产和 agent 知识会过时，并开始返回细微错误的答案。 - 检索失败：正确的信息可能确实存在于数据模型中并且有适当的注释，但由于搜索空间巨大，agent 就是找不到它。

我们的 agentic 分析栈

在 Anthropic，我们主要通过 agentic 数据栈来最小化这三种错误。每一层主要针对其中一个或多个问题： - 实体歧义：数据基础和事实来源将可能的实体空间缩小到只有一个受治理的答案。 - 过时：维护和验证流程确保随着业务变化，所有内容不会腐烂。 - 检索失败：Skill 确保 agent 可靠地找到并正确使用该答案。

在本节中，我们将讨论如何构建每一层。

数据基础

确保分析 agent 准确性的最重要方面是强大的数据基础，包括数据仓库中的数据模型、转换、测试和表，以及描述它们的元数据。标准的数据工程和数据质量实践，如维度建模、左移测试、关键管道的时效性和完整性检查，仍然适用（我们不会在此赘述）。

发生变化的是，你的数据模型的最终用户不再是数据专家（如数据科学家），而是代表具有不同程度数据专业知识或对底层基础设施了解的用户的 agent。这种转变带来了一个挑战，即结果不能要求用户验证其底层正确性，因为最终用户不知道。

数据基础层主要针对歧义：例如，如果“收入”解析为一个受治理的数据集，而不是四十个候选数据集，那么问题在 agent 需要搜索之前就基本上消失了。这里也是第一个针对过时的防御层，因为定义规范模型的同一 repo 自然是强制它们保持最新的地方。

我们看到了几种特别有效的实践： - 创建规范数据集：到目前为止，最常见的失败是 agent 无法将概念（“产品 X 的收入”）映射到唯一正确的表、列和指标定义，通常因为有多个候选方案，实现方式略有不同。解决方法是用更少、更严格治理的逻辑模型：策划一小组规范的、单一事实来源的数据集，这些数据集有明确的所有者、可供消费且可发现，然后积极废弃近似的副本。物理汇总和缓存仍然对成本和性能很重要，但它们应该从规范模型中机械地派生，而不是作为替代方案与之共存。目标是当 agent 搜索某个概念时，它只找到一个受治理的答案。 - 强制执行标准：我们发现，数据基础只有在规范模型和指标定义通过工具（agent 在结构上首先被引导到它们；下文将详述）、CI（绕过它们的变更将无法通过审查）和授权（下游团队在治理层之上构建或解释原因）强制执行时才有效。否则，没有强制执行的治理很快就会退化回多个候选问题。 - 共存工件：我们针对不断变化的数据模型和业务逻辑的主要防御手段是共存。几乎所有数据代码（即建模、语义层、参考文档、规范仪表盘定义）都位于一个 repo 中，并带有保护跨层完整性的 CI 检查。如果建模更改会破坏下游仪表盘或使已记录的指标失效，CI 会标记它，并且修复会在同一个 PR 中发布。（我们将在下面的 Skill 部分再次讨论这方面的机制。） - 将元数据视为一流产品：代码 agent 表现良好，部分原因是代码库是可读的：README、类型签名、文档字符串等。你的数据仓库也可以同样可读，但前提是列和表描述、规范指标定义、粒度文档、有效值范围、沿袭、所有权和模型分层都像转换本身一样严格维护。虽然这不是新见解，但良好的治理提供了关键上下文，帮助 agent 选择正确的数据集。

事实来源

如果说数据基础是数据仓库本身，那么事实来源就是 agent 用来导航它的参考界面。这一层减少了概念与实体的歧义，并将利益相关者问题中的“每周活跃用户”转化为数据模型中的特定受治理实体。大致按信任度降序排列： - 语义层：编译后的指标和维度定义。如果问题清晰地映射到已定义的指标，agent 调用一个函数并得到一个数字，与公司其他所有界面产生的数字相同。我们的 agent 在结构上被要求（通过 skill 指令）首先利用语义层（见附录）。我们尝试过但失败的一个想法：通过让 LLM 从原始表和查询日志自动生成指标定义来引导语义层。它产生了看起来合理的定义，但编码了我们想消除的确切歧义，并且相对于较小的人工策划层，对我们的评估是净负面的。因此，我们建议用 Claude 生成文档，但由人类拥有定义。 - 沿袭和转换图：当语义层无法覆盖某个问题时，沿袭和表排名（基于引用次数）让 agent 能够推理哪些上游模型输入某个概念，哪些已被弃用，以及哪些共享粒度。这将“我不知道指标”转化为“我知道从哪个受治理模型进行聚合”。它也是我们在下面在线验证中提供的时效性和来源信号的骨干。 - 查询语料库：来自仪表盘、笔记本和之前分析的历史 SQL。直观上，这应该很有价值：它记录了所有已正确回答的问题。在实践中，我们发现让 agent 对数千个先前查询进行原始检索访问，准确性提升不到一个百分点（我们在后面一节中展示了这个消融实验）。非结构化检索无法将新问题映射到正确的先例。有效的是，将那个语料库提炼成结构化的按领域参考文档和 skill 中描述的可重用分析模式。将查询历史视为策展的原始材料，而不是 agent 直接读取的事实来源。 - 业务上下文：大多数团队跳过的一层，也是我们长期以来低估的一层。不了解你业务的 agent 会回答用户提出的问题，但不会回答他们实际意图的问题。它不知道“Q2 发布”指的是某个特定产品，不知道两个团队对同一个术语的定义不同，也不知道某个问题被提出是因为周四有个董事会会议。我们引入了一个公司知识图谱，包含索引的文档、路线图、决策日志和组织结构，以便 agent 能够解析环境引用并提出更好的澄清问题。

这四个层次的常见失败模式与数据基础层相同：文档质量差或过时。Claude 在缩小差距方面异常有用（起草列描述、从查询模式提出指标文档、在 CI 中标记未记录的模型），但策展和所有权由人类管理。在接下来的两节中，我们讨论如何让这种所有权足够廉价，以便实际发生。

Skill

如果说事实来源是 agent 的声明性知识（即一个指标的含义），那么 skill 就是它的程序性知识：按什么顺序咨询哪些来源，如何导航有歧义的数据，以及完成的分析是什么样的。

在 Claude Code 中，skill 是一个文件夹，里面包含 agent 按需读取的 markdown 文件。在 Anthropic，我们开发的 skill 非常有价值。没有 skill，Claude 在我们的评估中准确回答分析问题的能力不超过 21%。添加 skill 后，这些数字在总体上持续超过 95%，在某些领域经常在 99% 左右。请参阅附录，了解我们用于创建大多数 skill 的框架。

一些最佳实践： - 创建成对的 skill：一个知识 skill 充当一个薄层顶级路由器，允许按需加载额外的领域细节。它说“首先尝试语义层，但如果 Coverage 不足，这里有约 30 个该领域的参考文件，描述相关的表、列、连接和陷阱”。这个路由器实际上是我们对检索失败的回应：不是让 agent 在一个百万字段的仓库中搜索，而是在编写查询之前将空间缩小到几十个策展文件。Unbook skill 编码了高级分析师会遵循的过程：澄清问题、找到来源（通过知识 skill）、运行查询，然后通过对抗性审查子 agent 循环结果。它还捆绑了一打可重用的分析模式（留存曲线、率分解、漏斗分析），这样常见请求就不会每次都重新发明。 - 创建适当的参考文档：为 LLM 检索而编写。我们的参考文档描述表（粒度、范围和排除项）、陷阱的机制（例如，“排除已知的免费电子邮件域，但保留自定义域如 anthropic.com”），以及显式的路由触发器（例如，“如果问题是关于实验提升……不要用于原始事件计数”），而不编写会过时的规定性配方。下面是我们用于创建参考文档的框架。 ` # [领域] 表

## 快速参考 ### 业务上下文 — [这个领域用简单的话说什么意思] ### 实体粒度 — [一行代表什么] ### 标准过滤条件 — [这个领域中每个查询都应用的过滤]

## 维度 - [关键维度如何编码，以及同一概念在不同表中的不同名称]

## 关键表 ### [表名] - 粒度: [...] · 范围/排除项: [...] - 用法: [何时使用，何时不该使用，连接键，必需过滤] [... 每个受治理表一个简短章节 ...]

## 陷阱 - [高级分析师会警告你的错误答案模式]

## 最佳实践 / 常见查询模式 - [默认选择、标准切分、确切查询形式是难点的有效模式]

## 交叉引用 - [处理相邻问题的相邻领域文档] ` - 将 skill 维护视为一等公民：Skill 文档描述的是每天变化的数据模型，因此没有主动维护，它们会在几周内出错。我们目睹了离线准确率从上线时的约 95% 在一个月内下降到约 65%，之后我们才将此视为工程问题。这意味着将 skill markdown 文件与转换模型放在同一个 repo 中，这样更改模型的 PR 就是更新文档的 PR。一个代码审查钩子会标记任何没有触及 skill 文件的报告模型更改。我们大约 90% 的数据模型 PR 现在都在同一 diff 中包含了 skill 更改。我们还定期修剪 skill 脚手架，随着模型改进和先前失败模式不再适用。 - 在所有界面上创建一致且无缝的体验：同一个 skill 必须在 Slack、IDE、仪表盘工具和独立 agent 会话中提供相同的答案。我们通过确保一个规范来源（数据 repo）以及 skill 更改自动同步来实现这一点。合并后，skill 同步到插件市场（供 IDE 用户使用）、云存储 blob（供读取单个文件的托管应用使用），并通过 MCP 作为资源直接提供。我们还从一开始就设计了可移植性，避免硬编码的 repo 路径和特定于界面的命名空间。

验证

最后，验证是你如何发现三种失败模式中哪一种仍然存在的。

#### 离线评估

我们看到的常见模式是，数据团队会建立复杂的分析环境，但没有任何流程来了解其分析 agent 的准确性。

解决这一差距的一种方法是通过离线评估，即简单的问题/答案对。你可以将离线评估视为类似于 ML 模型的离线测试：它们不会告诉你在线 agent 的性能，但会让你很好地了解是否存在关键缺口。

我们在 Anthropic 部署了两种离线评估。基于仪表盘的评估由 Claude 自动生成（然后由人工验证），涵盖最常见的利益相关者问题。长尾评估是我们向 Claude 提供业务上下文（路线图、表文档）并让它生成跨领域其余部分的合理问题。我们还会持续收集每次利益相关者在对话中纠正 agent 的情况，因为该纠正就是一个候选评估。

其他最佳实践包括： - 锚定真实答案，使其不会漂移：针对实时数据编写的评估在底层数字变化时会立即过时。将每个评估固定到某个快照日期，针对稳定的事实表编写，或者让评分者判断 agent 的查询而不是其数字。将评估套件接入 CI，这样触及依赖关系的 PR 会重新运行受影响的评估。 - 像存储遥测一样存储结果，而不是测试日志：每次运行都会落入一个仓库表，包含 skill 版本、git SHA、模型 ID、每个断言的通过/失败、token 数和墙上时间。“那个更改有帮助吗？”变成了一个查询，你可以获得时间序列来捕捉单个 CI 运行可能遗漏的缓慢回归。 - 按领域门控发布：领域所有者不能向利益相关者宣布 agent，直到他们那一部分的评估集超过某个阈值（我们最初使用约 90%）。这强制在用户看到失败之前进行参考文档修复。 - 创建适当数量的评估：你应该拥有的评估数量取决于业务领域的复杂性和底层数据模型的复杂性。通过跟踪离线准确性预测在线准确性的程度来校准：我们发现每个主题（例如“增长”）超过几十个评估后回报递减，并且随着每一代新模型的出现，该天花板会下降。 - 离线评估准确性应接近 100%；每个正确答案还应命中你的语义层（如果有的话）。再次强调，这种准确性水平并不说明你的系统不会产生错误答案，只是说明没有明显的缺口，假设你有适当的评估覆盖。

#### 消融技术

关于 skill 的每个结构性决策（例如，暴露哪些来源、子 agent 是否值得其延迟、是否合并两个 skill）都是通过固定我们的离线评估集来进行的。

我们每次只改变一个组件并比较通过率。每次运行只需一小时，并取代了大量争论。方法论比任何单个结果更重要： - 为无效结果而设计。我们最有用的消融是一个负面的消融。我们让 agent 可以直接 grep 访问我们所有的仪表盘、转换和分析师笔记本 SQL（数千个文件）。然后我们验证在转录中它在每次回答前确实读取了它们。准确性向任何方向移动了不到一个百分点。然后我们检查了明显的混淆因素：答案实际上在语料库中，但问题却答错了？大约 80% 的情况下，是的。“答案存在”是否预测“现在正确”？不，翻转率是平的。信息就在那里，agent 看到了，但仍然没有使用。那一个实验告诉我们，我们的瓶颈不是访问先前工作，而是结构（即将问题映射到正确的实体）。这一洞察改变了数月的路线图。 - 在 PR 粒度上消融。每个有意义的 skill 编辑都会在相关评估切片上进行前后运行，并在 PR 描述中附带差异。这保持了“我改进了文档”的真实性，并捕捉了意外常见的情况：善意的添加反而让事情变糟。 - 保留一个不起作用的内容的简短列表。我们的两个：超过某个点后堆叠额外的文档优化轮次（我们遇到了连续三次净负迭代：文档变得更长，而不是更好），以及将对抗性审查者换成更便宜的模型以降低延迟（它失去了大部分准确性提升，而速度几乎没有提高）。负面结果记录起来成本很低，而且它们阻止了下一个人重新运行相同的实验。

#### 在线验证

最后一步是确保实际在线系统的性能尽可能准确。我们采取的一些步骤包括： - 对抗性审查：我们发现，使用一个 Claude skill 来积极挑战最终答案的所有底层假设，在我们的评估集中将准确性提高了 6%，但代价是增加了 32% 的 token 和 72% 的延迟。 - 来源页脚：每个响应都带有一个页脚，其中包含它来自哪个源层级（语义层 > 策展参考 > 原始表）、底层数据的新鲜度以及模型的所有者。它不会使答案更正确，但有助于消费者判断他们可以多大程度信任该响应。一个“原始表，新鲜度未知”的页脚是在向上游转发之前进行验证的信号，也是我们对静默失败的少数缓解措施之一。 - 数据质量检查：你的 agent 可能以正确的方式使用了正确的字段，但数据本身可能是错误的。添加基本的数据质量检查以确保引用的字段是最新的、完整的且没有异常，通常是一种良好的卫生习惯。 - 被动监控：我们持续跟踪的两个生产信号是通过语义层解析的 agent 查询比例，以及使用纠正语言（“那是错误的表”、“你漏掉了欺诈过滤器”）的响应比例。两者都会输入到一个每周与离线通过率一起审查的仪表盘。 - 主动纠正收集：闭合循环的部分。一个定时 agent 每隔几小时扫描利益相关者频道，寻找类似的纠正语言，起草一条针对相关参考文档的一行修复，并打开一个标记给领域所有者的 PR。修复路径故意设计得很简单——编辑 markdown 文件，合并，自动同步到所有地方——这样领域所有者就不会花太多时间在这项任务上。相同的纠正会反馈到离线评估集中。

这些方法都无法完全捕获的失败模式是静默失败。答案错误，但看起来合理，并且没有被质疑而使用。我们的缓解措施是来源页脚、对任何面向领导层的内容有明确的人工签字，以及每个领域主要 KPI 的一个常设评估，用于每天对照受批准的仪表盘进行合理性检查，尽管我们还没有一个稳健的解决方案。

入门指南

如果你从零开始，一小部分规范数据集、几十个离线评估和一个薄薄的知识 skill 将捕获大部分收益；本文中其他所有内容都是我们在构建好这些之后才添加的。

我们也分享了许多最佳实践，但并非所有都适合每个数据团队。与你的组织就一些会影响你方法的原则达成一致，可以问以下问题： - 今天得到一个正确答案有多重要，还是未来更重要？ AI 模型正在快速进步。我们经常看到公司投入大量基础设施来弥补当前模型的不足，而一旦这些模型改进，这些不足就变得无关紧要了。知道模型在哪里有欠缺，并等待模型改进来填补空白，开销要少得多，但可能不符合公司的风险承受能力。 - 你预计你的业务复杂性在未来会如何变化？ 我们讨论的一些流程可能过于繁琐，例如，如果你不产生太多数据，只有少数几个输出消费者，或者你的数据模型可能保持简单。 - 输出目标受众的技术水平如何？ 换句话说，如果你是为此分析系统的数据科学家构建的，他们能够识别答案是否正确，那么你可能更能容忍错误，相比受众对底层数据模型不熟悉的情况。 - 你愿意为提高准确性投入多少？ 我们发现，某些流程如对抗性验证可以显著提高准确性，但通常以更高的成本和延迟为代价。 - 你对访问控制和内部数据隐私的舒适度如何？ Agent 通常拥有的上下文越多，性能越好；然而，广泛的数据访问与大多数公司的治理姿态相悖。这决定了你是构建一个 agent 还是多个有作用域的 agent。

无论你选择哪条路，我们最大的收益来自于解决这三种失败模式：将歧义压缩成一个受治理的答案，使该答案易于发现，并在两者中的任何一个过时后标记出来。

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

附录：Skill 文件框架

以下是我们主要仓库 skill 的框架：实际文件的结构，内部细节用 [括号占位符] 替换。它不是用来逐字复制的；而是为了展示我们认为值得写下来的那些章节类型。

` --- name: [warehouse-skill] version: [x.y.z] description: "如果用户要求查询[公司]的数据仓库以获取任何[业务领域列表]的问题 — 则调用此 skill。不要将其用于[相邻的工程任务]或没有数据仓库组成部分的问题。" ---

[仓库] Skill 指令

## 描述 安全有效的[仓库]查询的单一事实来源。被[列出的]其他 skill 引用以提供查询执行指导。

扮演数据分析师的角色，提供战略见解和数据驱动建议，但在此过程中寻求指导。

超出范围的决定: [产品领域等] → 仅提供数据，声明“决定是[拥有团队]的职责”，不要持有立场或编写代码修复。

## 执行查询 优先级: 1. [托管连接] (若可用): [查询工具] / [模式工具] 2. [CLI 回退] (若已安装): [默认项目, 回退项目] 3. 二者皆无 — 要求用户进行身份验证，然后停止

---

语义层（必需的第一步）

受治理的语义层是每个数据问题的强制性默认路径 — 与[BI 工具]相同的数字，连接/粒度/过滤器已内建。通过以下参考文档使用原始 SQL 是回退，仅在语义层路径被证明无法覆盖请求后才使用。

## 必需的工作流程 1. 加载 — [如何在每个运行时中加载语义层，包含回退] 2. 发现 — 按关键字搜索度量和维度；始终检查分段（命名的规范群体过滤器 — 为此手工编写的 WHERE 子句是主要的错误答案模式） 3. 编译 + 运行 — 构建规范 → 编译为 SQL → 执行 4. 回退 — 仅当发现未找到相关度量或编译失败时 → 通过 references/*.md 使用原始 SQL（下面的第 3 部分）

> 不要过早放弃。 不要因以下原因回退到原始 SQL： > - "[自定义日期过滤/群组]" → [由时间维度规范覆盖] > - "[需要连接]" → [度量层已封装其连接] > - [3–4 个 agent 用来跳过语义层的预先反驳的借口]

### 日期窗口和时区 — 在查询前决定 - 截至日期 vs 过去 N 天: [每种情况的约定] - “上周/上月” → 上一个完整的日历周/月，不是过去 7/30 天 - 默认时区: [TZ]; [某些报告汇总的例外] - 时效滞后: [一些]表延迟结算 — 锚定在 MAX(date)，而不是“昨天”

---

第 1 部分：必须知道（每次请求先阅读）

## 🚀 快速入门工作流程 1. 首先检查红旗标志: [受限/PII 请求、门控领域、需要额外验证的高风险要求] 2. 超出范围 — 升级，不要猜测: [访问请求、管道故障排除、过时仪表盘、根本原因断言、产品/定价建议] → 重定向到[拥有团队]，不要回答 3. 澄清请求: 时间段、分段、其通知的业务决策 4. 检查现有仪表盘: [按领域仪表盘目录] 5. 识别数据源: [下面的导航地图；优先选择受治理/聚合表] 6. 执行分析: [必需过滤器 + 对抗性审查] 7. 提供洞察: 展示方法论，区分观察结果与解释

🏢 业务上下文

### 实体消歧（必须澄清） - "[术语 A]" 可以表示: [实体 1] 或 [实体 2] — 始终澄清是哪个 - "[术语 B]" 可以表示: [实体 1] → [实体 2] → [实体 3]（一对多链） - "用户": [哪个标识符给出准确计数，哪个会膨胀计数]

### 业务术语 - [当前产品名称 vs 仍作为数据层冻结值出现的已弃用别名 — 用新名称写，用旧名称过滤] - [关键内部缩写] - [标题指标] 计算: [每月/默认窗口/先行指标] - 不熟悉术语 — 搜索[内部文档]，不要猜测

### 数据完整性要求 ⚠️ - 绝对不要: 编造数据/列；进行超出数据显示范围之外的推测性断言 - 始终: 使用安全除法；区分观察结果（“数据显示 X”）与解释（“这暗示 Y”）；标记局限性

---

第 2 部分：如何做（执行时遵循）

## 🔧 技术执行指南 - [托管连接工具和 CLI 调用细节] - PII 保护: 对于受限数据，返回 SQL 供用户自行运行 — 不返回结果

## 📊 分析最佳实践指南 1. 查询前澄清要求 2. 展示你的工作（过滤器、包含/排除、新鲜度） 3. 澄清分母 4. 考虑样本偏差 5. 联系业务影响 6. 对抗性 SQL 审查（强制） — 在最终答案之前为每个查询启动 [sql-reviewer] 子 agent；阻塞性发现必须修复并重新审查；不要自我认证 7. 附来源报告 — 每个答案以页脚结尾： > 来源: [语义层 | 受治理表 | 原始探索] · > 置信度: [层级] · 已审查: [审查者 ✓, 第 N 轮] · > 新鲜度: [数据中的最大日期] · 所有者: [拥有团队]

---

第 3 部分：数据参考与资源

## 📚 知识库导航 ### [领域 A] → references/[domain_a].md - 使用于: [种类的问题] - 关键表: [...] - 仪表盘: references/[domain_a]_dashboards.json

### [领域 B] → references/[domain_b].md - 使用于: [...]

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

⚠️ 故障排除指南

### 信息缺失时 - [缺失的表 / 访问被拒绝 / 过时文档 / 未知枚举值 → 做什么]

### 字段命名陷阱 - 使用 [field_x_v2] 而不是 [field_x] - [两个名称相似的表以不同粒度报告同一个指标 — 使用哪个] - [两个看似合理的来源中哪个是标题指标的规范来源] - [… 更多来之不易的单行 …] `