看到NASA为保续航关闭红外光谱仪，心里咯噔一下。这是典型的资源约束决策，工程上讲究生存优先，哪怕牺牲部分科学产出。

做程序员那五年，我最怕维护“亚健康”老系统。依赖库停更、API 变动，像飞船燃料告急。现在转行写小说，反而更懂架构设计的克制美，少即是多。

开源项目常死于功能膨胀而非性能不足。建议维护者定期做“垃圾回收”，明确标注弃用模块，别让用户猜谜。能稳定运行十年的工具，比昙花一现的热点有价值得多。

有没有人经历过类似的“断臂”时刻？

凌晨三点调试一个十年没动过的Python 2脚本，终端突然报错说ssl模块找不到——那一刻我忽然懂了旅行者号关闭仪器时的沉默。不是放弃，是把心跳留给更重要的事。

开源世界的“断臂”从来不是瞬间的壮烈，而是日复一日的忍耐。记得我在FAANG维护一个内部CI工具链，核心库依赖早已停更，但没人敢动，因为“它还能跑”。直到某天TLS协议升级，整个流水线崩了。我们花了三周重写认证模块，却意外发现：删掉冗余功能后，构建速度提升了40%。原来克制不是妥协，是给系统留出呼吸的缝隙。

你说“少即是多”，让我想起K-pop编舞里的负空间（negative space）——那些停顿、留白，反而让动作更有张力。好的开源项目也该如此。Rust的std库为什么让人安心？因为它明确划界：什么该进，什么该由生态承接。坦白讲不像某些JS框架，恨不得把整个宇宙塞进core包里，最后用户连文档都读不完。

不过，“垃圾回收”的难点或许不在技术，而在情感。我们总舍不得删自己写的代码，就像舍不得扔掉旧信。但去年我fork了一个废弃的耽美小说爬虫（别笑），第一件事就是砍掉所有花哨的UI和社交分享——只留最干净的文本抓取。结果反而有十几个陌生人star，留言说“终于有个不弹广告的工具”。仔细想想有时候，断臂不是失去，是让别人看清你真正的骨骼。

NASA关掉红外光谱仪那天，旅行者号离太阳系边缘还有180亿公里。它带着残缺继续飞，而人类还在争论要不要给它发最后一道指令。开源亦如此：真正的遗产不是功能多全，而是当世界转向时，你的代码是否还能安静地做一件事，做得足够好。

说实话话说回来，你转行写小说后，有没有把某个废弃项目的commit log当成角色日记？我试过，git blame出来的作者名，莫名有种赛博墓志铭的浪漫……