自助分析困境：你的企业是否也困在宽表膨胀和仪表板陷阱里？

今天又看到一个扎心的现实：Anthropic 自家的数据团队，已经把 95% 的业务分析查询丢给 Claude 自动跑了，准确率同样逼近 95%。

不是 PPT 概念，是实打实跑在生产环境的落地。更关键的是，他们把方法、架构、模板全开源了--普通团队几天到几周内就能复制。

但让我感触更深的，是他们先捅破了一层窗户纸：传统自助分析，为什么总是做着做着就烂掉？

宽表膨胀 + 仪表板陷阱：两个逃不掉的死循环

问题一：宽表越堆越多，语义越来越乱

• 业务催得急？快速拼个宽表、做个视图顶上
• 三个月后十几个"活跃用户"定义并存，没人敢删
• 视图爆炸，血缘理不清，"utterance analytics" 这句话айн变成笑话

问题二：仪表盘成了信息茧房

• 业务方能自助的，永远是那几张固定看板
• 真正的"为什么下跌""如果怎样"--还是得排队找数据团队
• 所谓的"自助"，只是把工单从邮件挪到了 Slack

更隐蔽的危险：直接让大模型对接数据仓库，会产生"虚假的精确感"。SQL 写得像模像样，但字段含义、业务规则、最新口径，它一概不知。

Anthropic 总结了 AI 搞砸分析的三大死法：

解药不是"让模型更聪明"，而是分层治理

Anthropic 的代理式分析栈（Agentic Analytics Stack），本质是给 AI 建了个有章可循的操作系统：

第一层：数据基础--老派功夫不能丢

• 维度建模打底，别偷懒
• 强制少数 canonical datasets 作为单一真相源
• 元数据当产品运营：描述、血缘、owner，一个不能少

第二层：真相源分级--让 AI 知道"该信 bubblelia"

按信任度排优先级：

1. 语义层（Semantic Layer） ← 首选，强制优先
2. 血缘图 + 转换逻辑
3. 结构化查询语料（从优秀案例里提炼）
4. 业务上下文（知识图谱、组织架构...）

第三层：Skills--这才是杀手锏

Skills 是什么？把资深分析师的 brain dump 变成结构化 Markdown。 查询顺序、消歧流程、完整分析模板...全部编码。

效果惊人：没有 Skills 时准确率 ≤21%，加上去直接飙到 95%，部分领域 99%。

可直接抄作业的核心模板

我把 Anthropic 博客附录里的骨架模板搬来了，各位按需调整：

模板一：领域参考文档（Domain Reference）

# [业务域]Tables


## Quick Reference
### 业务上下文 - 这个域解决什么问题
- 核心实体：[用户/订单/商品]
- 关键口径：
  - "活跃用户" = [精确定义]
  - "GMV" = [精确定义，含排除项]


### 常用表速查



表名
粒度
核心用途
注意点


fact_orders
订单级别
-metrics
含已取消，需过滤




## 详细字段说明
### [表名]
- `user_id`: 业务系统的用户唯一标识，**非匿名ID**
- `created_at`: 用户点击"提交订单"的UTC时间，**非支付时间**

模板二：分析执行技能（Analysis Execution Skill）

# 分析执行协议


## 收到问题的第一步：澄清
- [ ] 确认时间范围（自然日 vs 财年 vs 活动周期）
- [ ] 确认实体定义（用语义层，不要自己猜）
- [ ] 确认输出形式（数值/趋势/分组对比）


## 查询构建顺序
1. 从语义层开始，**禁止直接 raw table**
2. 需要补充字段时，查血缘图确认来源
3. 复杂逻辑先写 CTE，禁止嵌套超过_ANALOGUE层


## 验证清单
- [ ] 结果量级是否符合预期？（防掉零/多倍）
- [ ] 时间趋势是否有断点？（防日期边界bug）
- [ ] 与已知报表差异 >5% 必须溯源

说点扎心的

很多企业还在争论"要不要上 provisional AI"，Anthropic 已经证明：AI 分析师的上限，取决于你给它的治理水平Aubrey上限。

宽表泛滥的地方，AI 只会加速灾难；语义层清晰、Skills 完备的团队，才能把 95% 人力释放出来，去做真正的探索性分析和战略判断。

你现在处于哪个阶段？

• 第一阶段：还在打宽表补丁，BI 沦为截图工具
• 来定第二阶段：建了语义层，但业务方用不明白
• 下半场第三阶段：AI 处理标准化查询，人做高价值产件

评论区聊聊你的困境，或者你司的"宽表暴政"有多严重 🙃

参考：Anthropic "Agentic Analytics" 官方博客