# r2-engineer-reviews-others.md · 工程师评其他主笔

**作者视角**: 工程师（R2 阶段评 PM/架构师 R1 草稿）
**日期**: 2026-05-23
**评审原则**: 不全盘赞同，引用原文精确，重点是 R1 draft 里冒出来的新问题（不是 R1 之前就有的老问题）

---

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

### E-PM-1 · US-4 "1 小时内收到预警推送" 跟 FR-8 的 SLA 不自洽，且 PM 已知不写死却仍写 1 小时

**引用原文**（r1-pm.md §2.3 US-4）：
> "我希望在 1 小时内收到预警推送（不是邮件，不是站内信，是会响的渠道）"

**引用原文**（r1-pm.md §10.2.2 步骤 1）：
> "触发推送（不依赖日报节奏）| ≤ 1 小时延迟"

**引用原文**（r1-pm.md 边界 B-3）：
> "工程评审 T4 指出 SLA 在 scene-anchor / proposal 不一致（15 分钟 vs 1 小时）；工程现实可能更长"

**工程师看到的问题**：
- 我在 r1-engineer.md §5.9 FR-8 已经写"触发到推送 SLA：≤ 15 min（含聚合等待）"，并明确"覆盖锚点 §3.2 的'立刻'，与原'1 小时'冲突取严"。
- 但 PM 在 US-4 / §10.2.2 把"1 小时"写成可被引用的承诺（"通过标准"列）。**这就形成了 PM 验收 ≤ 1h、工程实现 ≤ 15min 的反向不一致** —— 工程做得更好，但验收只看 1h，等于工程白做。
- 更糟的是 §10.2.2 把"≤ 1 小时"作为通过标准 → QA 写测试时就按 1h 验收 → 工程降级到 1h 是合规的，但实际用户拿不到 15min 的体验。
- **可测的 AC 应该是**：监控触发后 P95 ≤ 15min，P99 ≤ 30min，硬上限 1h 触发告警。PM 写的"≤ 1h"只是硬上限，不是 SLA。

**建议**：R2 把 US-4 / §10.2.2 改成"P95 ≤ 15 min，硬上限 ≤ 1h"，且边界 B-3 不要"待工程师拍板"——工程师已经拍了，是 15min。

---

### E-PM-2 · §8.1.1 "看懂时间 1 分钟" 这条 UX 指标根本不可测，没有谁、用什么工具、什么频率收集

**引用原文**（r1-pm.md §8.1.1）：
> "决策可解释面板的'看懂时间' | N/A | 1 分钟内看懂 | 30 秒"

**引用原文**（r1-pm.md §8.2）：
> "可解释性 | 用户在决策面板上 1 分钟内能看懂每条建议的逻辑 | 用户自评（CEO 本人 ≥ 4/5）"

**工程师看到的问题**：
- "1 分钟内看懂"是一个**时间**指标，但验证方法又是**自评 ≥ 4/5**（一个李克特量表）。**时间 vs 主观评分是两套测量体系**，不能混。
- 用户 = CEO 1 人 → 没有 n，"4/5"在统计上等于"主观结论"。
- **谁来掐表？** PM 没说。是 CEO 每次点开抽屉时前端打 timestamp 吗（埋点 → 又有 PII / 行为日志问题）？还是事后回忆问卷？这两者得到的数字差几倍。
- **"看懂"的判定标准是什么？** 用户说"我看懂了"就算？还是 CEO 能复述 6 项分解中至少 4 项才算？没有判定，"4/5"是空谈。
- **频率？** 每次决策都问？每周一次抽样？没说就等于不收集 → v1 上线后这个指标就是死的。

**建议**：要么删了改成"侧抽屉 3 层结构完整可见 + CEO 抽样复述 6 项分解中能命中 ≥4 项 → 验收通过"（行为可观测），要么承认这就是主观满意度并降级成"用户自评"，不要冒充"时间指标"。

---

### E-PM-3 · §8.3 "事后正确率 ≥ 60%" 替代了 V0 的"接受率 70%"，但仍然在统计上无意义

**引用原文**（r1-pm.md §8.3 第一行）：
> "事后正确率（替代 V0 的'接受率 70%'，吸收商业评审）| 每条建议 vs 实际结果对比 | ≥ 60%（v1 起点）→ 12 月 ≥ 75%"

**引用原文**（r1-pm.md §2.1 注）：
> "单用户场景下'接受率 70%' 在统计上无意义 → 改用'事后复盘正确率'"

**工程师看到的问题**：
- PM 自己承认了"单用户接受率 70%"无意义，**但事后正确率 60% 的样本来源也是单用户**——CEO 给系统建议打分，跟 CEO 自己给自己打接受率没有本质区别，只是从"事前"变"事后"。
- 我在 r1-engineer.md §5.13 FR-12 已经定义了正确性评分算法：
  > "系统建议数量 ≤ 实际需求 × 1.2 且 ≥ 实际需求 × 0.8 → 正确"
  这是一个**机械化指标**（不依赖人评分），相对客观。但 PM §8.3 写的是"每条建议 vs 实际结果对比"，**这个口径跟我的算法一致吗 PM 没确认**。
- 更大的问题：v1 主要跑 mock，**mock 模式下"实际结果"是 mock 生成器跑出来的——这就是 debate-log 战略 R3 "自己出题自己答" 的同一问题换皮**。PM §8.3 没说这条指标只在影子模式 / v1.5 真实数据上算，等于在 mock 上算正确率 → 永远 100%（因为 mock 生成器和决策都基于同一组概率分布）。
- 12 月目标 75% —— 12 月是 v1 还是 v1.5？v1 还是 mock 数据吗？没说。

**建议**：明确"事后正确率"**只在影子 SKU 的真实数据上计算**，不在 mock 上算（mock 上算结构相似性即可）；样本数从一开始就标注"分子分母"（如"4 个影子 SKU × 90 天 = 360 决策点"），不要只写百分比。

---

### E-PM-4 · §1.2.1 全部"6 月目标 -50%" 都是百分比，但 §11.4 A-001 "v1 在虚拟数据上易达到 < 25%" 暴露了循环论证

**引用原文**（r1-pm.md §1.2.1）：
> "缺货天数 / 月 / SKU 下降 | 当前 _TBD_ → 6 月目标 −50% / 12 月目标 −70%"

**引用原文**（r1-pm.md §11.4 A-001）：
> "销量预测准确度 < 25%（v1 在虚拟数据上易达到，v1.5 真实数据待验证）"

**工程师看到的问题**：
- PM 老老实实标了"基线 TBD"，承认"承诺减 50% 在统计上无意义"。这是诚实的。
- **但**: A-001 同时承认"v1 在虚拟数据上易达到 < 25% 预测误差"——这等于说虚拟数据的预测难度被生成器人为压低了。
- 我在 r1-engineer.md §5.3 FR-2 写的预测模型（LightGBM 分位数 + Holt-Winters 分层路由）在真实数据上 MAPE 通常 30%-50%，**绝对达不到 25%** —— 这意味着 v1 的"虚拟数据演练"会形成一种"系统看起来很准"的假象，v1.5 切真实数据时所有指标都会爆掉。
- PM §1.2.1 的"6 月目标 -50% 缺货" 跟"v1 在 mock 上预测误差 < 25%" 是同一组数字论证，**没有跟 v1.5 的真实数据预测误差脱钩声明**。一旦企业家把 v1 mock 的好数字记下来作为预期，v1.5 上线时落差会被解读为"系统退步"。

**建议**：§1.2.1 表头加一栏"v1 (mock) / v1.5 (真实) 分列目标"，v1.5 的目标必须显著保守于 v1（如 v1 缺货 −50%、v1.5 缺货 −20% 就算好）。否则就是工程师在 v1.5 替 PM 接锅。

---

### E-PM-5 · §10.2.4 "海/空运报价 ±X%（X 待定）"—— 这个 X 直接影响 FR-4 重跑频率，不能"待定"

**引用原文**（r1-pm.md §10.2.4 步骤 1）：
> "监控发现海/空运报价 ±X%（X 待定） | 推送 + 重新跑当日优化 | 影响今日决策的 SKU 标红"

**工程师看到的问题**：
- 我在 r1-engineer.md §5.5 FR-4 边界数值写了"单次求解时长上限：1800 s（30 min）"，"并发任务上限：1"。**如果 X 太小（如 5%），货代报价一波动就触发重跑，单实例排队会爆**——海运报价日内波动 5%-10% 是常态。
- 如果 X 太大（如 30%），日内基本不会触发，等于这条规则形同虚设。
- **X 这个参数直接关联工程容量预算**，不能写"待定"丢给后端。我倾向 X = 15%（参考 r1-architect.md §3.4 灵敏度分析 sea_rate ±20% 是决策切换点），低于这个值的波动不重跑（标黄但不动决策），≥15% 才触发重跑。
- PM 应该跟架构师 §3.4 的灵敏度阈值对齐——**灵敏度告诉你"决策对参数有多稳"，预警阈值就该用这个数**，不要拍脑袋。

**建议**：X = 15%，且明确"日内同一路线最多触发 1 次重跑"（防货代连续小步刷价导致循环重算）。这是 FR-8 的边界，不是 §10.2.4 的"待定"。

---

### E-PM-6 · §10.4 推送渠道 v1 三选一（企微/Bark/TG），但 FR-8 的实现成本 = 3 个渠道 × adapter + 模板，是 1 个的 3 倍工时

**引用原文**（r1-pm.md §10.4）：
> "v1 企微应用 / Bark for iOS / Telegram 任选其一（CEO 配置）"

**引用原文**（r1-pm.md 边界 B-4）：
> "v1 先实现 1 个（推荐 Bark，最便宜最合规），其他延后"

**工程师看到的问题**：
- PM 已经在边界 B-4 自己提出"v1 先实现 1 个"的折中——**但正文 §10.4 仍写"任选其一"，"任选"≠ "只实现一个"**。"任选其一"在 PM 语义里是"CEO 配置时三选一"，在工程语义里是"三个 adapter 都得实现否则配置不出来"。
- 我在 r1-engineer.md §5.9 FR-8 已经写了"默认企微应用 / Bark / Telegram；每渠道独立模板；失败 fallback 到下一个渠道"——这暗示了**三个都做+fallback 链**。架构师 r1-architect.md §9.B 也写"多通道并行（至少 2 个）"。
- **三方加起来等于 v1 必做 3 个渠道**。我反对。
- 实际工程量差异：
  - 1 个渠道：~3 天（Bark 是最简单的 HTTP POST）
  - 3 个渠道 + fallback 链 + 失败重试 + 模板隔离 + 推送状态持久化：~2-3 周

**建议**：v1 硬性 1 个渠道（Bark），架构师 §9.B "多通道并行" 推到 v1.5。PM 正文 §10.4 改成"v1 仅 Bark；v1.5 增加企微/TG"，跟边界 B-4 自洽。

---

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

### E-ARCH-1 · §3.2.3 性能预算"日常每日 < 5 分钟"与 §3.5.4 "5 场景 900K 变量需 10-30 分钟"自相矛盾

**引用原文**（r1-architect.md §3.2.3）：
> "日常每日跑（baseline）| 200 | < 5 分钟 | 15 分钟（硬超时）"

**引用原文**（r1-architect.md §3.5.4）：
> "5 场景：900K 变量（stage-1 共享，stage-2 ×5）"
> "CP-SAT 经验：900K MILP 在 8 worker 上约 10-30 分钟。性能预算仍可行，但接近边界"

**工程师看到的问题**：
- §3.2.3 的"baseline < 5 分钟"用的是 200 SKU 单场景规模（72K 变量）。
- §3.5 引入场景法 robust 优化后规模变成 900K 变量，§3.5.4 自己估计 10-30 分钟。
- **架构师在同一篇文档里给出了两个相互矛盾的求解时长**——5 分钟 vs 10-30 分钟，相差 2-6 倍。
- 我在 r1-engineer.md §5.5 FR-4 写"单次求解时长上限：1800 s（30 min）"——**这是把硬超时定到了 30min**，已经覆盖了 §3.5.4 的"30 分钟接近边界"情况，但**完全打破了 §3.2.3 的"硬超时 15 分钟"承诺**。
- 调度上的影响：如果每日批跑要 30min，前面还有数据接入 + 预测 + 后处理 + 灵敏度，总时长可能 1.5-2h，**凌晨 23:30 PT 启动 → 完成时刻 ≈ 美东 04:30 / 北京 09:30**，赶不上 PM US-1 "早上 9:00 看日报"。

**建议**：架构师 R2 必须统一：
- 要么承认引入场景法后基线 = 15-30min，§3.2.3 表格的"5 分钟"删了；
- 要么 v1 暂不上 5 场景（先点估计 + 安全 buffer），§3.5 推到 v1.5。
- 我倾向后者：v1 用点估计 + 灵敏度作为 robustness 的近似，5 场景法跟 r1-engineer.md §5.5 写的"v1 用 p50 求基础解；用 p10/p90 各跑一次得到'乐观/悲观'对照解"对齐——这就是 3 次单场景求解，不是 5 场景联合求解，规模上小得多。

---

### E-ARCH-2 · §3.2.2 "选 CP-SAT" 的对比表里 SCIP "中等偏弱"，但 r1-engineer §5.5 已经默认 SCIP

**引用原文**（r1-architect.md §3.2.2 选型表）：
> "OR-Tools CP-SAT ... ✅ 首选"
> "SCIP ... 🟡 备选"

**引用原文**（r1-engineer.md §5.5 FR-4 交互逻辑 1）：
> "求解器选型（响应工程 R3 N1）：v1 默认开源 SCIP（Python via `pyscipopt`）；如 license 允许 fallback Gurobi"

**工程师看到的问题**：
- **架构师和工程师对 v1 求解器选择不一致**：架构师 CP-SAT，工程师 SCIP。
- 这不是小分歧——CP-SAT 和 SCIP 的建模 API 完全不同（CP-SAT 是约束编程范式，SCIP 是经典 MILP branch-and-bound），代码不能共用。**选错一个 = 全部建模代码重写**。
- 我（工程师）选 SCIP 的理由：PySCIPOpt 跟 Pyomo / PuLP 生态兼容，调试工具链成熟；CP-SAT 对"启动成本/最小批量"这类约束确实表达力强，但 Python 封装的可观测性弱（求解日志不结构化，gap 跟踪麻烦）。
- 架构师选 CP-SAT 的理由（§3.2.2）：约束编程范式友好，并行调度好。也有道理。
- **但两个 R1 不对齐 = v1 第一周开工就得停下来重选**。这是个必须 R2 当场拍板的硬冲突，不是边界小问题。

**建议**：R2 联席讨论后二选一，并且**先选定的人写一个 200 SKU × 13 周的 spike POC** 跑实际性能数据，不要纸面论证。我倾向 SCIP，但服从 spike 结果。

---

### E-ARCH-3 · §9.C 可扩展性"1000 SKU 估计 1-3h"——但 PM §10.4 兼容性已声明 v1 仅 200 SKU、v1.5 不承诺扩展

**引用原文**（r1-architect.md §9.C）：
> "MILP 求解时间 | 200 SKU: 5-15 min | 1000 SKU 时: 估计 1-3h"

**引用原文**（r1-architect.md §9.C 判断）：
> "v1 架构对 500 SKU 友好；600-800 SKU 是黄线；1000 SKU 必须切求解器（Gurobi）或改全局优化为'SKU 分组顺序求解'"

**引用原文**（r1-pm.md §10.4）：
> "SKU 规模 | v1 支持 200 SKU；v1.5 不承诺扩展（如做 SaaS 是另立项目）"

**工程师看到的问题**：
- PM 已经划界：v1 = 200 SKU，v1.5 不扩展。
- 架构师 §9.C 整张表围绕"200 → 1000 SKU"做容量规划——**对一个明确不扩展的项目做 5 倍容量预测，是过度工程**。
- 更危险的是 §4.5.2 "tenant_id + RLS"软隔离 + §9.C "Tenant 数: 1 → 100+" → 架构师**已经为多租户 SaaS 在做架构投资**。这跟 PM 的"v1 自用 / v1.5 自用"完全脱节。
- 引用 r1-architect.md 自己的边界 E12：
  > "若 v1.5 不打算 SaaS，多 tenant 设计是过度工程，需 PM 确认"
  架构师自己也意识到了，但 §4.5.2 已经把 tenant_id 写进了 schema 设计，每张表都加 `tenant_id` 字段 + RLS 强制——**写了就改不掉了**（schema 改动是高成本变更）。
- 工程后果：tenant_id 索引必须做、所有查询必须加 tenant filter、ORM 必须强制注入——**为不存在的 SaaS 多付一倍工程税**。

**建议**：v1 数据模型**不加 tenant_id 字段**，mock/real/shadow 三种模式用独立 schema 隔离即可（PostgreSQL 三个 schema：`mock`、`real`、`shadow`）。这跟 r1-engineer.md §5.11 FR-10 "Mock / Real 模式数据物理隔离（独立 schema 或独立 DB）" 自洽。等到 v1.5 确定要做 SaaS 时再加 tenant_id，那是一次合理的迁移成本，不是 v1 必须付的。

---

### E-ARCH-4 · §4.4.1 "凌晨跑批 23:30 PT 触发" 与 PM US-1 "早上 9:00 BJ 看日报"——美西夏令时切换日会撞死

**引用原文**（r1-architect.md §4.4.1）：
> "凌晨跑批的时刻按'美西时间 23:30'触发（因为 95% 销量在美西时区聚合）"

**引用原文**（r1-pm.md US-1）：
> "每天早上 9:00 打开一份按总收益排序的发货清单"

**工程师看到的问题**：
- 美西 23:30 → 北京时间冬令时（PST）= 次日 15:30；**夏令时（PDT）= 次日 14:30**。
- CEO 北京时间 9:00 看日报 → 9:00 BJ = 美西 17:00 前一天（PST）/ 18:00（PDT）。
- **23:30 PT 启动跑批 → 完成时刻 = 第二天 01:00-04:00 PT = 北京时间 16:00-19:00 当天**。**根本来不及让 CEO 在北京 9:00 看到当天清单**——他看到的是**昨天**北京时间 16:00 跑的清单，已经隔了 17 小时的数据。
- 正确的时刻应该是：CEO 9:00 BJ = 当天 17:00 PT 前一天 → 跑批必须在前一天美西 16:00 之前完成 → 启动时刻 = 前一天 PT 12:00-14:00（如果跑 2-3h）。
- **但 PT 14:00 还没出当天美西销售数据**（当天美西销售在 24:00 PT 关账才完整）→ **这是死循环**：要数据完整必须等到 PT 24:00，要 9:00 BJ 出报必须 PT 16:00 前出，差 8 小时。
- 加上夏令时切换日（3 月第二周日 / 11 月第一周日），cron 时刻每年要手动调整两次，否则那天的日报偏移 1 小时。

**建议**：
1. 重新定义"今日数据" = **昨日美西全天 + 今日截至 BJ 9:00 的实时库存**。算法上跑两份：一份用昨日数据（D-1），一份增量校准今日库存。
2. cron 用 UTC 表达式 + IANA tz 库（不要硬编码 "23:30 PT"），夏令时自动跟随，且要写测试覆盖切换日。
3. 这点在 r1-architect.md §9.A 的 A4 "销量日期用本地、时间戳用 UTC（双日期系统）" 中触及，但**没把"美西夏令时切换日"作为独立异常 case 列出**。FR-1 / FR-4 必须有切换日的 e2e 测试。

---

### E-ARCH-5 · §4.4.2 "采购成本字段加密 + 助理脱敏" 在 r1-engineer §5.8 FR-7 完全没有落实

**引用原文**（r1-architect.md §4.4.2）：
> "采购成本 / 利润率属敏感商业数据：
> - 数据库字段加密静态存储（应用层 AES-GCM，密钥走 KMS）
> - UI 渲染时按角色脱敏（助理视图不显示 unit_cost 和 expected_profit）"

**引用原文**（r1-engineer.md §5.8 FR-7 助理操作视图 界面元素）：
> "待办列表 | Table | 按'截止时间'升序；列：SKU/数量/物流/截止/CEO 备注/状态"

**工程师看到的问题**：
- 架构师明确"助理视图不显示 unit_cost / expected_profit"。
- 我（工程师）在 FR-7 助理视图列定义里**列了 SKU/数量/物流/截止/CEO 备注/状态——没有 unit_cost、expected_profit**，看似 OK。
- **但**: r1-engineer §5.7 FR-6 决策清单（CEO 视图）有"预估收益"列，可解释面板有"6 项收益/成本分解（含利润）"；FR-15 §5.16 "导出工厂下单建议 CSV" 也可能含成本。**助理如果拿到 CEO 的截图、或者通过"退回 CEO" 功能看到 batch 内某条的详情、或者在共享会议屏幕上看到——绕过了角色脱敏**。
- 更要命的是：r1-engineer §5.11 FR-10 "数据物理隔离（独立 schema 或独立 DB）"——schema 级隔离 ≠ 字段加密。**架构师说的是"DB 字段 AES-GCM 静态加密"，工程师实际写的是"schema 级 + 助理 role 过滤列"——两套机制不等价**。如果数据库被直接拖库（OS 层漏洞），schema 隔离形同虚设；AES-GCM 才能防。
- 而且 KMS 集成（密钥轮换、加密性能损耗、备份恢复时密钥可用性）r1-engineer 全篇没提，**这是个隐藏的几周工程量**。

**建议**：R2 必须明确"加密 vs 列脱敏"两套机制 v1 各做哪一套：
- 我倾向 v1 **只做应用层列脱敏（按 role 控制返回字段）**，不上 KMS + AES-GCM 静态加密（自用项目过度工程）。
- 架构师 §4.4.2 的"AES-GCM 静态存储"推到 v1.5（如果做 SaaS 才需要）。
- 这条要写进 r1-engineer §5.x 的"5.1 通用约定"表里，作为统一规则。

---

### E-ARCH-6 · §3.5.3 "CVaR 约束 user_tolerance 三档" 完全没在 r1-engineer §5 任何 FR 的界面元素表里

**引用原文**（r1-architect.md §3.5.3）：
> "用户在 UI 上可调 `user_tolerance`（'保守 / 平衡 / 激进'三档），架构师只暴露接口，业务由 PM 章节定义"

**引用原文**（r1-architect.md 边界 E1）：
> "§3.5 CVaR 风险偏好（保守/平衡/激进三档）| PM | PM 章节会定义这个用户参数的'业务命名'和默认值；我只暴露接口"

**工程师看到的问题**：
- 架构师把球踢给 PM（"业务命名归 PM"）。
- **但 PM 的 r1-pm.md 全篇没有 CVaR / user_tolerance / 风险偏好 任何字眼**。我搜了 §1/§2/§8/§10/§11，零提及。
- 这正是任务要求的第 5 点："架构师的数据治理是否落到我 §5 界面元素表里？还是只是写在 §4 没实现？" —— 这条**架构特性架构师设计了、PM 不知道、工程师没界面落地** → 三方都飘在 §4 的算法描述里，没有 §5 的元素表来兜底。
- 后果：v1 上线时这个参数要么硬编码"平衡"档（架构师的设计被弱化为单点），要么需要新加一个"风险偏好"设置项（PM/设计/前端都没规划过），要么干脆删了（架构师的 CVaR 章节变成 dead code）。
- 类似的"飘着"的还有：
  - §3.3 参数版本号 → r1-engineer §5.4 FR-3 参数管理页有"参数变更历史 Timeline"——**这条 OK 落地了**。
  - §4.4.3 "数字字段全部用 decimal 而非 float" → r1-engineer §5.4 FR-3 边界数值"浮点容差 1e-6 USD"是一致的，OK。
  - §4.4.3 "货币显式分两列：amount + currency(ISO 4217)" → r1-engineer §5.1 通用约定里有"原值以销售站点币种存储"但**没明确字段拆两列的硬约束** → 半飘。
  - §6.2.3 "系统运行档位 green/yellow/orange/red/black" → r1-engineer §5.7 FR-6 "决策任务跑挂时显示'昨日 11:23 决策'+ 红条" 只覆盖了 red 档，**black 档（人工模式）UI 完全缺失**。

**建议**：R2 集成时要做一次"§4 架构特性 → §5 界面元素"的反查 checklist，重点补：
1. CVaR user_tolerance 三档（建议放在 FR-3 参数管理页"全局参数"区块）
2. 系统降级档位 5 档徽章（建议放在 FR-6 顶部摘要卡片旁，紧贴 Mock/Real 徽章）
3. currency 双列硬约束（写入 §5.1 通用约定表）

---

### E-ARCH-7 · §3.2.4 退化方案"档 2 SKU 解耦近似 → 失去 5-15% 全局最优"，但 §3.5.3 CVaR 又依赖全局最优——降级时 CVaR 约束怎么办

**引用原文**（r1-architect.md §3.2.4 档 2）：
> "第二档：SKU 解耦近似 — 把全局资金/容量约束松弛为'按 SKU 配额预分', 每个 SKU 独立求解。代价：失去全局最优性，资金分配可能次优 5-15%"

**引用原文**（r1-architect.md §3.5.3）：
> "最差 25% 场景下的平均缺货损失 ≤ user_tolerance"

**工程师看到的问题**：
- 档 2 解耦后**每个 SKU 是独立 MILP**，无法计算"全局最差 25% 场景"——CVaR 约束本质是跨 SKU、跨场景的联合约束。
- 这意味着**降级到档 2 时 CVaR 约束失效** → user_tolerance 设的"保守"档变得无意义 → 系统给出的"次优 5-15%"决策可能恰好在"最差 25% 场景"里大幅缺货 → **用户被告知"系统在档 2 已尽力"，但实际承担了风险偏好被默默关闭的代价**。
- 这是个 silent failure，UI 即使显示了"档 2 橙色"，用户也不会知道"档 2 = CVaR 失效"。
- r1-engineer.md §5.5 FR-4 异常场景里 infeasible 处理是"自动放松软约束（按优先级：先放总资金 +20%，再放 Restock Limit）"——**没有提到 CVaR 约束的放松优先级**，意味着实现时可能比"全局资金"还先放，反而最严的风险约束最先丢。

**建议**：架构师 R2 在 §3.5.3 加一句"降级到档 2 (SKU 解耦) 时，CVaR 约束转为单 SKU 保守 buffer（如 P10 销量 + 20% 安全 stock），不再做跨 SKU 全局风险控制；UI 必须明示'风险偏好暂时降级为单 SKU 保守'"。这是 5.7 FR-6 顶部摘要卡片的额外文案需求，工程师才能正确实现降级时的用户告知。

---

### E-ARCH-8 · §4.4.5 保留策略与 r1-engineer §5.2 FR-1 数据保留不一致

**引用原文**（r1-architect.md §4.4.5）：
> "销量/库存原始快照 | 5 年 | 5 年后冷存 S3 Glacier"
> "决策建议 + 用户动作 | 2 年 | 2 年后冷存"

**引用原文**（r1-engineer.md §5.2 FR-1 边界数值）：
> "数据保留：原始快照 90 天，归档冷存（S3 Glacier）至 2 年"

**工程师看到的问题**：
- 架构师：原始快照 5 年；工程师：90 天 + 归档 2 年。**冷热分界点和总保留时长都不一致**。
- 对存储成本和合规都有影响：5 年 vs 2 年差 2.5 倍。
- 架构师 E6 自己提了"保留时长有合规和存储成本权衡，需 PM 拍板"——但 PM r1-pm.md 没回应（§10.4 / §10.5 完全没提保留时长）。
- 我的 90 天热存设计是基于"v1 决策窗口 = 90 天滚动" + "回测最长跨 90 天" 推出来的，超过 90 天的原始快照对每日决策无意义。但**架构师视角是合规/审计/事后追溯**（"销量/库存 5 年 财务/税务"），这视角我承认我没考虑。

**建议**：
- 原始快照：**热存 90 天（FR-1 满足）+ 冷存 5 年（架构师要求）**，分两段管理，存储成本可控。
- 决策建议 + 用户动作：**热存 2 年（架构师），跟 §5.7 FR-6 "操作日志：永久保留" 冲突——永久太重**。建议 2 年热 + 永久冷存，且"永久保留"改成"5 年冷存"。
- 这条 R2 PM 必须正面拍板（合规要求是什么——卖家所在国增值税审计要求一般 5-7 年）。

---

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