“最近转化率为什么下降？”一个演示型 Agent 很快就能找表、写 SQL、画折线并列出几个原因。真正交付时，问题才暴露出来：分母是什么，数据是否到齐，渠道结构是否变化，所谓“原因”是计算得到的贡献还是语言模型补出的故事？
Data Analytics Skills 最值得研究的地方，不是某句提示词，而是它把分析工作的责任、交接和完成标准写成了可复用协议。
本文基于公开整理仓库中 15 份 Skill 文档的 2026-10-04 版本进行设计解读。Skill 文本描述期望的工作方式，不等于完整运行架构、线上权限或效果实测。
15 个 Skills 形成五组责任
| 责任域 | Skills | 它们要解决的问题 |
|---|---|---|
| 路由与上下文 | Index、Gather Business Context、Create Data Context | 该不该分析；需要什么临时背景；哪些知识值得长期保存 |
| 度量与判断 | Design KPIs、Metric Diagnostics、Product & Business Analysis、KPI Reporting、Market Sizing | 衡量什么；变化如何构成；证据支持什么决定 |
| 可信度 | Analyze Data Quality、Validate Data | 输入是否适用；计算、方法和结论是否成立 |
| 计算与表达 | Jupyter Notebooks、Visualize Data | 计算是否可复算；图形是否诚实表达问题 |
| 交付 | Build Dashboard、Build Report、Publish Artifact to Sites | 成果如何服务监控、阅读和发布 |
这不是一条每次都跑完的十五步流水线，也不代表需要十五个独立 Agent。Index 应选择最小够用链，每个 Skill 只承担自己的完成责任。
路由先确定主任务，再决定交付形式
“为什么转化下降”是指标诊断；“把转化下降做成一页报告”仍要先完成诊断，再组织表达。用户提到报告，不会让原因调查自动完成。相反，查询一个定义清楚的指标，也不应自动扩张成全面业务分析。
这种分工能避免一个常见失败：Agent 交付了许多图表，最初的问题却没有答案。主 Skill 决定什么算完成，报告、看板和 Notebook 决定结果如何被使用。
临时业务背景和长期数据语义分开
Gather Business Context 服务当前任务：为什么现在要看、谁要做决定、近期发生了什么、哪些材料控制定义。Create Data Context 把可复用知识保存为语义资产：指标、表粒度、关联规则、过滤、查询模式和注意事项。
“本次活动面向新注册用户”是当前背景；“付费转化率按注册后七天内首次付费计算并排除测试账号”可能成为长期契约。把所有历史聊天放进长上下文，不会自然产生稳定语义。
数据质量和结论质量是两道门
Analyze Data Quality 检查数据是否适合用途：粒度、唯一性、缺失、时效、Join 和覆盖。Validate Data 进一步检查分析：问题是否回答正确、比较是否公平、加权是否合理、图表是否误导、证据是否支持主张。
一张订单表可以主键唯一、按时更新，却在关联多值标签后把收入放大。即使数字正确，“版本上线后转化下降”也不能直接写成“版本导致下降”。前者是数据和程序问题，后者是推断边界。
一个渠道结构案例
假设上期 A 渠道 800 人、转化率 10%，B 渠道 200 人、转化率 2%；本期两者人数交换，A 转化率升到 11%，B 升到 3%。整体转化率却从 8.4% 降到 4.6%。
按本期结构、上期组内转化率计算：
20% × 10% + 80% × 2% = 3.6%
结构变化贡献：3.6% - 8.4% = -4.8 个百分点
组内表现贡献：4.6% - 3.6% = +1.0 个百分点
合计：-3.8 个百分点
这个描述性分解说明渠道结构足以解释整体下降，同时两个渠道内部都改善。它不证明为什么流量结构变化，也不能直接支持削减 B 渠道预算。Metric Diagnostics 负责把变化算明白，Product & Business Analysis 再结合成本、长期价值和约束形成决策建议。
指标、诊断、汇报和估算的交接
Design KPIs 先选主指标、驱动指标与护栏，避免团队通过牺牲长期价值“优化”单一数字。Metric Diagnostics 复现变化、分解贡献并管理解释状态。KPI Reporting 把已定义指标用于经营读数；遇到新异常，应转入诊断而不是在汇报中即兴编故事。
Market Sizing 则要求事实、代理输入、假设和推算分开，展示计算链与敏感性。缺乏可靠输入时，指出哪项证据最值得补充，比多报几位小数更有价值。
图表、Notebook、看板和报告有不同完成标准
- Notebook保存输入、参数、代码、执行结果和环境。写完未运行与运行成功是不同状态。
- 图表先匹配分析问题，再考虑视觉形式；轴、单位、分母和缺失值会改变读者判断。
- 看板服务反复监控与探索，默认视图、筛选器和各组件要共享时间与指标口径。
- 报告服务一次明确阅读，让结论、证据、限制和下一步形成连续路径。
- 发布交付经过验证的产物或有界快照；有交互页面不等于实时连接数据源。
同一份结果可以进入多个制品，但应共享声明、数据和版本，避免数字在复制粘贴中分叉。
如何把 Skill 思想用于自己的 Agent
第一，为每个 Skill 写入口、输入、输出、禁止事项和完成条件，而不是只写人格。第二，把查询、参数、口径、假设和验证作为可引用产物保存。第三，让验证真正改变工作流：分母错误要回到计算，证据不足要收窄结论。第四，用陷阱样本测试流程：时间窗不齐、Join 放大、辛普森悖论、看板与查询冲突、局部修改导致内容丢失、代码未执行却生成结论。
判断一套 Data Analytics Skills 是否有效，可以问三个问题：别人能否找到证据，能否复算关键数字，能否理解为什么这些证据足以支持下一步。如果仍然做不到，更多图表和更长报告并没有让分析真正完成。
版本基线与 Skill 原文索引可见公开整理仓库。