题目重点：先证明问题值得解决，再讨论技术方案和投入。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 讲真实跨职能经历，区分你的职责与PM/设计/数据团队贡献。
- 不把技术新颖度当用户价值，也不虚构用户访谈/AB结果。
解题路线
- 提出想法先给观察与用户痛点，量化如果有基线。解释为什么现在值得做，影响哪些用户和已有目标，而非上来推一个新框架。
- 给至少两个选择，包括不做或较小替代，比较实现时间、风险、预期收益和机会成本。PM反对时先确认优先级/证据缺口，而不是把反对归因技术不懂。
- 设计最小试验：明确假设、招募/流量范围、可测指标、成功/停止条件。原型或shadow mode可验证工程可行性，但不能替代用户价值验证。
- 闭环说明决定和结果：可能采用、修改或放弃。被否决的正确提案不一定说明沟通失败；若证据后来变化，更新判断并尊重已定优先级。
手动走一遍
想做更智能搜索，先报告用户找不到内容的具体路径，再提小范围候选召回实验，不以“接LLM很快”作为立项理由。PM担心延误主要项目，可提可回收的一周验证和明确退出条件，实际时间按本人经历讲。
规模与取舍
主答2分钟，准备问题证据、备选、试验、决策结果；实验预算与样本需针对效应，不写通用万能AB人数。
易错点与追问
容易失分的边界
- 把争论胜利当项目成功。
- 只展示架构没有说明用户是否需要。
继续深挖
- PM同意但设计团队反对时，你怎样对齐验证问题？
- 试验无显著提升，你如何决定继续还是停？
