打开一篇工具介绍，最容易带走的是一个新名字，最难带走的是一个决定。文章说它轻巧、强大、设计漂亮；读者关掉页面后，仍要自己弄清楚：它能替我解决哪件事？要付出什么？试过以后怎么知道该留下还是删掉？

我也喜欢发现新东西。但如果一篇文章只能让收藏夹多一个链接，它提供的帮助很有限。比“值得试试”更有用的，是一张能在试用前写下来的小卡片。

先写问题，不写产品名

第一行只写正在发生的麻烦。例如：“每次交接前，我都要手工核对两份配置，常常漏掉一项。”这比“想找一个配置管理工具”窄得多，也更容易验证。

接着写现在的做法。也许是一个脚本、一张表，或者十分钟的人工检查。新工具必须与这个真实的基线比较；若连原来的成本都说不清，“效率提升”就只是漂亮的形容词。

最后列出不能接受的代价：是否要把资料交给第三方，是否会改变现有文件格式，团队里是否只有一个人懂得维护。这里没有通用的正确答案。同一个工具对个人实验可能合适，对共享工作流却可能太重。

让试用有终点

我会给试用卡加两句可以被推翻的话：

如果它能在一份副本上完成这项具体任务，结果能由我核对，而且退出后原来的做法仍可继续，我就考虑保留。

如果安装和迁移花掉的时间已经超过它可能省下的时间，或者关键结果无法核对，我就停下。

“一份副本”很重要。先在可丢弃的材料上试用，才能放心观察失败；直接把每天依赖的流程交给新工具，试用很快会变成不得不继续使用。

时间边界也要具体。可以先给自己半小时，结束时记录它完成了什么、哪里卡住，以及下一步还要投入多少。半小时不是产品质量的判决，只是阻止一次好奇心在不知不觉中变成长期承诺。

把结论写成三行

试用结束，不必写一篇长评。三行足够：

  1. 观察到的事实：我实际运行了什么，得到了什么结果。
  2. 目前的判断：在我的场景里，它比原来的做法好在哪里，或为什么没有。
  3. 仍然不知道的事：没有测过的系统、边界条件、长期维护和费用。

第三行不是客套的免责声明。它告诉后来读这张卡的人，结论能用到哪里、不能用到哪里。没有运行过，就不要把文档中的示例写成自己的体验；只看过介绍，也可以诚实地说这仍是一个值得验证的想法。

谷米接下来也按这张卡写

这个博客以前介绍了许多小项目，以后仍会写我觉得有意思的 GitHub 工具。但项目名不再是每天的选题起点。阅读、写作、维护一个小网站，以及某个值得慢慢想清楚的问题，都可以成为文章。

无论写什么，我希望每篇都能留下一个可核对的事实、一个讲清适用范围的判断，以及一个还没有答案的问题。今天这张试用卡就是第一个练习：下次想点“收藏”时，先把要解决的事写下来。写不出来，也许现在需要的不是另一个工具。