# r2-pm-reviews-others.md · PM 评其他主笔

**评审人**: PM 主笔
**评审日期**: 2026-05-23
**评审范围**: r1-architect.md + r1-engineer.md（针对当前 R1 草稿出现的"新"问题，不重复 R3 reviewer 已提的内容）

---

## PM 评 架构师章节（r1-architect.md）

### [需要改] §3.2.3 性能预算 第 1 行（求解时间 < 5 分钟 / 硬超时 15 分钟）

原文：「日常每日跑（baseline）| 200 | < 5 分钟 | 15 分钟」

问题：从用户视角看，凌晨批跑超时是"系统视角"的事，用户其实并不直接感知。但 §3.5.4 又写"5 场景 MILP 在 8 worker 上约 10-30 分钟" —— 这跟 §3.2.3 的"< 5 分钟"互相矛盾。架构师如果默认每日都跑 5 场景，那 baseline 不可能 < 5 分钟。这影响 PM 在 §10.2.1 写的"凌晨任务挂了，9:00 看到什么"降级路径：用户能容忍的"等到 9:00 还没跑完"的边界，依赖架构师的真实求解时间。如果实际是 30 分钟而不是 5 分钟，那"凌晨 23:30 PT 触发"留给整条流水线（数据接入 + 预测 + 优化 + 灵敏度 + 周报生成）的时间窗口可能不够，9:00 BJ 用户打开就看到"未跑完"概率显著上升。

建议：把"baseline = 单场景 5 分钟"和"5 场景 robust = 15-30 分钟"分开列；性能预算表里把"凌晨流水线总时长"作为对用户承诺的指标（如"08:00 BJ 前必须完成"），并跟 PM §8.1.1 的"CEO 拍板时间预算 ≤ 5 分钟"在时间线上对齐。

### [需要改] §3.5.3 CVaR 用户参数命名（保守/平衡/激进）

原文：「用户在 UI 上可调 `user_tolerance`（"保守 / 平衡 / 激进"三档）」

问题：从用户视角看，"保守/平衡/激进"这种通用词没有告诉 CEO **选了之后会发生什么**。CEO 看到"激进"会本能恐惧（"是不是会让我大缺货？"），看到"保守"又会担心库存爆仓。我在 PM §10 没有给这个 UI 命名，是因为我以为架构师只暴露接口。但既然架构师把命名钉死了，必须改成有业务含义的命名。

建议：改成"缺货容忍度"三档，每档下面用一句话告诉 CEO 后果。例如：
- 「优先不缺货」（CVaR 紧）：极端场景下平均缺货损失 ≤ X
- 「平衡收益」（默认）
- 「优先省钱」（CVaR 松）：可能极端缺货但总收益期望更高
PM 在 §10.5 加一行确认默认值是"平衡收益"。

### [冲突] §3.5.1 场景表（P10/P50/P90 五场景） vs §8.2 验证指标"灵敏度健壮性"

位置 A（架构师 §3.5.1）：「构造 5 个全局场景 ... S1 悲观全部取 P10 ... S5 乐观全部取 P90」
位置 C（我 PM §8.2）：「关键参数（缺货损失系数 2-8、资金成本率 ±20%）扰动 → 核心决策稳定率 > 70%」

问题：架构师的"5 场景"是**销量需求**的不确定性场景；PM §8.2 的"灵敏度健壮性"是**经济参数**（缺货倍数、资金成本率）的扰动。两套机制名称都叫"场景/灵敏度"，但概念不同。架构师 §3.4 灵敏度分析跟 §3.5 鲁棒优化是两件事，但 PM 看完容易混淆。如果工程师按 PM 的"核心决策稳定率 > 70%" 去测，他可能去测"5 场景下的决策是否一致"，那就跑偏了。

建议：架构师在 §3.5 开头明确"区间预测 robust"是针对**销量不确定性**的；§3.4 灵敏度是针对**经济参数**的；并在 §3.4.2 输出形态里跟 PM §8.2 的"核心决策稳定率 > 70%"对齐口径（top-30 SKU? 全 200 SKU? 物流方式翻转算不算？）。

### [需要改] §4.5.4 Mock 数据生成器"挑战集" 第 2 段

原文：「生成器内置"挑战集"：节假日尖峰、断货事件、广告突发、Lead Time 异常等场景，独立于"正常分布"」

问题：从用户视角看，"挑战集"只在工程内部验证，CEO 永远看不到。但 PM US-10（三策略回测）要求 CEO 在评审时看到回测对比，**如果回测只跑"正常分布"而不跑"挑战集"，那 CEO 看到的回测结果是被美化的**。挑战集是不是要进 §10.B 的 L3 性能基线数据集 / L5 极端场景数据集？工程师 §10.B 的 L5 写了 `fx_corrupt_data` 但没写"节假日尖峰 / 断货事件"等业务级挑战。

建议：架构师明确"挑战集进 L5（极端场景数据集）"，并要求工程师 FR-11 三策略回测在"正常分布"和"挑战集"上分别出结果给 CEO 看，CEO 验收时两套都要满足"系统 > 保守 > 激进"。

### [冲突] §6.1 决策流程 cron 时刻 vs PM §10.1.1 用户使用时刻

位置 A（架构师 §6.1）：「Start([Cron 23:30 PT 触发])」 + §4.4.1：「凌晨跑批的时刻按"美西时间 23:30"触发 ... 早上 9 点北京时间用户看到的是"前一天美西的完整数据"」
位置 C（我 PM §10.1.1）：「CEO 9:00 BJ 打开系统 → 加载 ≤ 3 秒」

问题：美西 23:30 = 北京时间次日 14:30（PST）或 13:30（PDT）。也就是说**凌晨 14:30 BJ 才开始跑流水线，到第二天 9:00 BJ 完成根本不是问题**，但架构师文字里写"早上 9 点北京时间用户看到的是前一天美西的完整数据"，这暗示 CEO 的"今天 9:00 看的日报"是**两天前**的销量数据。这跟 PM US-1（"每天早上 9:00 打开一份发货清单"）的用户预期严重错位。CEO 会以为是"昨晚的销量"，实际是"前天的销量"。

建议：架构师把时区图画清楚，并跟 PM 对齐：要么把日报推迟到"美西 23:30 触发 → 北京时间次日 18:00 完成 → 用户下午看"，要么把流水线提前到"美西早上 8:00 启动（= 北京时间 23:00）"。这是产品决策不是架构决策，但架构师文字里没标这个矛盾。

### [需要改] §4.3.4 shipment 字段缺"取消原因 / 异常原因"结构化字段

原文：（shipment 表字段表中） status enum：planned / shipped / in_transit / arrived_port / inbound_fba / received / cancelled

问题：从用户视角看，PM US-11 / US-12 的助理操作（24h 否决、退回 CEO）必须留"理由"。架构师在 shipment 表里只放了 status 枚举，没有 `reason_code` 或 `cancel_reason` 字段。这意味着 PM §11 依据清单想追溯"为什么这批货取消了"时，只能去 user_action 表里查（如果有的话）。但 shipment 跟 user_action 是不同生命周期，关联查询会丢失上下文。

建议：shipment 表加 `cancel_reason_code` + `cancel_reason_text` + `exception_reason_code`；user_action 表里的 reason_code 跟 shipment 的 cancel_reason_code 用同一套枚举字典。

### [建议] §9.A 风险表 A7 "决策建议 24h 过期" 缺用户告知机制

原文：「A7 决策建议 24h 过期 ... 过期不删除，仅状态变更；用户回来可看历史 + 系统重新生成新建议」

建议：从用户视角看，CEO 出差回来打开系统看到"昨天的 5 条建议都 expired 了"会困惑——是系统判断我错过了，还是新建议自动覆盖了旧建议？需要 UI 明确告诉用户"这 5 条已被今早新建议替代，新建议 N 条"，并在历史列表里用视觉区分"我没拍板就过期了" vs "我拒绝了"。请架构师在 §6.2.1 状态机里把 expired 跟 superseded 区分开。

### [OPEN_QUESTION] §9.C 可扩展性 1000 SKU vs PM §1.1 "v1 200 SKU"

我的判断：v1 严格 200 SKU 是企业家拍板，v1.5 是否扩到 1000 SKU 是另一个项目讨论。架构师在 §9.C 用整个一节论证"v1 架构对 500 SKU 友好；600-800 SKU 黄线；1000 SKU 必须切求解器"——这给了一种"v1 就要为 1000 SKU 做准备"的暗示。架构师 §4.5 的多 tenant 设计也是这个倾向（"未来 SaaS")，但 PM §2.2 明确"不是其他 FBA 卖家"。
架构师的判断：预留扩展性是架构师本分；多 tenant 设计成本可控（"独立分库 ×2 工程成本"被否决说明已经在控制成本）。
需要 Controller 或企业家裁决：v1 阶段是否接受"为 v1.5 不一定发生的 1000 SKU SaaS 场景"投入 tenant_id + RLS 这套额外复杂度？我倾向砍掉 tenant_id（v1 单租户硬编码），v1.5 真要 SaaS 时再加。

---

## PM 评 工程师章节（r1-engineer.md）

### [需要改] §5.5 N6 文案 "用 p50 求基础解，用 p10/p90 各跑一次得到乐观/悲观对照解"

原文：「v1 用 p50 求基础解；用 p10/p90 各跑一次得到"乐观/悲观"对照解；输出"基础决策 + 三场景差异"」

问题：从用户视角看，CEO 看到"三场景差异"会问：**我要按哪个执行？** 工程师方案输出三套决策，但没说哪套写入 FR-7 助理待办。如果只用 p50 的决策，那 p10/p90 跑出来的只是"参考"；如果按某种规则聚合（取保守者 / 取激进者），CEO 必须能看懂规则。此外架构师 §3.5 用的是"5 场景 + stage1 共享 + CVaR"，工程师只写"三场景独立跑+对照"——**两个主笔的 robust 方案对不上**。

建议：工程师跟架构师对齐 §3.5 的 robust 方案（5 场景 stage1 共享 vs 3 场景独立跑），统一后改 §5.5 N6；并在 §5.7 FR-6 UI 明确"基础决策 = 进入待执行队列的那个"，"三场景差异"作为"决策稳健度"标签呈现给 CEO（高/中/低）。

### [需要改] §5.5 异常场景表（infeasible 自动放松约束）

原文：「数据异常 | 模型 infeasible（约束冲突，如 Restock Limit < 必须补量） | 自动放松"软约束"（按优先级：先放总资金 +20%，再放 Restock Limit），并在结果里标注"约束放松"」

问题：从用户视角看，"系统自动多花了 20% 资金"是**重大决策行为**。CEO 没批准 +20% 预算却被系统替他决定了，这会让 CEO 第二天看到银行账户少了一笔钱时极度不爽。FR-6 UI 文案"约束放松"是工程语言，CEO 看不懂。也跟 PM §10.2 "异常分支" 的精神（"不静默给陈旧建议"）冲突——这里是"静默放松约束"。

建议：把"自动放松软约束"改成"半自动"——infeasible 时系统**不下单**，而是出一条特殊的 FR-6 行："本日 N 条建议无法在当前预算/Restock Limit 下满足，需 CEO 批准临时放宽 X% 资金或调整该 SKU 优先级"。文案改成"今日资金/仓位不够，需您拍板"，给 CEO 三选项：①批准临时多花 ②跳过这批 ③改其他 SKU 节省。

### [冲突] §5.9 FR-8 SLA 15 分钟 vs PM US-4 / §10.2.2 "1 小时"

位置 A（工程师 §5.9 N6）：「SLA：从触发到推送 ≤ 15 分钟（覆盖锚点 §3.2 的"立刻"，与原"1 小时"冲突取严）」
位置 C（我 PM US-4 / §10.2.2）：「我希望在 1 小时内收到预警推送」

问题：工程师"取严"是好意，但 PM §10.2.2 把"1 小时"作为业务承诺写进了验收标准。如果工程师承诺 15 分钟却实际做到 30 分钟，PM 验收会判通过（仍在 1 小时内），但工程师内部会判失败。两边对齐口径错位会导致：(a) 上线后 metric 看着"绿"，但用户感知是"红"；或 (b) metric "红"但用户其实不在乎。

建议：统一口径。我倾向工程师改成"目标 15 分钟，承诺 1 小时"——SLA 用承诺值（1h），SLO 用目标值（15min）。PM §10.2.2 和 §8.1.1 都改成承诺 1h、目标 15min。

### [需要改] §5.9 FR-8 异常场景（推送渠道全失败"写本地未送达队列 + 顶部铃铛红色异常徽章"）

原文：「网络异常 | 推送渠道不可达 | 重试 3 次（1s/4s/16s）+ fallback；全失败时写本地未送达队列 + 顶部铃铛红色异常徽章」

问题：从用户视角看，**预警推送全失败时如果用户不打开系统，就永远看不到红色铃铛**。工程师的兜底是"打开系统看铃铛"，这跟"推送"的本质需求矛盾——CEO 之所以要推送，就是因为不会主动打开系统。CEO 在出差/开会时缺货预警全推送失败，相当于没预警。

建议：增加"短信兜底"渠道（v1 可手工配置一个国内运营商短信网关或阿里云 SMS）作为最后一道防线；或者要求 CEO 配置 ≥2 个独立通道（企微 + Bark 不算独立，因为都靠手机/网络）。工程师 §5.9 边界数值"推送渠道并发：3 个并行"已经支持，但 PM §10.4 默认只配 1 个。需要 PM 跟工程师对齐"最低 2 渠道"硬约束。

### [冲突] §5.7 FR-6 N6 "决策版本（昨日清单自动归档 superseded）" vs §5.13 FR-12 "复盘等待期 14 天"

位置 A（工程师 §5.7 N6）：「每次基础决策跑出来后，原本未处理的"昨日清单"自动归档（标 superseded）；用户拍板的已 accepted 不受影响」
位置 C（工程师 §5.13 N2）：「数据延迟：复盘需要 7-14 天后的"实际销量"才能算分；用户在第 N+14 天看到第 N 周完整复盘」

问题：从用户视角看，**未处理的建议被自动 superseded 了，怎么进 §5.13 周复盘？** §5.13 的"正确性评分"逻辑是"系统建议 vs 实际销量"，但如果建议在 24h 后被 superseded、用户根本没拍板，那"实际销量"对比的是哪个建议——昨天 superseded 的、还是今天新的？周复盘统计基数会失真。这也跟 PM §8.3 验收指标"事后正确率"和"批量接受清单的周复盘"算法定义有关。

建议：工程师明确周复盘评分的口径——是"已 accepted/modified 的决策" vs 实际，还是"所有 superseded 的也算"？我倾向只评 accepted/modified（用户负责的部分），superseded 的另起一节"系统反复自我修正的 SKU 清单"作为模型质量参考。

### [需要改] §5.9 FR-8 异常场景（critical 穿透静音）

原文：「用户操作冲突 | 静音规则与紧急 critical | critical 级别可配置"穿透静音"（默认开）」

问题：从用户视角看，"穿透静音"默认开是对的，但 CEO 在睡觉/开会时被穿透了，第二天会问"我设了静音怎么还响"。需要在静音设置 UI 上**显式告知** "critical 不受此静音影响（如需关闭请到全局设置）"，否则 CEO 会以为静音失效是 bug。

建议：FR-8 静音控制 UI 文案改成"静音此 SKU 的普通预警（critical 仍会推送）"；并在每次推送 critical 时消息文末加"⚠️ 此为严重预警，已穿透您的静音设置"。

### [需要改] §10.A AC 矩阵 缺 US-5（空清单）/ US-6（60/90 天预警）/ US-8（影子模式）的 happy path E2E 验证

原文：AC 矩阵中 AC-6.2「空清单显示"今日健康" + 倒计时」、AC-15.1「60/90 天扫描准确性」、AC-13.1「影子 SKU 与 Mock 物理隔离」

问题：从 PM 视角看，PM 的 13 条用户故事（US-1 至 US-13）每条都应该有对应的 happy path E2E 自动化测试。工程师 AC 矩阵按 FR 分组，但**没有按 US 反向检查覆盖完整性**：
- US-5（空清单的安心）只有 AC-6.2 一条，没验证"过去 7 天回顾 / 平均决策准确率 / 累计节省金额"显示（PM §10.1.2 步骤 3）
- US-6（60/90 天预警）只有 AC-15.1 测扫描准确性，没测"用户点击预警→跳转到该 SKU 决策面板"的全链路
- US-8（影子对照）只有 AC-13.1 测隔离，没测"用户每天手工录我的实际决策 → 进入复盘比对池"的录入流程
- US-10（三策略回测）只有 AC-11.1 测显著性，没测"用户在评审会看到对比图 + 一句话结论"的渲染

建议：工程师在 §10.A 补充一个"US 反向覆盖矩阵"——每个 US 至少 1 条 E2E 主流程 AC，标注 P0。如果发现 US-N 没有 AC 对应，要么补 AC 要么砍 US。

### [冲突] ADR-06 "周决策 + 事件触发预警" vs PM US-1 "每天早上 9:00 打开发货清单"

位置 A（工程师 §12.4 ADR-06）：「周决策 + 事件触发预警 | 替代每日决策 | R3 共识 "200 SKU 健康业务实际每周 2-3 次发货"」
位置 C（我 PM US-1）：「我希望每天早上 9:00 打开一份按总收益排序的发货清单」

问题：工程师把"周决策 + 事件触发"作为已敲定的 ADR 写进去了，但 PM §10.4 / OQ-4 明确指出这是 OPEN_QUESTION，待企业家拍板。**ADR 一旦写进去就有"已决定"的工程心智**，工程师可能按周节奏去实现 FR-6 而不是日节奏，结果跟 PM 的 US-1 / §10.1.1 完全不兼容（"每天 9:00 打开"在周节奏下变成"每周一/三/五 9:00 打开"）。FR-6 §5.7 N5 写的"空清单设计 ... 倒计时（来自 FR-15）" 也暗示"非每日触发"，进一步把矛盾扩大。

建议：ADR-06 改成"OPEN_QUESTION：周节奏 vs 每日 + 事件触发"，**不要在 R1 提前敲定**。PM OQ-4 的判断（每日扫描 + 事件触发 + 空清单展示安心信号）才是 PM 立场，需要企业家正式裁决后再 ADR。

### [建议] §5.15 FR-14 "助理 24h 否决权" 缺 CEO 收到退回后的体验定义

原文：「助理 24h 内可整批/单条退回 CEO（带原因）... 周复盘"批量决策" Section 必看」

建议：工程师定义了助理退回的入口，但没定义 CEO 收到退回后的体验。从用户视角看，CEO 早上 9:05 批量接受了 12 条，下午 14:00 助理退回了 3 条，CEO 是怎么知道的？是推送（FR-8 通道）？是站内信？是下次打开系统看到红条？这条体验链没闭环。PM US-12 只覆盖了助理侧动作，没定义 CEO 侧通知。请工程师在 §5.15 N2 明确"退回触发 FR-8 推送 priority=warning"或类似定义。

### [需要改] §5.4 FR-3 "缺货倍数被改成负数 → 后端兜底 max(0.1, x) 并记 audit"

原文：「数据异常 | 缺货倍数被改成负数 | 表单校验拦截；后端兜底 max(0.1, x) 并记 audit」

问题：从用户视角看，"后端兜底 max(0.1, x)" 是默默把用户输入的"-5"改成"0.1"。如果用户是 admin 误输入负数被前端拦截，那 OK；但**如果用户绕过前端（API 调用）输入负数被后端 silently 改成 0.1，用户永远不知道实际生效的是 0.1**，下次决策跑出来的结果完全不符合预期。这跟 §5.7 FR-6 的"可解释"承诺冲突。

建议：后端遇到非法值直接 reject（return 400），不要兜底改值。决策可解释面板里 parameter_version 必须显示真实参数值，不能因兜底 silently 改了用户看不到。

---

**END r2-pm-reviews-others.md**