关于 forecasting
forecasting 是一项需求预测技能,指导 Agent 在简单情形使用滚动均值,在季节性、促销或趋势变化情形调用 forecaster 子 Agent。它还提供批量库存覆盖天数计算及置信度处理指引。
主要功能
- 01根据任务条件选择预测路径
- 02计算滚动均值预测
- 03按库存覆盖天数批量排列 SKU
- 04将复杂情形委派给 forecaster
- 05考虑季节性和促销因素
- 06向补货策略传递置信度与标记
适用场景
- 01预测短周期内非季节性 SKU 的需求
- 02在库存检查中按紧急程度排列多个 SKU
- 03估算促销影响下的需求
- 04补货前升级处理不确定的预测
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ anthropics/ cwc-workshops --skill forecasting安装后在 Claude Code 中输入/forecasting确认已加载。
附带文件batch_days_of_cover.pyrolling_mean.py
详细介绍
需求预测
预测有两种路径。选择正确的路径——不需要子 Agent 时调用子 Agent 会浪费轮次;需要时跳过它则会得到错误的数值。
路径 A — 自行计算(代码执行)
仅当以下所有条件都满足时使用:
- horizon ≤ 14 天
- 产品的
is_seasonal标志为 0 - 产品的
promo_next_month标志为 0 - 任务没有提到促销、节假日或趋势变化
此时,预测就是滚动均值。本技能附带了一个脚本:
python .claude/skills/forecasting/rolling_mean.py SKU-0057 14
就是这样——一次 Bash 调用,约 200 个 token,无需子 Agent。想要调整脚本的话,可以阅读它(约 20 行)。
批量处理变体,适用于全面扫描: 如果需要一次性计算许多 SKU 的库存可售天数(例如每日低库存检查),不要循环调用工具——运行批处理脚本:
python .claude/skills/forecasting/batch_days_of_cover.py 20
返回按库存可售天数排序、最紧急的 20 个 SKU 的 JSON。这替代了旧版 Agent 在 F1 上执行的 100 多次 get_stock_level / get_sales_velocity 调用。
路径 B — 启动预测子 Agent
满足以下任一条件时使用:
- horizon > 14 天
is_seasonal为 1promo_next_month为 1,或任务提到了促销- 近期销售显示出明显的趋势变化
为什么要用子 Agent: 预测器需要在上下文中查看完整的 90 天历史记录,才能发现季节性和促销影响。这大约是 90 行 × SKU 数量。把这些数据加载到你的上下文中,会挤占任务其余部分的空间。子 Agent 有自己的上下文窗口,可以在那里进行分析,然后返回精简的 JSON。
操作方法: 将任务委托给可调用的 forecaster Agent。只发送 SKU、产品标志和 horizon——不要发送历史记录行。预测器可以通过 Bash 访问相同的 /mnt/user/data/,并会在自己的上下文中基于完整历史记录进行计算(这正是这样做的目的:90 行数据留在那里,而不是这里)。它会返回 {forecast_qty, confidence, method, flags} JSON——请严格解析;如果 JSON 格式错误,那就是错误,不要试图猜测处理。
如果无法使用 callable_agents(这是一项研究预览功能),则改为自行内联计算滚动均值,并将 confidence 设为 ≤ 0.55,这样补货策略技能就会升级为人工审核,而不是根据你无法验证的数值自动下单。
季节日历(检查数值是否合理)
户外装备具有很强的季节性。当预测周期跨越季节分界时,滚动均值会滞后于趋势转变——依靠路径 B,并说明季节因素。
| 时间段 | 需求上升的类别 | 相较基线的预期 |
|---|---|---|
| Mar–May | 鞋类、背包、雨衣、登山杖 | 1.3–1.6× |
| Jun–Aug | 帐篷、睡眠用品、炉具、水过滤设备 | 1.5–2.0×(季度高峰) |
| Sep–Oct | 保暖服装、光学设备、头灯 | 需求上升;帐篷/鞋类需求趋缓 |
| Nov–Dec | 适合作为礼品的价位产品;促销力度最大 | 确认促销标志 |
| Jan–Feb | 淡季调整——销量最低 | 适合盘点 |
促销处理
促销是导致订货不足的最常见原因。当 promo_next_month=1 或任务提到促销时:
- 不要仅依赖滚动均值——它反映的是促销前的需求。
- 查找历史类比数据(同一 SKU,过去 12 个月内可比的促销),并采用该提升幅度。如果找不到,子 Agent 应设置
flags: ["promo_uplift_uncertain"],并将置信度设为远低于 0.6。 - 提升幅度不确定时,默认标记为待审核,而不是自动下单。促销期间订货过多可以补救;订货不足则会在关注度最高时造成缺货。
- 如果已知促销结束日期,应考虑促销后的需求下滑——不要让渠道在结束后一周库存过剩。
需要避免的失误: 在文字说明中声称需求有所提升(“可能达到约 3×”),但返回的 forecast_qty 仍然是未计入提升的基线均值。要让数值体现提升,而不只是叙述。
如何处理结果
将 {forecast_qty, confidence, flags} 传入补货策略技能。特别是:如果 confidence < 0.6,补货策略要求升级处理,不要自动下单。 不要忽略 confidence 或 flags——它们是约定的一部分。
示例(路径 B)
任务:“为下个月的促销补订 SKU-0091。” → promo_next_month=1,预测周期=30 → 路径 B。
子 Agent 返回:{"forecast_qty": 2100, "confidence": 0.41, "method": "baseline_mean_no_comparable_promo", "flags": ["promo_uplift_uncertain"]}
confidence 0.41 < 0.6 → 根据补货策略,不要创建 PO。通过 notify-templates 升级处理并附上 flags,建议按基准值补订约 2,100 件,并注明促销带来的增幅可能达到 2–3 倍,需要人工判断。