从自部署到自建

以前我在服务器上装过很多东西。文件同步、照片备份、密码管理、RSS 阅读器，都是在网上找开源项目，看文档，写 Docker Compose，配反向代理。装完的那一刻很有成就感，服务器上跑着一排服务，每个都有网页界面，看起来什么都能做。

后来我发现，这些服务里真正用到的功能往往只有一小部分。照片备份我只用得上自动上传和按时间浏览，但那套系统带着人脸识别、机器学习、地图、分享链接，每次升级都要小心数据库迁移。出问题的时候最难受，日志一大片，代码不是我的，只能去翻 issue，等着别人修，或者自己摸索着改一点配置碰运气。

转折是编程代理。一开始我只是让它帮我写小脚本，后来有一天我意识到，一个只有我需要的功能，没必要去找现成的项目了，直接说清楚要什么，让它写一个就行。

于是现在我的服务器上是另一番景象。我和 AI 对话的会话管理、给文章划意见的批阅页、背日语单词的游戏、记录读书进度的页面，这些服务都是自建的。它们的共同点是只做我要的事。要改的时候我直接说，改完就完。出了问题，代码全在我手里，日志是我让它们打的，读起来没有陌生感。

有人会问，自己写的能有成熟项目稳定吗。我的经验是，个人使用的服务，复杂度本来就低，功能砍到只留自己要的，出错的面反而小。成熟项目的稳定性是给几千种用法准备的，我只有一种用法。维护心态也不一样。部署别人的项目，维护像还债。维护自己的代码，是照顾自己的东西。

从自部署到自建，中间隔着编程代理。它把「写一个」的成本降到了「部署一个」以下。写代码比读文档还快的时候，答案就变了。

举一个最近的例子。自己写的客户端连服务器，地址协议写错，一启动就崩溃。日志里留着明确的异常，定位到那一行，改一个词就修好了。代码是编程代理写的，我没有逐行读过，但日志、结构、命名都是按我的习惯长出来的，排查起来像在自己家里找东西。

写这篇也是延续删掉大部分技术文章时定的方向，多写方案权衡与选择思路，少写很快会过时的技术细节。