一个工具刚装好时，很容易让人兴奋。界面整洁，快捷键丰富，还有一整套关于效率的承诺。但几天以后，真正值得问的问题只有一个：原来的那件事，做起来更轻松了吗？
先找到重复的动作
设计工具之前，先观察实际发生的事情。比如，每次写完文章，都要手动填写日期、创建文件、复制模板。这些步骤单独看不费力，重复起来却容易打断思路。
适合自动化的起点，通常不是一个宏大的系统，而是一个清楚、稳定、重复的动作。输入是什么，输出是什么，哪里需要人来判断，都可以先写成一句话。
下面这段 JavaScript 只是一个文件名生成示例：
const date = new Intl.DateTimeFormat('sv-SE', {
timeZone: 'Asia/Shanghai',
}).format(new Date());
const slug = 'a-small-observation';
const filename = `${date}-${slug}.md`;
console.log(filename);
它没有解决所有写作问题，只是把一个小步骤变得确定。
把维护成本也算进去
节省一分钟的操作，如果每周需要半小时维护，就未必划算。工具的成本除了购买和学习，还包括故障、迁移、升级，以及不断纠结配置的时间。
可以给新工具一个短暂的试用期。在这段时间里，只记录三个问题：
- 它替我减少了哪一个具体动作？
- 它引入了什么新的负担？
- 不用它的时候，工作是否依然能够继续？
如果答案含糊，就暂时保留原来的简单办法。工具不需要因为已经安装了，就获得永久席位。
给失败留一条退路
一个小脚本也值得认真对待。处理重要文件时先预览操作，保留原件，避免静默覆盖；发生错误时给出明确提示，而不是只留下一个无法解释的结果。
好的自动化让常见的事情顺畅，也让意外的事情可理解。一个有用的错误提示，可能比十个高级选项更值得优先实现。
最终回到事情本身
当工具真正合适时，你不会总想着它的存在。你更容易开始写作，更快找到资料，或者少做了一次重复劳动。
省下来的注意力，不必立刻投入更多任务。也可以留给一次散步、一段没有通知打扰的阅读，或一个终于想清楚的问题。