从 Whistle 说起#
我最近在写一个小项目 Whistle，是一个「互联网日报」。我选定信息源，由 Codex 帮忙过滤、加工、产出，产物是 HTML 和 PDF。前者放到一个 Next 搭出来的静态站上，后者实际没什么用，不过顺带做了，因为跑 Codex 的 Chromium 正好有这个功能。另外还有一个简单的基于 GitHub CI/CD 的定时任务，能在早上跑一遍构造流程，然后定时发布和推送邮件。
跟同学分享了 Whistle，他说「我说轮子多造」。
市面上确实有不少这样的产品，确实看似很符合「造轮子」的定义。
不过轮子这个词还是比较广义的，我们可以把各种工具称为轮子，比如 lodash；也可以把各种封装好的框架称为轮子，比如 React；轮子可以有很多种形态，不过它的目的通常是通过低耦合易使用的接口来解决通用性的问题。
过去的问题是成本#
从这个角度看，「不要重复造轮子」其实是一个很合理的工程原则。
如果一个东西已经足够通用、足够稳定、足够便宜，并且它的维护成本远远超过你自己重写的收益，那么你就不应该重写它。没有必要自己实现一个日期库，没有必要自己写一个加密算法，也没有必要为了显示一个弹窗从零写一套 UI 框架。这里的核心不是「不能造」，而是「收益不值得成本」。
但是 AI 时代改变了一个很关键的变量：成本。
以前造一个小轮子，意味着你要自己写代码、查文档、调 bug、做部署、补边界。如果只是为了满足一个很个人化的需求，这个投入经常不划算。所以大家更倾向于找现成工具，哪怕它有一堆自己用不上的功能，哪怕它的交互和自己的习惯不完全匹配，哪怕它最后变成了一个订阅制服务。
现在不一样了。很多小型系统的搭建成本被 AI 压得很低。
你不需要从零记住 Next 怎么配，也不需要完全手写 CI，也不需要自己慢慢查 Puppeteer 或 Playwright 的 PDF 导出参数。你只要能描述清楚自己要什么，能判断生成结果是否靠谱，能在关键地方做取舍，一个过去需要周末折腾的东西，现在可能几个小时就能跑起来。
于是「造轮子」这件事就从一个工程性决策，变成了一个更偏产品性和生活方式的决策。
私人轮子的价值#
Whistle 对我来说不是为了打败市面上的日报产品。
我想要的是我自己选的信息源，我自己定义的过滤规则，我自己认可的排版和摘要颗粒度，我自己能理解、能修改、能迁移的一套流程。它不一定比成熟产品更强，但它更贴近我的使用方式、我也对它有更完整的心智模型。对这种需求来说，「已有产品存在」并不能自动推出「我不应该做一个自己的」。
很多时候，公共产品解决的是最大公约数问题。
它要照顾足够多的人，所以会慢慢长出配置、账号、推荐算法、商业化入口、通知系统、团队协作和各种看起来合理但我并不需要的功能。最后它确实更完整，但也更重（Pi 的作者就是因为 Claude Code 日渐庞大才选择写自己的一个 Agent CLI的）
私人轮子解决的是最小闭环问题。
它不需要兼容所有人，不需要做权限系统，不需要设计复杂的计费模型，不需要考虑增长，也不需要把每个异常都包装成优雅提示。它只要在我的机器、我的仓库、我的工作流里稳定运行，就已经完成了它的使命。
这也是 AI 辅助开发最有意思的地方：它让「个人软件」重新变得可行。
以前个人软件最大的问题不是想法，而是手不够。你想做一个给自己用的工具，但一想到要搭项目、写界面、接服务、部署、维护，就会觉得不如算了。现在 AI 相当于补了一只手，甚至补了好几只手。它不能替你做判断，但可以替你承担大量低价值的体力活。
哪些轮子不要随便造#
所以我现在对「轮子」的态度更宽松了。
如果是基础设施，不要随便造。
如果是安全、金融、加密、存储、权限这类领域，更不要因为 AI 能写就随便造。这里的风险不是「能不能跑」，而是「出事的时候你知不知道为什么」。AI 会让代码出现得更快，但不会自动让责任消失。
如果是业务系统，也要谨慎造。
团队协作里的轮子有另一套成本。你今天用 AI 写了一个看起来很顺手的小框架，明天同事要理解，后天线上要排障，下个月需求变了还要迁移。个人项目里可以接受的粗糙，在团队项目里可能就是技术债。
但如果是个人工具、小型实验、一次性自动化、学习项目，或者高度贴合自己习惯的工作流，我觉得可以多造。
多造不是乱造#
因为这类轮子的价值不只在最终产物，也在过程本身。
你会被迫拆解需求，思考什么是必要的，什么是伪需求；你会理解一个系统从输入到输出的链路；你会知道现成产品为什么那样设计，也会知道它们的限制在哪里。哪怕最后这个轮子被你扔掉，它也不是完全浪费。
更重要的是，AI 让试错变便宜了。
以前「做一个自己的」常常意味着长期承诺。现在它更像是一次快速实验：先搭出来，用几天，看哪里别扭，再决定要不要继续。这个节奏很适合个人项目。一个轮子如果三天后死掉，也许它只是完成了验证；一个轮子如果每天都被你用，那它自然会长出继续维护的理由。
所以问题不应该是「这个东西外面有没有」。
这个问题太粗了。
更好的问题应该是：
- 我造它，是为了学习，还是为了逃避使用现成工具？
- 我造它，是因为需求真的特殊，还是因为我低估了维护成本？
- 我能不能接受它坏掉？
- 它坏掉以后，影响的是我自己，还是别人？
- AI 生成的部分，我是否有能力判断和接管？
如果这些问题都想清楚了，那轮子多造一点也没什么。
公共轮子和私人轮子#
「不要重复造轮子」是工业时代的好建议，因为当时造轮子贵，维护轮子更贵。
但现在很多个人轮子的成本已经低到接近写一篇笔记、做一个脚本、搭一个临时页面。它们不一定要成为产品，也不一定要长期存在。它们可以只是一个人和自己需求之间的接口。
所以我现在更愿意把轮子分成两类。
一种是公共轮子，目标是稳定、通用、可维护、可协作。这种轮子少造，能不用自己造就不用自己造。
另一种是私人轮子，目标是贴合、轻便、可修改、能解决自己的具体问题。这种轮子可以多造。AI 时代真正被释放的，恰恰是这一类。
Whistle 大概就是这样一个私人轮子。
它没有什么宏大的意义，也不需要证明自己比现有产品更好。它只是刚好把我想看的信息、我想要的格式、我能控制的流程连在了一起。
如果这也算重复造轮子，那我觉得可以多造。