阅读清单加过几次功能，最常碰到的麻烦却还是从详情返回时搜过的词会消失。我给这次修改留了一条记录，写明从哪里进入、返回后应看到什么，以及怎样确认刷新也能恢复同一组结果。后来改文案、改导出格式，我也这样记，但检查的范围随改动而变。
新功能很容易开始
我维护过一个很小的阅读清单工具。最初只有添加、归档和搜索，后来想加评分、年度图表、封面抓取。每个想法单看都合理，放在一起却让一个周末能修好的东西，变成需要先花半天理解的系统。
后来我把新增功能的入口关了一阵，只处理每天真实遇到的麻烦：搜索词丢失、空列表没有说明、导出日期不一致。没有哪项值得专门展示，但工具终于变得可靠。
把决定写在改动旁边
我开始保留很短的维护记录。每次只写触发场景、改动后的行为和检查方式。例如：
搜索后进入详情再返回，原来的关键词会消失。现在保留查询参数；确认刷新与浏览器返回都能恢复同一组结果。
这段话比“优化搜索体验”长，却能让未来的自己知道为什么改，也能判断下一次修改是否破坏原来的目的。
检查与风险相称
调整一处边框，不需要把所有流程重跑一遍；修改数据导出，就不能只点一下按钮。清单逐渐变成按影响范围选择，而不是机械执行同一套动作。
| 改动 | 最少要回答的问题 |
|---|---|
| 文案 | 语义准确吗，窄屏是否挤压 |
| 局部交互 | 正常操作、取消和返回是否合理 |
| 数据格式 | 旧数据还能不能读，空值怎样处理 |
| 公共逻辑 | 多个入口是否保持预期 |
最有用的一次调整，是把“以后也许需要”从当前任务里移走。记下来并不等于承诺实现，拒绝一个功能也不是维护失败。
一个人的项目，往往靠愿意再次打开它来延续。把每次改动控制在能理解、能检查的范围里，比扩充清单更能保护这份意愿。
现在那个工具仍然很小。偶尔打开旧记录，能认出当时为什么做出那些选择。这种可理解的连续性，是我最想保住的东西。