一个功能到底先上 MVP 还是先做扎实？我用 3 个数字判断，想听听你怎么选

背景： 我做了 8 年技术产品经理，带过 3 个 0→1 的项目。每次排期会上，"先上 MVP 快速验证" 和 "干脆一次做扎实别返工" 这两派都会吵起来。有意思的是，同一个团队、同一个功能，最后选哪边，往往不取决于功能本身，而取决于当下面临的"未知在哪"。我想把这个判断标准摊开聊聊。

常见分歧 / 几种做法：

1. 激进派：先砍到最小闭环，3 天上线，用真实数据说话。理由是"验证一个假设的成本远低于想清楚它"。
2. 稳健派：先花 2 周把架构、边界、异常路径想全再写。理由是"返工一次的成本 = 重写 3 次"。
3. 折中派：先做核心链路 + 一个可观测埋点，边跑边补。

我的倾向与理由（给个可复现的判断法）： 我会问 3 个带数字的问题，而不是拍脑袋：

• 这个功能的"核心假设"能被多快的数据证伪？如果 1 周内的 100 个真实用户就能验证，那 MVP 的窗口就该压到 1 周内上线，而不是 2 周——因为验证的边际成本随时间线性上涨。
• 做扎实那部分，有多少是"可逆决策"？可逆的（如 UI 文案、默认参数）先随便上，不可逆的（如数据模型、计费口径）才值得花时间想。我一般用"10% 的不可逆点"作为阈值：不可逆点超过 10 个，就先做扎实。
• 团队当下对这条链路的"认知缺口"是 30% 还是 80%？缺口 > 50% 时，写代码不如先写一个 500 字的路径推演 + 找 3 个真实用户口述流程。

但我也见过反直觉的例子：有次一个"看起来很简单"的导出功能，MVP 上线后发现真实用户的导出量是我们预估的 20 倍，直接打挂了下游。这种"假设本身没验证错，但量级假设错了"的场景，MVP 反而帮了倒忙。

想听大家：

• 你在什么场景下会坚定选 MVP，什么场景下一定会做扎实？
• 有没有"量级假设错了导致 MVP 帮倒忙"的亲身经历？大概差了几倍？
• 你们团队用什么信号判断"可以开始做扎实了"？是数据阈值、还是某个用户反馈？

欢迎带具体数字和场景来聊，越具体越好。