前两篇讲了"怎么写 Skill"和"该选什么来写"。这篇不空谈了，拿数据分析当样板，从头到尾走一遍：从需求定义、流程设计、脚本与模型的职责划分，到验收标准，把一个能稳定产出报告的 Skill 是怎么"长"出来的，一步步拆给你看。数据分析恰好是绝佳的案例------它同时包含确定性部分（计算）和不确定性部分（归因），正好覆盖 Skill 设计的全部要素。
一、先定义：这个 Skill 到底解决什么问题
写任何 Skill 前，第一件事不是写代码，而是写清楚需求边界。数据分析 Skill 的第一步，是回答这几个问题：
输入：什么数据？（Excel / CSV / 数据库导出 / 图片报表）
任务：要做什么分析？（经营复盘 / 指标异动 / 漏斗分析 / 留存分析）
产出：交付什么？（分析报告 / 可视化图表 / 结论清单）
边界：明确不做什么？（不做预测建模 / 不做数据采集）为什么边界重要 ？因为"数据分析"是个巨大的词。如果你写的 Skill 试图覆盖所有分析场景，它就会变成一锅粥------每步都含糊，每个输入都能进，每个输出都不标准。好的做法是收窄成具体场景，比如先做"月度经营数据异动分析"，而不是"万能数据分析"。
一个清晰的边界定义长这样：
Skill 名称：月度经营数据异动分析
输入：含日期、渠道、收入、订单量的 CSV/Excel
任务：识别关键指标的周环比/月环比异动，定位异动渠道，给出归因
产出：一份含结论清单、异动表格、趋势图的分析报告
不做：不预测未来，不处理非结构化文本，不采集数据二、设计核心流程：把"人类做分析"的步骤显性化
边界定了，下一步是把分析师的思考过程拆成可执行步骤。这一步别急着想代码，先想"一个合格的分析师拿到这份数据会怎么做"：
步骤 0：数据读取与口径核验
→ 读入数据，检查字段完整性、空值、异常值、日期格式
步骤 1：数据清洗
→ 处理缺失值、去重、修正格式、识别异常值
步骤 2：指标计算
→ 计算核心指标及环比/同比，汇总到渠道、日期维度
步骤 3：异动识别
→ 按阈值规则标出异常波动的指标和维度
步骤 4：归因分析
→ 对每个异动点，结合维度拆解定位"哪个渠道/品类/时段贡献了变化"
步骤 5：报告生成
→ 结论清单 + 数据表格 + 趋势图，按固定模板输出关键点 ：步骤 0 和步骤 1（口径核验、清洗）是数据分析 Skill 里最容易跳过但最致命的环节。人做分析时凭经验下意识完成了，但 Skill 如果不显式写出来，模型会直接跳过去------最后结论建立在脏数据上。
三、划分职责：脚本干确定性的活，模型干判断性的活
数据分析 Skill 的精华就在这一刀切------把流程里的每一步归类成"确定性"还是"不确定性"：
| 流程步骤 | 性质 | 谁来干 |
|---|---|---|
| 数据读取、字段校验 | 确定性 | 脚本 |
| 清洗、去重、格式修正 | 确定性 | 脚本 |
| 指标计算、聚合汇总 | 确定性 | 脚本 |
| 异动识别（阈值规则） | 半确定性 | 脚本 + 规则 |
| 归因分析（为什么波动） | 不确定性 | 模型 |
| 报告结构组织、结论措辞 | 不确定性 | 模型 |
核心原则：能计算的绝不靠猜。 指标数值、环比增幅、异动清单------这些必须由脚本精确算出来，绝不能交给模型"估算"。模型负责的是脚本算不出来的部分："这个异动意味着什么"、"可能是由什么导致的"、"报告怎么讲才清晰"。
这个划分直接决定了 Skill 的质量。很多失败的数据分析 Skill 都是反着来的------让模型去算数字，算出来的数对不上，结论自然不可信。
四、用规则把"异动识别"做成确定性
归因是模型的事，但"什么算异动"可以（也应该）是规则。把判断标准显性化，是这个 Skill 真正的经验沉淀所在：
异动判定规则（可配置）：
- 环比增幅 > 20% → 标记为"显著上升"
- 环比降幅 > 20% → 标记为"显著下降"
- 绝对值占比 > 总体的 30% → 标记为"关键渠道"
- 连续 3 期下降 → 标记为"持续走弱"为什么要用规则而不是让模型判断？ 因为规则可复现、可解释、可调参。今天说 20% 算异动，明天想改成 15%，改一行配置就行------而如果让模型"看着判断"，每次结果都可能漂移。规则负责"圈出值得看的点"，模型负责"解释这些点"。
五、定义验收标准：怎样算一份合格的报告
Skill 必须自带验收清单，否则你永远不知道跑出来的东西算不算成功。数据分析 Skill 的验收标准可以这样写：
验收清单：
□ 所有指标数值与原始数据核对一致（可复算）
□ 清洗规则有记录，改动可追溯
□ 每个异动点都有明确的原因结论或"数据不足以归因"的说明
□ 报告包含结论清单、支撑表格、趋势图三类要素
□ 无未说明的口径假设（如"统计口径为自然月"）
□ 失败场景有明确报错（如"缺少日期字段"）其中**"可复算"是最硬的一条**------报告里的每个数字，读者都能从原始数据重新算出来。这既是质量保证，也是信任基础。
六、一个 Skill 骨架示例
把上面的设计落成一个可执行的骨架（伪代码，表达结构而非具体实现）：
python
# 数据分析 Skill 执行骨架
def run_data_analysis(input_path, config):
# --- 确定性部分：脚本全权负责 ---
df = load_and_validate(input_path, config) # 步骤0：读取+口径核验
df = clean(df, config) # 步骤1：清洗
metrics = compute_metrics(df, config) # 步骤2：指标计算
anomalies = detect_anomalies(metrics, config) # 步骤3：规则识别异动
# --- 半确定性：规则 + 结构化数据传递给模型 ---
context = build_context(anomalies, metrics) # 把算好的结果结构化
# --- 不确定性部分：模型负责归因与写作 ---
report = llm_analyze(context, config) # 步骤4+5：归因 + 报告生成
return report注意这个骨架里最关键的设计：模型拿到的不是原始数据，而是脚本算好的结构化结果（异动清单、指标表）。这一步让模型的归因有据可依，而不是对着原始 Excel 瞎猜。
七、最容易踩的坑
- 让模型算数字：任何"模型告诉我这个数是多少"的设计都是错的，数字必须脚本算。
- 跳过口径核验：不做字段校验，脏数据直接进分析，结论全错，且难以发现。
- 验收标准写在文档里但不实测："输出规范报告"这种话没有意义，要用真实数据跑通验证。
- 规则参数写死：阈值应该可配置，而不是写死在代码里------否则换一个业务场景就废了。
- 报告没有"不知道"选项：归因不了就说"数据不足以归因"，强写原因比不写更危险。
- 一次想覆盖所有分析类型：先做窄而深的一个场景，跑通后再复制扩展。
八、一句话总结
一个数据分析 Skill 的成败，取决于你把"计算"和"判断"分得多干净。 脚本负责一切可计算、可复现的部分------清洗、算指标、圈异动；模型只负责解释和表达------为什么波动、结论怎么讲。规则给模型划定视野，结构化数据给模型提供依据，验收清单保证每次输出都可信任。
照着这个骨架，你可以把它扩展到任何分析场景：电商运营、日志分析、用户留存......换的是字段和规则，不变的是"确定性归脚本、判断性归模型"这一刀。