题目重点：先降低最关键不确定性，再逐步承诺交付范围。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 使用本人实际经历与可公开数据，团队scope、本人决策及他人贡献分清；没经历过的情况可说明，不能编造成功或失败故事。
- 案例没有通用唯一标准答案。结果指标没有可靠baseline就用可审查的交付/反馈证据，不捏造数值。
解题路线
- 说明不确定性来自用户目标、技术可行性、数据或组织依赖，不仅说没有文档。
- 先列已知/未知及关键stakeholder，找到能改变方案的最重要假设。范围澄清是决策过程，不是无限开会等待所有答案。
- 用小原型/样本分析/用户访谈验证高风险假设，再给最低可交付scope和验收。原型只证明技术可行，不自动证明产品价值。
- 在信息未全齐时明确可逆决策、风险owner和检查点，按验证结果调整。与合作方持续更新scope，不能把假设当确认需求直到上线失败。
- 结果讲交付和后来哪些假设不成立，如何处理而不掩盖。自己解决模糊应有主动行动和反馈，不是孤立闭门决定所有事。
手动走一遍
用户说“需要更好搜索”，先确认找不到什么、何时失败、如何衡量，再决定检索/界面/数据改哪层。关键数据不可用时先做有界验证，保留后续架构变化，而非承诺完整模型效果。
规模与取舍
主答2分钟，项目深挖可扩5–10分钟；准备1页系统/责任图与关键取舍，信息密度取决于与问题相关的证据，而非项目数量。
易错点与追问
容易失分的边界
- 把无需求理解成可随意加功能。
- 原型成功后跳过真实用户验证。
继续深挖
- 哪条假设被推翻后影响最大？
- 无法获取关键信息但deadline近，你怎样收缩承诺？
