问题：对代码的执着
做 MVP 时有一种常见的心理陷阱：
已经写了这么多了，改方向太可惜了，先把这版做完吧。
这种执着在 AI 出现之前有它的合理性——写代码是昂贵的，推倒重来意味着浪费大量时间和精力。所以人们倾向于保护已有的工作成果，哪怕方向已经偏了。
但这个逻辑的前提已经消失了。
原因：试错成本结构变了
AI 把编码成本压到接近于零。一个功能模块，过去可能需要几天，现在可能几小时甚至几十分钟。
这不只是”更快”，它改变了决策逻辑的基础：
| 过去 | 现在 |
|---|---|
| 写代码昂贵，要先想清楚再动手 | 写代码便宜，可以先动手验证再收敛 |
| MVP 做完要保护，改方向成本高 | MVP 验证完就可以扔，重写比修改还快 |
| 沉没成本是真实约束 | 沉没成本是心理幻觉 |
| 试错是奢侈品 | 试错是标准流程 |
当编码成本趋近于零，”已经写了多少”就不再是一个有意义的决策依据。
判断标准：资产在哪里
MVP 阶段真正的资产不是代码，而是验证结论。
代码是草稿。它的唯一用途是帮你跑通验证，从而得出一个结论：这个方向值得继续，或者不值得。
结论才是沉淀下来的东西。
这意味着：
- 不要问 “这段代码能不能复用”，要问 “这次验证得到了什么结论”
- 不要因为 代码写了很多就继续一个错误的方向
- 如果验证结果指向推倒重来，重来就是正确的选择，不是失败
陷阱：验证机制缺失
试错成本低，不代表验证成本低。
AI 降低的是”做”的成本，但”判断结果对不对”的成本并没有同步下降。如果验证机制缺失，低成本试错就会变成：快速地、自信地、大量地积累不确定性。
更危险的是确认偏误：跑通了流程、功能上线了、用户没投诉——这些都不等于”符合预期”。没有清晰的预期定义，就没有真正的验证，只是在用结果反推标准。
这带来一个前置条件：在试错之前，必须先定义”什么算成功”。
这个定义不能在试错之后补。事后补的标准会不自觉地向已有结果靠拢，看起来像验证，实际上是自我说服。
实践含义
MVP 的”M”（Minimum）的定义在变。
以前 Minimum 是”做到能用就行”——因为推倒重来太贵，所以要尽量让这版活下来。现在 Minimum 可以是”做到能验证就行”——验证完了，这版的使命就结束了。
正确的姿势是三步：
- 先定义假设：这次要验证什么，成功的标准是什么（必须在动手前写下来）
- 最小化实现：用最少的代码跑通验证路径
- 根据结论决策：继续、调整、还是推倒重来，都是正常选项
越执着于已有代码，越难做出基于验证结论的正确判断。AI 时代的 MVP，敢丢比敢做更难，也更重要。但丢之前，要确保你真的验证过——而不只是跑完了。