Build vs Buy：克制造轮子的冲动，才是独立开发者最贵的软实力

刚入手 .NET 项目需要加 Feature Flag 时，安装 Microsoft.FeatureManagement，在 appsettings.json 里写几行配置，三分钟搞定。这种“无聊”的解决方案，往往是大多数成熟产品的起点。

但在 AI 写代码变得异常简单的今天，一个反直觉的现象正在蔓延：越来越多的开发者陷入“自建陷阱”。不是因为能力不足，而是因为在没有约束的情况下，手写代码的快感远大于集成现成库的枯燥。

你的时间，比你的代码值钱

很多人有一个误区：自己写的代码完全可控，所以更安全、更灵活。这是一个昂贵的幻觉。

当你花三个月做一个“更好的 XX 工具”，结果发现市场上已有十个更成熟的竞品时，浪费的不是那三个月，而是本该用来打磨核心差异化的窗口期。我在社区见过太多聪明人倒在“重复造轮子”上——他们以为自己发现了蓝海，其实只是进入了红海的边缘。

独立开发的核心竞争力，从来不是你写了多少行代码，而是你有多快能验证一个想法并推向市场。一个能克制“自建冲动”的开发者，其产品在市场上的存活率通常更高，因为他们的每一小时都花在了真正的价值创造上。

决策三问：如何判断是否该自建？

下次当你面对一个功能需求，脑海中浮现出“我自己写”的念头时，先停下来问自己三个问题：

1. 有没有现成的开源方案？ 哪怕它有点丑，或者文档不太全。
2. 有没有付费 SaaS 能直接解决？ 如果月费只要 $10，而你每小时机会成本是 $50，买它是最优解。
3. 自己造的核心价值在哪里？ 如果现有方案已经覆盖了 80% 的需求，剩下 20% 的定制是否值得你投入数周的开发时间？

如果前两项已经够用，别犹豫，直接用。只有当现有方案无法满足你的差异化需求，或者自建能带来显著的长期成本优势时，才考虑自己造轮子。

先买，后用，再想必要

这个原则可以总结为一个简单的行动清单：先买，后用，再想有必要吗？

“买”不一定指花钱，也包括使用现成的开源库、API 或服务。让工具为你工作，而不是你为工具工作。

在这个 AI 辅助编程的时代，编码门槛降低了，但判断力的门槛变高了。真正区分赚钱者和空转者的，不是谁代码写得更漂亮，而是谁更懂得什么时候该停下来，直接使用那些已经被验证过的、无聊但可靠的方案。

记住，你的时间比你的代码值钱。除非你能做出别人做不了的东西，否则，别 reinvent the wheel。