从一个小麻烦开始

小工具的起点可以很窄：整理一组文件名，把零散的链接收在一起，或让重复输入少一点。不必先为它构想一个平台。把问题缩到可以一句话说清楚的程度，反而更容易看见真正需要的功能。

“慢慢做”不是拖延，也不是把简单的事装饰得复杂。它意味着允许工具在使用中长出形状。先确定输入和输出，再考虑界面；先让一个动作可靠，再决定是否需要第二个。每一步都留下可以理解的结果。

让核心保持可读

比如，一个为标题生成路径片段的函数，可以先只服务已经约定好的英文标题。与其立刻支持所有语言和格式，不如让当前边界清楚可见：

function titleToSlug(title) {
  return title
    .trim()
    .toLowerCase()
    .replace(/[^a-z0-9]+/g, '-')
    .replace(/^-+|-+$/g, '');
}

titleToSlug('Small tools, slowly');
// 'small-tools-slowly'

这段代码只是一个有意缩小的例子。它不会把中文转成拼音，也不负责解决路径冲突。把限制说清楚，才能判断下一步是在补上必要能力，还是在替尚未出现的问题忙碌。一份简短的使用说明也属于工具本身，它让后来接手的人，包括未来的自己，知道哪些输入合适，哪些结果需要再检查。

把边缘照顾好

决定品质的，常常是主流程旁边的小事：没有内容时显示什么，失败后能否重试，删除之前能否看清对象，完成之后是否有明确反馈。这些细节不像新增功能那样醒目，却影响一个工具是否值得反复使用。

可以给自己留一张很短的检查表：第一次打开是否知道怎么开始；一个操作是否只做一件事；错误是否说明下一步；退出之后是否还能找回结果。检查表不必越来越长。只保留那些确实帮助做出更好决定的问题。

也练习停下来

当工具已经顺手，新的想法不一定要立刻实现。把它们写在旁边，过一段时间再看：这个需求依然存在吗？它是否可以用现有动作完成？多一个设置，是否也多了一次解释？

小工具有一种很好的尺度：可以看懂，可以修改，也可以放下。它不需要证明自己能覆盖一切。慢慢做，是让每一次添加都有理由，也让每一次删减获得同样的尊重。一个恰到好处的句号，本身就是设计。