刷到HN上那篇"Write code like a human will maintain it"，第一反应不是感动，是焦虑——这更像是开源项目的生存契约，而不是一句心灵鸡汤。

我这种还在读高中的人都看得懂：代码可维护性本质是在降低协作熵增。其实Linux Kernel、PostgreSQL这些活过二十年的项目，共同点是边界契约足够显性，命名一致性极强，注释里写的不是"what"而是"why"。我也翻过一些死掉的开源仓库，问题往往不是功能不行，而是新维护者读不懂前任的意图，贡献成本指数级上升。

但现在的Linter和CI多半只查语法合规，ESLint、Black能管分号却管不了"人类可读性"。Rust的doc-tests、TypeScript的JSDoc+deno lint算是少数把文档和可维护性绑在一起的正向实践。更值得商榷的是，我们是否该把"维护者心智模型映射度"写进贡献指南？比如每个PR强制带三行上下文速览和一处最易出错的假设说明。

竞争才有进步，开源项目的竞争就是抢维护者的时间。写得像人话，其实是把隐性知识显性化，让陌生人能低成本接力。否则再酷的代码也活不过三个大版本。