有趣的 AI 工具层出不穷，早已超过任何人能够逐一评估的范围。真正稀缺的不是工具，而是你用来确认它是否有效的时间。
下面是一套更合理地投入这些时间的流程，而且会刻意帮助你尽快得出“不采用”的结论。
先看失败模式，而不是演示
每个项目都会先展示自己做得好的地方。真正有用的问题是它做不好什么，而答案通常不在 README，而在问题追踪器中。
按评论数量排序未关闭的问题，然后阅读前十条。五分钟内得到的信息，往往比阅读再多文档都更有价值。
判断它是否仍有人维护，而不是是否热门
Star 只能说明有多少人曾经觉得某个项目看起来有趣，无法说明它现在是否还能正常工作。
更可靠的信号包括：
- 最近一次非依赖升级提交的日期
- 问题是否会得到回复，哪怕只是简短回应
- 最新版本是否从一个仍然存在的分支发布
一款只有 800 个 Star、但维护者会回答问题的工具，通常比一款拥有 30,000 个 Star、问题列表里却堆满两年前未处理事项的工具更稳妥。
用真实任务运行它
演示代码仓库的选择目标，是让工具表现得更好。你的代码仓库并不是为此准备的。
给它一个你已经亲自完成过的任务，这样无需再次调查，就能判断输出质量。如果它连你知道答案的问题都处理不好，就更不可能处理好你不知道答案的问题。
投入之前先算清退出成本
真正重要的问题不是“它好不好”，而是“停止使用它时会发生什么”。
如果一款工具读取现有文件并写出普通格式的结果，放弃它几乎没有成本。如果它把数据存进自己的格式，或者让其他系统逐渐依赖它，情况就不同了。当两种选择实力接近时，优先选择可逆的方案——你是在购买一种能够低成本犯错的能力。
何时停止评估
得到答案后就停下，不必等到掌握完整全貌。大多数评估都应该在一小时内结束，通常结论是“不采用”，并留下一句话说明原因。这样下次再看到同一工具时，就不必重复这项工作。
把这条记录写在以后能够找到的地方。最常见的评估浪费，就是第二次评估一款你已经拒绝过的工具。