造了 5 个 Skill 之后我选出最满意的一个电商销售日报生成与异常归因先说结论前两周为了参加讯飞 AI 开发者大赛我用 WorkBuddy 连着造了 5 个 Skill跨了医疗、金融、电商、办公、穿搭五个领域。做完之后回头看「电商销售日报生成与异常归因」是完成度最高的一个。不是说其他四个不好而是这个在几个关键维度上都占优维度电商日报门诊病历行业研究会议纪要穿搭助手包体积195KB15.7KB16KB~15KB未完成代码文件含 Python 脚本纯文档纯文档纯文档纯文档测试通过3/314/14JSON 校验未记录未测试合规一次过是否打回否打回名称冲突—领域知识深度中高高中低工程完整度高中中低低选它当最佳主要因为三点有可执行的代码、流程一次跑通没被打回来、异常归因逻辑有实际工程含量。下面拆开讲。这个 Skill 是干什么的目标用户电商运营数据分析师。每天要从天猫、京东、抖音、拼多多等多个渠道导出销售数据手工汇总成日报还要判断哪些指标异常、异常的原因是什么。痛点一个做电商数据分析的朋友跟我说他每天早上的流程是这样的登 4-5 个后台分别导出昨天的销售数据把数据贴到一个大 Excel 里做渠道汇总算同比、环比看哪些数字不对劲逐个渠道去查异常原因——是断货了是推广停了还是大盘在跌写一段日报文字发到群里整个流程每天花 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():dfpd.read_csv(file_path)df[渠道]channel all_data.append(df)mergedpd.concat(all_data,ignore_indexTrue)# 2. 数据清洗——处理缺失值和异常格式merged[销售额]pd.to_numeric(merged[销售额],errorscoerce).fillna(0)merged[订单量]pd.to_numeric(merged[订单量],errorscoerce).fillna(0)# 3. 按渠道汇总daily_summarymerged.groupby(渠道).agg({销售额:sum,订单量:sum,客单价:mean}).round(2)# 4. 计算同比环比需要历史数据# 这里用模拟的历史数据做演示comparisoncalculate_comparison(daily_summary)# 5. 异常标记anomaliesflag_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,threshold0.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}resultprocess_sales_data(test_input)print(json.dumps(result,ensure_asciiFalse,indent2))这段代码不算复杂但解决了几个实际问题多渠道数据格式不统一不同后台导出的 CSV 列名可能不一样有的叫销售额有的叫GMV有的金额单位是元有的是万元。脚本里用pd.to_numeric(errorscoerce)统一转数字fillna(0)处理缺失值。不花哨但管用。异常判定阈值可配默认波动超过 20% 标记为异常超过 50% 标记为高严重度。这个阈值写在脚本参数里不是写死在 SKILL.md 的文字描述里——因为 Agent 执行文字描述时可能理解不一致但代码跑出来的结果每次都一样。输出是 JSON 而不是文字脚本的输出是结构化 JSONAgent 读取后再格式化成 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:dfpd.read_csv(file_path)df[渠道]channel all_data.append(df)exceptFileNotFoundError:print(f警告{channel}数据缺失已跳过)continue这个修复看着简单但它反映了一个设计原则Skill 要能优雅降级。数据不全不应该直接崩掉而应该处理能处理的部分同时给出缺失提示。这在软工课上叫防御性编程在这个场景下特别适用。为什么这个 Skill 做得最好回头看这个 Skill 之所以完成度高有几个原因1. 场景边界清晰电商日报这个场景天然有明确的输入销售数据和输出日报中间流程也不模糊汇总→计算→标记→归因。相比之下「行业动态多源采编与风险洞察助手」的边界就模糊得多——多源到底是几个源风险洞察的颗粒度是什么边界模糊的 SkillSKILL.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 处理模糊性逻辑 结构化的领域知识。四样缺一样做出来的东西要么不稳定要么没深度。