Shelf-Life Copilot 产品规格文档

版本：v0.1（Mock Demo 阶段）更新日期：2026-05-26 阶段：PoC 立项 / 首批客户 Demo 准备

1. 产品定位

一句话：Shelf-Life Copilot 是一个驻扎在企业微信里的 AI 临期管理副驾，每天早上把"哪个批次快过期 + 该怎么处置 + 能省多少钱"主动推送给采购/生产/供应链总监，一键决策、自动派单。

面向行业：冷冻食品、预制菜、休闲食品、烘焙、生鲜加工等所有"原料/半成品/成品有明确保质期"的食品制造企业。

核心命题：把"每年几十万到几百万的临期报损"从被动事后核算，变成主动预警 + AI 建议 + 一键执行。

2. 解决的核心问题

现状	痛点	Copilot 干预
仓库 ERP/WMS 里躺着数千个批次	没人盯，临期都是月底才发现	每天 07:00 主动推送预警
即使发现了也没法快速决策	"转加工 / 打折 / 转员工餐"靠人拍脑袋	AI 给出基于历史成功率的处置建议
决策从总监到车间要走 N 个微信群	信息层层失真、延迟	同意即派单，企微卡片直送车间
一年下来报损不明不白	老板问起说不清"省了多少"也说不清"漏了多少"	每次决策留痕，季度复盘可量化

3. 目标客户与决策人

3.1 首批锚定客户

编号	行业细分	年度临期报损	决策人	Demo 优先级
客户 A	冷冻食品厂（虾仁、鱼糜等水产冷冻原料）	150 万 / 年	供应链/生产总监	P0
客户 B	预制菜厂（盒饭馅料、调理品）	86 万 / 年	采购/生产总监	P0

3.2 决策人画像

角色：总监级别，对报损数字直接负责
决策半径：能拍板"把 850kg 虾仁转去做虾饺馅"这种动作
使用场景：企业微信是日常工作主入口，但讨厌再装一个新 App
关心的指标：报损率、采购成本、生产排期、车间产能匹配
不关心：技术细节、AI 模型、后台仪表盘有多花哨

设计原则：所有功能必须 在企微卡片里 3 秒内看懂。不让总监打开任何外部链接、不让他登录任何后台。

4. 核心用户旅程

07:00  系统扫描所有批次
  ↓
07:00  筛出"剩余 ≤ 30 天 且 库存 ≥ 阈值"的批次
  ↓
07:00  LLM 为每条预警生成处置建议 + 节省金额估算
  ↓
07:00  企微卡片推送给指定决策人
  ↓
       总监看到卡片（10 秒内做完决策）
       ├── ✅ 同意 → 自动生成工单 → 推送给车间主任
       ├── ❌ 稍后 → 进入"待跟进"列表，4 小时后再次提醒
       └── 💬 改方案 → 文字回复，LLM 重新生成建议
  ↓
       工单执行完成 → 车间回执 → 系统记录"实际节省"
  ↓
       季度复盘：累计节省 / 采纳率 / 模型胜率

5. 核心功能模块（MVP）

5.1 模块一：临期监测引擎

输入：物料主数据 + 批次库存（Mock JSON → 真实期对接 ERP/WMS）
触发规则：
- 剩余保质期 ≤ 30 天 → 黄色预警
- 剩余保质期 ≤ 15 天 → 橙色预警
- 剩余保质期 ≤ 7 天 → 红色预警
频率：每日 07:00 批量扫描；紧急批次（≤ 3 天）即时推送

5.2 模块二：AI 处置建议生成器

AI 角色：在"安全动作集合"里挑选 1-2 个最合适的，并生成自然语言解释
安全动作集合（v0.1 全集，实际启用按客户 JSON 配置）：
1. 转加工为下游产品（如：虾仁 → 虾饺馅）
2. 打折清仓（电商、批发渠道）
3. 转为员工食堂 / 关联企业内部消化
4. 调拨至需求更急的分厂或客户
5. 报损处理（仅在前 4 种均不可行时建议）
配置方式：每个客户一份 JSON 配置文件（customer_<id>.actions.json），声明启用的动作子集 + 行业话术覆盖。客户 A、B 两份配置由实施工程师在 Demo 前调研后预填，避免冷启动尴尬。
生成内容：
- 推荐动作（1 个主推 + 0-1 个备选，严格限定在该客户启用的动作子集内）
- 推荐理由（基于历史相似批次的成功率）
- 预估节省金额

5.3 模块三：企微卡片交互层

卡片样式（v0.1 固定模板）：

【临期预警】2026-05-26 07:00

原料：冷冻虾仁 | 批号：2026-03-15 | 保质期：2026-06-14
库存：850kg | 剩余：19 天

⚠️ 建议：【转加工为虾饺馅】(预估可省：¥8,500)

📊 根据历史数据，同类原料在剩余 15-20 天时
    采取此动作，可降低报损率 40%

[✅ 同意]  [❌ 稍后]  [💬 改方案]

交互动作：
- 同意 → 自动生成工单卡片，@车间主任
- 稍后 → 标记为待跟进，4 小时后再推
- 改方案 → 单轮重生成：用户文字回复一句反馈，LLM 携带原卡片上下文 + 反馈，仅重生成一次新卡片返回。不做多轮对话。
  - 越界处理：若反馈中提及的动作超出该客户启用的动作集合（如"送给客户当样品"），LLM 仍按需生成卡片，但顶部加 ⚠️ 非标准动作 · 需人工复核 红色标签，工单生成时需运营/实施二次确认。

5.4 模块四：工单流转

同意后生成的工单包含：
- 原料 / 批号 / 数量
- 处置动作（明确到"转去 3 号车间做虾饺馅"）
- 截止时间
- 责任人（车间主任 / 调度员）
工单完成回执：车间主任在卡片上点"已完成"，系统记录实际处置量

5.5 模块五：决策日志 & 复盘

每次决策留痕：批次 / 建议 / 决策 / 执行结果 / 实际节省
月度报告（纯 PDF 形式）：每月 1 号自动生成上一月 PDF 报告，通过企微文件 / 邮件下发给总监。定位是总监转给老板的汇报材料，因此设计上突出：
- 封面页：本月累计节省金额（大字号） + 同比 / 环比
- AI 建议采纳率 + Top 5 高频处置类型
- 3 个典型决策案例（图文）
- ROI 测算（本月 AI 投入 vs 节省）
- 不做企微卡片摘要、不做 Web 看板（v1.0 之前不投入）

6. AI 能力设计

6.1 模型选型

用途	模型	理由
处置建议生成（默认）	Claude Sonnet 4.6	性价比与文案质量平衡
复杂场景 / 多批次联合建议	Claude Opus 4.7	跨批次推理
改方案对话	Claude Haiku 4.5	低延迟、单轮反馈

6.2 Prompt 框架（核心建议生成）

角色：你是一家食品厂的临期处置专家。
输入：
  - 物料：{material}
  - 批号 / 保质期 / 库存 / 剩余天数
  - 历史同类处置数据：{historicalCases}
  - 当前可用动作集合：{actionSet}
约束：
  1. 只能从动作集合里选择
  2. 必须给出预估节省金额（基于历史均值）
  3. 必须说明"为什么是这个动作"（≤ 30 字）
  4. 输出 JSON 结构化结果
输出格式：
  { "action": "...", "savings": 8500, "rationale": "...", "confidence": 0.82 }

6.3 安全设计

AI 不直接执行任何动作，只生成"建议"
决策权 100% 在总监手上
LLM 输出经过 schema 校验，超出动作集合的建议自动丢弃
所有 prompt + 模型回复留痕，可追溯

7. 技术架构（v0.1）

┌─────────────────────────────────────────────────────────┐
│  企业微信 (用户唯一触点)                                  │
└──────────────────────┬──────────────────────────────────┘
                       │ WeCom Webhook / Bot API
┌──────────────────────▼──────────────────────────────────┐
│  Shelf-Life Copilot 后端 (Python FastAPI)               │
│  ┌────────────┐  ┌────────────┐  ┌──────────────────┐  │
│  │ 监测引擎    │  │ AI 建议器   │  │ 卡片渲染 / 派单   │  │
│  │ (定时任务) │  │ (LLM 调用) │  │ (WeCom SDK)      │  │
│  └────────────┘  └─────┬──────┘  └──────────────────┘  │
└────────────────────────┼────────────────────────────────┘
                         │
                ┌────────▼─────────┐
                │  Anthropic API   │
                │  (Claude 4.x)    │
                └──────────────────┘

数据源（v0.1）：本地 Mock JSON
数据源（v0.5+）：对接客户 ERP / WMS（SAP / 用友 / 金蝶 / 自研）

技术栈：

后端：Python 3.11+ / FastAPI / APScheduler（定时任务）
LLM：Anthropic Python SDK（anthropic）
企微：企业微信群机器人 + 应用消息 API
存储（v0.1）：SQLite 或 JSON 文件
存储（v0.5+）：PostgreSQL

8. Mock Demo 范围（2 周交付）

8.1 交付物

周次	任务	产出
Week 1	企微 SDK 对接 + 卡片模板 + Mock 数据集	能向指定企微群推送一条临期预警卡片
Week 1	LLM 调用 + Prompt 工程	卡片中"建议动作"由 Claude 实时生成
Week 2	跑通客户 A（冷冻）和客户 B（预制菜）两套场景	两份 demo 流程各 3 张卡片，可现场演示
Week 2	编写 Demo 演讲稿	5 分钟现场讲解脚本，含 FAQ

8.2 Mock 数据样本

{
  "customerA_冷冻食品": {
    "mockAlerts": [
      {
        "material": "冷冻虾仁",
        "batchId": "2026-03-15",
        "expiryDate": "2026-06-14",
        "daysLeft": 19,
        "stockQty": "850kg",
        "suggestedAction": "转加工为虾饺馅",
        "estimatedSavings": 8500
      },
      {
        "material": "冷冻鱼糜",
        "batchId": "2026-03-10",
        "expiryDate": "2026-06-08",
        "daysLeft": 13,
        "stockQty": "520kg",
        "suggestedAction": "打折清仓",
        "estimatedSavings": 6200
      }
    ]
  },
  "customerB_预制菜": {
    "mockAlerts": [
      {
        "material": "预制青菜盒饭馅料",
        "batchId": "2026-05-24",
        "expiryDate": "2026-05-31",
        "daysLeft": 5,
        "stockQty": "200盒",
        "suggestedAction": "转为员工食堂",
        "estimatedSavings": 2400
      }
    ]
  }
}

节省金额算法（v0.1）：客户 A 单次平均 = 150 万 / 年 ÷ 180 批次 ≈ ¥8,333；客户 B 单次平均 = 86 万 / 年 ÷ 350 批次 ≈ ¥2,457。批次数估算后续按客户实际生产排期调整。

8.3 Demo 验收标准

能成功向企微群推送 1 条临期预警卡片
卡片中的"建议动作"由 LLM 实时生成（非硬编码）
点击 ✅ 同意 后，企微中可见"工单已转发给 XX 车间"的确认消息
客户 A、客户 B 两套场景的卡片样式 / 文案均跑通
总监看完 Demo 给出"逻辑对、可以用"的反馈

9. 成功指标

9.1 Demo 阶段（v0.1）

指标	目标
总监 Demo 后表示"愿意试点"	至少 1 家（A 或 B）
Demo 卡片在企微的渲染完整度	100%
LLM 建议在动作集合内的合规率	100%

9.2 试点阶段（v0.5）

指标	目标
AI 建议采纳率（同意 / 总推送）	≥ 60%
年化报损降低率	≥ 30%（客户 A 即从 150 万 → ≤ 105 万）
卡片日均推送量	5-15 条 / 客户
决策平均响应时长	≤ 30 分钟

10. Roadmap

版本	时间窗口	关键里程碑
v0.1 Mock Demo	2 周（~2026-06-09）	企微卡片 + LLM 建议跑通；客户 A、B 现场 Demo
v0.5 试点 PoC	6-8 周	对接客户 A 真实 ERP；3 个月完全免费跑；目标产出报损降低数据 + 客户背书，作为 v1.0 商业化的销售弹药
v1.0 商业版	3-4 个月	多租户 SaaS；动作集合可配置；自助接入向导。计价：固定年费按客户年损分档：< 100 万 = 8 万/年；100-300 万 = 15 万/年；> 300 万 = 议价（合同期 1 年）
v1.5 智能版	6 个月	跨批次联合优化；预测性采购建议；季度报告自动生成

11. 风险与开放问题

11.1 已识别风险

风险	影响	缓解策略
客户 ERP/WMS 接口异构	集成成本高	v0.1 用 Excel/JSON 导入兜底；v0.5 优先对接最主流 2-3 家
LLM 生成的"节省金额"被质疑不准	总监信任度下降	在卡片上明确标注"基于历史均值估算"，并展示算法来源
总监看不到效果 / 内部推不动	PoC 续签难	月度自动报告 + 累计省钱看板（仅总监可见）
数据安全（库存数据敏感）	客户合规担忧	v0.5 起支持私有化部署 / VPC 部署

11.2 已决策方案（2026-05-26 grill 收口）

#	议题	决策	决策依据
1	动作集合差异化	按客户级 JSON 配置启用子集（非行业模板、非物料级）。A/B 两份配置由实施工程师 Demo 前预填。	5 类动作中明确存在某家走不通的（如预制菜难以"转加工"成品、冷冻原料难以直接"转员工餐"），但差异不到需要按物料粒度配置。客户级 JSON 在灵活性与工作量之间最平衡。
2	"改方案"是否进 v0.1	进，但只做单轮重生成。越界请求 LLM 仍生成卡片，但加"⚠️ 非标准动作 · 需人工复核"标签。	Demo 现场总监必然挑战 AI 建议，零兜底会冷场；多轮对话 2 周交付不动。打标签兜底既不冷场也不失控。
3	月度报告形式	纯 PDF，企微文件 / 邮件下发。不做企微卡片摘要、不做 Web 看板（直到 v1.0 之后）。	受众明确是"总监 → 老板汇报材料"。老板要的是"体面、可打印、可邮件转发给非企微用户"，PDF 是企业汇报标配。
4	商业模式	试点（v0.5）3 个月完全免费；商业版（v1.0）固定年费按客户年损分档：< 100 万 = 8 万/年；100-300 万 = 15 万/年；> 300 万 = 议价。	试点核心目标是拿数据 + 背书，付费摩擦会拖慢 PoC。正式收费用客户年损做锚，对客户解释为"省钱的 7-10%"，逻辑透明、销售好讲；抽成模式因 baseline 难界定而弃用。

12. 立项决策清单（团队 Kick-off 用）

技术栈：Python FastAPI + Anthropic SDK + 企微 API（确认）
首批 Demo 客户：客户 A（冷冻）+ 客户 B（预制菜）（确认）
2 周交付 Mock Demo（确认起点日期）
Demo 演示形式：现场到客户公司 vs 远程视频会议（待定）
Anthropic API Key / 企微管理员权限 / Mock 客户企微测试群（准备）
年损快速诊断问卷（销售前置工具，为 v1.0 年费分档报价提供锚点；详见 §12.1）

12.1 年损快速诊断问卷（销售前置工具）

用途：销售首次接触客户时 5 分钟内完成。用于：

判断该客户落入 v1.0 哪个报价档（见 §10 Roadmap 分档表）
评估行业适配度与 KP 决策权
为 PoC 阶段定制客户专属的动作集合 JSON 配置提供输入

问卷题目（建议印成一页 A4 或做成飞书 / 金数据表单，销售当场填写）：

#	题目	选项 / 格式	用于
Q1	贵司主营产品品类？	冷冻原料 / 预制菜 / 烘焙 / 休闲食品 / 生鲜加工 / 其他	行业适配度 + 动作集合预设
Q2	年原料 / 半成品采购总额？	< 1 亿 / 1-5 亿 / 5-20 亿 / > 20 亿	规模锚定
Q3	原料 SKU 数大约多少？	< 200 / 200-1000 / 1000-5000 / > 5000	系统负载 + 实施工作量估算
Q4	主要原料平均保质期？	< 30 天 / 30-90 天 / 90 天-1 年 / > 1 年	预警频率与紧迫感校准
Q5	去年报损 / 临期处置金额？	< 50 万 / 50-100 万 / 100-300 万 / > 300 万 / 答不出（跳 Q6）	直接决定 v1.0 年费档位
Q6	（Q5 答不出时）每月发生几次"赶在过期前打折/转加工/报损"？单次平均价值多少？	次数 × 单次价值 = 估算月损 × 12	Q5 的代理估算
Q7	当前临期管理方式？	人工 Excel / ERP 报表 / 完全凭车间经验 / 已有专门工具	痛点强度评估
Q8	处置决策由谁拍板？	供应链总监 / 采购总监 / 生产总监 / 老板亲自 / 多人会签	KP 确认

销售现场分档对照（Q5 答完即报价）：

Q5 答案	推荐年费档	销售话术（白话版）
< 100 万	8 万 / 年	"您每年付 8 万，AI 帮您从 100 万以内报损里抠回 15-30 万 — 净赚 2-4 倍"
100-300 万	15 万 / 年	"您每年付 15 万，AI 帮您从 200-300 万报损里抠回 60-90 万 — 净赚 4-6 倍"
> 300 万	议价（建议起步 25 万）	走单独 ROI 测算 + 高管对接

话术口径说明：销售嘴上讲的"净赚 2-4 倍 / 4-6 倍"是全采纳假设（年损 × 30% 减损率 / 年费）。 ROI 一页纸 PDF 上印的 roi_multiple 用 60% 采纳率折扣（年损 × 60% × 30% / 年费），是诚实下限 — 销售嘴上有热度，PDF 上不背锅，3 个月 PoC 验收时按 PDF 口径核对。

优先级判定规则（用于 PoC 排队）：

⭐⭐⭐ 优先排进 PoC：Q7 = "完全凭车间经验" 且 Q8 = 单一总监决策
⭐⭐ 适合 PoC：Q7 = "人工 Excel" 且 Q8 = 单一总监
⭐ 谨慎评估：Q8 = "多人会签"（决策链太长，AI 建议会被层层稀释）
❌ 暂缓：Q7 = "已有专门工具"（替换成本高，除非客户主动表达不满）

问卷流转规则：

销售填完后 24 小时内同步实施工程师
实施据此预填该客户的 customer_<id>.actions.json（见 §5.2）
一份留存 CRM，作为后续合同议价的官方依据

文档维护人：（待填） 最近一次评审：2026-05-26

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Shelf-Life Copilot 产品规格文档

1. 产品定位

2. 解决的核心问题

3. 目标客户与决策人

3.1 首批锚定客户

3.2 决策人画像

4. 核心用户旅程

5. 核心功能模块（MVP）

5.1 模块一：临期监测引擎

5.2 模块二：AI 处置建议生成器

5.3 模块三：企微卡片交互层

5.4 模块四：工单流转

5.5 模块五：决策日志 & 复盘

6. AI 能力设计

6.1 模型选型

6.2 Prompt 框架（核心建议生成）

6.3 安全设计

7. 技术架构（v0.1）

8. Mock Demo 范围（2 周交付）

8.1 交付物

8.2 Mock 数据样本

8.3 Demo 验收标准

9. 成功指标

9.1 Demo 阶段（v0.1）

9.2 试点阶段（v0.5）

10. Roadmap

11. 风险与开放问题

11.1 已识别风险

11.2 已决策方案（2026-05-26 grill 收口）

12. 立项决策清单（团队 Kick-off 用）

12.1 年损快速诊断问卷（销售前置工具）

FilesExpand file tree

PRD.md

Latest commit

History

PRD.md

File metadata and controls

Shelf-Life Copilot 产品规格文档

1. 产品定位

2. 解决的核心问题

3. 目标客户与决策人

3.1 首批锚定客户

3.2 决策人画像

4. 核心用户旅程

5. 核心功能模块（MVP）

5.1 模块一：临期监测引擎

5.2 模块二：AI 处置建议生成器

5.3 模块三：企微卡片交互层

5.4 模块四：工单流转

5.5 模块五：决策日志 & 复盘

6. AI 能力设计

6.1 模型选型

6.2 Prompt 框架（核心建议生成）

6.3 安全设计

7. 技术架构（v0.1）

8. Mock Demo 范围（2 周交付）

8.1 交付物

8.2 Mock 数据样本

8.3 Demo 验收标准

9. 成功指标

9.1 Demo 阶段（v0.1）

9.2 试点阶段（v0.5）

10. Roadmap

11. 风险与开放问题

11.1 已识别风险

11.2 已决策方案（2026-05-26 grill 收口）

12. 立项决策清单（团队 Kick-off 用）

12.1 年损快速诊断问卷（销售前置工具）