题目重点：先分清目标、约束和依赖的不确定性，再用短周期验证与决策记录推进，而不是等完美需求。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 只使用本人真实经历；本文场景为虚构练习，不应替换成自己的履历事实。
- 团队规模、结果数值、决策权和时序必须可解释；没有实际测量就说明证据局限。
- 回答先给约两分钟主线，再按追问展开；职级和团队会改变所需影响范围。
解题路线
- 先描述模糊在哪：目标不一致、成功指标未定、依赖不明确或技术未知。单纯任务很难不等于模糊，先给一个当时不知道但会改变行动的问题。
- 把事实、假设和待决策分开；列最关键的两三个未知及其影响，不通过长需求文档掩盖没人负责拍板。
- 给出可逆的小步：用户访谈、数据抽样、原型或接口spike，每步设时间盒与验收证据。先解决会改变方向的未知，避免在枝节上耗尽deadline。
- 明确与谁达成合同：成功标准、范围、必须满足的风险边界、Owner和决策时间。需求变化记录版本，不能上线后用新指标解释原来的承诺。
- 不确定仍无法消除时说明行动阈值与后备方案，比如先限定用户群或延后不可逆迁移。不能以“需求不全”为理由停止全部工作，也不能无授权自行定义业务目标。
- 结果不仅看最终交付，还看哪些假设被推翻、返工如何控制。展示一次自己澄清错方向后及时调整的证据，更能解释机制是否有效。
手动走一遍
练习场景：任务是“提升搜索体验”，没有目标。你先和PM确认先优化无结果查询，抽样检查10类原因，再做一个可回滚的小流量实验；不直接上新模型。回答要说抽样如何改变了优先级，以及后来如何验收，而不是仅列过程名称。
规模与取舍
主线按未知→验证→合同→交付组织。时间/资源约束是推进条件，不能把所有未知都列成必须等齐的前置。
易错点与追问
容易失分的边界
- 把技术难度当需求模糊。
- 等待需求完美才行动。
- 越权替业务定义最终目标。
- 不停调范围却不重置验收。
继续深挖
- 哪项未知最值得先验证？
- 业务Owner无法决定时怎么办？
- 你的假设被否定后如何调整？
- 怎样防止小步原型成为永久架构？
