有些事情，我已经拖了很久。
不是不知道重要。
恰恰相反。
就是因为太重要，所以一直没有真正开始。
想做一个长期项目。
想认真写一套东西。
想学习一个新的方向。
想把自己的知识系统重新整理一遍。
想开始运动。
想做一个副业。
想建立一个属于自己的长期资产。
每一件事情，开始的时候都觉得：
“这件事值得认真做。”
然后我就开始认真规划。
要不要先把资料收集完整？
是不是应该先把方法研究清楚？
工具是不是应该先选好？
是不是应该先设计一个完整的体系？
有没有更好的方案？
结果研究了很久。
规划了很久。
收藏了很多资料。
最后真正做的事情：
几乎没有。
后来我突然意识到：
这其实很像程序员第一次做一个新系统。
我们很容易一上来就想着：
架构怎么设计。
数据库怎么建。
服务怎么拆。
权限怎么做。
监控怎么接。
未来怎么扩展。
结果架构图画完了。
代码一行没写。
所以我开始重新理解一个词：
MVP。
Minimum Viable Product。
最小可行产品。
但后来我发现：
这个概念不只适合创业。
它同样适合解决人生里那些：
“我已经想了很久，却一直没有开始”的事情。
很多拖延，不是懒
以前我会把拖延理解成：
“我自制力不够。”
“我执行力太差。”
“我就是容易拖。”
但现在我觉得，很多拖延其实不是动力不足。
而是：
启动成本太高。
你告诉自己：
“我要开始写作。”
大脑听到的可能不是：
今天写500字。
而是：
我要建立个人品牌。
我要持续输出。
我要研究定位。
我要确定选题。
我要建立内容体系。
我要做公众号。
我要做小红书。
我要做视频。
我要考虑商业化。
一下子变成了一个巨大的项目。
于是大脑很自然地得出一个结论：
先等等。
我们经常把“第一步”设计得太大
比如：
想运动。
第一反应：
办健身卡。
制定训练计划。
买装备。
研究饮食。
安排每周训练。
记录体脂。
制定三个月目标。
结果一个星期以后：
没去了。
想写文章。
第一反应：
确定定位。
研究竞品。
规划栏目。
设计视觉。
建立知识库。
做内容日历。
研究平台算法。
结果：
一篇文章都没有。
想做副业。
第一反应：
寻找赛道。
研究商业模式。
设计产品。
建立品牌。
做网站。
做增长。
想得越来越完整。
行动越来越遥远。
这就是一个非常典型的工程问题：
我们把一个简单的启动任务，错误地设计成了一个完整项目。
MVP真正解决的，不是“做得少”
这是我后来对MVP最大的一个重新理解。
MVP不是：
“随便做一个差不多的东西。”
也不是：
“先做个垃圾版本。”
它真正解决的是：
在不投入大量资源的情况下，验证一个想法到底值不值得继续。
这句话放到人生里也一样。
当你想做一件拖延很久的事情时，不要问：
“我怎样才能把它做好？”
先问：
“如果只允许我做一个最小版本，我需要做到什么程度，才能证明自己真的开始了？”
这两个问题，会把你的行动成本直接拉下来。
我开始给自己的事情设计“人生MVP”
比如我想写东西。
以前的版本：
建立完整内容体系
↓
确定长期定位
↓
研究平台
↓
研究用户
↓
建立选题库
↓
设计视觉
↓
制定发布计划
↓
开始写这个流程的问题是：
真正的输出被放到了最后。
现在我会反过来：
想到一个问题
↓
写500～1000字
↓
发布
↓
看看真实反馈
↓
再决定下一篇先让系统跑起来。
然后再优化。
MVP的核心不是“小”，而是“可验证”
这一点特别重要。
如果你只是把事情做得很小，但没有办法获得反馈，它依然可能只是自我消耗。
比如：
你花三天整理了一个漂亮的知识库。
它很完整。
很漂亮。
分类也很合理。
但是：
你没有真正使用它。
那它验证不了任何东西。
所以一个真正的MVP应该至少回答一个问题：
“我到底想验证什么？”
例如：
想做内容。
验证：
我是否能持续写？
想做课程。
验证：
有没有人愿意为这个问题付费？
想做副业。
验证：
有没有真实用户愿意使用我的东西？
想学习新技能。
验证：
我能不能用它解决一个真实问题？
想运动。
验证：
我能不能连续坚持四周？
注意：
MVP不是为了证明自己很厉害。
而是为了获得真实反馈。
有时候，最好的MVP甚至不是一个产品
它可能只是一个动作。
这是我觉得特别有意思的地方。
比如：
你一直想开始写作。
MVP不一定是：
写出一篇完整文章。
甚至可以只是：
连续7天，每天写200字。
你一直想做个人项目。
MVP不一定是：
开发一个完整产品。
可以只是：
做出一个最简单的页面，让一个真实的人使用。
你一直想学习AI。
MVP不一定是：
系统学习所有AI技术。
可以只是：
用AI解决一个自己每天都会遇到的问题。
你一直想锻炼。
MVP不一定是：
每周训练5次。
可以只是：
今天出门走20分钟。
因为真正需要突破的，不是任务本身。
而是：
从0到1。
0和1之间，才是最难的地方
程序员应该特别理解这一点。
一个项目：
0 → 1和：
1 → 100完全不是一个难度。
0意味着：
没有代码。
没有用户。
没有反馈。
没有数据。
没有经验。
没有路径。
所以你面对的是巨大的不确定性。
而一旦出现第一个版本：
哪怕很粗糙。
你就开始拥有：
真实反馈。
真实问题。
真实用户。
真实数据。
真实经验。
于是后面的优化才有意义。
所以：
人生里很多事情，不是需要你先想清楚再开始。
而是：
你必须先开始，才能获得足够的信息去想清楚。
不要优化不存在的东西
这是程序员很容易犯的一个Bug：
过度设计。
系统还没有用户。
先考虑未来一千万用户怎么办。
功能还没有验证。
先考虑微服务架构。
代码还没有运行。
先考虑未来怎么扩展。
人生也是一样。
一件事情还没有真正开始。
我们已经开始考虑：
三年以后怎么办。
五年以后怎么办。
规模扩大怎么办。
商业化怎么办。
如果失败怎么办。
如果成功怎么办。
然后越来越复杂。
最后：
不动了。
所以我现在会提醒自己一句：
不要优化一个还不存在的问题。
如果第一篇文章都还没写出来，就不用先研究100篇文章之后怎么管理。
如果第一个用户都还没有，就不用先设计百万用户架构。
如果一次运动都没有开始，就不用先研究完整训练周期。
MVP还有一个重要原则：允许丑陋
很多事情迟迟开始不了，还有一个原因：
我们希望第一次就做得很好。
第一篇文章要有深度。
第一个产品要漂亮。
第一次表达要专业。
第一次尝试不能犯错。
第一次发布不能没人看。
于是：
宁可不做。
因为：
不做，就不会失败。
这其实是一种非常隐蔽的失败。
用“准备”保护自己不面对真实反馈。
MVP的价值就在于：
它天然允许你做一个不完美的版本。
甚至应该主动接受：
第一版就是不完美的。
因为第一版的任务，从来不是赢。
而是：
活下来。
给自己的事情设置一个“最小启动单元”
后来我开始尝试一个很简单的方法。
每当有一件事情拖了很久，我都会问：
如果今天只能投入30分钟，我能做什么？
注意。
不是：
“30分钟能不能把事情完成？”
而是：
“30分钟能不能让它从0变成0.1？”
例如：
写文章：
打开文档，写标题和第一段。
学习：
只看一个核心概念，并做一个小实验。
做产品：
先做一个页面。
整理知识：
只整理一个主题。
做副业：
联系一个潜在用户。
运动：
穿鞋出门。
读书：
读10页，并写一句自己的理解。
这些事情看起来都很小。
但它们有一个共同点：
可以真正改变系统状态。
从：
Not Started变成：
Started这个变化非常重要。
我现在特别警惕“准备完成”
还有一个很容易欺骗自己的状态：
准备已经完成90%。
资料搜好了。
工具选好了。
课程买好了。
笔记建好了。
文件夹建好了。
模板做好了。
计划写好了。
但是事情还是没开始。
这时候我会问自己：
如果现在删掉所有准备工作，我还能不能用一个最简单的方式完成第一次真实行动？
如果答案是不能。
那说明：
我可能一直在准备，而不是在行动。
人生MVP可以有一个非常简单的公式
我现在会这样理解：
人生MVP
=
最小投入
+
真实行动
+
真实反馈
+
下一次迭代缺一个都可能有问题。
只有最小投入：
容易变成浅尝辄止。
只有真实行动：
可能盲目。
只有真实反馈：
可能被反馈牵着走。
只有迭代：
可能一直优化，却没有真正开始。
所以最重要的是形成一个闭环：
想法
↓
最小行动
↓
真实世界
↓
反馈
↓
判断
↓
下一版这其实就是工程思维。
拖延已久的事情，可以重新做一次“架构设计”
如果你现在有一件拖了很久的事情。
不妨不要再问：
“为什么我还没完成？”
换成下面几个问题：
这件事情真正要解决什么？
我到底想验证什么？
最小可行版本是什么？
如果只给我30分钟，我能做什么？
第一次真实反馈从哪里来？
什么结果意味着继续？
什么结果意味着调整？
什么结果意味着放弃？你会发现：
事情突然没有那么可怕了。
因为你终于不再面对一个巨大而模糊的目标。
而是在面对：
一个可以执行的实验。
我越来越相信：很多人生问题，其实都不需要一次解决
以前我总觉得：
一件事情开始了，就应该坚持到底。
所以每次想到一个新方向，我都会担心：
“万一选错怎么办？”
后来我发现：
MVP恰恰给了我们试错的权利。
你不需要现在就知道最终答案。
你只需要知道：
下一次实验是什么。
做一个版本。
跑一下。
看看结果。
然后决定下一步。
这比站在原地思考三年以后会发生什么，要可靠得多。
写给未来自己的代码注释
// 不要等待完美版本
// 先让系统启动
if (task.isDelayedTooLong()) {
question = "What is the smallest viable version?";
if (question.hasAnswer()) {
execute(question.answer());
}
}
// 不要追求一次成功
// 先获得一次真实反馈
while (system.isRunning()) {
feedback = observe();
decision = evaluate(feedback);
if (decision == CONTINUE) {
iterate();
}
if (decision == PIVOT) {
changeDirection();
}
if (decision == STOP) {
releaseResources();
stop();
}
}
// 0 → 0.1
// 比 0 → 100 更重要写在最后
40岁以后，我越来越不相信：
“等我准备好了再开始。”
因为很多时候：
你永远不会准备好。
真正的准备，不是把所有问题都想明白。
而是：
先拥有一点真实世界的反馈。
一篇文章。
一个产品。
一次运动。
一次尝试。
一个用户。
一次对话。
一个小项目。
它们都不需要一开始就很厉害。
它们只需要完成一件事情：
让你从0变成1。
以前我总觉得：
人生的重要事情，应该认真规划。
现在我觉得：
越重要的事情，越应该允许自己先做一个很小的版本。
因为只有启动以后，你才会知道：
这条路到底是不是自己的路。
这个方向到底有没有价值。
自己到底能不能坚持。
别人到底需不需要。
而这些答案：
坐在原地想，是想不出来的。
所以，如果你现在也有一件拖了很久的事情。
不要问：
“我什么时候才能把它做好？”
先问一句：
“如果今天只允许我做一个最小版本，我能不能让它真正发生一次？”
哪怕只有0.1。
也比停在0，要好。
因为人生很多新的版本，
都不是从完美开始的。
而是从：
第一次真正运行起来。
我是语霖。
执笔为语，心落成霖。
记录一个40岁程序员重新设计人生系统的过程。
这一阶段，我越来越想做的，不是把人生设计得无比完美。
而是：
先让那些真正重要的东西，一个一个跑起来。
然后，再迭代。