从「接需求写代码」到「自己决定做什么」，中间隔着的不是技术，而是几个思维习惯的转变。这一篇讲我体会最深的四个转变，以及每个转变对应的具体做法。
做独立开发最难的部分，不是写代码，而是「没人告诉你要做什么」这件事。我把它拆成四个具体的转变，每一个我都真实经历过。
转变一：从「怎么做」到「做什么、为什么做」
写需求时，问题永远是「实现这个功能」；独立开发时，第一个问题是「这个功能到底要不要存在」。
这个转变最实际的落地方式是：在写第一行代码之前，先写下「这个产品解决谁的什么问题」，并且保证这句话里没有出现任何技术词。
转变二：从「把它做完」到「先让它能用」
我以前有很重的「完成度洁癖」：功能不完整就不愿意给人看。但独立开发里，这个习惯会致命 —— 因为你会在「永远差一点」里消耗掉全部动力。
我的做法是把目标从「做完」改成「能用」：
能用 = 核心流程能走通，哪怕界面很糙；
先让真实的人用一次，拿到第一条反馈；
再决定下一版做什么 —— 而不是先把它做「完整」。
转变三：从「追求正确」到「接受不完美」
在公司里，「架构正确」很重要；一个人做时，「可改」更重要。
因为你的判断大概率是错的 —— 一开始想的功能，做出来可能根本没人用。所以第一版的真正目标不是「做对」，而是「做出来一个可以改的东西」。
这带来一些具体做法上的改变：
数据结构想清楚，但功能先做最小集；
凡是「以后可能推翻」的部分，就不要花太多时间打磨；
给自己留一条「改回来」的路（版本管理、备份、开关）。
转变四：从「等灵感」到「看信号」
独立开发很容易陷入自我感动：我觉得这个想法很棒，所以它一定有人需要。但真实世界只认信号，不认感觉。
我后来只信三类信号：
真实的人主动来找我（而不是被我问出来的「还不错」）；
有人愿意为它付出成本（时间、钱、把数据填进去）；
有人用了以后还回来用第二次。
一句「挺好的」几乎没有任何价值，「我上次用了，这次又来了」才是真信号。
这几个转变背后的同一个原则
回头看，这四个转变都在做同一件事：**把「评价标准」从自己身上，挪到真实世界上。**
不是「我觉得完整」——而是「别人能不能用」；
不是「我觉得正确」——而是「错了能不能改」；
不是「我觉得有需求」——而是「有没有人真的在用」。
我常用的一份自检
每次开始一个新东西前，我会问自己这几个问题：
我能不能一句话说清它解决什么问题，且不出现技术词？
最小可用版本里，哪些功能是可以砍掉的？
如果这个方向错了，我的退路是什么？
我打算用什么信号来判断「该继续还是该放弃」？
这四个问题回答完，通常就不用再纠结「要不要开始」了 —— 因为要么你已经知道该做什么，要么你知道这件事暂时不该做。