一个想法刚出现时，总能顺着它想到很多功能：导入、统计、分享、提醒……但在开始写代码之前，先把问题缩小，通常更容易看清它是否值得解决。
把“想做”写成“要解决”
与其说“做一个效率工具”，不如写成“把每周从三份表格中核对同一字段的步骤整理清楚”。问题越具体，越容易判断输入是什么、结果应该是什么，以及是否真的省下了时间。
先走通一条完整路径
选一个真实但范围有限的样本，从输入到输出手动走一遍。标出重复动作、需要判断的步骤和最容易出错的地方。优先自动化规则明确的部分，把需要判断的地方留给人。
用三个问题复盘
- 它解决了原来的那个麻烦吗？
- 为了使用它，需要付出多少额外整理成本？
- 下次遇到同样的问题，是否还愿意打开它？
小工具不一定需要宏大的目标。能让一个具体步骤少一点重复、多一点确定性，就已经是一个值得记录的起点。