我为什么越做越小

今年上半年我在写「平台」，下半年我在写「工具」。星数没变多，但交付的东西变完整了，而且我不用天天惦记它们。

一、上半年：每个项目都要先解释怎么装

把 2026 年前几个月的仓库排开看，气质很一致：

  • X-admin：一套 PHP 的轻量 CMS，卖点是动静分离——后台 PHP 管内容，前端 Nginx/Apache 直接吐静态 HTML，请求完全不经过 PHP
  • xfm-cms：面向小微企业官网的 PHP 程序，支持 SQLite 和 MySQL 两套库
  • x-site：跨平台的静态博客桌面客户端，Vue 写的
  • x-collector：Tauri 2 + React + Rust + SQLite 的采集与发布工具，关键词采集、RSS / 网页 / 站点地图，清洗带伪原创，能导出 Hexo、能自动发布到 WordPress / Typecho / Z-Blog

这些项目有一个共同点：它们的说明书都比代码长。

每个都要回答同一串问题：装在哪、什么版本、数据库怎么建、伪静态怎么配、附件目录给什么权限、升级会不会丢数据。这些问题没有一个是「功能」，但它们决定了这个东西能不能被别人跑起来。

我当时觉得这叫「专业」。后来发现更准确的说法是：我在为复杂度付利息。

二、下半年：双击就能用的东西

然后画风突变。

tools-box：508 款工具，纯前端、零依赖、不用框架、不打包，index.html 双击就能开。所有计算在浏览器本地做完，一个字节都不上传。

whois：一个 Cloudflare Workers 的单文件，域名 / IP / ASN 的 RDAP 查询，走 RDAP.org 自动路由，中文结构化展示。没有后端，没有服务器账单。

cf-kv-nav：把别人的导航站 fork 过来改，跑在 Workers + KV 上，改完部署一次就完事。

和上面那批放在一起，第一眼看像是「能力退化」——从 CMS 退到计算器。但我自己的体感完全相反：

维度 平台类项目 小工具
上手成本 先读安装文档 打开就用
部署 数据库 + 运行时 + 反向代理 一个静态目录 / 一次 wrangler deploy
维护 依赖升级、安全补丁、数据迁移 基本为零
出故障 用户数据可能没了 刷新一下
谁会用到 需要「一套系统」的人 包括我自己

最后一行是分水岭。平台类项目的用户是「别人」，小工具的用户首先是「我自己」。这个区别决定了我会不会在半夜想起来去修它。

三、做小不是看开了，是承认精力有限

我不想把这件事包装成「断舍离」或者「极简主义」。真相朴素得多：我同时维护不了那么多东西。

一个 CMS 的真实成本不在写完那天，而在之后的每个月：PHP 版本升级要测、依赖有漏洞要补、用户问「为什么上传图片失败」要回。这些成本不会因为我这段时间在写别的项目而暂停。

而小工具的成本是一次性的：写完、部署、忘掉。它不需要运营，只需要在坏掉的时候修一次——而它坏掉的频率，通常比 CMS 低一个数量级。

所以现在的取舍标准只有一条：

这个东西一年后还需要我管吗？需要，就先别做。

四、小不等于简单

有件事要澄清：做小不是降低要求，是换了一种难法。

tools-box 两天堆到 508 个工具，看起来是「快」，实际上一半的功夫花在两件很枯燥的事上：

  1. 去重。第四批上线时发现 4 款和旧工具功能重叠，直接替换掉，没留着凑数。508 这个数字只有在每一款都能独立站住的时候才有意义。
  2. 守住约束。不许用框架、不许联网、不许上传——这三条一破，第五百个工具就会先把我拖进构建配置和依赖升级里。约束不是限制，是产能。

而 whois 那种单文件程序，难点全在「不写后端」：怎么在 Worker 里做超时控制、怎么处理上游 RDAP 服务器不响应、怎么把一个嵌套 JSON 渲染成人能看懂的结构。省掉服务器，复杂度并没有消失，只是被挤进了同一段代码里。

小项目的难，是「一次做对」的难；大项目的难，是「一直做对」的难。我现在的耐心只够前者。

五、心态变化

最初做开源，我想的是「做一个有用户的产品」。这个词很有诱惑力，也很容易让人把「功能多」当成「有价值」。

现在我更在意另一件事：做出来的东西，是否真的进入了我自己的日常。

tools-box 我每天都开，x-video 是我电脑上唯一的播放器，这个站（hexo-theme-lovou）承载了我全部输出。它们都没什么星，但它们被使用——被我使用。

至于那些平台类项目，我不后悔写过。正是写过 CMS、写过采集发布、写过桌面客户端，我才知道哪些复杂度是必要的、哪些只是我在自我感动。没做过大的，做小的时候容易把「简单」当成「随便」。