Anthropic用Claude自动化95%数据分析查询

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

• 分类企业 AI
• 产品Claude Code
• 日期：2026年6月3日
• 阅读时间：5分钟
• 分享复制链接https://claude.com/blog/how-anthropic-enables-self-service-data-analytics-with-claude

正如许多数据科学和数据工程团队所证实的那样，实现自助式业务分析历来是一项艰巨的任务。

通过宽表和非规范化表使数据模型对非技术同事更易用，往往会导致随着业务扩展而出现定义不一致的重叠视图（而且对于那些不太愿意学习 SQL 的员工来说，这几乎无助于弥合差距）。或者，为用户创建更多隔离环境，往往会遗漏长尾业务问题，并导致指标和仪表板膨胀，因为团队各自为政。

LLM 的兴起为自助式分析提供了另一条路径，可以避开这些挑战。然而，让 Claude 直接指向数据仓库并让代理执行可能会产生一种虚假的精确感。

最初摆脱临时请求的兴奋感，很快就会被恐惧所取代，因为人们意识到这种设置将利益相关者与底层基础设施、文档和专业知识隔离开来，而这些原本可以引导他们使用精心策划的数据集。

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

在与数十位 Anthropic 顶尖的 Claude Code 用户会面，并看到多种多样的分析代理设计模式之后，我们为其他使用 LLM 的数据团队积累了一些最佳实践。在这篇文章中，我们将分享这些技巧和方法，以最大化 Claude 推动自助式业务洞察的能力，包括：

• 为什么分析准确性是一个上下文和验证问题，而不是代码生成问题；
• 导致大多数错误的三种失败模式；
• 我们为解决这些错误而构建的代理式分析技术栈；
• 我们如何衡量有效性；以及
• 我们创建大部分技能的基本模板（见附录）

数据不是软件

LLM 的生成能力是一把双刃剑：使创造性解决复杂问题成为可能的机制也可能产生幻觉输出。要完全理解分析代理所面临的挑战，将其与编码代理进行比较是很有用的。

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

对于自助式代理业务分析，复杂性主要在于数据的模糊性。核心问题归结为我们的将用户的问题映射到数据模型中具体且最新的实体，并知道使用它们的正确方法的能力。如果我们能做到这一点，那么随后的执行和 SQL 就变得微不足道。

我们确定了这个问题的三个属性，它们导致了绝大多数不准确的响应：

1. 概念与实体之间的歧义：数据模型中有数百个可行选项（潜在可能有数百万个字段），代理无法选择最能回答用户问题的正确字段。例如，在衡量活跃用户数量时：什么行为构成“活跃”？是否包括欺诈用户？使用什么回溯窗口？

1. 数据过时：数据源、业务定义和模式不断变化；资产和代理知识会过时，并开始返回微妙的错误答案。

1. 检索失败：正确的信息可能实际上就在数据模型中，并且标注正确，但由于搜索空间巨大，代理根本找不到它。

未找到任何项目。

上一页

0/5

下一页

获取 Claude Code

或阅读文档

试用 Claude Code

试用 Claude Code

开发者文档

开发者文档

电子书

我们的代理式分析技术栈

在 Anthropic，我们主要通过代理式数据技术栈来最小化这三种错误。每一层主要针对其中一个或多个问题：

1. 实体歧义：数据基础和真相来源缩小了可能实体的范围，直到存在唯一的受治理的答案。

1. 过时：维护和验证流程确保一切不会随着业务变化而腐烂。

1. 检索失败：技能确保代理可靠地找到并正确使用该答案。

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

数据基础

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

所改变的是，数据模型的最终用户不再是数据专家（例如数据科学家），而是代表用户行事的代理，这些用户的数据专业知识或对底层基础设施的理解程度各不相同。这种转变带来了一个挑战：结果不能要求用户验证底层正确性，因为最终用户不知道。

数据基础层主要针对歧义：如果收入，例如，解析为一个受治理的数据集，而不是四十个可能的候选，问题在很大程度上在代理需要搜索之前就消失了。这也是第一道防过时防线所在，因为定义规范模型的同一仓库是强制执行它们保持最新的自然位置。

我们看到一些做法特别有效：

• 创建规范数据集：到目前为止，最常见的失败是代理无法将概念（“产品X的收入”）映射到唯一的正确表、列和指标定义，通常是因为存在多个具有微妙不同实现的候选。解决办法是减少但更严格治理的逻辑模型：精心策划一小套规范的、单一事实来源的数据集，这些数据集有明确归属、可直接消费且易于发现，然后积极弃用近似重复的模型。物理汇总和缓存对成本和性能仍然重要，但它们应从规范模型机械地派生，而不是作为替代品与之并存。目标是当代理搜索一个概念时，它找到一个受治理的答案。
• 强制执行标准：我们发现基础只有在规范模型和指标定义由工具（代理在结构上首先被引导到这些模型；下文将详细介绍）、CI（绕过它们的更改会审查失败）和指令（下游团队在受治理层上构建或解释原因）强制执行时才成立。否则，缺乏强制执行的治理很快就会退化回多候选问题。
• 放置工件：我们对抗不断变化的数据模型和业务逻辑的主要防御是放置。几乎所有数据代码（即建模、语义层、参考文档、规范仪表板定义）都位于单个仓库中，并通过保护跨层完整性的CI检查。如果建模更改会破坏下游仪表板或使文档中的指标无效，CI会标记它，修复会在同一PR中交付。（我们将在技能部分 下面回到其机制。）
• 将元数据视为一等产品：编码代理表现良好部分是因为代码库是可读的：README、类型签名、文档字符串等。你的仓库同样可以可读，但只有列和表描述、规范指标定义、粒度文档、有效值范围、沿袭、所有权和模型分级与转换本身一样严格维护时才行。虽然这不是新见解，但良好的治理提供了关键上下文，帮助代理选择正确的数据集。

事实来源

如果数据基础是数据仓库本身，那么事实来源是代理为导航仓库而查阅的参考表面。这一层减少了概念与实体之间的歧义，并将利益相关者问题中的“每周活跃用户”转化为数据模型中的特定受治理实体。大致按信任程度降序排列：

• 语义层：编译后的指标和维度定义。如果问题能清晰映射到已定义的指标，代理调用函数并得到一个数，与公司其他表面产生的数相同。我们的代理被结构性要求（通过技能指令）首先利用语义层（见附录）。我们尝试过的一个想法没有奏效：通过让LLM从原始表和查询日志自动生成指标定义来启动语义层。它产生了看似合理的定义，却编码了我们试图消除的歧义，并且相对于较小的人工策划层，对我们的评估是净负面的。因此，我们建议用Claude生成文档，但由人类拥有定义。
• 沿袭和转换图：当语义层未覆盖某个问题时，沿袭和表排名（基于引用数）让代理推理哪些上游模型提供概念，哪些已弃用，哪些共享粒度。这会将“我不知道指标”转化为“我知道从哪个受治理模型聚合”。这也是我们在下面在线验证中呈现的新鲜度和来源信号的主干。
• 查询语料库：来自仪表板、笔记本和先前分析的历史SQL。直觉上，这应该具有高价值：它记录了每个已正确回答的问题。实际上，我们发现让代理直接检索数千个先前查询将准确性提高了不到一个百分点（我们将在下面一节中介绍该消融实验）。非结构化检索无法将新问题映射到正确的先例。有效的是将该语料库提炼为结构化的按领域参考文档和可复用的分析模式，如技能所述。将查询历史视为策划的原始材料，而不是代理直接阅读的事实来源。
• 业务上下文：大多数团队跳过的一层，也是我们低估最久的一层。不理解你业务的代理会回答用户所问，但不是用户所意指。它不会知道“第二季度发布”指的是特定产品，两个团队以不同方式定义同一术语，或者问题被问是因为董事会会议在周四。我们输入一个由索引文档、路线图、决策日志和组织结构组成的公司知识图谱，使代理能够解析环境引用并提出更好的澄清问题。

所有四层中常见的失败模式与数据基础层相同：文档不佳或过时。Claude在缩小差距方面异常有用（起草列描述、从查询模式提出指标文档、在CI中标记未记录的模型），但策划和所有权由人类管理。

在接下来的两节中，我们讨论如何使这种所有权足够便宜，以便真正发生。

技能

如果事实来源是代理的陈述性知识（即指标的含义），那么技能是它的程序性知识：按什么顺序查阅哪些来源，如何处理模糊数据，以及完整的分析结果是什么样子。

在Claude Code中，一个技能是代理按需读取的Markdown文件夹。在Anthropic，我们开发的技能极具价值。没有技能，在我们的评估中，Claude准确回答分析问题的能力不超过21%。添加技能后，这些数字在总体上持续高于95%，在某些领域通常达到99%左右。参见附录中我们用于创建大多数技能的骨架。

一些最佳实践：

创建成对技能：一个知识技能作为薄顶路由器，允许按需加载额外的领域细节。它说：“先尝试语义层，但如果没有覆盖，这里有大约30个关于该领域的参考文件，描述相关的表、列、连接和陷阱。”这个路由器实际上是我们对检索失败的答案：而不是让代理搜索一个百万字段的仓库，它在编写查询之前将空间缩小到几十个精选文件。运行手册技能编码了高级分析师会遵循的过程：澄清问题，通过知识技能查找来源，运行查询，然后将结果循环通过对抗性审查子代理。它还会捆绑十几个可重用的分析模式（留存曲线、比率分解、漏斗分析），这样常见的请求就不会每次都重新发明。

创建适当的参考文档：为LLM的检索而编写。我们的参考文档描述了表（粒度、范围、排除项）、陷阱的机制（例如，“排除已知的免费电子邮件域，但保留自定义域，如anthropic.com”）以及明确的触发路由（例如，“如果问题涉及实验提升…不要用于原始事件计数”）而不包含会过时的规定性配方。参见下面我们用于创建参考文档的骨架。

# [Domain] Tables## Quick Reference### Business Context — [what this domain means in plain words]### Entity Grain — [what one row represents]### Standard Hygiene Filter — [the filter every query in this domain applies]## Dimensions- [How the key dimensions are encoded, and how the same concept is named
  differently across tables]
## Key Tables### [table_name]
- **Grain**: [...] · **Scope/exclusions**: [...]
- **Usage**: [when to use it, when NOT to, join keys, required filters]
[... one short section per governed table ...]
## Gotchas
- [The wrong-answer modes a senior analyst would warn you about]
## Best Practices / Common Query Patterns
- [Default choices, standard cuts, worked patterns where the exact query
  form is the hard part]
## Cross-References
- [Neighboring domain docs that own adjacent questions]

将技能维护视为一等公民：技能文档描述的数据模型每天都在变化，因此如果没有主动维护，几周后它们就会过时。我们观察到离线准确率从发布时的约95%在一个月内下降到约65%，之后我们将其视为一个工程问题。这意味着将技能Markdown文件与我们的转换模型放在同一个仓库中，这样改变模型的PR就是更新描述该模型的文档的同一个PR。代码审查钩子会标记任何不涉及技能文件的报告模型更改。大约90%的数据模型PR现在包含同一差异中的技能更改。我们还定期修剪技能脚手架，随着模型的改进和以前的失败模式不再适用。

在所有表面创建一致且无缝的体验：同一个技能必须在Slack、IDE、仪表板工具和独立代理会话中对相同的问题提供相同的答案。我们通过确保一个规范来源（数据仓库）和技能更改自动同步来实现这一点。合并时，技能同步到插件市场（供IDE用户使用）、云端存储blob（供读取单个文件的托管应用使用），并通过MCP作为资源直接提供。我们还从一开始就通过避免硬编码的仓库路径和特定于表面的命名空间来设计可移植性。

验证

最后，验证是找出三种失败模式中哪一种仍然泄漏的方法。

离线评估

我们看到的一个常见模式是，数据团队会建立复杂的分析环境，却没有了解其分析代理准确性的流程。

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

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

其他最佳实践包括：

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

消融技术

关于技能的每一个结构决策（例如，暴露哪些数据源、子代理是否值得其延迟、是否将两个技能合并为一个）都是在保持我们的离线评估集不变的情况下做出的。

我们每次只改变一个组件并比较通过率。每次运行只需一个小时，并且取代了很多争论。方法论比任何单一结果都重要：

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

在线验证

最后一步是确保实际的在线系统性能尽可能准确。我们采取的一些步骤包括：

• 对抗性审查：我们发现，使用Claude技能积极挑战潜在最终答案的所有基本假设，在我们的评估集中将准确率提高了6%，但代价是增加了32%的令牌数和72%的延迟。
• 来源页脚： 每个响应都带有一个页脚，其中包含它来自哪个来源层（语义层 › 精选参考 › 原始表）、底层数据的新鲜程度以及谁拥有该模型。它不会使答案更正确，但确实帮助消费者判断他们能在多大程度上信任该响应。一个“原始表，新鲜度未知”的页脚是向上游转发前需要验证的信号，也是我们针对无声故障的少数缓解措施之一。
• 数据质量检查：你的代理可能以适当的方式使用了正确的字段，但数据本身是错误的。添加基本的数据质量检查以确保引用的字段是最新的、完整的且没有异常，通常是一种良好的卫生习惯。
• 被动监控： 我们持续跟踪的两个生产信号是代理查询中通过语义层解决的份额，以及使用纠正语言（“那是错误的表”，“你缺少欺诈过滤器”）的响应份额。两者都输入到一个仪表板中，每周与离线通过率一起审查。
• 主动纠正收集：这是闭环的部分。一个定时代理每隔几小时扫描利益相关者渠道，寻找类似的纠正语言，起草对相关参考文档的一行修复，并打开一个标记给域所有者的PR。修复路径故意很平淡——编辑一个markdown文件，合并，自动同步到所有地方——这样域所有者就不会花太多时间在这项任务上。相同的纠正也反馈到离线评估集中。

以上所有方法都无法完全捕获的故障模式是无声的。答案错了，但看起来合理，而且被没有异议地使用。我们的缓解措施是来源页脚、任何面向领导层的内容都需要明确的人工签字，以及每个域顶级KPI的常设评估，每天对照受信任的仪表板进行合理性检查，尽管我们还没有一个强大的解决方案。

入门

如果你从零开始，一小组规范数据集、几十个离线评估和一个精简的知识技能将捕获大部分价值；这篇文章中的其他内容是我们一旦建立这些之后添加的。

我们还分享了许多最佳实践，但并非所有实践都适用于每个数据团队。与你的组织就一些会影响你方法的原则达成一致，可以问：

• 正确回答在今天与未来的重要性？AI模型正在飞速发展。我们经常看到公司为了应对当前模型的不足而建立了大量基础设施，而这些不足一旦模型改进就会变得无关紧要。知道模型在哪里不足，并等待模型改进来填补差距，开销会显著降低，但可能不符合你公司的风险承受能力。
• 你预计业务复杂性随时间如何变化？例如，如果你不产生大量数据，只有少数消费者使用输出，或者你的数据模型可能保持简单，那么我们讨论的一些过程可能过于繁琐。
• 输出目标受众的技术水平如何？换句话说，如果你是为一群能识别答案错误的数据科学家构建这个分析系统，你可能比面对对底层数据模型不熟悉的受众时更能容忍错误。
• 你愿意为提高准确性付出多少？我们发现某些过程如对抗性验证可以显著提高准确性，但通常以更高的成本和延迟为代价。
• 你对访问控制和内部数据隐私的舒适度如何？代理人通常拥有越多的上下文，其表现就越出色；然而，广泛的数据访问与大多数公司的治理姿态相悖。这决定了您是构建一个代理还是多个有范围的代理。

无论您选择哪条路线，我们最大的收益来自于解决三种失败模式：将模糊性收敛为一个受治理的答案，使答案易于被发现，并标记两者何时已经过时。

本文由陈畅、彭晓明、Justin Leder、Johanne Jiao 和 Josh Cherry 撰写，他们是数据科学和数据工程团队的成员。作者感谢 Michael Segner 的贡献。

附录

技能文件骨架

以下是我们主要仓库技能的骨架：真实文件的结构，内部细节替换为 [带括号的占位符]。它并非要逐字复制；而是要展示我们认为值得写下来的各种部分。

---
name: [warehouse-skill]
version: [x.y.z]
description: "IF the user asks to query [the company]'s data warehouse for any
  [list of business domains] question — THEN invoke this skill. DO NOT invoke
  for [adjacent engineering tasks] or questions with no data-warehouse component."
---# [Warehouse] Skill Instructions## DescriptionThe single source of truth for safe and effective [warehouse] querying.
Referenced by other skills [listed] for query execution guidance.
Act as a Data Analyst, providing strategic insights and data-driven
recommendations but seek guidance along the way.
**Out-of-scope decisions**: [product areas, etc.] → surface data only,
state "decision is [owning team]'s call", do NOT take a position or author
code fixes.
## Executing queriesPriority:
1.**[Managed connection]** (if available): [query tool] / [schema tool]
2.**[CLI fallback]** (if installed): [default project, fallback project]
3.**Neither** — ask the user to authenticate, then stop
---
# Semantic Layer (REQUIRED first step)The governed semantic layer is the **mandatory default path** for every data
question — same numbers as [the BI tool], joins/grain/filters baked in. Raw SQL
via the reference docs below is the **fallback**, used only after the
semantic-layer path is shown not to cover the ask.
## Required workflow1.**Load** — [how to load the semantic layer in each runtime, with fallbacks]
2.**Discover** — search measures/dimensions by keyword; **always check
   segments** (the named canonical population filters — hand-rolled WHERE
   clauses for these are the dominant wrong-answer mode)
3.**Compile + run** — build the spec → compile to SQL → execute
4.**Fallback** — only if discovery finds no relevant metric or compile fails
   → raw SQL via `references/*.md` (PART 3 below)
> **Don't bail early.** Do NOT fall back to raw SQL on these grounds:> - "[custom date filtering / cohorts]" → [covered by time-dimension specs]> - "[needs a join]" → [the metric layer already encapsulates its joins]> - [3–4 more pre-rebutted excuses agents use to skip the semantic layer]### Date windows & timezone — decide before you query-**As-of date vs trailing-N days**: [convention for each]
-**"Last week/month"** → the last *complete* calendar week/month, not trailing-7/30
-**Timezone default**: [TZ]; [exception for certain reporting rollups]
-**Freshness lag**: [some] tables settle late — anchor on MAX(date), not "yesterday"
---
# PART 1: MUST KNOW (Read First for Every Request)## 🚀 Quick Start Workflow1.**Check for red flags first**: [restricted/PII requests, gated domains,
   high-stakes asks that need extra validation]
2.**Out of scope — escalate, don't guess**: [access requests, pipeline
   troubleshooting, stale dashboards, root-cause assertions, product/pricing
   recommendations] → redirect to [the owning team], don't answer
3.**Clarify the request**: time period, segment, the business decision it informs
4.**Check for existing dashboards**: [per-domain dashboard catalogs]
5.**Identify the data source**: [navigation map below; prefer governed/aggregated tables]
6.**Execute the analysis**: [required filters + adversarial review]
7.**Deliver insights**: show methodology, differentiate observations from interpretations
## 🏢 Business Context### Entity Disambiguation (MUST CLARIFY)-**"[Term A]" can mean**: [entity 1] or [entity 2] — always clarify which
-**"[Term B]" can mean**: [entity 1] → [entity 2] → [entity 3] (one-to-many chain)
-**"Users"**: [which identifier gives accurate counts, and which ones inflate them]
### Business Terminology- [Current product names vs deprecated aliases that still appear as frozen
  values in the data layer — write with the new names, filter with the old]
- [Key internal acronyms]
-**[Headline metric] calculations**: [monthly / default window / leading indicator]
-**Unfamiliar terms — search [internal docs], don't guess**### Data Integrity Requirements ⚠️-**NEVER**: make up data/columns; make speculative assertions beyond what data shows
-**ALWAYS**: use safe division; differentiate observations ("data shows X")
  from interpretations ("this suggests Y"); flag limitations
---
# PART 2: HOW TO DO (Follow During Execution)## 🔧 Technical Execution Guide- [Managed-connection tools and CLI invocation details]
-**PII protection**: for restricted data, return the SQL for the user to run
  themselves — do not return results
## 📊 Analysis Best Practices Guide1. 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 the [sql-reviewer] sub-agent
   for every query before the final answer; blocking findings must be fixed
   and re-reviewed; do not self-certify
7.**Report with provenance** — every answer ends with a footer:
   > **Source:** [semantic layer | governed table | raw exploration] ·
   > **Confidence:** [tier] · **Reviewed:** [reviewer ✓, round N] ·
   > **Freshness:** [max date in the data] · **Owner:** [owning team]
---
# PART 3: DATA REFERENCES & RESOURCES## 📚 Knowledge Base Navigation### [Domain A] → `references/[domain_a].md`
- **Use for**: [kinds of questions]
- **Key tables**: [...]
- **Dashboards**: `references/[domain_a]_dashboards.json`
### [Domain B] → `references/[domain_b].md`-**Use for**: [...]
[... one entry per business domain — a few dozen in total ...]
## ⚠️ Troubleshooting Guide### When Information Is Missing- [missing tables / access denied / outdated docs / unknown enum values → what to do]
### Field Naming Gotchas- Use `[field_x_v2]` NOT `[field_x]`- [Two similarly-named tables report the same metric at different grains — which to use]
- [Which of two plausible sources is canonical for the headline metric]
- [… a dozen more hard-won one-liners …]

常见问题

未找到项目。

相关帖子

探索更多产品新闻和构建 Claude 团队的最佳实践。

2026年8月11日

合规 API 覆盖扩展到 Claude Cowork 和 Claude Code

企业 AI

合规 API 覆盖扩展到 Claude Cowork 和 Claude Code

合规 API 覆盖扩展到 Claude Cowork 和 Claude Code

2026年6月5日

Claude Cowork 产品指南

企业 AI

Claude Cowork 产品指南

Claude Cowork 产品指南

2026年5月22日

Anthropic 的财务团队如何使用 Claude 塑造数字背后的叙事

企业 AI

Anthropic 的财务团队如何使用 Claude 塑造数字背后的叙事

Anthropic 的财务团队如何使用 Claude 塑造数字背后的叙事

2026年8月7日

Anthropic 的业务发展团队如何使用 Claude 大规模处理入站和出站

企业 AI

Anthropic 的业务发展团队如何使用 Claude 大规模处理入站和出站

Anthropic 的业务发展团队如何使用 Claude 大规模处理入站和出站

利用 Claude 转变您的组织运营方式

查看定价

查看定价

联系销售

联系销售

获取开发者新闻通讯

产品更新、操作指南、社区亮点等。每月发送到您的收件箱。

谢谢！您已订阅。

抱歉，您的提交出现问题，请稍后重试。