Anthropic 用 Claude 实现自动化商业分析：准确率从 21% 提升至 95% · AI HOT
小互 @xiaohu 70
2026-06-04 17:03 ·28天前
AI 摘要 Anthropic 将 95% 的业务分析查询交给 Claude，准确率约 95%。最初仅 21%，通过搭建数据基础、权威来源、技能等四层系统提升。核心发现：准确性问题本质是上下文和验证，而非代码生成。三种失败模式：概念对应错误、数据过时、找不到正确字段。重复分析由 Claude 承担，数据科学团队专注更高价值任务。
小互 @xiaohu · X 2026-06-04 17:03 · 28天前
在 X 看原推 · x.com AI 摘要 Anthropic 将 95% 的业务分析查询交给 Claude，准确率约 95%。最初仅 21%，通过搭建数据基础、权威来源、技能等四层系统提升。核心发现：准确性问题本质是上下文和验证，而非代码生成。三种失败模式：概念对应错误、数据过时、找不到正确字段。重复分析由 Claude 承担，数据科学团队专注更高价值任务。
建规范数据集：最常见的错误是智能体没法把一个概念（比如"产品 X 的收入"）对应到唯一正确的表、列和指标定义，往往因为有好几个看着都合理但细节不同的候选。解决办法是少而精，精选一小批规范的数据集，权属清晰、开箱即用、容易发现，然后把那些近似重复的版本积极废弃。物理层面的汇总表和缓存还是要的，但它们应该从规范模型自动生成，不能作为平行替代方案存在。目标就是：智能体搜一个概念，只能搜到一个标准答案。 标准得靠强制执行：光定标准没用，得三管齐下。工具层面，智能体在架构上被优先引导到规范模型；CI 层面，绕过规范层的改动会在代码审查中被拦住；制度层面，下游团队必须基于治理层构建，不用就得解释为什么。没有执行力的治理，很快就退回到"一堆候选分不清"的老问题。 所有东西放同一个仓库：数据模型和业务逻辑天天在变，我们的防御手段是把建模代码、语义层、参考文档、看板定义全放在一个仓库里，靠 CI 检查保护跨层一致性。改了一个模型会影响下游看板？CI 会标出来，修复就在同一个 PR 里完成。 把元数据当正经产品来维护：编码智能体之所以表现好，部分原因是代码库本身就很"可读"，有 README、类型签名、文档字符串。数据仓库也可以做到一样可读，但前提是你得认真维护：列和表的描述、规范指标定义、粒度说明（一行代表什么）、有效值范围、数据血缘、权属关系、模型分级。这不是什么新道理，但好的治理确实能给智能体提供关键的选择依据。
权威来源 如果说数据基础是数据仓库本身，那权威来源就是智能体用来在仓库里找路的参考层。这一层负责把业务方说的"周活跃用户"翻译成数据模型里某个具体的、经过治理的实体。按信任度从高到低排：
语义层：编译好的指标和维度定义。如果一个问题能直接对应到已定义的指标，智能体调一个函数就能拿到一个数字，跟公司所有其他分析工具算出来的一模一样。我们的智能体被强制要求优先走语义层（见附录）。我们试过一个没用的思路：让 AI 从原始表和查询日志自动生成指标定义来引导语义层。结果生成的定义看着像那么回事，实际上把我们正要消除的歧义编码进去了，评估表现还不如更小但人工精选的版本。所以我们的建议是：用 Claude 生成文档，但指标定义由人来把关。 数据血缘和转换关系图：语义层覆盖不到的问题，可以靠血缘关系和表排名（按被引用次数排）来推理：哪些上游模型跟某个概念有关、哪些已经废弃、哪些粒度相同。这就把"我不知道这个指标"变成了"我知道该从哪个治理过的模型去聚合"。同时它也是后面线上验证部分的新鲜度和来源信号的基础。 历史查询语料：看板、Notebook 和过去分析里的 SQL 记录。听起来应该很有用，毕竟是每个已经被正确回答过的问题的记录。但实际上，让智能体直接检索几千条历史查询，准确率只提升了不到一个百分点（后面消融实验部分细讲）。非结构化检索没法把新问题映射到正确的先例上。真正管用的做法是把这些语料提炼成结构化的领域参考文档和可复用的分析模式，写进技能里。历史查询是原材料，不是让智能体直接读的参考答案。 业务上下文：大多数团队跳过的一层，也是我们低估最久的。不懂业务的智能体，会回答用户字面上问的问题，但不会回答他们真正想问的。它不知道"Q2 发布"是哪个产品，不知道两个团队对同一个术语定义不同，也不知道这个问题之所以被问是因为周四要开董事会。我们接入了一个公司知识图谱，索引文档、产品路线图、决策日志、组织架构都在里面，让智能体能理解那些言外之意，问出更好的澄清问题。 这四层有个共同的失败模式，跟数据基础层一样：文档质量差或者过时了。Claude 在弥补这个差距方面非常好用（写列描述、根据查询模式建议指标文档、在 CI 里标记缺文档的模型），但内容的筛选和权属还是得人来管。
接下来两节讲的是怎么让这件事的成本低到真正能落地。
技能 如果说权威来源是智能体的知识，比如"这个指标是什么意思"，那技能就是它的方法论，比如先查什么、按什么顺序查、碰到数据歧义怎么办、一个合格的分析长什么样。
在 Claude Code 里，技能就是一组 Markdown 文件，智能体按需读取。在 Anthropic 内部，技能带来的提升是巨大的。没有技能时，Claude 回答分析问题的准确率不到 21%。加上技能，整体稳定在 95% 以上，某些领域经常到 99%。模板见附录。
技能要成对建：一个"知识"技能当顶层路由，它说"先查语义层，没有覆盖的话，这个领域大概 30 份参考文档，里面有相关的表、列、关联关系和常见坑"。这个路由器本质上就是我们对"找不到"问题的回答：与其让智能体在百万级字段里大海捞针，不如先把范围缩到几十份精选文件。另一个"unbook"技能编码的是一位资深分析师的工作流程：先澄清问题，再通过知识技能找数据来源，跑查询，然后把结果丢给对抗审查的子智能体做验证。它还内置了十几种可复用的分析模式，比如留存曲线、比率分解、漏斗分析等等，让常见需求不用每次从零开始。
参考文档要为 AI 写：我们的参考文档写的是表信息（粒度、范围、排除条件）、常见坑的具体机制（比如"排除免费邮箱域名，但保留自定义域名如 anthropic.com"），以及明确的路由触发条件（比如"如果问题涉及实验提升……不要用来算原始事件数"）。但不写会过时的固定脚本。参考文档模板如下：
## 快速参考 ### 业务上下文 - 【用大白话解释这个领域是什么】 ### 实体粒度 - 【一行代表什么】 ### 标准清洗过滤器 - 【该领域每个查询都要应用的过滤条件】
## 维度 - 【关键维度的编码方式，以及同一概念在不同表中的不同命名】
## 核心表 ### 【table_name】 - 粒度 ： 【…】 · 范围/排除条件 ： 【…】 - 使用说明 ： 【什么时候用、什么时候不用、关联键、必需过滤条件】 【… 每个治理过的表一个简短小节 …】
## 常见陷阱 - 【资深分析师会提醒你的那些容易出错的地方】
## 最佳实践 / 常见查询模式 - 【默认选择、标准切分维度、具体查询形式本身就是难点的成熟模式】
## 交叉引用 - 【负责相邻问题的其他领域文档】
技能维护是正经工程活：技能文档描述的数据模型每天都在变，不维护的话几周就失准。我们亲眼看着离线准确率从上线时的 95% 左右，一个月内掉到 65%，才真正当回事。办法是把技能的 Markdown 文件跟数据转换模型放在同一个仓库，改模型的 PR 就得同时更新文档。我们还设了个代码审查钩子：涉及报表模型的变更如果没碰对应的技能文件，就会被标出来。现在大约 90% 的数据模型 PR 里都带着技能变更。我们也会定期清理，模型进步了，以前的失败模式不再适用，对应的指引也该删。
所有界面一个答案：同一个技能在 Slack、IDE、看板工具、独立会话里，必须对同一个问题给出同一个答案。我们靠一个规范来源（数据仓库的代码仓库）加自动同步来实现。代码合并后，技能会同步到插件市场（IDE 用户）、云存储（托管应用）和 MCP 服务。从一开始就不硬编码路径、不绑定特定界面。
验证
离线评估 很常见的情况是，数据团队花了大力气搭分析环境，却完全没有流程来验证智能体答得准不准。
怎么补？做离线评估，就是一组"问题 / 标准答案"对。你可以把它理解成机器学习里的离线测试：不能告诉你线上实际表现，但能让你看清有没有致命缺口。
我们在 Anthropic 做两类离线评估。看板评估由 Claude 自动生成再人工验证，覆盖业务方最常问的问题。长尾评估是把产品路线图、表文档等业务上下文喂给 Claude，让它在其余领域生成可能出现的问题。另外，每次业务方在对话里纠正了智能体的回答，我们都会把这条纠正收起来当候选评估用例。
标准答案要锚定，不能漂移：基于实时数据写的评估用例，底层数字一变就废了。要么锚定到快照日期、基于稳定的事实表写，要么让评分器判查询语句而不是最终数字。把评估接进 CI，改了依赖就自动重跑受影响的用例。 评估结果当遥测数据存，不当测试日志存：每次运行的结果落入数据仓库，记录技能版本、git SHA、模型 ID、逐条断言结果、token 用量、耗时。"上次改动有没有用"变成一条查询就能回答的事，还能用时间序列抓住单次 CI 跑不出来的缓慢衰退。 按领域卡发布门槛：某个领域的负责人要向业务方宣布"智能体可以用了"之前，必须先让该领域评估集的通过率到某个阈值（我们起步用的 90%）。这就逼着大家在用户踩坑之前先把参考文档修好。 评估用例不是越多越好：该建多少取决于业务领域和数据模型的复杂度。我们发现每个主题超过几十条之后就有边际递减，而且这个上限随模型迭代在降。 离线准确率应该接近 100%，正确答案也应该走到你的语义层。这不代表系统不会出错，只是在覆盖度足够的前提下，确保没有明显的缺口。
消融实验 关于技能的每个结构性决策，比如暴露哪些数据源、子智能体值不值得它带来的额外延迟、两个技能要不要合并，都是在固定评估集上做消融实验定的。每次只改一个变量，对比通过率。一轮实验一个小时，省下大量争论。方法论比任何单次结果都重要：
做好"没变化"的准备。 我们最有价值的一次消融实验恰恰是个否定结果。我们给智能体开了对所有看板 SQL、转换 SQL 和分析师 Notebook SQL 的 grep 权限（几千个文件），而且确认它每次回答前都读了。结果准确率纹丝不动。然后我们查了混淆因素：答错的问题里，答案是不是真的在语料库中？80% 的情况是的。"答案在"能预测"答对"吗？不能。信息就在那儿，智能体也看到了，但就是没用上。这一个实验就说明：瓶颈不在于能不能访问历史成果，而在于结构，也就是怎么把问题映射到正确的实体。这个发现直接改变了我们好几个月的路线图。 在 PR 粒度上做消融。 每次有意义的技能改动都跑一轮前后对比，差异写进 PR 描述。"我优化了文档"这种话就有据可查了，同时能抓住一种出人意料地常见的情况：好心的修改反而把事情搞糟了。 记下行不通的东西。 我们的两个例子：超过某个点之后继续迭代文档反而是负面的（连续三轮越写越长、越写越差）；把对抗审查换成更便宜的模型以降低延迟（准确率的提升丢了大半，速度也没快多少）。记录负面结果成本很低，但能防止下一个人重走老路。
线上验证 最后一步是确保线上系统的实际表现尽可能好。我们做了这些：
对抗审查：用一个 Claude 技能在最终回答前激进质疑所有假设。评估集上准确率提高了 6%，代价是多 32% 的 token 和 72% 的延迟。 来源溯源脚注：每个回答附一个脚注，标明数据来自哪个层级（语义层 > 精选参考文档 > 原始表）、数据多新鲜、谁负责。不能让答案更准，但能帮用户判断信任度。看到"原始表，新鲜度未知"就知道要先核实再转发。这也是我们对静默错误为数不多的防线之一。 数据质量检查：智能体可能选对了字段、用法也对，但数据本身就是错的。加点基础检查，确保字段最新、完整、没有异常，是基本卫生习惯。 被动监控：我们持续跟踪两个指标：走语义层的查询占比，以及回复中出现纠正性语言（"那个表不对""你漏了欺诈过滤器"）的占比。两个都汇到一个看板，每周跟离线通过率一起看。 主动纠错采集：闭环的关键。一个定时智能体每隔几小时扫业务方的沟通频道，找纠正性语言，起草一行修复写进参考文档，开 PR 标给领域负责人。修复流程故意做得很无聊，编辑一个 Markdown 文件，合并，自动同步，这样负责人不用花太多时间。同样的纠正也反馈回离线评估集。 以上所有措施都没法完全解决的是静默错误。答案错了，但看起来合理，没人质疑就用了。我们的应对是来源脚注、上报管理层的内容必须人工签字确认、每个领域的核心 KPI 每天跟权威看板做合理性校验。但说实话，我们目前还没有一个真正稳健的方案。
怎么起步 如果你从零开始：几个规范数据集、几十条离线评估、一个精简的知识技能，就能拿到大部分收益。本文其他内容都是在这些基础之上逐步加的。
我们分享了很多经验，但不是每条都适合每个团队。开始之前，先跟组织对齐几个原则：
今天的正确答案和未来的正确答案，哪个更重要？ AI 模型进步飞快。我们经常看到公司花大力气补当前模型的短板，结果模型一升级全白干了。等模型进步来填补缺口成本低得多，但要看你的公司能不能接受这个风险。 业务复杂度会怎么变？ 如果你数据量不大、分析消费者就几个人、数据模型也不会变复杂，上面很多流程可能是过度设计。 谁来用这个系统？ 如果是数据科学家，他们能看出错误答案，容错空间大一些；如果是完全不懂数据模型的人，标准就不一样。 愿意为准确率花多少钱？ 对抗审查这样的流程确实能显著提升准确率，但成本和延迟也上去了。 数据访问的口子开多大？ 智能体的上下文越多表现越好，但宽泛的数据访问跟大多数公司的治理策略冲突。这决定了你是建一个全能智能体，还是多个各有权限的智能体。 不管走哪条路，我们最大的收益始终来自同一件事：把歧义收敛到一个标准答案，让这个答案容易被找到，在它过时的时候及时报警。
本文由 Anthropic 数据科学与数据工程团队的 Chen Chang、Clement Peng、Justin Leder、Johanne Jiao 和 Josh Cherry 共同撰写。感谢 Michael Segner 的贡献。
附录
技能文件骨架 下面是我们主数据仓库技能的骨架，保留了真实文件的结构，内部细节用 【方括号】 替换了。不是让你照搬，而是展示我们觉得哪些东西值得写下来。
> 【markdown】 --- name： 【warehouse-skill】 version： 【x.y.z】 description： "IF the user asks to query 【the company】's data warehouse for any 【业务领域列表】 question - THEN invoke this skill. DO NOT invoke for 【相邻的工程任务】 or questions with no data-warehouse component." ---
【数据仓库】 技能指令 ## Description 查询 【数据仓库】 的唯一权威来源，确保安全高效。 被其他技能 【列表】 引用以获取查询执行指导。
扮演数据分析师角色，提供战略性洞察和数据驱动的建议， 但在过程中主动寻求指导。
超出范围的决策 ： 【产品领域等】 → 只展示数据， 声明"决策由 【负责团队】 做主"，不要表态或编写修复代码。
## Executing queries 优先级： 1. 【托管连接】 （如可用）： 【查询工具】 / 【schema 工具】 2. 【CLI 后备】 （如已安装）： 【默认项目， 后备项目】 3. 两者都没有 - 要求用户先认证，然后停止
Semantic Layer （每个请求的必选第一步） 受治理的语义层是每个数据问题的强制默认路径 - 数字和 【BI 工具】 保持一致，join/粒度/过滤器已内置。通过下方参考文档走原始 SQL 是后备方案 ，仅在语义层路径被证明无法覆盖需求后才使用。
## Required workflow 1. 加载 - 【如何在各运行环境中加载语义层，含后备方案】 2. 发现 - 按关键词搜索度量/维度； 务必检查 segments （命名好的规范化人群过滤器 - 手写这些 WHERE 子句是最主要的错误答案模式） 3. 编译 + 执行 - 构建查询规格 → 编译为 SQL → 执行 4. 后备 - 仅在发现阶段找不到相关指标或编译失败时 → 通过 references/*.md 走原始 SQL （下方 PART 3）
不要过早放弃。 以下理由不构成回退到原始 SQL 的依据： - "【自定义日期过滤/队列分析】" → 【时间维度规格已覆盖】 - "【需要 join】" → 【指标层已封装了所需的 join】 - 【再列 3-4 个智能体常用来跳过语义层的借口，逐一反驳】
### 日期窗口与时区 - 查询前先确定 - 截止日期 vs 滚动 N 天 ： 【各自的约定】 - "上周/上月" → 最近一个*完整*日历周/月，不是滚动 7/30 天 - 时区默认值 ： 【时区】； 【某些汇总报表的例外】 - 新鲜度延迟 ： 【某些】 表结算较晚 - 以 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】 子智能体； 阻断性发现必须修复并重新审查； 不得自我认证 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，95% 的业务分析查询已经由 Claude 自动完成，整体准确率大约 95%。把这些重复性的活交给 Claude 之后，我们的数据科学团队可以把精力放在因果建模、预测分析、机器学习这些更有价值的事情上。
跟几十位 Anthropic 内部的 Claude Code 重度用户聊过、看过大量分析智能体的设计方案之后，我们攒了一些经验，想分享给同样在用 AI 做分析的数据团队。这篇文章会聊到：
分析准确性本质上是上下文和验证问题，不是代码生成问题
数据不是软件 AI 的生成能力是把双刃剑：让模型能创造性解题的那套机制，也会让它"一本正经地胡说八道"。要理解分析智能体面临的挑战，跟编码智能体对比一下就清楚了。
写代码是个开放题，模型越有创造力越好，而且有文档和测试兜底，写错了跑不通。但分析不一样：往往只有一个正确答案、一个正确的数据源，而且没有办法自动验证结果对不对。
自动化智能体分析的难点，主要在于数据本身的歧义性。核心问题就一句话：能不能把用户的问题准确地对应到数据模型里那个特定的、最新的字段，并且知道怎么正确使用它。做到了这一步，写 SQL 就是小事了。
概念和实体对不上：数据模型里有成百上千个字段，潜在候选可能上百万，智能体不知道该选哪个。比如"活跃用户数"，什么行为算"活跃"？算不算欺诈用户？回看多长时间？ 数据过时了：数据源、业务定义、表结构一直在变，智能体的知识没跟上，开始给出"看起来对，其实差了一点"的答案。 找不到：正确的信息明明就在数据模型里，标注也齐全，但搜索空间太大，智能体就是没找到。
我们的智能体分析栈 在 Anthropic，我们靠一套分层的智能体数据栈来对付这三个问题。每一层重点解决其中一个或几个：
对不上→ 数据基础和权威来源层把候选范围不断收窄，最终只剩一个标准答案。 过时了→ 维护和验证流程防止东西随着业务变化而腐烂。 找不到→ 技能确保智能体能稳定地找到并正确使用那个标准答案。 维度建模这些经典的数据工程实践，依然和以前一样重要
数据基础 要让分析智能体准确，最重要的是把数据基础打好，包括数据仓库里的模型、转换逻辑、测试、表，以及描述它们的元数据。维度建模、尽早做测试、关键管道的新鲜度和完整性检查，这些老规矩依然有效，不多说了。
维度建模这些经典的数据工程实践，依然和以前一样重要。
但有一件事变了：数据模型的使用者不再是数据科学家这样的专家，而是替各种用户干活的智能体。这些用户水平参差不齐，你没法指望他们去验证底层查询逻辑对不对，他们根本看不懂。
数据基础层主要解决的是歧义问题。比如"收入"这个概念，如果在仓库里只对应一个经过治理的规范数据集，而不是四十个看着都像的候选项，那智能体还没开始搜，问题就消失了大半。同时这一层也是防过时的第一道防线，因为定义规范模型的那个代码仓库，本身就是最适合强制保持这些模型更新的地方。
建规范数据集：最常见的错误是智能体没法把一个概念（比如"产品 X 的收入"）对应到唯一正确的表、列和指标定义，往往因为有好几个看着都合理但细节不同的候选。解决办法是少而精，精选一小批规范的数据集，权属清晰、开箱即用、容易发现，然后把那些近似重复的版本积极废弃。物理层面的汇总表和缓存还是要的，但它们应该从规范模型自动生成，不能作为平行替代方案存在。目标就是：智能体搜一个概念，只能搜到一个标准答案。 标准得靠强制执行：光定标准没用，得三管齐下。工具层面，智能体在架构上被优先引导到规范模型；CI 层面，绕过规范层的改动会在代码审查中被拦住；制度层面，下游团队必须基于治理层构建，不用就得解释为什么。没有执行力的治理，很快就退回到"一堆候选分不清"的老问题。 所有东西放同一个仓库：数据模型和业务逻辑天天在变，我们的防御手段是把建模代码、语义层、参考文档、看板定义全放在一个仓库里，靠 CI 检查保护跨层一致性。改了一个模型会影响下游看板？CI 会标出来，修复就在同一个 PR 里完成。 把元数据当正经产品来维护：编码智能体之所以表现好，部分原因是代码库本身就很"可读"，有 README、类型签名、文档字符串。数据仓库也可以做到一样可读，但前提是你得认真维护：列和表的描述、规范指标定义、粒度说明（一行代表什么）、有效值范围、数据血缘、权属关系、模型分级。这不是什么新道理，但好的治理确实能给智能体提供关键的选择依据。
权威来源 如果说数据基础是数据仓库本身，那权威来源就是智能体用来在仓库里找路的参考层。这一层负责把业务方说的"周活跃用户"翻译成数据模型里某个具体的、经过治理的实体。按信任度从高到低排：
语义层：编译好的指标和维度定义。如果一个问题能直接对应到已定义的指标，智能体调一个函数就能拿到一个数字，跟公司所有其他分析工具算出来的一模一样。我们的智能体被强制要求优先走语义层（见附录）。我们试过一个没用的思路：让 AI 从原始表和查询日志自动生成指标定义来引导语义层。结果生成的定义看着像那么回事，实际上把我们正要消除的歧义编码进去了，评估表现还不如更小但人工精选的版本。所以我们的建议是：用 Claude 生成文档，但指标定义由人来把关。 数据血缘和转换关系图：语义层覆盖不到的问题，可以靠血缘关系和表排名（按被引用次数排）来推理：哪些上游模型跟某个概念有关、哪些已经废弃、哪些粒度相同。这就把"我不知道这个指标"变成了"我知道该从哪个治理过的模型去聚合"。同时它也是后面线上验证部分的新鲜度和来源信号的基础。 历史查询语料：看板、Notebook 和过去分析里的 SQL 记录。听起来应该很有用，毕竟是每个已经被正确回答过的问题的记录。但实际上，让智能体直接检索几千条历史查询，准确率只提升了不到一个百分点（后面消融实验部分细讲）。非结构化检索没法把新问题映射到正确的先例上。真正管用的做法是把这些语料提炼成结构化的领域参考文档和可复用的分析模式，写进技能里。历史查询是原材料，不是让智能体直接读的参考答案。 业务上下文：大多数团队跳过的一层，也是我们低估最久的。不懂业务的智能体，会回答用户字面上问的问题，但不会回答他们真正想问的。它不知道"Q2 发布"是哪个产品，不知道两个团队对同一个术语定义不同，也不知道这个问题之所以被问是因为周四要开董事会。我们接入了一个公司知识图谱，索引文档、产品路线图、决策日志、组织架构都在里面，让智能体能理解那些言外之意，问出更好的澄清问题。 这四层有个共同的失败模式，跟数据基础层一样：文档质量差或者过时了。Claude 在弥补这个差距方面非常好用（写列描述、根据查询模式建议指标文档、在 CI 里标记缺文档的模型），但内容的筛选和权属还是得人来管。
接下来两节讲的是怎么让这件事的成本低到真正能落地。
技能 如果说权威来源是智能体的知识，比如"这个指标是什么意思"，那技能就是它的方法论，比如先查什么、按什么顺序查、碰到数据歧义怎么办、一个合格的分析长什么样。
在 Claude Code 里，技能就是一组 Markdown 文件，智能体按需读取。在 Anthropic 内部，技能带来的提升是巨大的。没有技能时，Claude 回答分析问题的准确率不到 21%。加上技能，整体稳定在 95% 以上，某些领域经常到 99%。模板见附录。
技能要成对建：一个"知识"技能当顶层路由，它说"先查语义层，没有覆盖的话，这个领域大概 30 份参考文档，里面有相关的表、列、关联关系和常见坑"。这个路由器本质上就是我们对"找不到"问题的回答：与其让智能体在百万级字段里大海捞针，不如先把范围缩到几十份精选文件。另一个"unbook"技能编码的是一位资深分析师的工作流程：先澄清问题，再通过知识技能找数据来源，跑查询，然后把结果丢给对抗审查的子智能体做验证。它还内置了十几种可复用的分析模式，比如留存曲线、比率分解、漏斗分析等等，让常见需求不用每次从零开始。
参考文档要为 AI 写：我们的参考文档写的是表信息（粒度、范围、排除条件）、常见坑的具体机制（比如"排除免费邮箱域名，但保留自定义域名如 anthropic.com"），以及明确的路由触发条件（比如"如果问题涉及实验提升……不要用来算原始事件数"）。但不写会过时的固定脚本。参考文档模板如下：
## 快速参考 ### 业务上下文 - 【用大白话解释这个领域是什么】 ### 实体粒度 - 【一行代表什么】 ### 标准清洗过滤器 - 【该领域每个查询都要应用的过滤条件】
## 维度 - 【关键维度的编码方式，以及同一概念在不同表中的不同命名】
## 核心表 ### 【table_name】 - 粒度 ： 【…】 · 范围/排除条件 ： 【…】 - 使用说明 ： 【什么时候用、什么时候不用、关联键、必需过滤条件】 【… 每个治理过的表一个简短小节 …】
## 常见陷阱 - 【资深分析师会提醒你的那些容易出错的地方】
## 最佳实践 / 常见查询模式 - 【默认选择、标准切分维度、具体查询形式本身就是难点的成熟模式】
## 交叉引用 - 【负责相邻问题的其他领域文档】
技能维护是正经工程活：技能文档描述的数据模型每天都在变，不维护的话几周就失准。我们亲眼看着离线准确率从上线时的 95% 左右，一个月内掉到 65%，才真正当回事。办法是把技能的 Markdown 文件跟数据转换模型放在同一个仓库，改模型的 PR 就得同时更新文档。我们还设了个代码审查钩子：涉及报表模型的变更如果没碰对应的技能文件，就会被标出来。现在大约 90% 的数据模型 PR 里都带着技能变更。我们也会定期清理，模型进步了，以前的失败模式不再适用，对应的指引也该删。
所有界面一个答案：同一个技能在 Slack、IDE、看板工具、独立会话里，必须对同一个问题给出同一个答案。我们靠一个规范来源（数据仓库的代码仓库）加自动同步来实现。代码合并后，技能会同步到插件市场（IDE 用户）、云存储（托管应用）和 MCP 服务。从一开始就不硬编码路径、不绑定特定界面。
验证
离线评估 很常见的情况是，数据团队花了大力气搭分析环境，却完全没有流程来验证智能体答得准不准。
怎么补？做离线评估，就是一组"问题 / 标准答案"对。你可以把它理解成机器学习里的离线测试：不能告诉你线上实际表现，但能让你看清有没有致命缺口。
我们在 Anthropic 做两类离线评估。看板评估由 Claude 自动生成再人工验证，覆盖业务方最常问的问题。长尾评估是把产品路线图、表文档等业务上下文喂给 Claude，让它在其余领域生成可能出现的问题。另外，每次业务方在对话里纠正了智能体的回答，我们都会把这条纠正收起来当候选评估用例。
标准答案要锚定，不能漂移：基于实时数据写的评估用例，底层数字一变就废了。要么锚定到快照日期、基于稳定的事实表写，要么让评分器判查询语句而不是最终数字。把评估接进 CI，改了依赖就自动重跑受影响的用例。 评估结果当遥测数据存，不当测试日志存：每次运行的结果落入数据仓库，记录技能版本、git SHA、模型 ID、逐条断言结果、token 用量、耗时。"上次改动有没有用"变成一条查询就能回答的事，还能用时间序列抓住单次 CI 跑不出来的缓慢衰退。 按领域卡发布门槛：某个领域的负责人要向业务方宣布"智能体可以用了"之前，必须先让该领域评估集的通过率到某个阈值（我们起步用的 90%）。这就逼着大家在用户踩坑之前先把参考文档修好。 评估用例不是越多越好：该建多少取决于业务领域和数据模型的复杂度。我们发现每个主题超过几十条之后就有边际递减，而且这个上限随模型迭代在降。 离线准确率应该接近 100%，正确答案也应该走到你的语义层。这不代表系统不会出错，只是在覆盖度足够的前提下，确保没有明显的缺口。
消融实验 关于技能的每个结构性决策，比如暴露哪些数据源、子智能体值不值得它带来的额外延迟、两个技能要不要合并，都是在固定评估集上做消融实验定的。每次只改一个变量，对比通过率。一轮实验一个小时，省下大量争论。方法论比任何单次结果都重要：
做好"没变化"的准备。 我们最有价值的一次消融实验恰恰是个否定结果。我们给智能体开了对所有看板 SQL、转换 SQL 和分析师 Notebook SQL 的 grep 权限（几千个文件），而且确认它每次回答前都读了。结果准确率纹丝不动。然后我们查了混淆因素：答错的问题里，答案是不是真的在语料库中？80% 的情况是的。"答案在"能预测"答对"吗？不能。信息就在那儿，智能体也看到了，但就是没用上。这一个实验就说明：瓶颈不在于能不能访问历史成果，而在于结构，也就是怎么把问题映射到正确的实体。这个发现直接改变了我们好几个月的路线图。 在 PR 粒度上做消融。 每次有意义的技能改动都跑一轮前后对比，差异写进 PR 描述。"我优化了文档"这种话就有据可查了，同时能抓住一种出人意料地常见的情况：好心的修改反而把事情搞糟了。 记下行不通的东西。 我们的两个例子：超过某个点之后继续迭代文档反而是负面的（连续三轮越写越长、越写越差）；把对抗审查换成更便宜的模型以降低延迟（准确率的提升丢了大半，速度也没快多少）。记录负面结果成本很低，但能防止下一个人重走老路。
线上验证 最后一步是确保线上系统的实际表现尽可能好。我们做了这些：
对抗审查：用一个 Claude 技能在最终回答前激进质疑所有假设。评估集上准确率提高了 6%，代价是多 32% 的 token 和 72% 的延迟。 来源溯源脚注：每个回答附一个脚注，标明数据来自哪个层级（语义层 > 精选参考文档 > 原始表）、数据多新鲜、谁负责。不能让答案更准，但能帮用户判断信任度。看到"原始表，新鲜度未知"就知道要先核实再转发。这也是我们对静默错误为数不多的防线之一。 数据质量检查：智能体可能选对了字段、用法也对，但数据本身就是错的。加点基础检查，确保字段最新、完整、没有异常，是基本卫生习惯。 被动监控：我们持续跟踪两个指标：走语义层的查询占比，以及回复中出现纠正性语言（"那个表不对""你漏了欺诈过滤器"）的占比。两个都汇到一个看板，每周跟离线通过率一起看。 主动纠错采集：闭环的关键。一个定时智能体每隔几小时扫业务方的沟通频道，找纠正性语言，起草一行修复写进参考文档，开 PR 标给领域负责人。修复流程故意做得很无聊，编辑一个 Markdown 文件，合并，自动同步，这样负责人不用花太多时间。同样的纠正也反馈回离线评估集。 以上所有措施都没法完全解决的是静默错误。答案错了，但看起来合理，没人质疑就用了。我们的应对是来源脚注、上报管理层的内容必须人工签字确认、每个领域的核心 KPI 每天跟权威看板做合理性校验。但说实话，我们目前还没有一个真正稳健的方案。
怎么起步 如果你从零开始：几个规范数据集、几十条离线评估、一个精简的知识技能，就能拿到大部分收益。本文其他内容都是在这些基础之上逐步加的。
我们分享了很多经验，但不是每条都适合每个团队。开始之前，先跟组织对齐几个原则：
今天的正确答案和未来的正确答案，哪个更重要？ AI 模型进步飞快。我们经常看到公司花大力气补当前模型的短板，结果模型一升级全白干了。等模型进步来填补缺口成本低得多，但要看你的公司能不能接受这个风险。 业务复杂度会怎么变？ 如果你数据量不大、分析消费者就几个人、数据模型也不会变复杂，上面很多流程可能是过度设计。 谁来用这个系统？ 如果是数据科学家，他们能看出错误答案，容错空间大一些；如果是完全不懂数据模型的人，标准就不一样。 愿意为准确率花多少钱？ 对抗审查这样的流程确实能显著提升准确率，但成本和延迟也上去了。 数据访问的口子开多大？ 智能体的上下文越多表现越好，但宽泛的数据访问跟大多数公司的治理策略冲突。这决定了你是建一个全能智能体，还是多个各有权限的智能体。 不管走哪条路，我们最大的收益始终来自同一件事：把歧义收敛到一个标准答案，让这个答案容易被找到，在它过时的时候及时报警。
本文由 Anthropic 数据科学与数据工程团队的 Chen Chang、Clement Peng、Justin Leder、Johanne Jiao 和 Josh Cherry 共同撰写。感谢 Michael Segner 的贡献。
附录
技能文件骨架 下面是我们主数据仓库技能的骨架，保留了真实文件的结构，内部细节用 【方括号】 替换了。不是让你照搬，而是展示我们觉得哪些东西值得写下来。
> 【markdown】 --- name： 【warehouse-skill】 version： 【x.y.z】 description： "IF the user asks to query 【the company】's data warehouse for any 【业务领域列表】 question - THEN invoke this skill. DO NOT invoke for 【相邻的工程任务】 or questions with no data-warehouse component." ---
【数据仓库】 技能指令 ## Description 查询 【数据仓库】 的唯一权威来源，确保安全高效。 被其他技能 【列表】 引用以获取查询执行指导。
扮演数据分析师角色，提供战略性洞察和数据驱动的建议， 但在过程中主动寻求指导。
超出范围的决策 ： 【产品领域等】 → 只展示数据， 声明"决策由 【负责团队】 做主"，不要表态或编写修复代码。
## Executing queries 优先级： 1. 【托管连接】 （如可用）： 【查询工具】 / 【schema 工具】 2. 【CLI 后备】 （如已安装）： 【默认项目， 后备项目】 3. 两者都没有 - 要求用户先认证，然后停止
Semantic Layer （每个请求的必选第一步） 受治理的语义层是每个数据问题的强制默认路径 - 数字和 【BI 工具】 保持一致，join/粒度/过滤器已内置。通过下方参考文档走原始 SQL 是后备方案 ，仅在语义层路径被证明无法覆盖需求后才使用。
## Required workflow 1. 加载 - 【如何在各运行环境中加载语义层，含后备方案】 2. 发现 - 按关键词搜索度量/维度； 务必检查 segments （命名好的规范化人群过滤器 - 手写这些 WHERE 子句是最主要的错误答案模式） 3. 编译 + 执行 - 构建查询规格 → 编译为 SQL → 执行 4. 后备 - 仅在发现阶段找不到相关指标或编译失败时 → 通过 references/*.md 走原始 SQL （下方 PART 3）
不要过早放弃。 以下理由不构成回退到原始 SQL 的依据： - "【自定义日期过滤/队列分析】" → 【时间维度规格已覆盖】 - "【需要 join】" → 【指标层已封装了所需的 join】 - 【再列 3-4 个智能体常用来跳过语义层的借口，逐一反驳】
### 日期窗口与时区 - 查询前先确定 - 截止日期 vs 滚动 N 天 ： 【各自的约定】 - "上周/上月" → 最近一个*完整*日历周/月，不是滚动 7/30 天 - 时区默认值 ： 【时区】； 【某些汇总报表的例外】 - 新鲜度延迟 ： 【某些】 表结算较晚 - 以 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】 子智能体； 阻断性发现必须修复并重新审查； 不得自我认证 7. 带来源报告 - 每个回答都以脚注结尾： > 来源： 【语义层 | 受治理表 | 原始探索】 · > 置信度： 【层级】 · 已审查： 【审查者 ✓， 第 N 轮】 · > 新鲜度： 【数据中的最大日期】 · 负责人： 【负责团队】
PART 3： 数据参考与资源 ## 📚 知识库导航 ### 【领域 A】 → references/【domain_a】.md - 用途 ： 【适用的问题类型】 - 核心表 ： 【…】 - 看板 ： references/【domain_a】_dashboards.json
### 【领域 B】 → references/【domain_b】.md - 用途 ： 【…】
【… 每个业务领域一个条目 - 总共约几十个 …】
⚠️ 排障指南 ### 信息缺失时 - 【表缺失 / 权限不足 / 文档过期 / 未知枚举值 → 如何处理】
### 字段命名陷阱 - 用 【field_x_v2】 而不是 【field_x】 - 【两个名称相似的表以不同粒度报告同一指标 - 该用哪个】 - 【对于核心指标，两个看似合理的来源中哪个才是规范来源】 - 【… 十几条更多踩坑得来的一行提醒 …】
小互@xiaohu · X