为什么要制作轮子？

“不要重复造轮子”，想必这是大家听得最多也看得最多的一句话了。这原本是一条工程经验，但是有些人把它奉为圣旨一样，只要看见有人分享类似功能的开源项目，就说人家浪费时间、浪费 Token 造轮子。这句话最初的价值，是提醒开发者不要无谓地浪费时间。比如一个商业项目只需要完成基本的 JSON 解析，却决定从 0 开始写，还没有任何特殊需求，这时候提醒他使用成熟的方案完全合理。

但问题在于，上述说到的问题，有些人一看见就会忍不住说：为什么要制作轮子？我一直觉得这种质疑缺少一个关键的前提：为什么一个东西已经存在，就意味着其他人不应该再做？

如果所有的开发者都严格遵循这个逻辑，那么今天的许多优秀项目根本不会诞生。

Linux 出现的时候有 Unix，Rust 出现的时候有 C++，Bun 出现的时候有 Node.js，后来者也不是因为前人完全不可用才出现的。

当然，这些例子不能证明重复制作轮子一定有意义，但至少说明了一件事：现有方案的存在，不构成禁止新方案出现的理由。

拿我制作的 Pulse 这个工具举例。制作它的当初，只是因为我在 X 上刷到了一个很漂亮的概念设计图。Pulse 最初的诞生并没有什么宏大的目标，也不是我觉得 CodexBar 不好用，仅仅只是我看见了一张设计图，我认为它很符合我的审美和我的使用习惯，然后产生了一个很简单的念头：这个东西看起来很棒，我能不能尝试把它制作出来？开发者创造一个东西，有时候根本不需要先找到技术痛点，或者证明它比现有方案更优秀，单纯的兴趣和好奇心，就足以成为开始一个项目的理由。

但是，为什么我要拿这个举例呢？Pulse 看起来和上面说的重复造轮子也没什么区别。

我认为，开源社区有时会混淆 3 个完全不同的问题：

• 有没有必要做？ 这是作者的选择，尤其是个人项目。即使它是开源的，所有人都可以使用和下载，但是作者的初心只是想做一个自己使用的软件，顺便开源。
• 有没有技术价值？ 即使功能重复，也可能探索新的架构、语言和实现方式。
• 值不值得别人用？ 这才需要认真比较可靠性、性能、维护成本和生态。

一个项目可以没有广泛的使用价值，却有很高的学习价值。

还有一点我觉得特别重要：开源本来就应该允许一定程度的低效率、重复和失败。

因为开源社区的一大优势就是允许个人基于兴趣自由探索，不需要所有项目都通过商业价值或技术创新来证明自己。当然反过来也一样，作者有自由造轮子，社区也有自由批评其设计，只是批评应该尽可能具体，例如指出架构缺陷、兼容性或者不合理的技术取舍，而不是简单的一句“已经有类似项目”就否定其存在。

其实在把概念图做出来的过程中，Pulse 也确实切中了我自己一个最大的痛点，那就是可以挂载屏幕边缘实时监控 AI 额度。与 CodexBar 不同，Bar 只是挂载在顶部栏，最多只能展示一个额度，想要看其他的必须展开，而且还会占用 Mac 顶部本来就不多的菜单栏空间。对于我这种 AI Coding 用得比较多的，有很多个不同的套餐，我就需要时刻盯着这些额度什么时候重置，规划一下我现在应该如何使用，才能既达到重置时间，也不会立马用完导致空窗期。

我的需求就是一个能实时显示、我一眼就能看见、不会占用我的 bar 空间、不需要鼠标移到 bar 处点一下的工具。我最初甚至根本没有打算挑战 CodexBar，也没有想证明自己能做出来一个更优秀的替代品，我只是根据我的需求出发，刚好刷到了那张概念设计图，一拍即合。

后来我把这个工具发在小红书上火了，不可避免地会有人说这是重复造轮子，为什么不直接使用 CodexBar，然后高谈阔论自己的见解。

这恰好触及了“不要重复造轮子”这句话我觉得最有问题的地方：有些人习惯从自己的需求出发，判断别人的创造是否有必要。

对于那些评论者来说，CodexBar 已经能查看 AI 额度了，所以他们自然会觉得再做一个 Pulse 没有任何意义。

但是他们忽略了一点，每个人对于工具的需求程度并不一样。

有很多人都有和我相同的需求：

对偶尔查看额度的用户来说，点击菜单栏展开查看可能已经足够。但对重度用户来说，频繁展开菜单本身就是一种操作负担，更何况菜单栏空间有限。Pulse 的屏幕边缘常驻设计，恰好针对了这个问题：让多个套餐的剩余额度和重置状态始终处于随时可见的位置。这也是 Pulse 能走到今天的原因，有无数个和我相同需求的人共同维护 Pulse。

那么在 AI 时代呢？我的个人理解就是 AI 就是用来造轮子的，AI 使得每个人都可以造从自己需求出发的轮子。

AI 时代让软件开发有了一个很大的变化，软件正在从“尽可能为大多数人解决共同需求”，逐渐走向“每个人都能为自己的具体需求创作工具”。

过去我们使用软件，往往需要使用开发者设计好的工作流程，哪怕只有一个地方不符合自己的习惯，也只能忍受、寻找替代品，或者给作者提 Issue 和 PR，但是作者接不接受就是另一回事了。

但 AI 让另一种选择变得更加现实：既然现有的软件不符合我的需求，那我为什么不能自己做一个？

我上述说到的 Pulse 就是这么一个典型的例子，它是我和 Claude 一起做出来的。我没有必要证明所有人都需要屏幕边缘常驻的额度监控，也没有必要证明 CodexBar 的设计问题，只要它能满足我的使用习惯，创造它就有了充分的理由。

而且我觉得这背后存在一种观念的转变。

以前我们强调软件的通用性，是因为开发成本太高；现在个人制作软件的成本正在极速下降，软件未必需要服务更多人才值得创造。

当然还有最后一类人，就是我个人比较痛恨的这种人，带着一种明显的优越感，仿佛自己使用成熟工具，遵循所谓的“最佳实践”，就天然比那些自己造轮子的人更专业。

我觉得这种态度可能来源于以下这些：

一种是技术上的精英主义。有些人会建立一套自己认可的技术鄙视链，例如底层开发高于应用开发，手写代码高于 AI 辅助开发，原创技术高于功能整合，使用 AI 就一定不能重复造轮子，要做有创新、有价值的新技术，然后用这套标准评价其他的开发者。

另一种是通过贬低他人的创造获得优越感。指出一个项目已经有替代品，确实可以让评论者显得见多识广。但知道某个成熟项目存在，和真正理解新项目取舍是两回事。

当然我们无法仅凭别人说的几句话就判断 TA 的真实想法，有些人的表达方式比较刻薄，但确实在指出有价值的问题。

最值得警惕的是这种逻辑：我认为这个东西没有必要存在，所以你创造它是一种低水平行为。

它把个人偏好包装成普世标准，甚至进一步变成对开发者能力和身份的评价。

尤其是在 AI 时代，技术门槛降低之后，有些人更加执着于通过开发方式、技术难度来区分所谓的“真正的开发者”和“低水平开发者”。

但我认为一个人可以不喜欢 Pulse，可以觉得 CodexBar 更好用，可以批评 Pulse 的代码质量、功能实现和维护的方式，唯独不应该因为别人愿意花自己的时间实现一个想法，就认为对方低人一等。

更甚者还有一类：

传统的“不要造轮子”，有时会变成对创造必要性的批判；

而 AI 辅助开发引发的鄙视，则可能变成创造者能力的审判：代码都不是你亲手写的，你凭什么称自己为开发者？

这两者最终都指向同一个问题：一个人是否必须先证明自己的技术能力和创新能力，才有资格把自己的想法变成软件？

首先，技术能力确实存在差异，经验丰富的开发者也确实能发现新人容易忽略的架构、安全、维护问题，承认这种差异很正常，问题在于有些人会把技术能力上的差异转变为人格或者身份上的优越感。

其次，降低开发门槛，可能让原本具有稀缺性的技能不再那么稀缺，这可能也是这类人感到自己的专业地位受到挑战。

创作自由、技术水平、作品质量，本该是 3 个应该分开讨论的问题。

任何人都可以创作软件，不代表任何人创作的软件都足够优秀；一个项目存在的技术缺陷，也不意味着作者不应该尝试开发它。

我甚至认为 AI 时代应该重新审视“轮子”这个词。

当一个人能够针对自己的需求，低成本创作一款个性化工具时，我们凭什么仍然要用工业软件开发时代避免重复投入的标准，来衡量这种个人创作？

当然这并不意味着 AI 生成的软件可以免于质量审查，只要公开发布给用户，安全性、可靠性、维护责任依然重要。

但是这些责任应该成为评价软件的依据，而不应该成为嘲笑一个人尝试创造的理由。