做小工具时，我会先想它如何留下来

很多小工具都从一个很具体的烦恼开始：一段重复命令、一份需要清理的数据，或一个每周都会手动检查的列表。第一次实现通常不难，真正的问题是它能不能在两周之后仍然值得打开。

我现在做这类工具，会把“能否留下来”放在功能清单前面。它不等于提前设计一套庞大架构，而是先把几个基本边界想清楚：输入是什么，完成的信号是什么，失败时如何恢复，以及下一次打开时会看到什么状态。

把一次动作说清楚

一个按钮如果只写“开始”，使用者就不知道它会开始什么，也不知道操作之后会发生什么。相比之下，“检查 18 个文件”或“生成预览”会把动作和结果说在一起。

我会先写出这个工具最小的一条路径：

1. 使用者提供一个明确的输入。
2. 工具在处理前验证格式和范围。
3. 执行期间显示正在做什么。
4. 完成后展示结果和下一步。

这条路径如果无法被一句话描述，通常意味着产品边界还没有收紧。先删掉次要选项，反而能让第一个版本更容易被反复使用。

状态应该可以重新进入

日常工具会被关掉、刷新，也会在不完整的状态下重新打开。如果每次都丢失用户正在做的事情，工具就像一次性对话，而不是工作台。

我会区分三类状态：

• 输入草稿：用户还在编辑、不应被自动覆盖的值。
• 已提交状态：工具已经接受并正在执行的参数。
• 结果状态：最近一次操作的成功、失败和输出。

分开这三类状态之后，界面刷新时就能知道哪些值可以从后台重新读取，哪些必须保留为草稿。自动同步不应该让用户正在输入的数字突然跳回旧值。

失败时保留上下文

失败消息的任务不是解释实现细节，而是帮助用户判断接下来做什么。Unexpected error 没有提供可操作信息；“文件没有变化，原因是第 4 行的日期无效”就能让人继续处理。

一条实用的错误反馈通常包含三件事：

1. 哪个操作没有完成。
2. 已经发生了什么、哪些数据保持不变。
3. 可以立即采取的恢复方式。

如果操作能安全重试，就直接提供重试；如果用户需要修正输入，就把焦点放回有问题的字段，并保留其他已填内容。

自动化也需要退出路径

小工具常常会自动做事情：定时刷新、批量改名、同步文件或保存草稿。自动化越积极，越需要让用户看见它当前的状态，并能在必要时暂停或撤销。

保存操作尤其如此。一个安静的状态提示，例如“已保存 14:32”，通常比每次保存都弹出确认框更好。如果保存失败，界面应保留草稿并显示重试入口，而不是声称“保存成功”。

什么时候可以交付

我不会用设置项数量来判断一个工具是否成熟。我会用实际任务检查这些问题：

• 第一次打开时，是否知道从哪里开始？
• 输入错误时，是否能定位和修正？
• 关闭后重新打开，是否能继续原来的任务？
• 网络或权限失败时，是否保留已有结果？
• 键盘操作是否能覆盖主要流程？

如果这些答案都清楚，小工具已经有机会成为工作流的一部分。此时再根据真实使用记录扩展能力，通常比一次性猜测所有需求更稳妥。