Anthropic 如何用 Claude 实现 95% 自助数据分析自动化
不是让 Agent 更聪明地写 SQL，而是通过数据治理、结构化参考文档和严谨的评估体系，让 Agent 根本不需要"猜"。
Part 1: 核心解读
准确率是上下文问题，不是代码生成问题。Skill（精心编排的 Markdown）是最关键的跃迁。
编码 Agent 有编译器、测试、类型系统做验证。但分析 Agent 的输出——"上月活跃用户数是 1.2M"——没有编译器帮你检查。你不会知道 Agent 用了错误的"活跃"定义或漏了某个过滤。
There's often only a single correct answer using a single correct source in which there's no deterministic way of proving the correctness.
三种核心失败模式
概念-实体歧义
数据模型里几百个字段都能勉强匹配用户提问，但只有一个是"正确"的。比如"活跃用户"——什么行为算活跃？含不含欺诈用户？回看窗口多长？
数据陈旧
数据源、业务定义、Schema 不断变化。资产和 Agent 知识变得过时，返回"微妙地错误"的答案——看起来合理，但差了一个过滤条件。
检索失败
正确的信息就在数据模型中且有标注，但搜索空间太大，Agent 就是找不到。不是信息不存在，是信息不可发现。
三层 Agent 分析栈
数据基础层
规范数据集（单一来源的真实数据）+ 同仓库放置（代码/文档/CI 一体）+ 元数据一等公民。目标是：当 Agent 搜索"收入"，只找到一个受治理的答案。
真实信息源
语义层（编译好的指标定义）> 血缘/转换图 > 查询语料库（蒸馏后有效，原始无用）> 业务上下文（知识图谱）。信任度从高到低。
Skill 层
knowledge Skill（薄路由器，按需加载领域细节）+ unbook Skill（资深分析师流程 + 可复用模式）。21% → 95% 的关键跃迁。
Skill 的影响：数字说话
| 状态 | 准确率 | 说明 |
|---|---|---|
| 没有 Skill | 21% | Agent 直接查数据仓库，大量歧义和检索失败 |
| 有 Skill | 95%+ | 综合准确率，某些领域达 99% |
| Skill 不维护（1个月） | ~65% | 准确率严重漂移，Skill 文档与数据模型脱节 |
| + 对抗性审查 | +6% | 代价：32% 更多 token，72% 更高延迟 |
| + 历史 SQL 检索 | <1% | 最有价值的否定实验：信息在那里，Agent 看到了，但没用 |
消融实验的黄金教训
我们给了 Agent 直接 grep 访问数千个历史 SQL 的权限。准确率变化不到 1%。80% 的情况下答案确实在语料库中。Agent 看到了，但仍然没用上。瓶颈不是信息的可访问性（access），而是信息的结构化（structure）。
That single experiment told us our bottleneck wasn't access to prior work, it was structure (i.e., mapping a question to the right entity). That insight redirected months of roadmap.
什么有效
- 精心编排的 Markdown Skill — 一份"地图"，告诉你怎么走
- 语义层优先 — 编译好的指标定义，一次调用=一个正确数字
- 同仓库放置 — 代码和文档在同一个 PR 中更新
- 离线评估 + CI 集成 — 离线准确率应 ~100%
- 主动纠正收集 — 定时 Agent 扫描修正、自动开 PR
什么无效
- 原始 SQL 语料库直接检索 — 准确率提升 <1%
- LLM 自动生成指标定义 — 编码了正试图消除的歧义，净负面
- 无限叠加文档精炼 — 连续 3 次迭代净负面，文档更长而非更好
- 用便宜模型做对抗审查 — 失去大部分准确率提升，速度没快多少
- Skill 写一次就不管 — 一个月后准确率从 95% 暴跌到 65%
参考文档模板（可复用）
# [Domain] Tables
## Quick Reference
### Business Context — [这个领域在业务上意味着什么]
### Entity Grain — [一行代表什么]
### Standard Hygiene Filter — [该领域每条查询都要加的过滤]
## Dimensions
- [关键维度如何编码，同一概念在不同表中的命名差异]
## Key Tables
### [table_name]
- **Grain**: [...] · **Scope/exclusions**: [...]
- **Usage**: [何时用、何时不该用、join keys、必加 filters]
## Gotchas
- [资深分析师会警告你的"错误答案陷阱"]
## Cross-References
- [相邻领域文档，负责相关问题]未解的难题：静默失败
答案是错的，但看起来合理，被使用而不被质疑。我们没有健壮的解决方案。
The failure mode none of this fully catches is the silent one. The answer is wrong, but looks plausible and is used without objection.
缓解措施：来源页脚（Source/Confidence/Freshness/Owner）、面向领导层的人工签字、顶部 KPI 每日与受信仪表盘的健全性检查。但根本性挑战依然存在。
Part 2: 苏格拉底对话
通过对话揭示为什么"精心编排的 Markdown > RAG 检索"，以及 Skill 维护的工程化现实。
Anthropic 说用 Claude 做数据分析准确率 95%，这也太高了吧？我们试过让 AI 查数据库，经常给出看起来对但实际错的数字。
你觉得"看起来对但实际错"通常是什么原因？
大概是 AI 搞错了字段？比如把"注册用户"和"活跃用户"搞混了。
对。Anthropic 把这个叫"概念-实体歧义"——数据模型里有几百个字段都能勉强匹配用户提问，但只有一个是正确的。核心发现是：这不是 AI 推理能力的问题，是你有没有给它正确导航信息的问题。
那 RAG 呢？直接让 AI 搜索历史 SQL 不就行了？
这是他们做过的最有价值的实验：给了 AI 直接访问数千条历史 SQL 的权限——准确率提升不到 1%。80% 的情况下答案确实在那些 SQL 里，AI 也看到了，但就是没用上。
为什么？信息就在那里啊。
因为检索 ≠ 理解 ≠ 应用。一堆散落的 SQL 脚本就像一堆积木——零件都在，但没有说明书告诉你哪块积木用在哪个场景。精心编排的 Skill 文档就是那份说明书。
所以他们的做法是先搞治理（让每个概念只有一个正确答案），再用 Skill 把路径写清楚？
完全正确。三层架构：数据基础确保只有一个正确答案，信息源告诉 Agent 怎么找到它，Skill 告诉 Agent 找到后怎么用。缺任何一层，准确率都会掉。而且 Skill 不是写一次就完了——他们把 Skill 和代码放同一个仓库，90% 的数据模型 PR 都包含 Skill 变更。不维护的话，一个月就从 95% 暴跌到 65%。
Part 3: 个性化洞察
基于你的技术栈和工作场景，提炼可执行的行动建议。
1. Skill 设计模式可直接复用
Anthropic 的 knowledge/unbook 配对模式（薄路由 + 按需加载领域细节）和你现有的全局 Skill 架构高度一致。你的 wiki 知识库（qmd）本质上在做语义层的角色。
2. "否定结果"方法论——做自己的消融实验
Anthropic 的"历史 SQL 无用"实验值千金。下次有人推销"给 AI 接入所有历史数据就能解决问题"，你有 Anthropic 的数据作为反驳。
3. Skill 腐烂检测——你的 wiki 也有这个问题
你已经有了 /lint 和 /refresh skill，但可能需要更激进的自动化。Anthropic 的教训：90% 的 PR 必须包含文档变更，否则一个月就废了。
4. 数据治理 > AI 能力——做 AI 产品的核心洞察
这篇文章最大的 meta-lesson：不是 AI 不够聪明，是你的数据不够干净。做 AI 产品的核心竞争力不是"用了什么模型"，而是"积累了多少结构化的领域知识"。
5. 来源页脚——应对"静默失败"的实用策略
Anthropic 的 Source/Confidence/Freshness/Owner 页脚是值得借鉴的实践。在你的分析输出中标注信息来源和可信度。