克制造轮子冲动：AI时代独开发者最该学会的赚钱效率法则

当微软的FeatureManagement让一切变得 boring

在 .NET 应用里第一次需要功能开关时，最精彩的答案往往是最无聊的：Install-Package Microsoft.FeatureManagement，往 appsettings.json 里塞几个 flag，然后继续做真正重要的事。

这种 boring 的选择，背后藏着一个反直觉的赚钱效率法则——大多数独立开发者赚不到钱，不是因为代码写得差，而是因为花三个月造了一个"更好的轮子"，结果市场上已经有十个更好的了。

AI 让造轮子变得更容易，也让自制陷阱更深

ChatGPT 出现后，"自己写代码" 的成本暴跌。但问题也来了：以前你因为不会写，所以买了现成方案；现在你会写了，就开始觉得"我为什么不能自己做？"

这个"自己做"的冲动，正在制造一批聪明却空转的开发者。他们写了一堆代码，却没时间打磨产品价值；他们造了很多轮子，却发现路上已经有车在跑了。

真正区分赚钱者和空转者的，不是代码质量，而是克制自制冲动的判断力。

遇到需求时，先问三个问题

当你在开发中遇到一个需求时，别急着写代码，先问：

1. 有没有现成的开源方案能解决？
2. 有没有付费 SaaS 能满足？
3. 我自己造的核心价值在哪里？

如果前两项已经够用，直接用。只有当现有方案无法满足你的差异化需求时，才考虑自建。

这不是偷懒，这是时间分配效率。你的时间比你的代码值钱，除非你能做出别人做不了的东西。

少造一个轮子，就多一小时打磨价值

这条规则救过我很多次。我见过太多聪明的开发者，花三个月做了一个"更好的XX"，结果发现市场上已经有十个更好的了。

这不是嘲笑他们——我也干过这事儿。但我后来学到最重要的一课是：除非你能做出别人做不了的东西，否则别 reinvent the wheel。

一个克制"自建冲动"的开发者，其产品在市场上的存活率通常更高。少造一个轮子，就多一小时打磨真正有价值的功能。

先买，后用，再想有没有必要自己造

这不是关于"买还是建"的技术决策，这是关于"时间应该花在哪里"的商业判断。

你的时间在代码上，还是在市场上？是在造轮子上，还是在卖产品上？是在重复发明，还是在差异化创新？

先买，后用，再想有没有必要自己造。这条规则看起来 boring，但它救过我很多次。