# r3-pm.md · PM R3 修订版

**项目**: fba-smart-restock
**版本**: r3（PM 根据 R2 架构师 / 工程师 review 修订）
**作者视角**: PM
**基础输入**: r1-pm.md + r2-architect-reviews-others.md（针对 PM 章节部分）+ r2-engineer-reviews-others.md（针对 PM 章节部分）

---

## §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 设计目标 + 假设值，非承诺。
>
> **R3 新增声明（吸收工程 E-PM-4）**：v1 在 mock 数据上的指标 ≠ v1.5 真实数据上的指标。v1.5 真实数据上的指标会显著保守于 v1 mock（mock 生成器的预测难度被人为压低）。所有指标分 v1 (mock) / v1.5 (real) 两列；v1 数字仅作为"决策引擎逻辑可行性"验证，不作为真实业务承诺。

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

| # | 收益项 | v1 (mock + 影子) 目标 | v1.5 (真实) 目标 | 依据等级 | 依据来源 |
|---|--------|----------------------|------------------|---------|---------|
| U1 | **缺货天数 / 月 / SKU 下降** | mock 上 −50%（仅验证决策逻辑） | 真实 6 月 −20% / 12 月 −35% | E | scene-anchor §5.1，待企业家校准 |
| U2 | **平均库存周转天数下降** | mock 上 −20% | 真实 6 月 −10% / 12 月 −20% | E | scene-anchor §5.1 |
| U3 | **物流成本节省**（海/空运组合优化） | mock 上 −15% | 真实 6 月 −8% / 12 月 −15% | D | benchmark §三：68% 补货场景空运更优；EOQ 应用得当降总库存成本 15-30%（Finale Inventory） |
| U4 | **决策拍板时间** | v1 每日 ≤ 5 分钟（含批量接受） | v1.5 ≤ 3 分钟 | D | scene-anchor §5.2 |
| U5 | **预警响应延迟** | v1 P95 ≤ 15 min / 硬上限 ≤ 30 min | v1.5 P95 ≤ 5 min | D | scene-anchor §5.2；R3 已与架构/工程统一口径，见 §10.2.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 |
| R3 | **错误的海/空运决策** | 该走海运的走空运 → 物流成本 5-10 倍；该走空运的走海运 → 错过补货窗口 | C |
| R4 | **订阅现成工具替代方案的局限** | SoStocked/Sellerboard 等只解"补多少+何时补"局部最优，不解 5 项完整目标函数 | C |

**收益论证的薄弱处**（诚实记录）：
- B1 / U1 / U2 / U3 当前基线全部 _TBD_，承诺"减 50%"在统计上无意义 → [OPEN_QUESTION OQ-1] v1 启动前必须做 1 周历史数据回归校准
- 战略评审 debate-log R3："100 万全周期成本 vs 10 万订阅 + 助理" → 必须正面计算"5 分准确性差异 × 年化金额" → 企业家拍板
- **R3 新增**：mock 数据指标会高估真实表现 → v1.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
- **R3 新增（吸收工程 E-PM-3）**：事后正确率**仅在影子 SKU 真实数据上计算**，不在 mock 上算（mock 上算"结构相似性"即可），样本数标注"分子分母"

### 2.2 明确不是谁

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

### 2.3 用户故事

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

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

> 作为 **FBA 卖家 CEO**，我希望每天早上 9:00 打开一份按总收益排序的发货清单，上面写明哪个 SKU 该补多少、走海运还是空运、为什么这么建议、预计带来多少收益，让我能在 5 分钟内拍板。
> （由 **FR-6 决策清单 + 可解释面板** 实现）
>
> **R3 注（响应工程 E-ARCH-4 跨时区问题）**：日报"今日"= 昨日美西全天 + 今日截至 BJ 9:00 的实时库存增量。日报必须在 BJ 9:00 前生成，跨时区时刻锁定由架构/工程负责实现。

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

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

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

> 作为 **CEO**，当我不同意某条建议时，我希望能调整数量 / 改物流方式 / 跳过，**系统立即显示这一条决策的成本变化（landed cost / 预估收益）；置信度沿用上次批跑值并标注"调整数量后此值仅供参考"**。如需重新计算全局最优，等下次批跑。
> （由 **FR-6 拍板交互**实现；UI 必须显式提示"局部重算 vs 全局最优"差异）
>
> **R3 修订说明（接受架构师 P-A4 + 工程 E-A3）**：原 US-3 写"立刻重算 landed cost 和总收益影响"会被读者理解为"系统重跑全局优化"，实际架构层只能做单 SKU 局部重算（200ms 内）。置信度变化无法在 200ms 内重算（需 30-60s 的灵敏度 heuristic）。本次修订把语义讲清楚，避免给用户误期待。

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

> 作为 **CEO**，当任何 SKU 库存跌破安全天数阈值、或销量异常上涨、或物流报价大幅波动时，我希望**P95 ≤ 15 分钟、硬上限 ≤ 30 分钟**收到预警推送（不是邮件，不是站内信，是会响的渠道）。
> （由 **FR-8 缺货+销量异常预警** 实现）
>
> **R3 修订说明（解决三方 SLA 不一致）**：原文"1 小时"是 PM 最初的保守估计；架构 §6.3.3 实测扫描周期 15min，工程 §5.9 已承诺 ≤ 15min。PM 视角校验：用户场景需要"看到推送时还来得及做空运补救" → 海运 25-42 天、空运 2-14 天 → 30 min vs 1h 的差异对补货窗口影响不大，但 15 min vs 1 h 对"是否能在当天工作时间内联系货代"有差异。综合三方意见，最终承诺 **P95 ≤ 15 min（监控扫描 15 min + 推送）/ 硬上限 ≤ 30 min（含一次 fallback 重试）**。这是可测 AC，QA 按此验收。

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

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

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

> 作为 **CEO**，我希望系统提前 60/90 天预警"该考虑给工厂下单了，否则有断货风险"。**v1 仅输出"X 天后该下单 + 建议数量"，不计算工厂产能/起订量/排期（这些需要供应商主数据，留 v1.5）**。我看到预警后，手工去联系工厂确认产能。
> （由 **FR-14 上游下单预警** 实现）
>
> **R3 修订说明（接受架构师 P-A6）**：原文"留出工厂产能和海运排期"暗含需要 `supplier` 实体（含 lead_time / MOQ / capacity），但 v1 自用 200 SKU 不值得为此建立完整供应商主数据。v1 退化到"只输出建议数量 + 日历提醒"，与工程 §5.16 现状一致。`supplier` 实体留 v1.5（连带海运排期 API）。

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

> 作为 **CEO**，对每一条建议，我希望面板按**三层信息架构**呈现，**任意一层能在 30-60 秒内消化**：
> - **L1 摘要（30 秒）**：SKU / 推荐数量 / 物流方式 / 预计总收益 / 置信度
> - **L2 分解（1-2 分钟）**：6 项成本/收益分解（销售收入 / 资金占用 / 仓储费 / 缺货损失 / 在途成本 / 运费）+ 关键参数 ±20% 决策稳定性
> - **L3 数学详情（按需展开）**：目标函数细节、灵敏度区间、参数版本号
>
> （由 **FR-6 可解释面板 + FR-5 灵敏度分析** 实现）
>
> **R3 修订说明（响应工程 E-PM-2 + 设计评审 R3）**：原文"1 分钟内看懂"是不可测的单一时间指标；R3 改为"三层信息架构 + 每层独立验收"。验收指标改为行为可观测（见 §8.1.1）：CEO 抽样复述 L2 6 项分解中能命中 ≥ 4 项 = 通过。

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

> 作为 **CEO**，v1 阶段我希望同步跑 1-2 个真实 SKU（影子模式），看系统在真实数据上的建议跟我的人工决策偏差有多大。
> （由 **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 已拍板的发货清单，我希望看到一个"待执行"任务列表，按下单截止时间排序，操作完后能勾选"已派单 / 执行中 / 已发货 / 已入仓"四个状态。**助理视图不显示 unit_cost / expected_profit / 利润率等敏感字段**。
> （由 **FR-7 助理操作视图 + 状态回写** 实现）

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

> 作为 **助理**，对于批量被 CEO 一键接受的建议，如果我在执行过程中发现明显不合理（如海运报价已过期、SKU 实际有质量问题），我有 24 小时窗口把这一条退回 CEO 复核。退回后该建议状态变为 `pending_review`（与全新待决策的 `pending` 区分），CEO 在主面板上看到独立的"待复核"分区。
> （由 **FR-7 助理操作视图 + FR-12 决策日志责任回路** 实现）
>
> **R3 修订说明（接受架构 P-A5）**：原文"CEO 复核"是模糊的业务表述，三方文档对状态命名不一致（PM "CEO 复核" / 架构 "pending" / 工程 "pending_review"）。R3 统一采用工程师的 `pending_review`，§10.3.1 状态机同步更新。

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

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

---

## §8 成功度量

### 8.1 北极星指标

> ⚠️ 当前基线在 v1 启动前必须由企业家用历史数据填实。
>
> **R3 关键修订**：
> 1. 北极星按 **v1 (mock + 影子) / v1.5 (真实)** 两列分开承诺（吸收工程 E-PM-4）
> 2. "+10% 总收益"由 **FR-11 三策略回测 + 架构师新建的 `backtest_trajectory` 表统计**（吸收架构师 P-A1，需架构师在 §4 补表）

| 指标 | 当前基线 | v1 (mock + 影子) 6 月 | v1.5 (真实) 12 月 | 验证方法 | 对应 §1.2 收益 |
|------|---------|-----------------------|-------------------|---------|--------------|
| **缺货天数 / 月 / SKU** | _TBD_ | mock 上 −50%（仅证逻辑可行） | 真实 −35% | 系统统计；v1 mock 数据上仅用于验证算法逻辑，v1.5 真实数据上是真实承诺 | U1, B1, R2 |
| **平均库存周转天数** | _TBD_ | mock 上 −20% | 真实 −20% | 库存历史回算 | U2, B3 |
| **物流成本节省** | _TBD_ | mock 上 −15% | 真实 −15% | 同期对比 | U3, R3 |
| **系统建议带来的"总收益"提升**（相对保守策略） | 0（保守策略 = baseline） | +10%（v1 mock 回测） | +15%（v1.5 真实 90 天） | FR-11 三策略回测，从 `backtest_trajectory` 表统计（架构师 §4 需补此表） | B1 |

**北极星补充验收**（接受架构师 P-A1 + 自评 B-1）：
- 单看"+10%"不够，v1 验收必须同时满足"三策略相对排序合理"（系统 > 保守 > 激进 或 系统 > 激进 > 保守，按场景区分）
- 影子 SKU 的偏差能被合理解释（不是"差异为 0"，是"差异有合理原因"）

### 8.1.1 用户体验指标（R3 修订）

| 指标 | 当前基线 | v1 目标 | v1.5 目标 | 验收方法 | 对应 User Story |
|------|---------|---------|----------|---------|---------------|
| **CEO 拍板时间 / 日** | 当前每周 2-3 小时 Excel | ≤ 5 分钟 | ≤ 3 分钟 | 前端埋点（开始拍板 → 全部处理完时间戳）周平均 | US-1, US-2 |
| **预警响应延迟**（监控触发 → 推送 API 返成功） | 几天后才发现 | **P95 ≤ 15 min / 硬上限 ≤ 30 min** | P95 ≤ 5 min | 系统日志统计，按周回报 P50/P95/P99 | US-4 |
| **空清单日的"安心信号"完成度** | N/A | 连续 5 天空清单后 CEO 自评仍信任系统 ≥ 4/5 | 同 | CEO 主观自评 | US-5 |
| **决策可解释三层结构验收**（R3 替代原"1 分钟看懂"） | N/A | 抽样 10 条建议，CEO 能复述 L2 6 项分解中 ≥ 4 项 → 通过率 ≥ 80% | ≥ 90% | 每周 1 次抽样测验（5 分钟） | US-7 |
| **影子模式偏差解释率** | N/A | ≥ 80% 偏差能被合理解释 | N/A（v1.5 全真实） | 周复盘人工判定 | US-8 |

**R3 修订说明**：
- **预警延迟**：吸收工程 E-PM-1 + 架构 P-A3，统一三方口径为 P95 ≤ 15 min / 硬上限 ≤ 30 min，原"1 小时"作为告警阈值不再作为 SLA
- **可解释指标**：吸收工程 E-PM-2，废弃不可测的"看懂时间"，改为行为可观测的"复述命中率"+ 三层结构完整性
- **CEO 拍板时间**：从前端埋点统计（开始拍板 → 全部处理完毕的真实耗时），不是估算

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

| 验证项 | 方法 | 通过标准 |
|--------|------|---------|
| **决策合理性** | 虚拟数据集 + 1-2 真实 SKU 影子 90 天回测 | 系统建议总收益 > 保守策略 > 激进策略（按行业经验合理排序） |
| **灵敏度健壮性** | 关键参数（缺货损失系数 2-8、资金成本率 ±20%）扰动 | 核心决策稳定率 > 70% |
| **可解释三层结构** | CEO 抽样测验复述 L2 分解（替代原"1 分钟看懂"） | 命中 ≥ 4/6 项的通过率 ≥ 80% |
| **影子模式契合度** | 1-2 个真实 SKU 90 天对比 | 系统建议 vs 用户实际决策的偏差能被合理解释 |
| **运营成本** | CEO 拍板时间（前端埋点） | ≤ 5 分钟 / 日（周平均） |
| **空清单可信度** | 连续 5 天空清单后用户仍信任系统 | CEO 自评 ≥ 4/5 |

### 8.3 上线后验收（v1 上线 + 8 周，R3 修订）

**R3 修订说明（接受架构师 P-A2）**：原"上线后 + 4 周"验收对于"事后正确率"指标在统计上不可用——FR-12 复盘需要 7-14 天销量回流缓冲，4 周内只有最后 2 周可有效复盘（N≈14）。R3 延长到 **+ 8 周**（4 周决策 + 2 周回流 + 2 周观察），且"事后正确率"分子分母明确（**仅在影子 SKU 真实数据上算**，不在 mock 上算）。

| 验收项 | 方法 | 通过标准 |
|--------|------|---------|
| **事后正确率**（仅影子 SKU 真实数据） | 每条建议 vs 实际结果对比；算法口径以工程 §5.13 FR-12 为准（"系统建议数量 ∈ 实际需求 × [0.8, 1.2] → 正确"） | 分子分母明确（如"2 影子 SKU × 28 决策点 = 56 样本"）；正确率 ≥ 60%（v1 起点）→ 12 月 ≥ 75%（v1.5 真实数据全量后） |
| **批量接受清单的周复盘** | CEO 每周 5 分钟回顾批量清单中是否有"事后看明显错误"的 | 错误率 < 10% |
| **助理 24h 否决权使用率** | 助理退回率 | 5%-15% |
| **预警准确率** | 预警触发后 SKU 实际是否发生预测的状况 | ≥ 70% |
| **每日日报"非空率"** | 90 天观察 | 30%-70% |
| **mock vs real UI 区分有效性** | CEO 是否曾把 mock 建议误用于真实下单 | 0 次 |

---

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

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

### 10.1 主流程

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

**前置条件**：凌晨系统已跑完预测和优化，日报已生成（架构/工程负责确保跨时区调度正确，见 §10.4 业务兼容"决策频率"行）。

| 步骤 | 用户操作 | 系统行为 | 通过标准 |
|------|---------|---------|---------|
| 1 | CEO 9:00 打开系统 | 显示今日决策清单（按总收益贡献排序） | 加载 ≤ 3 秒 |
| 2 | CEO 查看第一条建议 L1 摘要 | 展示：SKU / 推荐数量 / 物流方式 / 预计总收益 / 置信度 | 30 秒内消化 |
| 3 | CEO 点击"展开" 查看 L2 分解 | 展示成本/收益分解（6 项）+ 灵敏度 ±20% 时决策是否变化 | 数据完整，1-2 分钟内消化 |
| 4 | CEO 调整数量 / 改物流（US-3 场景） | 实时显示"这一条"的 landed cost 与预估收益变化；置信度沿用上次批跑值并标注"调整后仅供参考" | < 500 ms 局部更新；UI 必须显式说明"局部 vs 全局" |
| 5 | CEO 接受建议 | 该条进入"待执行"队列、助理视图、系统记录决策日志 | 状态切换正确（pending → accepted） |
| 6 | CEO 对置信度 ≥ 80% 的项目"批量一键接受" | 全部进入待执行队列、批量清单加入周复盘必看 | 责任回路完整 |
| 7 | 全部处理完 | 显示"今日处理完毕 / 待执行 N 条 / 待复核 M 条" | 清晰收尾 |

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

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

#### S-10.1.3 助理执行

| 步骤 | 用户操作 | 系统行为 | 通过标准 |
|------|---------|---------|---------|
| 1 | 助理 9:30 打开操作视图 | 显示按截止时间排序的待执行任务（不含敏感字段） | 排序正确；助理视图不显示 unit_cost / expected_profit |
| 2 | 助理下单订船 | 勾选状态："已派单" | 状态回写到主系统（v1 用轮询 30s 或手动刷新，WebSocket 留 v1.5） |
| 3 | 货代发货 | 助理勾选"执行中" → "已发货" | CEO 视图可见 |
| 4 | 助理发现批量接受中某条不合理 | 在 24h 内退回到 CEO 复核（状态 → `pending_review`） | 进入 CEO "待复核"分区 |
| 5 | FBA 入仓 | 助理勾选"已入仓" | 系统记录 lead time 实际值 |

### 10.2 异常分支

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

| 场景 | 系统行为 | 通过标准 |
|------|---------|---------|
| 数据源不通 | 显示"今日数据未更新（最后一次更新：昨晚 23:12）" + "暂不推荐拍板" + 预计修复时间 | 不静默给陈旧建议 |
| 求解超时 | 显示"今日决策未跑完" + "已用昨日清单 + 缺货预警继续监控" | 降级方案明确 |
| 部分 SKU 计算失败 | 标记失败 SKU + 其余正常显示 | 不全盘失败 |
| **系统降级档位**（R3 新增，吸收工程 E-ARCH-6 / E-ARCH-7） | 顶部摘要卡片旁显示档位徽章 green/yellow/orange/red/black；橙/红档（解耦近似）时必须额外文案"风险偏好暂时降级为单 SKU 保守" | 用户能清晰看到当前档位与含义 |

#### S-10.2.2 缺货预警插队（R3 修订 SLA）

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

| 步骤 | 系统行为 | 通过标准 |
|------|---------|---------|
| 1 | 监控发现库存跌破阈值 | 触发推送（不依赖日报节奏） | **P95 ≤ 15 min / 硬上限 ≤ 30 min**（监控扫描周期 + 推送 + 重试 buffer） |
| 2 | 推送到 CEO 选定渠道（v1 仅 Bark；企微/TG 留 v1.5，见 §10.4） | 一条消息（不是 5 条） | 同一 SKU 24h 内不重复推 |
| 3 | CEO 点击推送 | 跳转到该 SKU 的紧急决策面板 | 含一键空运补货按钮 |

**R3 SLA 度量说明**：
- 度量起点 = 监控扫描发现阈值跌破的时刻
- 度量终点 = 推送 API 返成功（fire-and-forget；不等用户已读，吸收架构 E-A10）
- P95 ≤ 15 min 是 SLA；30 min 是硬上限触发告警；1 h 删除（原 PM 文案不再保留）

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

| 步骤 | 系统行为 | 通过标准 |
|------|---------|---------|
| 1 | 监控发现某 SKU 销量异常上涨 | 推送 + 标记"销量异常" | 准确率 ≥ 70% |
| 2 | CEO 查看 | 显示销量曲线 + 广告投放叠加 + 系统建议 | 含理由 |

#### S-10.2.4 物流报价大幅变化（R3 修订）

| 步骤 | 系统行为 | 通过标准 |
|------|---------|---------|
| 1 | 监控发现海/空运报价波动 **≥ 15%**（参考架构 §3.4 灵敏度阈值；< 15% 标黄但不重跑） | 推送 + 重新跑当日优化 | 影响今日决策的 SKU 标红；同一路线日内最多触发 1 次重跑（防货代连续小步刷价） |

**R3 修订说明（接受工程 E-PM-5）**：原"X 待定"不能丢给后端，X = 15% 与架构 §3.4 sea_rate ±20% 决策切换点对齐；同时加"日内同一路线最多 1 次重跑"硬约束。

### 10.3 状态切换

#### 10.3.1 单条建议状态机（R3 修订）

```
[新建议 pending] → [接受/调整/跳过]
                      ↓ 接受
                [待助理执行 dispatched]
                      ↓
                [助理已派单 in_progress]
                      ↓
                [已发货 shipped]
                      ↓
                [已入仓 received → 系统校准 lead time]

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

**R3 修订说明（接受架构 P-A5）**：三方统一状态命名为 `pending_review`（不是 PM 原文"CEO 复核"或架构 "pending"），与工程师 §5.8 实现一致。架构师需在 §4.3.6 `decision_recommendation.status` enum 新增 `pending_review` 取值。

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

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

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

| 兼容项 | 业务要求 | 依据 / R3 修订说明 |
|--------|---------|------------------|
| **数据来源** | v1 虚拟数据 + 1-2 影子 SKU 真实数据；v1.5 全量 Amazon Seller Central API | scene-anchor §1.5 |
| **决策频率** | v1 每日 1 次日报（BJ 9:00 前送达）+ 事件触发预警；[OPEN_QUESTION OQ-4] 商业评审建议改"事件触发+周节奏" | debate-log R3；**R3 新增**：跨时区调度由架构/工程负责，必须覆盖美西夏令时切换日（架构 E-ARCH-4） |
| **SKU 规模** | v1 支持 200 SKU；v1.5 不承诺扩展（如做 SaaS 是另立项目） | scene-anchor §2；**R3 新增 OPEN_QUESTION OQ-6**：架构 §4.5.2 的 tenant_id + RLS 软隔离已经在为 SaaS 做架构投资，但 PM 已声明 v1/v1.5 都不做 SaaS——是否撤掉 tenant_id 改为 mock/real/shadow 三 schema 隔离？需企业家拍板（影响后续可扩展性 vs 短期工程税） |
| **物流方式** | v1 仅海运 / 空运二选 | proposal-v1 §1.2 |
| **推送渠道** | **v1 仅 Bark for iOS（最便宜最合规）；企微 / Telegram 留 v1.5**（R3 修订） | **R3 接受工程 E-PM-6 + 自评 B-4**：原"任选其一"在工程语义里 = 三个 adapter 都要实现（工时 ~2-3 周 vs 1 个渠道 ~3 天），v1 自用场景没必要；正文与边界 B-4 自洽 |
| **助理协同** | 单助理；多助理不在 v1 | proposal-v1 FR-7 |
| **语言** | 中文界面；SKU 名称支持中英文混排 | benchmark §四 |
| **货币** | 美元（FBA 业务）+ 人民币（采购成本）双币种显示 | competitors §四；**R3 新增（接受架构 P-A7）**：展示汇率为日批跑时刻汇率，盘中波动不重新折算；汇率拉取时刻建议改"美西时间 23:00 拉取（与日切对齐）"，由架构/工程负责实现 |
| **数据保留**（R3 新增） | 原始快照：热存 90 天（FR-1）+ 冷存 5 年（合规审计）；决策建议 + 用户动作：热存 2 年 + 冷存 5 年；不存在"永久保留" | **R3 接受工程 E-ARCH-8**：原 PM 章节未提保留时长，导致架构 / 工程不一致。OPEN_QUESTION OQ-7：5 年是否满足国内增值税/海外销售税审计？需企业家或合规顾问拍板 |

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

| 影响域 | 业务层风险 | 缓解措施 |
|--------|----------|---------|
| **CEO 决策习惯** | 看 v1 mock 数据看多了，对真实业务的直觉感被弱化 | FR-10 Mock/Real 模式 UI 强警示；周复盘强调"mock 不代表真实"；**R3 新增**：§1.2 已声明 v1 mock 指标 ≠ v1.5 真实指标，避免预期错位 |
| **助理工作流** | v1 引入新工作流，原 Excel 流程是否保留？ | v1 期间双轨：Excel + 新系统并行 4 周，4 周后切单轨（双轨期可延长，见 OQ-8） |
| **CEO 心智模式** | 每天早上第一件事看库存日报，可能把 CEO 锁死在"运营者"心智，影响"洞察者"产出 | [OPEN_QUESTION OQ-3]；缓解：批量接受 + 5 分钟硬上限 |
| **影子 SKU 的真实订单** | v1 影子建议如果被误执行 = 资金事故 | FR-10 UI 强警示 + 影子模式下"接受"按钮需二次确认 |
| **数据一致性**（v1.5 切真实数据时） | mock schema 与真实 API schema 不一致导致大重构 | FR-1 v1 数据 schema 按真实 FBA API 反向设计 |
| **数据敏感性**（R3 新增） | 助理通过截图 / 共享屏幕 / 退回 CEO 功能绕过角色脱敏看到 unit_cost | 列脱敏机制 v1 必做（按 role 控制返回字段）；KMS + AES-GCM 静态加密留 v1.5；OPEN_QUESTION OQ-9：自用项目不上 KMS 是否可接受？ |

---

## §11 依据清单

### 11.1 用户依据

| # | 用户判断 | 依据等级 | 来源 |
|---|---------|---------|------|
| UE-1 | 决策者 = 使用者 = 企业家本人，独自决策 | A | scene-anchor §2 |
| UE-2 | 助理是真正的执行人，v1 必须解决 | C | debate-log 商业 B4 |
| UE-3 | "每日决策"频率（vs 周/事件触发）是企业家指示 | A | scene-anchor §3.1 |
| UE-4 | CEO 每天 5 分钟拍板的时间预算 | D | scene-anchor §5.2 |
| UE-5 | 单用户场景下"接受率 70%" 是空口承诺 → 改为"事后复盘正确率"（**R3 进一步明确：仅在影子 SKU 真实数据上算**） | C | debate-log 商业 B2 + 工程 E-PM-3 |
| UE-6 | **R3 新增**：可解释面板必须三层结构（L1/L2/L3），验收用"复述命中率"替代"看懂时间" | C | 工程 E-PM-2 + 设计评审 R3 |

### 11.2 竞品依据

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

### 11.3 行业 Benchmark

| # | 行业判断 | 依据 | 来源 |
|---|---------|------|------|
| IE-1 | 缺货损失 = 缺货天数 × 日销额 × (1 + 排名恢复倍数 2-4) | benchmark §3.5 | ExFreight |
| 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 |
| 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 内部假设

| # | 假设 | 等级 | 风险 |
|---|------|------|------|
| A-001 | 销量预测准确度 < 25%（**v1 mock 上易达到，但工程 E-PM-4 指出真实数据上通常 30%-50% MAPE**） | E | 🔴 |
| A-002 | 海空运报价能实时获取（v1 推迟到 v1.5） | D | 🟠 |
| A-003 | 缺货损失 ≈ 3-5 倍直接销售额 | C | 🟠 |
| A-004 | 建议接受率 > 70%（已被推翻 → 改为事后复盘正确率，仅影子 SKU 真实数据算） | E | 🟠 |
| A-005 | 200 SKU 适合单一决策模型 | E | 🟡 |
| A-006 | 每日决策频率合理（OQ-4 待定） | D | 🟡 |
| A-007 | 缺货成本 >> 库存成本 | D | 🟡 |

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

### 11.5 辩论 + R3 修订记录

| # | 辩论/修订结论 | 影响章节 |
|---|---------|---------|
| DE-1 | V0→V1 重定位（"补货 workflow 工具" → "经济决策引擎"） | §1.1 |
| DE-2 | 加"影子模式" FR-15 化解工程 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；**R3 进一步收敛到 v1 仅 Bark** | §10.2.2, §10.4 |
| **R3-1** | **预警 SLA 三方统一为 P95 ≤ 15 min / 硬 30 min**（删除 PM 原 1h） | US-4, §8.1.1, §10.2.2 |
| **R3-2** | **US-3 调整后只显示局部成本变化，置信度沿用上次批跑值** | US-3, §10.1.1 |
| **R3-3** | **US-6 退化到"只输出建议数量+日历提醒"**（不算工厂产能/排期） | US-6 |
| **R3-4** | **US-7 改为三层信息架构 + 复述命中率验收** | US-7, §8.1.1 |
| **R3-5** | **状态命名统一为 `pending_review`** | US-12, §10.3.1 |
| **R3-6** | **指标按 v1 mock / v1.5 真实两列分开承诺** | §1.2, §8.1 |
| **R3-7** | **v1 推送渠道收敛到 Bark 单一** | §10.4 |
| **R3-8** | **物流报价波动阈值 X = 15%（对齐架构 §3.4 灵敏度切换点）+ 日内单路线 1 次重跑上限** | §10.2.4 |
| **R3-9** | **8.3 验收窗口从 4 周延长到 8 周**（架构 P-A2） | §8.3 |
| **R3-10** | **数据保留时长写入 §10.4**（架构 E-ARCH-8） | §10.4 |

#### OPEN_QUESTION 索引（待企业家 / Controller 拍板）

| # | 分歧 | PM 倾向 | 影响章节 |
|---|------|--------|---------|
| OQ-1 | ROI 算式：年化决策提升收益 vs 100 万全周期成本 | 必须用历史数据先做 1 周回归校准 | §1.2 全部 |
| OQ-2 | 影子模式：1-2 SKU vs 20+ SKU | 商业评审"高/中/低三档各 1-2"折中 | US-8, §10.4 |
| OQ-3 | CEO 心智锁死风险（每天看日报 vs 写第三本书） | 用"5 分钟硬上限 + 批量接受 + 助理承接"缓解 | §10.5 |
| OQ-4 | 每日 vs 事件触发+周 | 保留每日扫描 + 事件触发 + 空清单也展示安心信号 | §8.3 |
| OQ-5 | LP→MINLP 工程难度 + 求解器选型 SCIP vs CP-SAT（R3 注：架构 E-A1 / 工程 E-ARCH-2 三方仍未对齐） | 不在 PM 边界，由架构师/工程师以 spike POC 决定 | （转架构师 / 工程师） |
| **OQ-6** | **R3 新增**：tenant_id 是否撤掉（v1/v1.5 都不做 SaaS） | PM 倾向撤掉，用 mock/real/shadow 三 schema 隔离即可；省一倍工程税 | §10.4 SKU 规模 |
| **OQ-7** | **R3 新增**：数据保留 5 年是否满足合规审计要求 | 需企业家或合规顾问拍板（FBA 海外销售税审计通常 5-7 年） | §10.4 数据保留 |
| **OQ-8** | **R3 新增**：双轨期（Excel + 新系统）是否延长到 v1.5 真实数据接入完 | 商业评审 R3 指出 mock 期间复盘"自言自语"；建议双轨延长 | §10.5 |
| **OQ-9** | **R3 新增**：v1 自用是否可以不上 KMS + AES-GCM 静态加密，只做应用层列脱敏 | PM 倾向 v1 只做列脱敏（自用项目），KMS 推 v1.5 | §10.5 |
| **OQ-10** | **R3 新增**：CVaR 风险偏好 user_tolerance 三档（保守/平衡/激进）的业务命名 + 默认值（架构 §3.5.3 + 工程 E-ARCH-6 指出 PM 章节飘空） | 业务命名"保守 / 平衡 / 激进"；默认"平衡"档；放在 FR-3 参数管理页"全局参数"区块；可由 CEO 调整 | §10.4 + 需 FR-3 增加界面元素 |

---

**PM R3 边界声明**：本文档只覆盖 §1 §2 §8 §10.1-10.5 §11。架构 / 工程冲突中涉及技术细节（求解器选型、变量数口径、性能预算、tenant 隔离实现方案）由架构师 / 工程师在 R3 联席解决，PM 仅在"用户视角承诺"维度发声（如 SLA 30 min vs 15 min 的用户场景影响、tenant_id 与 PM 业务范围的脱节）。

---

# R3 修订记录

## 对架构师 review 的处理

### P-A1: 北极星 "+10%" 数字在 schema 里取不到，需要新建 `backtest_trajectory` 表
- **架构师建议**：架构师在 §4 补 `backtest_trajectory` 表（per 策略 × per day × per SKU 的 inv/sold/short/cost 轨迹）；PM 在 §10.4 兼容性里补"回测数据保留期"
- **PM 处理**：✅ **接受**。北极星指标的验证方法已改写为"FR-11 三策略回测，从 `backtest_trajectory` 表统计"。请架构师在 R3 联席时补此表 schema 并加入保留策略。
- **修订位置**：§8.1 北极星表验证方法列 + §10.4 数据保留行（包含回测数据）

### P-A2: 8.3 "事后正确率"的统计窗口跟 4 周验收对不上（前 14 天无销量回流）
- **架构师建议**：把 +4 周验收延长到 +8 周，或明示"前 14 天不计入分母"
- **PM 处理**：✅ **接受 8 周方案**（4 周决策 + 2 周回流 + 2 周观察）。同时明确"事后正确率"仅在影子 SKU 真实数据上算，分子分母标注。
- **修订位置**：§8.3 标题改"上线 + 8 周"，加修订说明

### P-A3: SLA 三方口径不一（架构 15 min / 工程 15 min / PM 1 h）
- **架构师建议**：v1 统一承诺 ≤ 30 min；PM §10.2.2 改 30 min，§8.1.1 v1 目标改"< 30 分钟"
- **PM 处理**：✅ **接受，但折中为 P95 ≤ 15 min / 硬上限 ≤ 30 min**（细化为可测 AC，吸收工程 E-PM-1）。**用户视角校验**：用户需要"看到推送时还来得及联系货代做空运补救" → 30 min vs 1h 对当天工作时间内联系货代有差异，15 min vs 30 min 对用户体感差异不大；P95 15 min 是合理的工程承诺 + 用户能接受的硬上限是 30 min。
- **修订位置**：US-4、§8.1.1、§10.2.2 全部统一

### P-A4: US-3 "立即重算" vs §3.5 两阶段决策的 stage-1 共享非预期性约束
- **架构师建议**：要么 PM US-3 改文案为"实时显示这一条决策的成本变化，全局最优需等下次批跑"；要么工程在 /preview-decision 加 tooltip
- **PM 处理**：✅ **接受 PM 改文案**。原 US-3 用户会理解成"系统重新算了"，但架构上只能做单 SKU 局部重算。修订后明确"局部重算 vs 全局最优需等下次批跑"，UI 必须显式说明（不放在 tooltip 这种容易被忽略的位置）。
- **修订位置**：US-3 全文改写 + §10.1.1 步骤 4 加 UI 说明要求

### P-A5: US-12 状态命名三方不一致（PM "CEO 复核" / 架构 "pending" / 工程 "pending_review"）
- **架构师建议**：统一为工程师的 `pending_review`，PM §10.3.1 和架构 §6.2.1 改字
- **PM 处理**：✅ **接受**。`pending_review` 语义最清晰（区分"全新待决策"和"被助理退回需复核"）。
- **修订位置**：US-12 文案 + §10.3.1 状态机 + 请架构师 §4.3.6 enum 同步

### P-A6: US-6 暗含 `supplier` 实体但 PM 没意识到
- **架构师建议**：v1 退化到"只输出 X 天后该下单"（与工程 §5.16 一致）；或架构师补 `supplier` 实体
- **PM 处理**：✅ **接受 v1 退化方案**。v1 自用 200 SKU 不值得为此建立完整供应商主数据；CEO 手工联系工厂确认产能即可。`supplier` 实体留 v1.5。
- **修订位置**：US-6 全文改写

### P-A7: 双币种汇率时刻 vs 9:00 BJ 看日报的时差问题
- **架构师建议**：工程 §5.1 把汇率拉取改"美西时间 23:00 拉取（与日切对齐）"，PM 在 §10.4 货币行补"展示汇率为日批跑时刻汇率，盘中波动不重新折算"
- **PM 处理**：✅ **接受**。
- **修订位置**：§10.4 货币行加说明

## 对工程师 review 的处理

### E-PM-1: US-4 "1 小时" 跟 FR-8 SLA 不自洽，PM 已知不写死却仍写 1 小时
- **工程师建议**：US-4 / §10.2.2 改成"P95 ≤ 15 min，硬上限 ≤ 1h"，且边界 B-3 不要"待工程师拍板"
- **PM 处理**：✅ **接受 P95 ≤ 15 min**，硬上限折中为 30 min（不是 1 h，因为 1 h 的用户场景影响真实——见 P-A3 处理）。边界 B-3 删除（已解决）。
- **修订位置**：US-4、§8.1.1、§10.2.2 全部统一；删除原边界 B-3

### E-PM-2: §8.1.1 "看懂时间 1 分钟" 不可测
- **工程师建议**：要么删了改成"侧抽屉 3 层结构完整可见 + CEO 抽样复述 6 项分解中能命中 ≥4 项"，要么承认是主观满意度
- **PM 处理**：✅ **接受行为可观测方案**。US-7 改写为三层信息架构（L1 30 秒 / L2 1-2 分钟 / L3 按需），§8.1.1 验收改为"抽样 10 条建议，CEO 能复述 L2 6 项分解中 ≥ 4 项 → 通过率 ≥ 80%"。
- **修订位置**：US-7 全文 + §8.1.1 表 + §8.2 表

### E-PM-3: 事后正确率 60% 仍是单用户，且 mock 上算 = 自己出题自己答
- **工程师建议**：明确"事后正确率"仅在影子 SKU 真实数据上算（mock 上算结构相似性即可），样本数标注分子分母
- **PM 处理**：✅ **完全接受**。这是 V0 "接受率 70%" 同源问题的更彻底解决。
- **修订位置**：§8.3 表 + §2.1 注

### E-PM-4: §1.2.1 百分比 + A-001 "v1 mock 上易达到 < 25%" 暴露循环论证
- **工程师建议**：§1.2.1 表头加一栏"v1 (mock) / v1.5 (真实) 分列目标"，v1.5 目标必须显著保守于 v1
- **PM 处理**：✅ **完全接受**。这是非常重要的诚实声明，避免 v1.5 上线时被解读为"系统退步"。
- **修订位置**：§1.2.1 表格重做（两列分开），§1.2 加 R3 新增声明；§8.1 北极星表同步两列

### E-PM-5: §10.2.4 "X 待定" 直接影响 FR-4 重跑频率
- **工程师建议**：X = 15%（对齐架构 §3.4 灵敏度切换点）；日内同一路线最多 1 次重跑
- **PM 处理**：✅ **完全接受**。PM 同意把灵敏度阈值作为预警阈值（这是合理的工程经济学逻辑：参数变化未到决策切换点就不必重算）。
- **修订位置**：§10.2.4 表格 + R3 修订说明

### E-PM-6: §10.4 推送渠道三选一 vs 边界 B-4 "v1 先 1 个" 不自洽
- **工程师建议**：v1 硬性 1 个渠道（Bark），PM 正文 §10.4 改"v1 仅 Bark；v1.5 增加企微/TG"
- **PM 处理**：✅ **完全接受**。正文与边界 B-4 自洽（B-4 已废弃，结论吸收到正文）。架构师 §9.B "多通道并行（至少 2 个）" 推到 v1.5（请架构师 R3 同步）。
- **修订位置**：§10.4 推送渠道行重写

## 转给 Controller / 企业家的 OPEN_QUESTION

| # | 问题 | 触发来源 | 影响 |
|---|------|---------|------|
| **OQ-6** | v1/v1.5 都不做 SaaS，是否撤掉架构 §4.5.2 的 tenant_id + RLS 软隔离？改用 mock/real/shadow 三 schema 物理隔离 | 工程 E-ARCH-3 | 撤掉省一倍工程税；保留为未来 SaaS 预留接口 |
| **OQ-7** | 数据保留 5 年是否满足合规审计要求？（FBA 海外销售税 / 国内增值税通常 5-7 年） | 工程 E-ARCH-8 | 决定冷存策略与存储成本 |
| **OQ-8** | 双轨期（Excel + 新系统并行）是否延长到 v1.5 真实数据接入完？ | 商业评审 R3 + R3 PM | 影响 v1 上线后 4 周切单轨的承诺 |
| **OQ-9** | v1 自用是否可接受"只做应用层列脱敏，不上 KMS + AES-GCM 静态加密"？ | 工程 E-ARCH-5 | KMS 集成是几周隐藏工程量 |
| **OQ-10** | CVaR user_tolerance 三档"保守 / 平衡 / 激进"的默认值（PM 倾向"平衡"档）+ 是否纳入 FR-3 全局参数页？ | 架构 §3.5.3 + 工程 E-ARCH-6（架构师把球踢给 PM，PM 章节飘空） | UI 落地位置 + 默认风险偏好 |

## 转给架构师 / 工程师的协商项（PM 用用户视角发声但不裁决技术细节）

| # | 三方冲突 | PM 用户视角发声 | 转交 |
|---|---------|---------------|------|
| 求解器选型 SCIP vs CP-SAT（E-A1 / E-ARCH-2） | 用户不关心求解器是什么，只关心"每日日报必须在 BJ 9:00 前生成"+"灵敏度场景跑完时间不影响 5 分钟拍板"。建议以 spike POC 实际性能数据为准。 | 架构 + 工程 |
| 变量数 / 周聚合 vs 日级（E-A2 / E-A7） | 周聚合后"一键空运补货精确到日"会被弱化为"启发式拆分"，US-4 紧急补货的用户体验受影响。建议保留日级，性能不够时用 SKU 分组并行求解。 | 架构 + 工程 |
| 灵敏度场景数 5-7 vs 27（E-A4） | 用户能看懂的灵敏度场景数 ≤ 7（27 个组合用户消化不了）。建议 5-7 OAT 场景 + 2-3 关键参数组合扫描，与 US-7 L2 灵敏度面板呼应。 | 架构 + 工程 |
| 预测分位数 3 vs 5（E-A5） | 用户视角无差别，由架构决定。 | 架构 + 工程 |
| Schema 映射器 v1 锁定 vs 多版本回滚（E-A6） | 用户视角：v1 自用 200 SKU 不需要 schema 版本灵活性，建议 v1 锁定为硬编码（吸收架构师倾向）。 | 工程 |
| 助理 WebSocket vs 30s 轮询（E-A8） | 用户视角：助理操作不需要实时同步（最长容忍 30s），轮询足够，砍掉 WebSocket 省一个子系统工时。 | 工程 |
| 三策略回测资金池共用 vs 独立（E-A9） | 用户视角：三策略应独立求解（不互相消耗资金池），缺货损失分别累计——这样回测对比才公平。 | 架构 + 工程 |
| 推送 fallback 链 vs fire-and-forget（E-A10） | 用户视角：v1 仅 Bark 单渠道（已接受 E-PM-6），所以 fallback 链自动失效，fire-and-forget 即可。 | 工程 |
| 双 ID 体系（E-A11） | 不在 PM 边界，由架构 + 工程协商。 | 架构 + 工程 |
| 凌晨跑批跨时区 / 夏令时（E-ARCH-4） | 用户视角强诉求：日报必须在 BJ 9:00 前出现。已在 US-1 R3 注 + §10.4 决策频率行加要求。**实现细节请架构 + 工程在 R3 解决**（cron 用 UTC + IANA tz / 双日期系统 / 切换日 e2e 测试）。 | 架构 + 工程 |
| 降级档位 5 档 UI（E-ARCH-6） | 用户视角：橙/红档时 UI 必须显式告知"风险偏好暂时降级为单 SKU 保守"（已在 §10.2.1 R3 新增） | 工程 |

---

**END r3-pm.md**