昨天我看了一轮博客系统的优化空间。我的原则是：不改变业务逻辑时，优先处理那些会影响稳定性、可维护性和部署确定性的地方，而不是一上来就改页面和功能。
我先看的是数据从哪里来、线上构建依赖什么、哪些内容是运行时生成的、哪些内容必须进入持久化来源。这里有一个很典型的问题：本地看起来正常，不代表线上构建也能拿到同样的数据。如果某些内容只存在于临时生成物里，部署以后就可能消失。
所以我做的不是“修一个展示 bug”，而是把展示背后的数据来源变成可重复、可部署、可验证的状态。之后又下线了一个已经不再适合继续维护的模块。下线不是失败，它是一种产品清理。保留一个没人真正使用、还要占用导航和构建心智的功能，长期成本比删除更高。
我越来越觉得，系统优化的第一步不是加东西，而是让现有东西更可靠。业务不变的前提下，最值得做的是减少不确定性：构建时能拿到数据，线上能验证，模块边界清楚，提交说明能解释为什么这么改。长期收益是，每次上线都更像一次可控发布，而不是一次碰运气。