提出根据任务失败模式(而非模型排名)选择 AI 工具的决策框架:长文本用通用模型、代码用专化工具、设计用视觉模型。帮助开发者避免盲目跟风,提高工具选型的合理性。
打开任何技术信息源,都会有人声称发现了新的"最佳 AI"。某个模型登顶排行榜,相关帖子刷屏,一周后又有另一个模型登上另一个排行榜。如果你这样选择工具,那你优化的是一个与你的工作毫无关系的数字。
真正有用的问题不是"哪个模型最聪明"。而是"这个任务在出错时会惩罚什么?"营销邮件会惩罚机械生硬的语气。迁移脚本会惩罚构建失败。财务表格会惩罚差一列的错误。Logo 会惩罚显得通用无趣。这四个失败是不同的,它们指向四个不同的工具。
打开聊天窗口前,你需要明确两件事:工作类型,以及你如何判断它失败了。失败模式为你做了大部分选择。
这是一个简洁的框架。把工具名称当作分类,而不是金科玉律,因为具体排名每隔几个月就会改变。
两个核心观点主要起作用。
首先,将工具与任务无法容忍的失败类型相匹配。如果任务有硬性检查(代码能编译、数字加起来对、事实真实),那就选择能连接到这个检查的工具:代码执行、仓库访问、网络检索。对于初稿,猜测型模型还可以接受,但对于薪资公式来说很危险。
其次,通用聊天模型是通才。对于开放式的工作(标准是柔性的),如写作和大声思考,它们是正确的默认选择。但当任务有机械的基本事实时,它们就不是正确的默认了,因为此时你需要的是掌握基本事实的工具,而不是排行榜分数最高的那个。
举个快速的例子。如果让一个普通聊天模型对粘贴的数据执行"汇总地区为 EU 的 C 列",它常常会给出一个有把握但略微错误的数字。但如果向代码执行工具提出同样的请求,它会写出:
df[df.region == "EU"]["C"].sum()
运行它,然后返回一个你可以信任的数字。同样的请求,不同的失败表面。
公共基准是对不属于你的任务的平均值。在编码基准上获胜的模型可能在你的代码库、你的命名约定、你的奇怪遗留模块上失败。
所以对你真正拥有的任务进行一个小规模的对比测试。这需要花一个下午,结果反映的是你的工作,而不是每个人的平均值。
选择三个你真正做过的真实任务,每个对你重要的类别一个。
用相同的提示在两到三个候选工具上各运行一次。
按你关心的方面评分:正确性、所需编辑数、时间节省。而不是感觉。
记下哪个工具在哪个类别赢了。这个记录是你真正的排行榜。
也许一年重跑两次,或者当你使用的工具发布重大更新时。排名会改变,但你的测试不会,所以重新检查很便宜。
类别会模糊。许多真实工作是混合的:以书面总结结尾的数据任务,需要当前库文档的编码任务。对于混合工作,拆分工作并路由每部分,或接受一个工具在所有方面都只是不错而不是在某一方面很出色的事实。
"倾向于适合"是一个起始的假设,不是最终判决。上面的标签反映了这些工具家族是如何构建的,不是对你确切提示的保证。如果你自己的对比测试与表格不一致,相信你的对比测试。这就是运行它的整个意义。
按任务选择,在你自己的工作上验证,让排行榜随意奖励它们喜欢的。
我写的是如何把 AI 从聊天玩具变成工作工具。我帮助开发 AGINE Academy,一个基于游戏的学院,通过实际练习学习 Claude。这是一个独立的产品,与 Anthropic 无关联。
如需进一步操作,你可以考虑屏蔽这个人和/或举报滥用