题目重点：用最初假设、用户/质量信号和机会成本判断继续扩展、修复还是停止，展示真正的迭代闭环。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 以候选人真实项目为例，MVP 的成功标准应在发布前或尽早定义；不能把所有后续工作都包装成‘产品迭代’。
- 反馈可以来自用户访谈、使用数据、错误率或客户支持，但样本量与偏差要说明。
- 改进不总是加功能，也可能是稳定性、可访问性、成本或明确停止投入。
解题路线
- 说清 MVP 要验证哪一个风险最大假设，最小功能是什么、没有做哪些功能以及为什么。
- 发布后收集相反方向的证据：采用/完成率与错误/退款/工单，区分新用户与老用户，避免只看总体平均。若样本不足，用定性反馈补充但不夸大结论。
- 列两个以上下一步：修摩擦、增加能力、改定价/流程或停止；按用户影响、实现成本、风险和可逆性排序。
- 讲自己具体执行的一次改动、如何做小范围验证/回滚、与 MVP 基线对比的结果，以及下一轮仍未解决的问题。
手动走一遍
虚构训练例上线简化开户流程，注册转化升但资料校验错误也升。你不急着加第三种付款方式，而先定位错误来源、修文案和字段校验，再试点比较完成率与误填率。数字只能用真实项目数据填充。
规模与取舍
非算法题。至少给 MVP 假设、发布后两类相反指标、一次取舍和复测窗口；若只说‘根据反馈继续优化’，无可判断信息。
易错点与追问
容易失分的边界
- 把 MVP 当半成品却没有待验证假设。
- 只听最响亮的单个客户，不看整体与高风险人群。
- 后续改进全靠增加功能，不考虑质量/维护成本。
- 没有记录原基线，无法说明改进是否有效。
继续深挖
- 若采用率低但少数客户非常依赖，继续投入吗？
- 改进指标提升同时退款率变差，如何判断？
- 什么时候应停止迭代并关闭 MVP？
