# r1-pm.md · PM 主笔章节

**项目**: fba-smart-restock
**版本**: r1（PM 视角首稿，待 R2 跟架构师/工程师对齐）
**作者视角**: PM（为什么做 / 给谁做 / 做完算成功的标准）
**基础输入**: scene-anchor.md · proposal-v1.md · assumptions.md · debate-log.md · evidence/

---

## §1 项目背景与收益

### 1.1 需求简介

**一句话定位**：每天求解一次"200 SKU 的总收益最大化问题"，输出最优发货决策清单（哪些 SKU 补、补多少、走海运还是空运），并对缺货风险随时预警。

**这不是什么**（V0→V1 的关键重定位，依据：debate-log.md R2 企业家明示）：

- 不是"替代 Excel + 直觉"的 workflow 工具（V0 误解）
- 不是"省 15 分钟周报时间"的效率工具
- **是一台经济决策引擎**：用 50+ 维度的目标函数优化，做出人脑做不到的最优决策

核心目标函数（业务侧表述，数学形式见架构师章节）：

> **总收益 = 销售收入 − 资金占用成本 − FBA 仓储费 − 缺货损失 − 在途货物成本 − 运费**

人在系统里的价值：判断异常 + 修正模型 + 战略调整。机器的价值：消化 50+ 维度同时优化。

**v1 MVP 策略**（依据：scene-anchor §1.5，企业家拍板）：
- v1 用虚拟数据集 + 1-2 个真实 SKU "影子模式"（吸收 R1 商业评审 B1）
- 真实数据全量接入（FBA / 销量 / 货代报价 API）推迟到 v1.5
- v1 的核心任务是**验证决策引擎的逻辑可行性**，不是验证算法对真实业务的精度

### 1.2 收益预估

> ⚠️ 当前基线均为 _TBD_，企业家在 [OPEN_QUESTION OQ-1] 中需正面回答"年化决策提升收益规模"。下表数字均为 v1 设计目标 + 假设值，非承诺。

#### 1.2.1 用户收益（你/企业家本人）

| # | 收益项 | 量化 | 依据等级 | 依据来源 |
|---|--------|------|---------|---------|
| U1 | **缺货天数 / 月 / SKU 下降** | 当前 _TBD_ → 6 月目标 −50% / 12 月目标 −70% | E | scene-anchor §5.1，待企业家校准 |
| U2 | **平均库存周转天数下降** | 当前 _TBD_ → 6 月 −20% / 12 月 −30% | E | scene-anchor §5.1，待企业家校准 |
| U3 | **物流成本节省**（海/空运组合优化） | 6 月 −15% / 12 月 −25% | D | benchmark §三：landed cost 含缺货损失后 68% 补货场景空运更优；EOQ 应用得当降总库存成本 15-30%（来源：Finale Inventory） |
| U4 | **决策拍板时间** | 当前每周 2-3 小时 Excel → v1 每日 ≤ 5 分钟（含批量接受） | D | scene-anchor §5.2，吸收 R1 商业 B5 |
| U5 | **预警响应延迟** | 当前"几天后才发现缺货" → v1 < 1 小时推送 | D | scene-anchor §5.2 |

#### 1.2.2 业务收益（FBA 业务整体）

| # | 收益项 | 量化 | 依据等级 |
|---|--------|------|---------|
| B1 | **避免拍脑袋错误的金额** | 假设 200 SKU × 年错 5%-10% 决策 × 单次错误损失 = _TBD_ | E（待企业家用历史数据校准） |
| B2 | **FBA 长期仓储费节省** | _TBD_（v1.5 真实数据接入后量化） | E |
| B3 | **资金周转效率提升** | 库存价值占用 × 年化资金成本（假设 10%）× 周转天数缩短 = _TBD_ | D（行业基线，来源：assumptions A-002 强烈建议项校准） |

#### 1.2.3 不做的风险

| # | 风险项 | 量化 | 依据等级 |
|---|--------|------|---------|
| R1 | **SKU 规模扩大后人工决策必然崩盘** | 200 SKU → 500 SKU 时 Excel + 直觉模式时间成本指数上升 | D（scene-anchor §4.1） |
| R2 | **缺货损失隐性放大** | 缺货 1 天 = 销售额 × (1 + 排名恢复倍数 2-4) | C（亚马逊运营圈共识，来源：assumptions A-003、benchmark §3.5） |
| R3 | **错误的海/空运决策** | 该走海运的走空运 → 物流成本 5-10 倍；该走空运的走海运 → 错过补货窗口 | C（benchmark §3.2：空运按 kg 比海运贵 4-16 倍，来源：ExFreight 2026） |
| R4 | **订阅现成工具替代方案的局限** | SoStocked/Sellerboard 等只解"补多少+何时补"局部最优，不解 5 项完整目标函数 | C（competitors §三痛点 #4、#8） |

**收益论证的薄弱处**（诚实记录，待 R2 联席解决）：
- B1 / U1 / U2 / U3 当前基线全部 _TBD_，承诺"减 50%"在统计上无意义，必须在 v1 启动前先做 1 周历史数据回归校准 → 已写入 [OPEN_QUESTION OQ-1]
- 战略评审在 debate-log R3 提出："100 万全周期成本 vs 10 万订阅 + 助理" → 必须正面计算"5 分准确性差异 × 年化金额" → 企业家拍板

---

## §2 用户画像

### 2.1 用户角色矩阵

| 角色 | 是谁 | 在系统里做什么 | 使用频率 | 关键诉求 |
|------|------|--------------|---------|---------|
| **决策者（CEO）** | 企业家本人（FBA 卖家创始人，独自决策） | 每天 5 分钟看日报 / 拍板 / 批量接受 / 推翻调整 / 周复盘 | 每天 1 次（早 9:00） | 准确性、可解释、不被信息淹没 |
| **执行者（助理）** | 1 名采购/运营助理（可能是远程兼职） | 接收已拍板的发货清单 / 下单订船订机 / 状态回写 / 异常上报 | 每天 1-2 次 | 任务列表清晰、状态机简单、可否决 |
| **系统**（非人） | v1 算法 + 决策引擎 | 凌晨跑预测和优化、白天监控预警 | 24×7 | （此行只为说明边界，不计入用户画像） |

**单用户场景说明**（吸收 R1 商业 B2）：
- 决策者 = 使用者 = 1 人 → "决策建议接受率 70%" 在统计上无意义
- 改用"事后复盘正确率"作为反馈机制（FR-12 实现），每周 5 分钟 → 见 §8.3

### 2.2 明确不是谁

| 不是 | 理由 |
|------|------|
| ❌ 其他 FBA 卖家 | v1 自用；v1.5 才考虑 SaaS（依据：scene-anchor §6.3） |
| ❌ 工厂/采购方 | 上游下单不归本系统管（见 §6 不做） |
| ❌ 亚马逊运营人员 | 不替代 Listing 优化 / 广告投放 / 文案 |
| ❌ 财务 | 不做财务对账 |
| ❌ 大型多渠道卖家 | v1 只对 Amazon FBA，不含 Walmart/Shopify |

### 2.3 用户故事

> 每个 US 必须可被某条 FR 实现（引用见末尾括号）。

#### US-1（决策者 · 主流程）

> 作为 **FBA 卖家 CEO**，我希望每天早上 9:00 打开一份按总收益排序的发货清单，上面写明哪个 SKU 该补多少、走海运还是空运、为什么这么建议、预计带来多少收益，让我能在 5 分钟内拍板。
> （由 **FR-6 决策清单 + 可解释面板** 实现）

#### US-2（决策者 · 批量加速）

> 作为 **CEO**，对于系统置信度 ≥ 80% 的建议，我希望"批量一键接受"，不需要逐条点击；同时这些被一键接受的项必须在周复盘里被强制回顾。
> （由 **FR-6 批量接受 + FR-12 决策日志/事后正确率** 实现）

#### US-3（决策者 · 调整）

> 作为 **CEO**，当我不同意某条建议时，我希望能调整数量 / 改物流方式 / 跳过，系统立刻重算这条的 landed cost 和总收益影响。
> （由 **FR-6 拍板交互**实现）

#### US-4（决策者 · 缺货预警）

> 作为 **CEO**，当任何 SKU 库存跌破安全天数阈值、或销量异常上涨、或物流报价大幅波动时，我希望在 1 小时内收到预警推送（不是邮件，不是站内信，是会响的渠道）。
> （由 **FR-8 缺货+销量异常预警** 实现）

#### US-5（决策者 · 空清单的安心）

> 作为 **CEO**，大多数日子日报清单可能是空的（库存充足），我希望这种"无事可做"的早晨也能给我安心信号——"今日扫描 200 SKU、最近临界 SKU 还有 45 天"，而不是怀疑系统挂了。
> （由 **FR-6 空清单设计**实现，吸收 debate-log 设计 R1 D4）

#### US-6（决策者 · 60/90 天上游下单预警）

> 作为 **CEO**，我希望系统提前 60/90 天预警"工厂该下单了，否则会断货"，留出工厂产能和海运排期。
> （由 **FR-14 上游下单预警** 实现）

#### US-7（决策者 · 决策可解释）

> 作为 **CEO**，对每一条建议，我希望能在 1 分钟内看懂：背后哪些数据、哪些假设、关键参数变化 ±20% 决策会不会变。这样我才敢信。
> （由 **FR-6 可解释面板 + FR-5 灵敏度分析** 实现）

#### US-8（决策者 · 影子对照）

> 作为 **CEO**，v1 阶段我希望同步跑 1-2 个真实 SKU（影子模式），看系统在真实数据上的建议跟我的人工决策偏差有多大，证明算法值不值得在 v1.5 投入全量真实数据接入。
> （由 **FR-15 影子模式** 实现）

#### US-9（决策者 · Mock 与真实身份区分）

> 作为 **CEO**，因为 v1 主要在虚拟数据上跑，我需要 UI 明确告诉我"这是演练数据"还是"这是真实 SKU"——否则我可能照着虚拟建议去真实下单。
> （由 **FR-10 Mock/Real 模式切换 + UI 警示** 实现）

#### US-10（决策者 · 回测对比）

> 作为 **CEO**，在 v1 启动评审时，我希望看到一份"按系统建议执行 vs 保守策略 vs 激进策略"的 90 天回测总收益对比，证明系统建议显著优于另外两个。
> （由 **FR-11 三策略回测对比** 实现）

#### US-11（执行者 · 助理操作视图）

> 作为 **助理**，对于 CEO 已拍板的发货清单，我希望看到一个"待执行"任务列表，按下单截止时间排序，操作完后能勾选"已派单 / 执行中 / 已发货 / 已入仓"四个状态。
> （由 **FR-7 助理操作视图 + 状态回写** 实现）

#### US-12（执行者 · 助理 24h 否决权）

> 作为 **助理**，对于批量被 CEO 一键接受的建议，如果我在执行过程中发现明显不合理（如海运报价已过期、SKU 实际有质量问题），我有 24 小时窗口把这一条退回 CEO 复核，而不是必须执行。
> （由 **FR-7 助理操作视图 + FR-12 决策日志责任回路** 实现，吸收 debate-log 商业 R3）

#### US-13（决策者 · 周复盘）

> 作为 **CEO**，每周用 5 分钟看一份"上周决策回顾"——批量接受的清单、被推翻的清单、事后正确率统计，作为模型迭代的反馈。
> （由 **FR-12 决策日志 + 事后正确率统计** 实现）

---

## §8 成功度量

### 8.1 北极星指标

> ⚠️ 当前基线在 v1 启动前必须由企业家用历史数据填实，否则"减 50%"承诺无意义。

| 指标 | 当前基线 | 6 月目标 | 12 月目标 | 验证方法 | 对应 §1.2 收益 |
|------|---------|---------|----------|---------|--------------|
| **缺货天数 / 月 / SKU** | _TBD_ | −50% | −70% | 系统统计（v1 在虚拟数据上验证，v1.5 在真实数据上验证） | U1, B1, R2 |
| **平均库存周转天数** | _TBD_ | −20% | −30% | 库存历史回算 | U2, B3 |
| **物流成本节省**（海/空运组合 vs 当前策略） | _TBD_ | −15% | −25% | 同期对比 | U3, R3 |
| **系统建议带来的"总收益"提升**（相对保守策略） | 0（保守策略 = baseline） | +10%（v1 在虚拟数据回测） | +15%（v1.5 真实数据 90 天） | FR-11 三策略回测 | B1 |

### 8.1.1 用户体验指标（对应 User Goals）

| 指标 | 当前基线 | v1 目标 | v1.5 目标 | 对应 User Story | 对应 §1.2 收益 |
|------|---------|---------|----------|---------------|--------------|
| **CEO 拍板时间 / 日** | 当前每周 2-3 小时 Excel → 日均 ~20 分钟 | ≤ 5 分钟（含批量接受） | ≤ 3 分钟 | US-1, US-2 | U4 |
| **预警响应延迟**（从触发到 CEO 收到推送） | 几天后才发现 | < 1 小时 | < 15 分钟 | US-4 | U5 |
| **空清单日的"安心信号"完成度**（用户自评 1-5） | N/A | ≥ 4 | ≥ 4.5 | US-5 | U4 |
| **决策可解释面板的"看懂时间"** | N/A | 1 分钟内看懂 | 30 秒 | US-7 | U4 |
| **影子模式偏差解释率**（系统建议 vs 人工决策的偏差能被解释清楚） | N/A | ≥ 80% | N/A（v1.5 全量真实） | US-8 | B1 |

### 8.2 v1 验证指标（虚拟 + 影子）

吸收 proposal-v1 §6 + debate-log R3 工程评审"加技术 spike"。

| 验证项 | 方法 | 通过标准 |
|--------|------|---------|
| **决策合理性** | 虚拟数据集 + 1-2 真实 SKU 影子 90 天回测 | 系统建议总收益 > 保守策略 > 激进策略（按行业经验合理排序） |
| **灵敏度健壮性** | 关键参数（缺货损失系数 2-8、资金成本率 ±20%）扰动 | 核心决策稳定率 > 70% |
| **可解释性** | 用户在决策面板上 1 分钟内能看懂每条建议的逻辑 | 用户自评（CEO 本人 ≥ 4/5） |
| **影子模式契合度** | 1-2 个真实 SKU 90 天对比 | 系统建议 vs 用户实际决策的偏差能被解释（不是"差异为 0"，是"差异有合理原因"） |
| **运营成本** | CEO 拍板时间 | ≤ 5 分钟 / 日 |
| **空清单可信度** | 连续 5 天空清单后用户仍信任系统 | CEO 自评 |

### 8.3 上线后验收（v1 上线 + 4 周）

| 验收项 | 方法 | 通过标准 |
|--------|------|---------|
| **事后正确率**（替代 V0 的"接受率 70%"，吸收商业评审） | 每条建议 vs 实际结果对比 | ≥ 60%（v1 起点）→ 12 月 ≥ 75% |
| **批量接受清单的周复盘** | CEO 每周 5 分钟回顾批量清单中是否有"事后看明显错误"的 | 错误率 < 10% |
| **助理 24h 否决权使用率** | 助理退回率 | 5%-15%（过高说明 CEO 拍板太草率；过低说明助理不敢退） |
| **预警准确率**（不是误报） | 预警触发后 SKU 实际是否发生预测的状况 | ≥ 70% |
| **每日日报"非空率"** | 90 天观察 | 30%-70%（>70% 说明阈值太宽，<30% 说明频率过高） |
| **mock vs real UI 区分有效性** | CEO 是否曾把 mock 建议误用于真实下单 | 0 次 |

---

## §10 验收标准（业务场景）

> 技术兼容矩阵 / 性能预算 / 求解器 / Schema 在工程师章节，本节只写业务场景验收。

### 10.1 主流程

#### S-10.1.1 早上 9:00 看日报并拍板

**前置条件**：凌晨系统已跑完预测和优化，日报已生成。

| 步骤 | 用户操作 | 系统行为 | 通过标准 |
|------|---------|---------|---------|
| 1 | CEO 9:00 打开系统 | 显示今日决策清单（按总收益贡献排序） | 加载 ≤ 3 秒 |
| 2 | CEO 查看第一条建议 | 展示：SKU / 推荐数量 / 物流方式 / 预计总收益 / 置信度 / 推荐理由 | 1 分钟内看懂 |
| 3 | CEO 点击"展开" | 展示成本/收益分解（销售收入 / 资金占用 / 仓储费 / 缺货损失 / 在途成本 / 运费 6 项） + 灵敏度 ±20% 时决策是否变化 | 数据完整 |
| 4 | CEO 接受建议 | 该条进入"待执行"队列、助理视图、系统记录决策日志 | 状态切换正确 |
| 5 | CEO 对置信度 ≥ 80% 的项目"批量一键接受" | 全部进入待执行队列、批量清单加入周复盘必看 | 责任回路完整 |
| 6 | 全部处理完 | 显示"今日处理完毕 / 待执行 N 条" | 清晰收尾 |

#### S-10.1.2 空清单的早晨

**触发条件**：今日所有 SKU 库存充足、无补货建议。

| 步骤 | 系统行为 | 通过标准 |
|------|---------|---------|
| 1 | 不显示"空白" | 显示"今日扫描 200 SKU、无补货建议" |
| 2 | 显示"安心信号" | 最近临界 SKU 还有 X 天（X 应是次临界 SKU 距离阈值的天数） |
| 3 | 显示"过去 7 天回顾" | 已发货 N 条、平均决策准确率、累计节省金额（估算） |
| 4 | 用户自评 | 连续 5 天空清单后用户仍信任系统（来源：debate-log 设计 R1 "最担心的事"） |

#### S-10.1.3 助理执行

| 步骤 | 用户操作 | 系统行为 | 通过标准 |
|------|---------|---------|---------|
| 1 | 助理 9:30 打开操作视图 | 显示按截止时间排序的待执行任务 | 排序正确 |
| 2 | 助理下单订船 | 勾选状态："已派单" | 状态回写到主系统 |
| 3 | 货代发货 | 助理勾选"执行中" → "已发货" | CEO 视图可见 |
| 4 | 助理发现批量接受中某条不合理 | 在 24h 内退回到 CEO 复核 | 进入 CEO 异常队列 |
| 5 | FBA 入仓 | 助理勾选"已入仓" | 系统记录 lead time 实际值，校准模型 |

### 10.2 异常分支

#### S-10.2.1 凌晨任务挂了，9:00 用户打开看到什么

**触发条件**：凌晨预测/优化任务失败、超时、或数据源不通。

| 场景 | 系统行为 | 通过标准 |
|------|---------|---------|
| 数据源不通 | 显示"今日数据未更新（最后一次更新：昨晚 23:12）" + "暂不推荐拍板" + 预计修复时间 | 不静默给陈旧建议 |
| 求解超时 | 显示"今日决策未跑完" + "已用昨日清单 + 缺货预警继续监控" | 降级方案明确 |
| 部分 SKU 计算失败 | 标记失败 SKU + 其余正常显示 | 不全盘失败 |

#### S-10.2.2 缺货预警插队

**触发条件**：白天任何时刻 SKU 库存跌破安全天数阈值。

| 步骤 | 系统行为 | 通过标准 |
|------|---------|---------|
| 1 | 监控发现库存跌破阈值 | 触发推送（不依赖日报节奏） | ≤ 1 小时延迟 |
| 2 | 推送到 CEO 选定渠道（企微 / Bark / Telegram，依据：debate-log 商业 B6） | 一条消息（不是 5 条） | 同一 SKU 24h 内不重复推 |
| 3 | CEO 点击推送 | 跳转到该 SKU 的紧急决策面板 | 含一键空运补货按钮 |

#### S-10.2.3 销量异常上涨

| 步骤 | 系统行为 | 通过标准 |
|------|---------|---------|
| 1 | 监控发现某 SKU 销量异常上涨（比如广告投放生效） | 推送 + 标记"销量异常" | 准确率 ≥ 70%（验收：8.3） |
| 2 | CEO 查看 | 显示销量曲线 + 广告投放叠加 + 系统建议（是否补货 + 数量上调） | 含理由 |

#### S-10.2.4 物流报价大幅变化

| 步骤 | 系统行为 | 通过标准 |
|------|---------|---------|
| 1 | 监控发现海/空运报价 ±X%（X 待定） | 推送 + 重新跑当日优化 | 影响今日决策的 SKU 标红 |

### 10.3 状态切换

#### 10.3.1 单条建议状态机

```
[新建议] → [待 CEO 拍板] → [接受/调整/跳过]
                                ↓ 接受
                          [待助理执行]
                                ↓
                          [助理已派单]
                                ↓
                          [执行中（在途）]
                                ↓
                          [已发货]
                                ↓
                          [已入仓 → 系统校准 lead time]

异常分支:
[待助理执行] → [助理 24h 内退回] → [CEO 复核] → [接受/取消]
```

#### 10.3.2 Mock vs Real 模式切换

| 切换前 | 切换后 | 通过标准 |
|--------|--------|---------|
| Mock 模式（顶部斑马条 + "演练数据"标签） | Real 模式（影子 SKU，正常皮肤 + "真实数据"绿标） | 切换需 CEO 二次确认 |
| Real 模式 | Mock 模式 | 切换需 CEO 二次确认（防误操作） |

### 10.4 兼容性（业务层）

> 技术兼容矩阵（浏览器版本/操作系统/数据格式）在工程师章节。本节只写业务层兼容。

| 兼容项 | 业务要求 | 依据 |
|--------|---------|------|
| **数据来源** | v1 虚拟数据 + 1-2 影子 SKU 真实数据；v1.5 全量 Amazon Seller Central API | scene-anchor §1.5 |
| **决策频率** | v1 每日 1 次日报 + 事件触发预警；[OPEN_QUESTION OQ-4]：商业评审建议改"事件触发+周节奏"，待企业家拍板 | debate-log R3 |
| **SKU 规模** | v1 支持 200 SKU；v1.5 不承诺扩展（如做 SaaS 是另立项目） | scene-anchor §2 |
| **物流方式** | v1 仅海运 / 空运二选；不含铁路、海运快船等中间档 | proposal-v1 §1.2 |
| **推送渠道** | v1 企微应用 / Bark for iOS / Telegram 任选其一（CEO 配置）；不用微信个人号（合规风险） | debate-log 商业 B6 |
| **助理协同** | 单助理；多助理不在 v1 | proposal-v1 FR-7 |
| **语言** | 中文界面（卖家是国内）；SKU 名称支持中英文混排 | benchmark §四：现有工具中国卖家适配差 |
| **货币** | 美元（FBA 业务）+ 人民币（采购成本）双币种显示 | competitors §四：中国卖家本地化空白 |

### 10.5 回归影响（业务层）

> 因为这是新建系统、v1 自用，回归影响主要看"v1 的虚拟数据决策是否影响 CEO 的真实决策习惯"。

| 影响域 | 业务层风险 | 缓解措施 |
|--------|----------|---------|
| **CEO 决策习惯** | 看 v1 mock 数据看多了，对真实业务的直觉感被弱化 | FR-10 Mock/Real 模式 UI 强警示；周复盘强调"mock 不代表真实" |
| **助理工作流** | v1 引入新工作流，原 Excel 流程是否保留？ | v1 期间双轨：Excel + 新系统并行 4 周，4 周后切单轨 |
| **CEO 心智模式**（debate-log 战略 R3 提出） | 每天早上第一件事看库存日报，可能把 CEO 锁死在"运营者"心智，影响"洞察者"产出 | [OPEN_QUESTION OQ-3]，待企业家自评；缓解：批量接受 + 5 分钟硬上限 |
| **影子 SKU 的真实订单** | v1 影子建议如果被误执行 = 资金事故 | FR-10 UI 强警示 + 影子模式下"接受"按钮需二次确认 |
| **数据一致性**（v1.5 切真实数据时） | mock schema 与真实 API schema 不一致导致大重构 | FR-1 v1 数据 schema 按真实 FBA API 反向设计（吸收工程 T7） |

---

## §11 依据清单

### 11.1 用户依据

| # | 用户判断 | 依据等级 | 来源 |
|---|---------|---------|------|
| UE-1 | 决策者 = 使用者 = 企业家本人，独自决策 | A | scene-anchor §2，企业家自述 |
| UE-2 | 助理是真正的执行人，v1 必须解决 | C | debate-log 商业 B4，设计 R1 D7 共识 |
| UE-3 | "每日决策"频率（vs 周/事件触发）是企业家指示 | A | scene-anchor §3.1 + assumptions A-006 |
| UE-4 | CEO 每天 5 分钟拍板的时间预算 | D | scene-anchor §5.2，吸收 R1 商业 B5 |
| UE-5 | 单用户场景下"接受率 70%" 是空口承诺 → 改为"事后复盘正确率" | C | debate-log 商业 B2，工程 🟢 建议 |

### 11.2 竞品依据

| # | 竞品判断 | 依据 | 来源 |
|---|---------|------|------|
| CE-1 | 现有工具（SoStocked / RestockPro / Helium 10 / Sellerboard）只解"补多少+何时补"局部最优，不解 5 项完整目标函数 | competitors §三痛点 #4：海空运决策没做 / 痛点 #8：缺乏可解释性 | competitors.md |
| CE-2 | 海空运决策结合 + 决策可解释性 = 蓝海机会 | competitors §四 4.1 蓝海机会 #1 #2 | 同上 |
| CE-3 | 中国卖家本地化（人民币 / 1688 / 国内货代）现有工具普遍差 | competitors §三痛点 #7 | 同上 |
| CE-4 | "黑盒算法 FBA 卖家被骗多了，不信" | competitors §五"必须避免的"#3 | 同上 |

### 11.3 行业 Benchmark

| # | 行业判断 | 依据 | 来源 |
|---|---------|------|------|
| IE-1 | 缺货损失 = 缺货天数 × 日销额 × (1 + 排名恢复倍数 2-4) | benchmark §3.5 | https://www.exfreight.com/air-freight-vs-ocean-freight-cost-transit-decision-framework/ |
| IE-2 | 总 landed cost 含缺货损失后，68% 补货/促销场景空运实际更优 | benchmark §3.3 | Unicargo 2026-03 |
| IE-3 | 空运按 kg 贵海运 4-16 倍 | benchmark §3.2 | ExFreight 2026 |
| IE-4 | FBA 长期仓储费：库龄 >365 天 $6.90/立方英尺 | benchmark §4.1 | Amazon 2026 费率 |
| IE-5 | EOQ 应用得当可降总库存成本 15-30% | benchmark §1.2 | Finale Inventory |
| IE-6 | Safety Stock 典型为 10-30 天销量 | benchmark §1.2 | eComEngine RestockPro |
| IE-7 | 服务水平目标 95-99% 缺货率 | benchmark §1.2 | 通用零售 |
| IE-8 | BSR + Ad Spend 联动是区分"自然需求"和"投放驱动需求"的关键 | benchmark §2.3 | sell.amazon.com |
| IE-9 | 海运中国→美西 25-32 天 / 美东 35-42 天；空运 2-14 天 | benchmark §3.1 | 综合 |

### 11.4 内部假设

> 来源：assumptions.md 全部假设条目（A-001 至 A-007）

| # | 假设 | 等级 | 风险 |
|---|------|------|------|
| A-001 | 销量预测准确度 < 25%（v1 在虚拟数据上易达到，v1.5 真实数据待验证） | E | 🔴 |
| A-002 | 海空运报价能实时获取（v1 推迟到 v1.5） | D | 🟠 |
| A-003 | 缺货损失 ≈ 3-5 倍直接销售额 | C | 🟠 |
| A-004 | 建议接受率 > 70%（已被推翻 → 改为事后复盘正确率） | E | 🟠 |
| A-005 | 200 SKU 适合单一决策模型 | E | 🟡 |
| A-006 | 每日决策频率合理（[OPEN_QUESTION OQ-4]：商业评审挑战要改周/事件） | D | 🟡 |
| A-007 | 缺货成本 >> 库存成本 | D | 🟡 |

**v1 需要的额外假设值**（assumptions.md 待量化项）：
- 年化资金成本率：假设 10%（行业基线，v1.5 财务真实校准）
- FBA 月仓储费：按 SKU 体积/月模拟（v1.5 真实费率）
- 缺货损失系数：2-8 区间灵敏度分析（FR-5），不固定 3-5

### 11.5 辩论记录

> 来源：debate-log.md

| # | 辩论结论 | 影响章节 |
|---|---------|---------|
| DE-1 | V0→V1 重定位（"补货 workflow 工具" → "经济决策引擎"） | §1.1 |
| DE-2 | 加"影子模式" FR-15 化解 R1 工程 T1（虚拟数据自欺） | US-8, §10.4 |
| DE-3 | 改"事后复盘正确率"替代"接受率 70%" | §8.3, US-13 |
| DE-4 | 助理 FR-7 从 v1.5 提前到 v1 必做 | US-11, US-12 |
| DE-5 | "批量接受 80%+" + 助理 24h 否决权 + 周复盘必看 = 责任回路 | US-2, US-12 |
| DE-6 | 微信合规问题 → 改企微/Bark/Telegram | §10.2.2, §10.4 |
| DE-7 | [OPEN_QUESTION OQ-1] 至 [OQ-5] 待企业家正面回答 | §1.2, §10.4, §10.5 |

#### 5 个 OPEN_QUESTION 索引（待 R2 企业家拍板）

| # | 分歧 | PM 倾向 | 影响章节 |
|---|------|--------|---------|
| OQ-1 | ROI 算式：年化决策提升收益 vs 100 万全周期成本 | 必须用历史数据先做 1 周回归校准，再决定是否投入 | §1.2 全部 |
| OQ-2 | 影子模式：1-2 SKU vs 20+ SKU | 商业评审"高/中/低三档各 1-2 + 主动选近期缺货事故 SKU" 是更可行折中 | US-8, §10.4 |
| OQ-3 | CEO 心智锁死风险（每天看日报 vs 写第三本书） | 用"5 分钟硬上限 + 批量接受 + 助理承接"缓解，不取消 | §10.5 |
| OQ-4 | 每日 vs 事件触发+周 | PM 倾向保留"每日扫描 + 事件触发预警 + 空清单也展示安心信号"——但日报阈值要保证非空率 30%-70% | §8.3 |
| OQ-5 | LP→MINLP 工程难度 ×2，团队配置 1+1 不够 | 不在 PM 边界，由架构师/工程师答 | （转架构师） |

---

## ⚠️ 待 R2 跟其他主笔对齐的章节边界

下面列出 PM 视角已写、但可能跟架构师/工程师有冲突或边界模糊的地方，方便 R2 联席：

### 边界 B-1：§8.1 北极星指标中"v1 在虚拟数据回测 +10%"

- **PM 视角**：把"系统建议总收益 vs 保守策略" 作为 v1 核心验收数字
- **可能冲突**：架构师可能认为"虚拟数据是自己出题自己答，不能作为北极星"（debate-log 战略 R3 / 工程 T1 残留风险）
- **R2 联席建议**：北极星指标里加一行"v1 验收以三策略相对排序合理 + 影子 SKU 偏差可解释为准"，不只是"系统赢 +10%"

### 边界 B-2：§10.2.1 凌晨任务挂了的降级方案

- **PM 视角**：业务层要求"不静默给陈旧建议"
- **可能冲突**：架构师/工程师对"降级方案"的实现成本可能挑战（双轨调度、状态机复杂度）
- **R2 联席建议**：让架构师确认这是 v1 必做 vs v1.5

### 边界 B-3：§10.2.2 预警延迟 < 1 小时

- **PM 视角**：US-4 要求 < 1 小时
- **可能冲突**：工程评审 T4 指出 SLA 在 scene-anchor / proposal 不一致（15 分钟 vs 1 小时）；工程现实可能更长
- **R2 联席建议**：让工程师拍板 SLA 实际承诺值，PM 不强行写 1 小时

### 边界 B-4：§10.4 推送渠道（企微/Bark/Telegram）

- **PM 视角**：v1 业务要求"任选其一，CEO 配置"
- **可能冲突**：设计评审 R3 指出"多通道 = UX 灾难，必须心智统一"；工程实现 3 个渠道 vs 1 个差很多
- **R2 联席建议**：v1 先实现 1 个（推荐 Bark，最便宜最合规），其他延后

### 边界 B-5：§10.5 v1 双轨运行 Excel + 新系统 4 周

- **PM 视角**：业务层要求"4 周后切单轨"
- **可能冲突**：商业评审 R3 指出"v1 用 mock 拿不到真实销量对比 → 周复盘等于自言自语"
- **R2 联席建议**：v1 双轨期延长到 v1.5 真实数据接入完，期间复盘机制需重新设计

### 边界 B-6：§10.4 业务层兼容 vs 工程师 §10 技术兼容矩阵

- **PM 视角**：本节只写"决策频率 / SKU 规模 / 物流方式 / 推送渠道 / 助理协同 / 语言 / 货币"
- **不写**：浏览器版本、操作系统、Schema 兼容、API 版本、性能基准
- **R2 联席**：确认工程师 §10 不重复 PM 已写的业务层兼容，避免冲突

### 边界 B-7：§8.1 北极星指标中"基线 _TBD_"

- **PM 视角**：v1 启动前必须由企业家用历史数据填实
- **可能冲突**：架构师/工程师可能认为"数据未准备好就不能开工"
- **R2 联席建议**：把"基线填实"作为 v1 启动的 Gate 1，未通过不进入正式开发

### 边界 B-8：US-7 "决策可解释" 1 分钟看懂

- **PM 视角**：用户故事要求
- **可能冲突**：设计评审 R3 指出"目标函数显性化 ≠ 用户能看懂，一屏 6 个数字 + 灵敏度 + 区间 + 置信度认知负荷比 V0 高 3 倍"
- **R2 联席建议**：让设计/前端架构师补"信息分层 wireframe"（30 秒摘要 → 5 分钟分解 → 数学详情），PM 验收用三层结构而不只看"1 分钟"

---

**PM 边界声明**：本文档只覆盖 §1 §2 §8 §10.1-10.5 §11，不涉及系统架构、技术栈、Schema、求解器、性能预算、测试细节、算法实现。这些由架构师/工程师主笔。