15 个数据分析 Skills，谁来决定该调用哪一个

Wed, 07 Oct 2026 00:00:00 +0000

一个 Data Agent 同时会做指标设计、异动诊断、质量检查、Notebook、图表、看板和报告，听起来很强。但能力越多，越容易出现一种隐蔽失败：每个工具都调用了，真正的问题却没有被负责。

Data Analytics Skills 的 Index 值得看，不是因为它列出了 15 个 Skill，而是因为它承担了四件更接近控制面的工作：判断任务是否属于数据分析、选择谁负主责、处理来源冲突，以及定义什么叫完成。

第一道门：这真的是数据分析任务吗

“做一份报告”“研究一下市场”“验证这个观点”都不自动等于数据分析。判断标准应该是：结论是否依赖结构化记录、数值指标或可计算证据；用户是否需要据此做产品、运营或资源决策。

这道资格门很重要。普通写作被误路由到分析链，会制造不必要的查询和伪精确；真正的量化问题被当作写作任务，又会跳过数据验证。

复杂任务可以调用多个 Skill，但最好只有一个对最终问题负责。

请求	主 Skill	支持 Skill	完成标志
“周活为什么跌了？”	`metric-diagnostics`	业务背景、报告	原因链有证据，报告已检查
“这张表能用于月报吗？”	`analyze-data-quality`	数据验证	风险、缺口和使用条件明确
“建立持续经营看板”	`build-dashboard`	指标设计、可视化	口径、交互和刷新均可验证

主 Skill 决定问题如何收敛；支持 Skill 负责补背景、验证、表达或发布。若每个 Skill 都只是“帮一点忙”，就没人对遗漏负责。

路由器还需要区分三件事：运行环境提供了什么能力、用户有权使用什么能力、当前任务允许执行到哪一步。看到数据库连接器，不能推断可以查询所有表；能够生成网站，也不代表这次任务允许发布。

因此，能力路由与交付路由应分开：前者决定用什么方法解决问题，后者决定成果能否写入文件、站点或外部系统。

数仓、BI、指标文档、语义层、会议纪要和旧报告可能同时出现一个指标，但权威性、新鲜度和粒度不同。路由前至少要回答：哪个来源控制定义？哪个来源控制当前数值？冲突是否会改变结论？

如果无法裁决，正确动作是保留冲突并指出需要谁确认，而不是挑一个更顺手的数字。

分析结束至少要经过四项检查：主 Skill 确实执行；关键结论能够追到来源；方法、数字和图表经过验证；约定的制品真实存在、可打开并适合接收者使用。

这正是 Index 最实用的设计：入口有资格门，中间有责任路由，出口有完成门。数据 Agent 的可靠性，不只取决于模型会不会算，也取决于系统能否拒绝错误任务、选择最小责任链，并在证据不足时不假装完成。

不要从“有哪些工具”开始列菜单。先为高频请求定义主责任、必要上下文、允许动作、验证条件和失败去向。工具可以替换，责任契约不应该随提示词漂移。