Agent Skills on DataAgentX

把 15 个 Skills 变成可验收的 Agent

Sat, 17 Oct 2026 00:00:00 +0000

装好 15 个 Skills，就等于有了一个可靠的 Data Agent 吗？

还差最关键的一步：把“会做什么”变成“怎样证明已经做好”。

这一篇不是新的官方 Skill，而是基于前 9 期原文整理的产品化方法。文中提到的任务协议、验收链和陷阱清单都是编辑整理的框架，不是原文定义的统一规范。

别把 Skill 数量当成系统成熟度

工作流需要按任务选择：补背景、定指标、诊断变化、检查质量、组织计算、表达或发布。

不是每次都串行跑一遍，也不是 15 个文档就代表 15 个独立 Agent。原文的口径一直很明确：主 Skill 只有一个，支持 Skill 按需加入，由主 Skill 决定什么算完成。

真正重要的是交接：前一步交给后一步什么证据？来源缺失时停在哪里？完成条件由谁核验？

这三个问题，正好对应下文的协议、工作链和验收链。

给每个任务写一份小协议

建议至少写清六项：

要素	要回答的问题
输入	这个问题需要哪些必要信息才算清楚
必需来源	哪个系统或文档控制这个答案
允许的方法	可以做什么、不可以做什么
交付产物	输出是什么形态、给谁看
验收条件	什么证据能证明任务完成
失败分支	来源缺失、口径冲突、证据不足时怎么办

以“解释留存变化”为例：

输入需要窗口、人群和产品范围；缺任何一个都应该先问。
必需来源不可用时暂停，而不是拿相邻口径代替。
输出不能只有“下降了 3%”，还要有定义、证据、备选解释和限制。
验收要求关键数字可复算，且比较基线明确。

六项写全之后，一个任务的“完成”就不再依赖模型的自我判断。

同时设计工作链和验收链

分析负责形成判断，验证负责检查判断有没有超出证据。

两条链并行推进，而不是串联：在工作链里，Metric Diagnostics 形成解释；在验收链里，Validate Data 检查这个解释的方法、数字和措辞。

高风险结论应当复算数字、核对口径、检查比较基线与表达边界，而不是让模型再润色一遍。润色只会让措辞更自信，不会让证据更充分。

可复用的语义层值得保存，但当前分析的临时背景不必全部写入。维护动作和任务分析要保持边界，否则语义层会被一次性上下文污染，反而降低可靠性。

用六类陷阱检验真实表现

这是最实用的一部分：与其问 Agent “你会不会”，不如设计具体的失败场景。

发布的是快照，不是实时系统

Fri, 16 Oct 2026 00:00:00 +0000

把分析结果发布成一个网址，团队就有了实时数据系统吗？

没有。Publish Artifact to Sites 的原文第一件事就把这个边界说清楚：发布的是快照，不会自动添加实时数据源连接。

这条边界决定了后续所有设计：访问权限怎么设、版本怎么管、交接时该说什么。

不是把一段草稿丢上网

发布之前，报告或看板流程应当已经产出完整的规范化结构与受控数据快照，并通过验证。

这个 Skill 负责接住合格产物，组织打包、版本保存、部署和核验。它不负责分析，也不负责判断数字对不对。

因此，发布成功不能替代分析验证。一个错误数字，不会因为有了分享链接就更可信；反过来，一次成功的部署也不能证明数据是最新的。

同一份逻辑产物，复用同一个站点

原文建议：一个逻辑报告或看板对应一个 Site；后续更新发布新版本，而不是每次重新建一个零散网址。

这个约定把两个问题分开了：

“报告是谁”：稳定的身份，对应固定的地址和访问策略。
“当前是哪一版”：每次发布产生一个版本，对应一个数据截止时间。

如果不这样分，团队的聊天记录里会散落着十几个链接，没人说得清哪个是最新、哪个还能打开。

更新成功之后仍要核对部署状态。原文的要求是轮询到终态，而不是把“开始发布”当成“已经可访问”。

有链接，不代表访问范围正确

原文要求读取当前访问策略，并严格验证是否只有创建者有权限。

这里有一组容易混淆的权限：

权限	控制什么
读者访问	谁能打开页面看内容
演示编辑	谁能在页面上修改文字与布局

读者权限和编辑权限是两件事。把页面分享给更多读者，不应该顺带给出编辑能力；反过来，给创建者编辑能力，也不应该扩大读者范围。

原文还规定：启用编辑时，指定创建者可以修改文字和布局，或发起刷新、导出交接；这些展示层面的覆盖保留在 Sites，不会反向同步到桌面端。这一点需要在使用前说清楚，否则团队会误以为编辑结果会回写到源文件。

自动发布有条件，不是普遍承诺

原文区分运行模式：

在明确识别的工作模式下，且完整的 Sites 生命周期工具可调用时，持久产物按自动路线发布。
桌面端非工作模式，则要求明确请求或接受分享建议。

原文也给出了失败处理：如果完整生命周期不可用，或在工作模式下重试一次后仍失败，应自动切换到所属工作流的自包含 HTML 模式，简要说明失败阶段，并且不能声称站点已经发布。如果用户明确只要 Sites，就如实报告阻塞，而不是擅自换交付面。

这是该仓库版本的路由规则，不代表任何具体环境已经具备相应权限，也不表示所有内容都可以自动公开。

最终交接要说明三件事

原文要求在交付时明确：

页面在哪里：可访问的地址。
数据截至什么时候：快照对应的时间点。
它是快照而非实时连接：后续数据变化不会自动反映。

第三点最常被省略，也最容易造成误用。业务方拿到链接后，会默认它是“当前数据”；如果实际是三周前的快照，基于它做的决定就会出错。

失败时还应说明失败阶段，并按允许的路线回退。

一个常见的误解链

这条链在实践中反复出现：

“数据在仓库里，所以页面是实时的。”
“页面能打开，所以数据是对的。”
“链接发出去了，所以任务完成了。”

每一步都不成立。页面是快照，正确性来自前置验证，任务完成取决于接收者能否正确使用。

原文的设计恰好逐条对应：快照要有截止时间，验证要在发布之前，交接要说清边界。

设计自己的发布流程时

三个可以立刻用的检查：

发布前，产物是否已经通过验证，并带着受控的数据快照？
站点是否复用了同一地址，而不是每次新建？
交接信息里，是否同时写清了位置、截止时间和“非实时”？

发布能力解决的是“怎样共享一个已验证版本”，而不是一键变成实时 BI。更新、权限和证据边界，仍然需要明确的产品设计。

参考：OpenAI Data Analytics Skills 公开参考仓库

看板与报告：共用可信底座，但完成不同的工作

Thu, 15 Oct 2026 00:00:00 +0000

看板越做越像长文，报告越做越像指标大屏，往往不是设计问题，而是没有先分清：读者到底要持续看状态，还是理解一次判断？

Data Analytics Skills 用两个 Skill 处理这件事：Build Dashboard 和 Build Report。它们共享一套可信底座，但服务的目的、结构和验收标准都不同。

看板：让人持续知道发生了什么

Build Dashboard 的第一步是明确看板简报：谁用、监控什么、多久刷新、需要哪些过滤和访问权限、交付面在哪。

原文要求先判断看板属于哪一类，因为这决定了布局和验收标准：

状态监控：持续看有没有异常。
周期性经营复盘：按节奏对比目标与计划。
分析性探索：支持临时的多角度下钻。

这个分类很实用。很多“看板很乱”的问题，本质是把三种目的塞进了同一个页面：监控区被探索控件淹没，复盘所需的对比基线又被省略。

指标模型要有分层，但不要凑数

原文要求按测量对象选择平衡的指标模型，而不是套固定清单。

通常需要考虑的指标族包括：主结果、驱动、护栏、明细与诊断。原文特别提醒，没有要求固定放四张指标卡——数量由决定需要什么来确定，不要为了排版凑数。

另一条要求是默认视图要直接回答主要问题，而不是让读者先点一圈筛选器。过滤器和参数是为追问服务的，不是进入看板的前置门槛。

报告：让人理解为什么这样判断

Build Report 的起点是报告要完成的工作：用户问题、要支持的决定或行动、主要受众、范围、时间框架、比较基线、成功标准。

原文要求恰好选择一个受众：

产品与业务相关方：产品、业务、管理层、战略、诊断、KPI 读数和一般相关方报告。
技术受众：用户明确要求技术或方法优先的报告，或者报告的主要价值在方法论。

受众的选择不是措辞风格问题，而是结构契约问题。同一份证据，写给管理层要答案先行，写给技术读者要方法先行。

报告的结构不能只有摘要

原文在动手之前要求先写出“报告骨架”：

问题
对决定有用的答案
指标、队列、分母、时间窗口与比较基线
按细分或驱动组织的发现，附支撑证据
比较性或因果邻近结论所需的敏感性或验证检查
会改变解读的注意事项
建议的下一步、监控点或未决问题

然后设了一道“深度闸门”：只有标题、执行摘要和一张图表或表格的报告，除非用户明确要求简报，否则应当先扩充证据路径。

它同时规定：一段总结配几张图，不自动等于完整报告。图旁要解释读法、发现和含义；比较性发现要交代人群、分母、时间与基线；因果表述附近必须放限制说明。

共用可信底座，不代表共用版式

两者都需要可靠来源、统一指标口径、足够的数据检查与可追溯记录。

差别在于对账的对象不同：

维度	看板	报告
对账对象	卡片、图表、明细之间能互相解释	每条主张能找到对应证据
时间处理	数据新鲜度、刷新节奏	比较窗口、基线、截止时间
读者动作	发现异常后去追问	读完形成一个判断
主要失败	数字对不上、刷新滞后、越权可见	结论超出证据、限制缺失

原文对数据的要求也很直接：来源路径必须在渲染之前找到；核心看板数据不可用时应当停下，不能拿样例数据冒充真实业务看板，除非用户明确要的是演示原型。

完成标准不同，但都要打开检查

看板的完成标准：默认视图可用、过滤器行为正确、指标对账通过、数据新鲜度达标、权限正确、性能可接受。

报告的完成标准：阅读顺序清楚、证据解释到位、限制与可行动结论完整、每条主张可追溯。

两者还有一条共同要求：必须打开最终产物检查。聊天里说“已经完成”，不是文件或页面真实可用的证明。

这条规则针对的是一种典型的 Agent 失败：工具调用返回成功，模型据此宣布完成，而实际渲染出来的页面是空白或错位的。

算得能复现，图才有说服力

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

同一张图，换个人重跑就变了；同一组数据，换个坐标轴又像另一个故事。Data Agent 的可信度，常常就在这些细节里掉下来。

Data Analytics Skills 把这段工作分成两个 Skill：Jupyter Notebooks 让计算能复现，Visualize Data 让表达不误导。前者负责“这数怎么来”，后者负责“这图能说明什么”。

Notebook 不是代码草稿堆

原文要求先锁定 Notebook 的模式和范围：它是分析报告、实验日志、诊断记录、质量检查、市场估算、模型探索，还是配套产物。读者是谁、支持什么决定、预期交接什么，都要先明确。

分析型 Notebook 的默认结构是：

## tl;dr
## Context & Methods
## Data
## Results
## Takeaways

关键约束是：tl;dr 和 takeaways 要在看过执行输出之后再写。摘要里要出现具体的观察值、可见的模式、行数或图表，而不是事先的假设。当假设影响正确性时，还要在 Context & Methods 下加一节 Key Assumptions。

这个顺序和很多人的习惯相反。常见做法是先写结论，再跑数验证；结果是结论和实际输出之间悄悄产生了偏差，而读者看不出偏差在哪里。

分离步骤，记录来源

原文要求把环境准备、导入、参数、数据加载、数据准备、计算、可视化和解读分开。如果同时使用 SQL 和 Python，复杂 SQL 应保留在 SQL 单元或独立查询文件中，而不是塞进 Python 长字符串。

代码单元要短、要单一职责：一个单元做一件事，前面配一句说明目的、假设和预期结果的 Markdown。多个表格或图表应拆到不同单元，而不是从一个单元里倾倒出所有输出。

对于支撑分析的每个已执行结果，原文要求记录来源：查询链接、请求 ID、源路径、看板链接、提取名称或其他来源产物。重查询要有过滤和边界，不要让 Notebook 变成对实时源的广泛扫描。

跑完，才谈得上复现

完成条件不是文件能打开，而是从头到尾成功执行。原文给出的命令是：

python -m jupyter nbconvert --execute --to notebook --inplace path/to/notebook.ipynb

如果受数据权限、依赖、内核或凭证限制无法执行，应明确说明，并给出在本地验证所需的确切命令、缺失依赖、凭证、数据访问或环境步骤。不能把旧缓存当成这次运行的证明。

数据质量与分析验证：两道门守住不同的风险

Tue, 13 Oct 2026 00:00:00 +0000

一张表没有空值、没有重复，分析就能放心发吗？

未必。数据全对，也可能算错；算得对，也可能比较错了，或者把相关性写成了因果。这三类失败发生在不同的环节，需要用不同的检查去拦。

Data Analytics Skills 把它们分成两个 Skill：Analyze Data Quality 检查数据，Validate Data 检查分析。两道门分别守住不同的风险，缺任何一道都会漏。

先问数据适不适合这次用途

Analyze Data Quality 的起点不是数据本身，而是用途和粒度：一行是用户、订单、订单明细，还是事件？

这个问题决定了后面所有检查是否有意义。订单号重复，不一定是脏数据，也可能是合法的明细行。如果粒度判断错了，去重反而会删掉有效记录，把一个正确的数据源变成错误的分析输入。

原文要求先确认：数据集代表什么、预期粒度、主键或候选键、重要日期列、时区假设、领域规则、允许取值和业务阈值。缺失的上下文应当谨慎推断并标注为假设，而不是默默补齐。

质量检查要按数据形态选

确认粒度之后，再选择高价值检查。原文给出的默认覆盖面是完整性、唯一性、有效性、一致性、完整性约束、时效性、体量与形态。

它也按数据形态给出不同的重点：

数据形态	典型检查
事件数据	重复事件 ID、未来时间戳、会话或用户覆盖缺口、发布后事件结构突变
维度表	非唯一业务键、孤儿代理键、状态变化缺少时间戳、参考值异常流失
事实表	混合粒度、不可能的量值（负收入）、Join 膨胀、迟到或部分加载的分区
特征与评分表	结果字段泄漏、特征稀疏度突增、模型变更后的分布漂移、标签漂移
实验数据	重复分流、分组不均衡、有曝光无分流、分流时间戳之前的事件

一条重要的方法论：比较比例，而不只是计数。1,000 条空值在一个亿级表里和在十万级表里，意义完全不同。同时按时间、来源、国家、平台、模型版本等维度分组，才能区分真实问题和预期波动。

质量报告要解释影响

“发现空值”只是检查结果，不是质量报告。

更有用的写法是：哪些日期、来源和人群受影响；会不会改变分母；会不会造成关联丢行；会不会让看板滞后。原文要求把每项发现与下游风险绑定：破坏可信分析、造成有偏决策、打断 Join、让看板过期、让实验失效、让模型特征不可靠，或者让细分结论失真。

每项发现应带证据、风险、严重度、置信度和最小修复建议，并保留 SQL 或 Notebook。原文对自动化的态度是克制的：稳定规则适合做成自动化测试，波动较大的指标不宜套死阈值。

一个容易被忽略的中间层

粒度之外，还有一类问题最容易被漏掉：时间维度上的完整性。

当用户说“从某天开始”“突然”“最近才出现”时，原文要求优先做时间诊断：首次出现日期、最后出现日期、每日或每周的空值率趋势、重复率趋势、行数趋势、类别份额变化、分布漂移，以及发布、迁移、事故、模型变更和回填前后的变化点。

这类检查之所以重要，是因为很多“业务变化”其实是采集或管道变化。把它们当成业务问题去解释，会浪费大量时间，还会得出错误结论。

再问分析能否支持决定

Validate Data 的对象是分析、图表、报告和建议——不是数据表。

它先提取关键主张：主要问题、受众、决定、头条数字、数据来源、时间窗口、人群、过滤、比较基线和已声明的限制。然后核对方法：人群、资格规则、排除项、抽样、指标定义、公式、单位、分母、时区、队列、比较期和基线，是否与这个决定匹配。

原文特别点出几类隐藏问题：隐藏的排除项、不一致的定义、部分周期比较，以及缺少实验或可靠因果证据的因果措辞。

独立复算，而不是再读一遍

Validate Data 要求独立重算影响最大的数字，检查粒度、小计、分母、非零分母、比率基数、环比基数、加权平均、单位、币种、时区处理，以及互斥类别是否加总到总数。

对 SQL，还要检查 Join 类型、Group By 粒度、过滤、去重计数，以及 Join 前后的行数变化。

教学示例：A 渠道 9 次转化、10 次访问，转化率 90%；B 渠道 50 次转化、100 次访问，转化率 50%。两组率直接平均是 70%，但整体应为 59 ÷ 110 ≈ 53.6%。记录没错，平均方式错了。

市场有多大：别只报一个数，要交付一套能追问的估算

Mon, 12 Oct 2026 00:00:00 +0000

“这个市场有多大？”Data Agent 最容易给出的，是一个看起来很精确的数字。最难交付的，是一套能追问、能调整的估算。

Market Sizing 这个 Skill 的重点不是帮答案补几个零，而是让规模估算有边界、有来源、有假设，并且在证据不足时明确说出不足在哪里。

先说清楚在估什么

原文要求在估算之前锁定五件事：

要素	需要明确的内容
对象	产品类别、工作流、问题、用例，还是某类活动
范围	地区、细分、时间跨度、市场成熟度
成员	谁或什么算在市场内：人群、需求单位、交易类型
单位	支出、收入、数量、创造的价值
问题类型	TAM／SAM／SOM、进入机会、扩张空间、支出池、收入池

这一步看起来像流程形式，实际上是估算质量的分水岭。估“收入”和估“交易额”会得到完全不同的数量级；把“意向客户”算进市场，和只算“付费客户”，结论可能差一个量级。

TAM、SAM、SOM 也不必每次都凑齐三层。原文的口径是按问题需要选择，而不是按模板填满。

选择最简单、站得住的方法

原文给出三类方法，各自适用条件不同：

自上而下：存在可靠的市场总量数据时，从总量拆解。
自下而上：市场可以由可观察的单元和假设搭建时，从单元累加。
价值法：估算应从创造的价值出发，而不是从已发布的市场总额出发。

混合方法适合交叉核验，但原文并没有要求每次必须双算。只有当交叉核验能实质提升信心时才值得做。

如果两条路径差得很远，正确动作是先查边界、单位、覆盖和假设，而不是把两个结果平均成一个“更稳”的数。平均会掩盖真正的分歧来源。

把三类输入分开

这是整个 Skill 里最实用的一条约束：把已查证的事实、用于替代直接数据的代理输入、以及主观判断，分别标注来源与可信度。

输入类型	例子	处理方式
已查证事实	公开财报中的市场规模、官方统计	标注来源与日期
代理输入	用相邻品类的客单价替代本品类	说明为什么可替代、局限在哪
主观假设	采用率、渗透速度、转化比例	标注为假设，给出区间

常见的失真发生在边界处：行业均值悄悄变成自己的成交价，意向客户被当作付费客户，试点转化率被外推到全量。

原文还设了一条硬规则：如果缺少的是必需的权威来源，应暂停这条估算路径，请用户补充或认可替代来源，不能拿更弱的数据冒充同等证据。如果缺的只是可选的补充信息，可以继续，但要在影响结论时标注缺口。

模型要能改，别只留最终值

原文要求模型可审计、可修改，至少包含：

市场定义与计量单位
假设与来源上下文
计算链与派生值
基准情形、实质区间与敏感性逻辑
验证优先级

每个主要输入都要能看到来源路径：结构化数据、上下文渠道、公开来源、用户输入，还是代理假设。派生值应当能追溯到公式或代码，而不是硬编码的结果。

教学示例：1 万家企业 × 40% 可服务比例 × 2,000 元年费 = 800 万元的年收入池。这是满足假设时的可服务规模，不是已经实现的收入。

指标跌了，先复现变化，再谈原因与行动

Sat, 10 Oct 2026 00:00:00 +0000

“转化率跌了，肯定是新版本不好用。”

这句话跳过两个问题：指标真的可比吗？变化真的来自产品体验吗？在具体排查中，需要先排除口径、覆盖或分母变化，再判断业务本身是否发生了变化。

Data Analytics Skills 把这段工作分成两个 Skill：Metric Diagnostics 解释变化，Product & Business Analysis 把解释转成有证据的业务选择。前者对“发生了什么”负责，后者对“该做什么”负责。

第一步不是找原因，是复现变化

原文把诊断拆成一个明确顺序：先定义问题，再验证来源，再建立模式，最后才分解驱动。

“建立模式”这一步最容易被跳过。它要求先量化变化的规模、时间与范围：跌了多少、从哪天开始、影响哪些人群和粒度。在规模、时间和范围被验证或明确标记为不确定之前，不应该开始搜索原因。

原因是最容易“找”出来的东西。只要愿意，任何一次下跌都能配上一段听起来合理的故事。先复现变化，是用数据把可解释的空间收窄。

口径与来源要一起验证

Metric Diagnostics 要求确认指标定义、粒度、聚合逻辑、过滤、Join、排除规则、时效与血缘，并检查可信表面之间是否存在分歧。

它也提醒不要被熟悉的表名迷惑：当前上下文、命名语义层和常见表名都只是来源候选，不是来源选择。对于宽泛的指标问题，应该在可用的表、看板、指标文档和语义层中做一次实际发现，并同时检查一个业务表面和一个底层来源，然后说明为什么选定的来源控制这个答案。

这一步在实际工作里经常被压缩成“用我们平时用的那张表”。如果那张表的粒度或过滤和这次的决策不匹配，后面所有精致的分解都会建立在错误的基础上。

率、加总与分组：三种诊断路径

原文按问题类型给出不同的诊断方式：

指标变化：对比窗口与基线，排序列出分组贡献，检查同行与历史背景，区分结构变化与组内变化。
尖峰、回退或事故：锁定起点、峰值、恢复、分布形态（而不只看均值）、受影响切片，以及是否发生流量或失败行为变化。
集中度与最大贡献者：先定义“最大”，再排序、比较份额与变化，找出主要变动者、进入者与退出者。
对账与差异分析：对齐定义、过滤、粒度、分子、分母与排除项，量化各组成部分，并说明残差。

对率类指标，要先看是分子变了还是分母变了。对加总指标，要计算贡献份额。当结构变化与组内表现同时存在时，两者的区分往往决定解释的走向。

一个容易被误读的例子

教学设定：高转化渠道的转化率始终 20%，低转化渠道始终 5%。前期两个渠道访问量各占 50%，整体转化率 12.5%；本期访问占比变成 20% 和 80%，整体转化率降到 8%。

复算：

前期：0.5 × 0.2 + 0.5 × 0.05 = 0.125
本期：0.2 × 0.2 + 0.8 × 0.05 = 0.08
差值：−0.045，即 −4.5 个百分点

各渠道自身的转化率一点没变，整体却跌了 4.5 个百分点。这是典型的结构效应（mix shift）。

这个例子说明了诊断的边界：算术分解能说明“变化如何组成”，但不能证明渠道占比为什么变了。要回答后者，需要继续核实流量来源和业务动作。把结构效应直接写成“渠道质量下降”，就是把解释力用超了。

测量问题也是解释，不是清理工作

原文特别强调：日志变更、近期数据未齐、重复记录、分母漂移，都可能是变化的真实原因，而不只是需要“清理掉”的噪音。

从定义成功到持续经营：KPI 系统的完整闭环

Fri, 09 Oct 2026 00:00:00 +0000

很多团队有一长串 KPI，却说不清三件事：什么叫成功、当前是否在轨、下一步该做什么。指标数量增加，判断力反而下降。

Data Analytics Skills 把这件事拆成两个 Skill：Design KPIs 负责定义成功，KPI Reporting 负责把实际表现、目标、驱动和行动组织成经营读数。两者合起来，才是一条从度量契约到持续经营的闭环。

本文基于公开 Skill 文档做结构化解读。文中的 AI 数据分析 KPI 是教学示例，不是 OpenAI 官方指标；Skill 文本描述的是预期方法与边界，不代表任何真实业务基线。

先明确决定，再选择指标

指标不是越多越好，也不是越漂亮越好。Skill 原文要求先回答：这套指标要支持谁、在什么节奏下、做什么决定。

这个顺序很容易被跳过。团队通常先问“我们该看哪些指标”，于是把能算的都算出来，再挑几个看起来重要的放进看板。结果是每个指标都有人负责解释，却没人对“成功”负责。

原文给出的筛选标准有六项，可以当作候选指标的过滤器：

标准	要回答的问题
反映真实目标	它是结果本身，还是只是容易涨的替代量
能改变决定	数值变动后，团队会做什么不同的事
及时给出信号	在决策节奏内能看出变化，而不是一年后才揭晓
有可控杠杆	团队是否有办法影响它
可稳定测量	能否持续、一致地计算，而非一次性手工统计
不易刷高	提升它是否会悄悄损害质量、信任或成本

最后一条最容易被低估。“不易被误导性地改善”意味着指标本身要带防作弊结构：如果提升转化率可以通过放宽资格实现，那么这个转化率就必须和资格指标一起看。

原文建议收敛到 1–3 个主 KPI，每个主 KPI 在有助于诊断时配 1–2 个驱动指标，在存在权衡时配 1–2 个护栏。除此之外的指标，只有在能实质改善决策时才值得加入。

三层结构：结果、驱动与护栏

指标体系不是平铺的清单，而是三类关系：

Outcome（结果）：最终想改变什么。
Drivers（驱动）：通过哪些可控路径影响结果。
Guardrails（护栏）：哪些底线不能被牺牲。

以一个 AI 数据分析产品为例，教学设定可以是：

层级	示例指标	它负责回答
Outcome	决策可用的分析完成率	分析是否真的支持了决定
Drivers	首个有效答案耗时、可验证来源覆盖率	哪些环节决定结果
Guardrails	返工与错误率、单任务成本、端到端延迟	代价是否可接受

这个结构比“一个总分”更有用，因为总分无法告诉你该改哪里。结果下滑时，驱动指标说明是慢了还是错了；护栏指标说明修得对不对。原文同时提醒：不要在没有来源定义支持时凭空发明因果层级。驱动关系应该来自业务实际如何运作，而不是为了让图好看。

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

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

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

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

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

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

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

主 Skill 只能有一个

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

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

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

工具可见，不等于获得授权

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

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

冲突来源不能被悄悄合并

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

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

完成门比“已经算完”更严格

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

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

设计自己的路由器时

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

参考：OpenAI Data Analytics Skills 公开参考仓库

Anthropic Skills：把分析经验从提示词变成可维护工作流

Mon, 21 Sep 2026 00:00:00 +0000

把模型接到数仓，不会自动得到稳定的分析师。它还需要知道团队怎样检查数据、如何建模、什么图适合表达结论，以及交付前必须做哪些复核。

Anthropic 将 Skill 定义为包含指令、脚本和资源的文件夹，相关时才加载所需内容。这个设计把“每次重新解释工作方法”变成可版本化的工作协议，也允许在需要确定性的环节执行代码。

Skill 封装的是方法，不是知识幻觉

指令可以规定步骤和边界；脚本可以承担清洗、计算或格式转换；模板与参考材料可以约束最终制品。三者组合后，同一套方法可用于表格、文档、演示和 PDF 等不同交付面。

但 Skill 不会凭空补齐企业指标定义和权限。分析类 Skill 仍需显式接入数据语义、来源优先级、允许调用的工具，以及谁负责最终批准。

为什么比一次性提示词更容易治理

Skill 可以进入版本控制，变更能审阅，测试任务能回归，组织也能分发经过批准的版本。它把模型行为的一部分从隐藏对话移到可检查文件中。

代价是新的供应链风险：Skill 可能包含可执行代码，也可能引导模型访问文件和连接器。Anthropic 官方同样建议只使用可信来源。企业至少需要来源审查、最小权限、隔离执行、依赖固定和制品扫描。

分析 Skill 的合理分层

一个成熟工作流通常分成六段：理解用户任务、加载方法指令、取得必要文件与工具、执行可重复计算、生成制品、进行内容与视觉验收。封面图中的每个区块都对应一个可测试的责任，而不是一句抽象的“做分析”。

适合怎么落地

先挑一个高频、边界清楚的交付，例如周度经营复盘。把输入契约、指标口径、异常处理、图表规范和验收清单写进 Skill；将真实历史任务做成回归集；让分析师审阅失败类型，而不是只看平均满意度。

Skills 最有价值的地方，不是给模型增加更多身份，而是把专家经验变成可以维护、组合和验证的工作流。

验收应覆盖过程与制品

分析 Skill 的测试不能只问“有没有生成文件”。过程层要检查输入数据是否完整、公式是否可追溯、异常是否被记录；制品层要检查表格公式、图表尺度、标题结论和移动端可读性。对同一批历史任务做版本回归，才能知道新指令是改进了方法，还是只让输出更像模板。

企业还需要明确失败策略：缺少关键字段时停止并说明，还是用替代口径继续；脚本报错后允许重试几次；生成的文件在发送前由谁批准。把这些边界写进 Skill，才算把经验工程化，而不是把一段更长的提示词放进文件夹。

维护时还应把方法更新与模型更新分开评估。模型升级可能改善推理，却也可能改变工具选择和制品风格；Skill 版本变化则会直接改变步骤与验收。分别固定变量做回归，才能知道质量变化来自哪里。

参考：Introducing Agent Skills

快手 Data Agent：1 万周活背后的规模化系统工程

Sun, 20 Sep 2026 00:00:00 +0000

一个 Data Agent 获得 1 万周活，意义不在于聊天框里多了多少提问，而在于它已经进入数据生产、经营诊断和日常交付。快手 2026 年 9 月 19 日技术分享中的阶段性数据，展示了一条从单场景 Workflow 到统一 Agent 入口的演进路径。

分享材料给出的快照包括：周活超过 1 万、核心数据分析与产运岗位渗透率超过 80%、Skill 数量超过 2,000，以及超过 60 万条评测记录。这些数字来自快手材料，未经过独立审计，也不应被理解为对其他组织的效果承诺。真正有参考价值的，是规模背后的系统关系。

先从能够验证结果的黄金任务开始

快手早期从单场景 Workflow 探索，逐步扩展到多场景、Agentic 能力和统一入口。规模化并不是先构建一个“万能 Agent”，而是不断找到高频、价值清楚、结果可核对的任务。

所谓黄金任务至少有三个条件：需求持续发生，节省时间对业务有价值，结果能够通过指标、查询或交付物验证。报告生成、异动归因、数据研发和实验分析都符合这一特征。

父 Agent 负责路由，专业 Agent 承担责任

统一入口接收用户目标，父 Agent 理解问题并选择主站、电商、商业化、安全或海外等专业 Agent。通用 Skill 则承担查数、归因和报告等可复用方法。

这种结构解决的是责任分配，而不只是多角色展示。父 Agent 要判断场景和权限，子 Agent 要在自己的数据域、规则和工具范围内完成任务。材料给出父子 Agent 路由准确率 95% 的阶段性口径；实际部署仍需要持续观察误路由如何被发现、纠正和回归。

Skill 把方法变成组织资产

指标查找、异常诊断、SQL 开发、报告和治理规则可以被封装成 Skill。Skill 市场让业务团队复用方法，也为评审和版本控制提供载体。

数量不是目标。一个有价值的 Skill 应明确输入、允许工具、异常处理、验证条件和交付物。若 2,000 个 Skill 缺少 Owner、版本和淘汰机制，路由成本与维护负担也会迅速上升。

知识飞轮解决模型之外的准确性

快手的架构把知识构建、分层存储、搜索或确定性路由、业务应用连成一条链。数据资产与历史任务被抽取为可服务知识，真实使用产生的纠正再回到知识和评测。

OpenAI Data Agent 发布：把企业数据变成答案、看板与行动

Fri, 11 Sep 2026 00:00:00 +0000

2026 年 9 月 10 日，OpenAI 在 ChatGPT Work 中发布 Data Agent。它不是单独增加一个 Text-to-SQL 对话框，而是把企业数据源、业务上下文、分析工作流、交互式看板和批准后的行动接入同一条会话链。

这项发布值得关注，因为它把 Data Agent 的竞争从“模型能否写查询”推向了“组织能否让更多员工在现有权限内完成一项可复核的数据工作”。

数据连接和业务上下文同时进入分析

官方列出的获批数据源包括 Amazon Redshift、Datadog、Google BigQuery、ClickHouse、Databricks、MongoDB 和 Snowflake，也可将 Google Drive、SharePoint 中的文件与文档带入分析。

连接器只解决“数据可达”。Data Agent 还会使用组织已有的业务术语、指标定义、自定义计算和数据关系，相关上下文可来自 Databricks Genie Ontology、dbt、GitHub、Snowflake Horizon 与 BI 看板等可信来源。

这两类输入必须分开理解：数据源提供记录，语义资产规定这些记录如何变成业务含义。若组织没有稳定定义，Agent 只会更快暴露口径冲突。

分析过程变成可继续追问的工作区

用户可以在同一会话中要求 Agent 调查变化、比较历史时期、检查证据并调整范围。结果不仅是文字回答，还可以形成可编辑、分享和刷新的交互式看板；官方同时列出 Tableau、Power BI、Sigma 和 ThoughtSpot 等 BI 生态合作伙伴。

这里最重要的产品变化，是中间过程不再完全隐藏。用户可以沿着问题、证据和制品继续迭代，而不是每次重新提交一个孤立查询。

Skills 把常见分析方法拆成工作协议

Data Agent 背后包含指标设计、业务背景收集、数据上下文、质量分析、诊断、Notebook、可视化、看板和报告等分析 Skills。连接器回答“可以访问什么”，Skill 回答“这类任务应该怎样做、怎样验证、什么时候完成”。

Skill 不等于已经证明的产品性能。它描述的是工作方法和验收边界，实际效果仍取决于数据质量、语义资产、权限配置和具体任务。

从发现到行动，多了一道批准边界

Agent 可以建议下一步、识别需要参与的人，通过 Slack 或邮件分享发现，并使用连接工具执行用户批准的行动。这里的“批准”非常关键：分析建议、动作提案、授权执行和执行后回读应被视为不同状态。