# 产物研讨正反例

正例展示如何帮助用户做方向性决策，不代表默认选择。结论必须由项目事实和用户确认形成。

## 正例

- 已知事实：移动端 3.8 仍有 42% 活跃用户，客户端枚举反序列化遇未知值会失败。
- 客观约束：本次发布不能强制所有客户端同步升级。
- 待决策：取消流程是否新增公开状态。
- 方案 A：API v1 映射为旧状态，v2 暴露新状态；兼容性最好，但需维护版本映射。
- 方案 B：所有版本直接返回新状态；实现简单，但会破坏现有客户端。
- 推荐：方案 A，因为满足不可强制升级的约束；当 v1 活跃占比低于 5% 再评估移除映射。
- 需用户确认：是否接受维护 v1 映射至少一个发布周期。

## 反例

- 我们可以用微服务、单体或 Serverless。
- 推荐微服务，因为更先进。
- 请确认。

问题：没有事实、真实约束、与目标相关的取舍、证伪条件或迁移成本，只是在罗列名词。

## 拍板沉淀正反例

正例（约束性拍板即时沉淀）：

- 用户确认：同页多形态表单一律右抽屉，不用弹窗。
- 当场调用 `sf_knowledge add`：标题「同页表单形态右抽屉纪律」，triggers 从讨论词派生（表单/弹窗/抽屉/形态），正文含结论、理由、反例边界（详情页例外及条件）。
- 规则可正则判定（禁 `el-dialog` 直接用于表单），加 `--pattern` 附一段含违规形态的样本，升级 L0 执法；作为项目拍板加 `--announce`，CLAUDE.md 索引行生成，下一轮生效。

反例（拖延形态）：

- 用户确认：同页多形态表单一律右抽屉。
- 「好，记下了，交付时一起沉淀进知识库。」随后继续实现，交付时只记得「表单要用抽屉」，理由（嵌套子弹窗切段必错）、边界（详情页例外）、反例形态均已流失，沉淀出的条目缺少可执行约束。

问题：拍板发生在热时刻（理由、边界、反例全在上下文里），交付是冷时刻；沉淀时机后移等于放弃最容易写对的机会。约束性拍板确认后当场沉淀；非约束性的探索结论不需要。

## 研讨结论形态反例

- 新拍板直接覆盖旧结论段——三个月后没人说得清当初为什么改，也没人敢再改（不知道会破坏什么）。
- 备选方案被毙后整段删除——下次遇到同类取舍从零论证，且无法解释「为什么不是它」。

问题：研讨的价值一半在结论，一半在「排除了什么」；删历史等于丢掉后一半。

## 迁移到当前项目

替换目标、硬约束、候选项、成本和触发器。不要保留示例推荐；先用当前代码、运行数据、业务目标和用户偏好重新推导，价值判断由用户确认。