一种安静的进度

发版说明里通常只有新功能。但真正在改变一个产品的，往往是那些写不进去的东西。

看不见的工作

有三类进展几乎不会出现在任何"更新了什么"的清单里：

类型更清楚。 一个字段从 string 变成联合类型，一个可选参数变成必填。功能完全没变，但下一次改动时，编译器会替你想起那些本来要靠记忆守住的前提。

错误更可恢复。 请求失败后能重试，重试不会重复写入，中断后重新进来还在原来的位置。用户平时感觉不到，只有在出事的那一次会庆幸。

少一次卡顿。 首页少一个阻塞脚本，滚动少一次重排，慢设备上少一次白屏。看不见，但每天都在发生。

它们的共同点是：只有在缺失时才被注意到。做得好没人夸，做坏了会被骂——所以很容易被排到"有空再说"那一栏。

为什么它容易被低估

原因不复杂：这类工作没有"可展示的产出"。

一个新功能可以截图、可以演示、可以写进周报；而"把错误状态补全了"没法演示——除非你故意断网，而演示断网看起来像在给自己找麻烦。

于是排期时它们天然吃亏：

• 需求方看不到，不会主动提
• 出事前没有证据说明它重要
• 做完了也没有正向反馈

打破这个循环的办法只有一个：把稳定也当成产出记录。

把稳定记录下来

这个站的做法是给"没有发生的事"也留位置：

• 建站纪事不只记新增，也记删掉了什么复杂度和为什么
• 失败博物馆专门收被放弃的方案，以及它们留下的判断
• 写作里那些踩坑记录，大多来自"差点出事但被挡住了"的时刻

这么做的收益很具体：

1. 下次遇到同类问题，有据可查，不用重新踩一遍
2. 能看出系统是不是真的在变好，而不只是功能在变多
3. 让"改善稳定性"这件事有可见的产出，它才不会被一直往后排

进度感的另一种来源

如果只以新功能计进度，很容易出现一种状态：做了很多，却说不清哪里变好了。

换一种计法会清晰很多——问自己：

• 上一次改动之后，哪一类错误不会再发生了？
• 哪一处以前要靠记性、现在靠类型或测试守住了？
• 哪条路径以前会卡住、现在不会了？

这些问题有答案，进度就是实的；答不出来，功能再多心里也没底。

安静的进度不热闹，但它决定了这个东西能不能被长期信任。