题目重点：将‘有无 curiosity’落到提问、验证、改变方案与客户结果，和处理生气客户的应急故事区分。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 好奇心用本人真实项目的行为证据回答，而非自评性格；案例可来自外部客户、内部用户或产品调研，但必须说明角色边界。
- 用户提的功能请求不一定等于真实需求，需要先核对工作流、失败成本和限制；不能为了探索而延误已知紧急问题。
解题路线
- 先讲初始表面需求与自己发现的不确定性，例如客户要更多报表，却无法解释哪项决策需要它。
- 给具体提问顺序：谁在什么任务中使用、当前替代办法、最常失败的步骤、出现频率和不可接受的结果；结合日志/现场观察验证，不只问‘你想要什么’。
- 提出可证伪假设和最小验证：样本、对照、成功标准、停止条件；如果证据推翻原假设，描述怎样改变方案并与客户重新对齐。
- 说明最终影响和知识沉淀：客户任务完成率、人工步骤、错误率或采用情况，以实际数字与时间窗为准；把发现记入产品需求/文档，使后续团队可复用。
手动走一遍
训练例子：客户要求按天导出审批数据；访谈发现真实阻碍是跨系统员工 ID 对不齐，报表再多也无法对账。团队先验证映射错误样本，再设计可审计的 ID 对照与少量导出字段。例子仅示范结构，不是题目经历。
规模与取舍
首答约 90 秒，备一条被推翻的原假设和一条验证材料；探索时间应与客户紧急程度相称，不给无依据的调研周期。
易错点与追问
容易失分的边界
- 只说‘我爱学习新技术’，没有客户问题或改变决策。
- 把客户模糊需求当确定方案。
- 只讲提问次数，不讲证据和结果。
- 未征得客户同意就查看敏感数据。
- 紧急故障时持续探索而不先止损。
继续深挖
- 你最初的假设哪里错了？
- 客户不愿接受调研时如何低成本验证？
- 如何区分一个人的反馈与普遍问题？
- 探索结果怎样影响产品优先级？
