Data Analysis Skill 火起来，说明 Agent 终于需要“分析纪律”

数据分析类 Skill 的价值，不在于让模型多会几个 pandas 命令，而在于把“怎么算”之前的判断流程固定下来。真实数据工作很少输在不会求和、不会画图，更多输在问题没有拆开、异常没有追问、口径没有写清楚，最后得到一堆正确但没用的数字。

这类 Skill 把 Agent 从“临时写脚本的人”推向“按分析流程工作的初级分析师”：先看数据结构和业务问题，再决定分析角度，最后把结论写成能被业务方使用的报告。这里的关键不是自动化，而是让分析过程变得可复用、可审计。

从跑代码到形成判断

没有分析框架时，模型很容易把 CSV 当成练习题：读文件、做描述统计、画几张图，然后用“趋势明显”“建议关注”收尾。这种输出看起来完整，但很难指导决策。复购率下降，是新客问题、老客问题、渠道问题、品类问题，还是促销口径变化？如果 Skill 没有逼它先建问题树，答案通常会散。

好的 data-analysis Skill 会先建立语义层：字段是什么，时间粒度是什么，指标是否可比，缺失值和异常值是否影响口径。只有这一步过了，后面的图表才不是装饰。

多专家并行不是噱头

公开案例里的 data-analysis-pro 采用多专家并行思路，这一点真正有价值。复杂数据集往往同时包含财务、用户行为、运营效率和市场背景，一个上下文里什么都分析，结果往往每个方向都浅。拆成若干独立分析视角，可以让每个视角在自己的上下文里深入，再由最终报告收束成主题化结论。

但多专家也不是默认答案。十几行单表数据不该启动五个角色。更合理的做法是按复杂度自适应：简单数据直接分析，中等数据用三条主线，复杂多表再并行拆解。这样既保留深度，也避免把 token 花在仪式感上。

报告要按结论组织，而不是按角色组织

一个常见错误是把最终报告写成“财务专家认为、运营专家认为、用户专家认为”。这暴露了过程，却没有服务读者。真正能拿去开会的报告应该按结论排布：哪个指标变了，主要贡献来自哪里，下一步最该验证什么。

Skill 的最终目标不是展示 Agent 做了多少工作，而是让人快速判断：这个问题现在是否被解释清楚，哪些建议能落地，哪些仍只是待验证假设。

落地时要保留三条边界

第一，数据口径必须写清楚，特别是时间范围、过滤条件和指标定义。第二，所有建议要能追溯到证据，不要把相关性包装成因果。第三，报告要区分“发现”“解释”“行动”，否则模型会把观察到的数字直接写成经营建议。