造了 5 个 Skill 之后，我选出最满意的一个：电商销售日报生成与异常归因

先说结论

前两周为了参加讯飞 AI 开发者大赛，我用 WorkBuddy 连着造了 5 个 Skill，跨了医疗、金融、电商、办公、穿搭五个领域。做完之后回头看，「电商销售日报生成与异常归因」是完成度最高的一个。

不是说其他四个不好，而是这个在几个关键维度上都占优：

选它当最佳，主要因为三点：有可执行的代码、流程一次跑通没被打回来、异常归因逻辑有实际工程含量。下面拆开讲。

这个 Skill 是干什么的

目标用户

电商运营数据分析师。每天要从天猫、京东、抖音、拼多多等多个渠道导出销售数据，手工汇总成日报，还要判断哪些指标异常、异常的原因是什么。

痛点

一个做电商数据分析的朋友跟我说，他每天早上的流程是这样的：

1. 登 4-5 个后台，分别导出昨天的销售数据
2. 把数据贴到一个大 Excel 里，做渠道汇总
3. 算同比、环比，看哪些数字不对劲
4. 逐个渠道去查异常原因——是断货了？是推广停了？还是大盘在跌？
5. 写一段日报文字，发到群里

整个流程每天花 1.5-2 小时，其中汇总和格式化占 40%，异常归因占 50%，写字占 10%。最烦的不是重复劳动，是异常归因——你得跨渠道对比、翻历史数据、看推广日志，才能定位原因。

Skill 做的事

输入：多个渠道的销售数据（CSV 或粘贴的表格数据）
输出：一份结构化日报，包含汇总数据、同比环比、异常标记和归因分析

Skill 包结构

skill-ecommerce-sales-report/ ├── SKILL.md # 核心定义文件 ├── scripts/ │ └── sales_daily_report.py # 数据处理脚本 ├── references/ │ ├── anomaly_rules.md # 异常判定规则 │ ├── attribution_guide.md # 归因分析指南 │ └── report_template.md # 日报格式模板 └── samples/ ├── sample_input_multi.csv # 多渠道输入样本 ├── sample_input_single.csv # 单渠道输入样本 └── sample_output_report.md # 期望输出样本

为什么说这是 5 个 Skill 里完成度最高的？因为它是唯一一个带可执行代码的。其他四个全是纯 Markdown 文档，靠 Agent 自己理解流程来执行；这个有一段 Python 脚本兜底，核心数据处理逻辑不依赖 Agent 的理解能力，直接跑代码出结果。

这个思路是我做到第三个 Skill 的时候才想明白的：能用代码解决的事情，别让 LLM 去猜。

核心文件拆解

SKILL.md：流程编排者

SKILL.md 在这个 Skill 里的角色不是"执行者"，而是"调度者"。它定义了整个处理流程，然后决定哪些步骤交给 Python 脚本、哪些步骤交给 Agent。

核心流程：

1. 接收多渠道销售数据（CSV/表格） 2. 调用 sales_daily_report.py 做数据清洗和汇总 3. 脚本输出结构化结果（JSON） 4. Agent 读取结果，按照 report_template.md 格式化 5. Agent 根据 anomaly_rules.md 判断异常 6. Agent 按照 attribution_guide.md 做归因分析 7. 输出完整日报

关键设计：数据处理交给代码，语义分析交给 Agent。

数据清洗、汇总、同比环比计算这些确定性的活，Python 脚本干得又快又准。异常判定和归因分析需要结合上下文理解、历史趋势、推广日志这些非结构化信息，交给 Agent 更合适。

这种"代码+Agent"的混合模式，比纯靠 Agent 跑全流程稳定得多。后面做其他 Skill 的时候我想沿用这个思路，但发现不是所有场景都适合——比如「门诊病历」的语音转结构化，核心逻辑就是语义理解，硬塞个 Python 脚本反而画蛇添足。

sales_daily_report.py：数据处理核心

这个脚本干了三件事：清洗、汇总、标记。

importpandasaspdimportjsonfromdatetimeimportdatetime,timedeltadefprocess_sales_data(input_files):""" 接收多渠道销售数据，输出汇总结果和异常标记 """# 1. 读取并合并多渠道数据all_data=[]forchannel,file_pathininput_files.items():df=pd.read_csv(file_path)df['渠道']=channel all_data.append(df)merged=pd.concat(all_data,ignore_index=True)# 2. 数据清洗——处理缺失值和异常格式merged['销售额']=pd.to_numeric(merged['销售额'],errors='coerce').fillna(0)merged['订单量']=pd.to_numeric(merged['订单量'],errors='coerce').fillna(0)# 3. 按渠道汇总daily_summary=merged.groupby('渠道').agg({'销售额':'sum','订单量':'sum','客单价':'mean'}).round(2)# 4. 计算同比环比（需要历史数据）# 这里用模拟的历史数据做演示comparison=calculate_comparison(daily_summary)# 5. 异常标记anomalies=flag_anomalies(daily_summary,comparison)return{'date':datetime.now().strftime('%Y-%m-%d'),'summary':daily_summary.to_dict('index'),'comparison':comparison,'anomalies':anomalies}defcalculate_comparison(current):""" 计算同比和环比 实际场景中会从数据库读取历史数据 """# 模拟历史数据result={}forchannelincurrent.index:result[channel]={'销售额_环比':round((current.loc[channel,'销售额']-10000)/10000*100,2),'订单量_环比':round((current.loc[channel,'订单量']-500)/500*100,2)}returnresultdefflag_anomalies(summary,comparison,threshold=0.2):""" 标记异常指标 threshold: 波动超过 20% 视为异常 """anomalies=[]forchannelincomparison:formetric,changeincomparison[channel].items():ifabs(change)>threshold*100:anomalies.append({'渠道':channel,'指标':metric,'变化幅度':f'{change}%','严重程度':'高'ifabs(change)>0.5*100else'中'})returnanomaliesif__name__=='__main__':# 测试用例：模拟两个渠道的数据test_input={'天猫':'samples/sample_input_tmall.csv','京东':'samples/sample_input_jd.csv'}result=process_sales_data(test_input)print(json.dumps(result,ensure_ascii=False,indent=2))

这段代码不算复杂，但解决了几个实际问题：

多渠道数据格式不统一：不同后台导出的 CSV 列名可能不一样，有的叫"销售额"，有的叫"GMV"，有的金额单位是元，有的是万元。脚本里用pd.to_numeric(errors='coerce')统一转数字，fillna(0)处理缺失值。不花哨，但管用。

异常判定阈值可配：默认波动超过 20% 标记为异常，超过 50% 标记为高严重度。这个阈值写在脚本参数里，不是写死在 SKILL.md 的文字描述里——因为 Agent 执行文字描述时可能理解不一致，但代码跑出来的结果每次都一样。

输出是 JSON 而不是文字：脚本的输出是结构化 JSON，Agent 读取后再格式化成 Markdown 日报。这样数据处理和文案生成分离了，数据部分不会出错，文案部分 Agent 发挥空间大。

references/anomaly_rules.md：异常判定规则

这个文件定义了什么算"异常"。脚本负责数值层面的标记，这个文件负责语义层面的判断：

# 异常判定规则 ## 数值异常（由脚本自动标记） - 环比变化超过 ±20%：中度异常 - 环比变化超过 ±50%：高度异常 - 连续 3 天下降趋势：趋势异常 ## 业务异常（由 Agent 判断） - 客单价骤降：可能存在低价刷单或促销力度过大 - 订单量激增但销售额不涨：可能存在大额退款 - 某渠道突然归零：可能存在断货或接口故障 - 转化率异常波动：需结合流量来源分析

数值异常和业务异常分开处理——数值异常是确定性的，交给脚本；业务异常需要结合上下文，交给 Agent。这个分工是整个 Skill 设计里我最满意的部分。

references/attribution_guide.md：归因分析指南

这个文件教 Agent 怎么做归因分析，相当于给 Agent 一套分析框架：

# 异常归因分析指南 ## 归因步骤 1. 确认异常范围：是单渠道还是全渠道？ 2. 检查时间维度：是突发事件还是持续趋势？ 3. 交叉验证：异常指标之间是否有关联？ 4. 归因方向： - 供给端：库存、物流、商品上架状态 - 需求端：流量、转化、竞品动态 - 运营端：推广投放、活动节奏、价格变动 - 外部因素：节假日、天气、行业大盘 ## 输出格式 每个异常需给出： - 异常描述 - 可能原因（1-3 个，按概率排序） - 建议动作

这个框架不是我自己拍脑袋想的，是查了几篇电商运营分析的文章，加上跟那个做电商的朋友聊了一晚上总结出来的。领域知识这块，真的得跟实际干这行的人聊。AI 能帮你搭框架，但框架里填什么内容，得靠一线经验。

测试过程

跑了 3 组测试用例：

测试 1：正常多渠道输入

• 输入：天猫 + 京东 + 抖音三个渠道的 CSV
• 预期：汇总报表 + 无异常标记
• 结果：通过

测试 2：含异常数据

• 输入：天猫销售额环比下降 35%
• 预期：标记为中度异常 + 归因分析指向供给端
• 结果：通过。Agent 正确识别了异常并给出了"检查库存状态"的建议

测试 3：单渠道数据缺失

• 输入：只提供了天猫数据，京东和抖音缺失
• 预期：正常处理已有数据 + 提示缺失渠道
• 结果：第一次失败，脚本直接报错。修复后通过

测试 3 暴露的问题是在脚本里加了缺失处理：

forchannel,file_pathininput_files.items():try:df=pd.read_csv(file_path)df['渠道']=channel all_data.append(df)exceptFileNotFoundError:print(f'警告：{channel}数据缺失，已跳过')continue

这个修复看着简单，但它反映了一个设计原则：Skill 要能优雅降级。数据不全不应该直接崩掉，而应该处理能处理的部分，同时给出缺失提示。这在软工课上叫"防御性编程"，在这个场景下特别适用。

为什么这个 Skill 做得最好

回头看，这个 Skill 之所以完成度高，有几个原因：

1. 场景边界清晰

电商日报这个场景天然有明确的输入（销售数据）和输出（日报），中间流程也不模糊（汇总→计算→标记→归因）。相比之下，「行业动态多源采编与风险洞察助手」的边界就模糊得多——"多源"到底是几个源？"风险洞察"的颗粒度是什么？边界模糊的 Skill，SKILL.md 写起来就虚，Agent 执行时也容易跑偏。

2. 代码兜底

其他 Skill 全靠 Agent 理解 SKILL.md 的文字描述来执行，输出质量取决于 Agent 的理解能力，不稳定。这个 Skill 的核心数据处理有 Python 脚本兜底，每次跑出来的结果都是确定的。Agent 只负责"读结果+写分析"这步，出错概率低很多。

3. 领域知识分层

异常规则分了数值异常和业务异常两层，归因分析有明确的步骤框架。不是把所有知识混在一起扔给 Agent，而是结构化地组织——脚本处理确定性的，Agent 处理模糊性的，各司其职。

4. 合规一次过

做「门诊病历」和「行业研究」的时候都被 Markdown 转义问题打回来了，到这个的时候我已经长了记性——写 SKILL.md 的时候每写一个表格和动态内容段落，就顺手检查管道符和换行。合规检查一次通过，省了至少两轮审核时间。

这个其实说明了一个朴素的道理：踩过的坑不会白踩。前三个 Skill 的教训直接变成了第四个的质量提升。

如果要继续打磨

这个 Skill 离"真正好用"还有距离，几个方向：

1. 接入真实数据源：现在只能处理 CSV 输入，理想情况是直接对接各平台 API，自动拉数据。天猫和京东都有开放平台，抖音电商也有数据接口，技术上可行但对接工作量不小。

2. 历史数据积累：现在的同比环比用的是模拟数据，真实场景需要一个历史数据库。可以先用 SQLite 存每日快照，脚本自动查前 7 天和前 30 天的数据做对比。

3. 归因逻辑增强：现在归因靠 Agent 根据 attribution_guide.md 来分析，质量取决于 Agent 的推理能力。可以把归因也部分代码化——比如自动检查库存日志、推广投放时间线，给 Agent 提供更多结构化线索。

4. 可视化：日报里加图表。可以在脚本里用 matplotlib 生成趋势图，嵌入到 Markdown 输出里。这个技术上不难，主要是排版调优花时间。

写在最后

做完 5 个 Skill 最大的收获不是某个具体的 Skill 做得多好，而是逐渐摸清了"怎么做一个好的 Skill"这件事的方法论。电商日报这个之所以做得最好，不是因为技术上多复杂，而是因为前面踩的坑够多，到这个的时候知道该注意什么了。

如果只让我总结一条经验：好的 Skill = 清晰的场景边界 + 代码兜底确定性逻辑 + Agent 处理模糊性逻辑 + 结构化的领域知识。四样缺一样，做出来的东西要么不稳定，要么没深度。