本页目录9
- 技能文件要当作「持续刷新的服务内容」，每次对话重新读取，刷新频率要跟得上数据模型的变化频率
- 除了教表结构的「知识技能」，还要补充预测、队列留存、漏斗分析、制图规范、分析写作等「分析技能」
- 把内部知识索引（文档、讨论、事件记录）接入代理，才能回答「为什么」而不只是「是什么」
- 服务账户模式下，代理是受管仓库的共享只读副本，需要用五层权限设计（受管数据范围、列级 PII 分类、连接路径文档化、频道成员即授权、逐条查询打标）来控制暴露面
- 遥测要从第一天就上线，分别追踪「采纳率」（走受管层的查询占比）和「正确性」（👎反馈与更正率）
- 部署顺序建议：先做权限设计，再选传输机制并验证新鲜度，随后上遥测，最后接知识索引和分析技能
本文是对 Anthropic 官方博文的中文要点摘要，完整内容以原文为准：https://claude.com/blog/self-service-data-analytics-in-slack-how-anthropic-deploys-claude-tag-for-ad-hoc-questions
背景：从「Claude Code 里能做到」到「全员都能用」
Anthropic 此前的一篇文章介绍过内部数据分析体系如何做到约 95% 的精度，靠的是三件事：受管的语义层、编码分析规范的技能文件、以及一套性能评估套件。这篇文章讨论的是下一步——如何把这套已经在 Claude Code 里跑通的能力，搬到 Slack 里的 Claude Tag 上，让不写 SQL 的同事也能直接提问，并且答案仍然由分析师维护的受管定义支撑。
作者强调，「提高精度」和「向非分析师开放」是两件不同的事：一旦把入口开放给所有人，可访问性本身会带来新的复杂度——尤其是权限和信息新鲜度问题。
技能文件当作实时服务，而不是一次性交付物
数据模型可能一天内多次变化：列改名、指标口径修正、表被弃用。如果 Claude 读到的是旧版技能文件，它会「自信地给出错误答案」，而且提问者往往没有背景知识去判断答案是否可疑。
Anthropic 的做法是让 Claude Tag 运行时直接挂载数据仓库里的 skills/ 目录，每次对话都重新读取技能文件，跳过传统的版本发布流程。核心结论是：技能文件的刷新频率，应该和数据模型的变化频率一样快。
技能不只是「知道查什么」，还要「会分析」
最初只做了「知识技能」——教 Claude 表结构和语义层的组织方式。但实际提问往往是开放式的，比如「是什么导致了这次下降」「月底大概会落在哪」。为此补充了一批分析技能：
- 预测：趋势拟合、季节性假设、判断数据是否充分
- 队列与留存分析：标准定义、模板、需要人工复核的问题清单
- 漏斗分析：规范化的阶段定义
- 制图规范：图表类型选择、配色、表格 vs 图表的取舍
- 分析文写作：结论先行的结构、按置信度分级的措辞
接入内部知识索引，回答「为什么」
数据仓库能回答「是什么」，但原因通常散落在 Slack 线程、事件记录、发布说明、文档里。把这些内部知识索引接入之后，Claude 能给出类似这样的回答：「周二注册量下降 12%：当天上午 9-11 点支付服务发生过事件，下降集中在受影响地区。」
建议做法是：如果公司已有知识图谱或内部搜索，优先接入它（信息杠杆最高），并允许 Claude Tag 读取关键 Slack 频道以提取上下文。
权限设计：代理是受管仓库的只读副本
Claude Tag 用的是服务账户去查询仓库，而不是提问者本人的账户——这意味着任何 @ 它的人，都能拿到该账户权限范围内的数据。Anthropic 用了五层控制来约束暴露面：
- 限定受管数据范围：服务账户只能读语义层输出表和精选数据集，读不到原始事件流、暂存模式或个人沙箱；超范围的问题，代理会明确拒绝。
- 列级 PII 分类：数据目录维护列级敏感标签，Claude 扫描新列并标记疑似 PII 供人工审核，标签沿血缘传播到派生表；服务账户对敏感列没有可见性。
- 在技能文件里写清连接路径：CLI、直接 API、MCP 服务器，各自的认证方式都要文档化，让代理能解释自己的能力边界。
- 频道成员身份即授权：把 Claude Tag 拉进某个频道，等于给了它该频道成员级别的读权限，由数据团队负责添加和维护清单。
- 逐条查询打标：记录界面、对话、请求用户等信息，不在查询时做强制拦截，但用于成本归因和审计追溯。
这套设计背后的定位很明确：数据分析代理是受管仓库的共享只读副本。
观测与监测
每个问题都记录结构化事件：用到了哪个版本的技能文件、用户的 👍/👎 反馈或更正、接触到的表上是否有数据质量告警。以此追踪两个核心指标：
- 采纳率：走受管层的查询占临时 SQL 的比例（按界面、按业务域拆分），下降通常意味着技能文件过时或出现了未覆盖的新问题类型。
- 正确性：👎 反馈和更正率，作为两次离线评估之间的在线代理指标。
部署顺序建议
文章给出的推荐顺序是：先做权限设计，再确定技能文件的传输机制（挂载仓库或基于 MCP）并验证端到端的新鲜度，随后从第一个问题起就上遥测，数据路径稳定后再接知识索引，最后才加分析特定的技能。
使用场景（官方以虚构对话演示）
注：以下前后两段对话场景，原文均标注为「Fictional recreation of a Claude Tag conversation for illustrative purposes. Incident details, names, and tools are not real.」——即为说明用途重构的虚构情节，事件细节、人名与工具均非真实。
- 协作式排障（虚构演示）：某仪表板加载变慢，用户在共享频道提问，Claude 定位到缓存问题、通知相关负责人；后续发现同一个缓存 bug 影响了数十个仪表板，数据团队成员在同一线程里复核 Claude 起草的修复并合并 PR，不到一小时全部恢复。这段演示要说明的是：公开线程本身就是一份可审计的历史记录。
- 重复性任务自动化：比如周会前的主动摘要、实验期间的多次读出（能捕捉设置中途的变化）、管道/仪表板异常时的主动调查与通知、以及数据问题频道的分诊。
- 主动协助：在部分授权频道里，Claude 会主动介入。这一条有真实数据支撑——过去一个月某数据频道中 75% 以上的提问由 Claude 回答，且通常无需显式 @ 它，响应在几分钟内。文章另配了一段虚构演示：团队成员问某仪表板是否覆盖了新的使用类别，Claude 在 90 秒内给出定义确认、指出缺失并起草修复 PR，数据科学家审核后合并并刷新了仪表板。
小结
这篇文章的核心是权限与新鲜度这两条隐藏的工程线：能把 Claude Code 里验证过的分析能力搬到 Slack，关键不在于接口本身，而在于让技能文件像数据模型一样「实时刷新」，以及用分层权限把代理牢牢限制在「受管仓库的只读副本」这个角色上。