最近两个月，我把电脑上的 AI 工具删到只剩三个。
不是因为新的不好用。恰恰相反，是因为我发现自己陷入了一个很隐蔽的循环：每次有新模型、新 Agent 出来，我都会花半小时装上，试着让它做两个任务，感叹一句"确实强"，然后……继续用回原来那套。工具在增加，交付没有变快。
后来我意识到问题出在组织方式上。我一直是在用产品名组织工作——"这个任务用 A，那个任务用 B"。但真正决定效率的，不是产品名，而是交付物。同样一句"帮我写个页面"，交付一个能上线的静态站，和交付一个还在验证想法的原型，是两件完全不同的事。
所以这篇文章不排榜单。我只讲一个判断标准，和我最后留下的三件工具。
我的判断标准：三个问题
在决定要不要留下一个 AI 产品之前，我会问三个问题。
第一，它交付的是什么？ 是一段能运行的代码、一份可编辑的文档、一次可回滚的改动，还是一屏只能"看起来不错"的文本？交付物的形态，决定了它能不能进入真正的工作流。
第二，我怎么验证它？ 有测试可以跑吗？有 diff 可以看吗？有预览可以点吗？如果验证成本高于自己重做一遍，那这个工具再聪明也没用。
第三，上下文从哪来？ 是从仓库和构建系统里自动读出来的，还是需要我手动把一屏文本贴进去？上下文越依赖人工搬运，任务越长越容易崩。
用这三个问题筛一遍，很多"看起来很厉害"的产品会自然掉队。留下来的，通常是那些愿意把自己嵌进工程链路、而不是停在对话框里的东西。
CodeArts：把验证闭环放进同一个环境
CodeArts 是我目前放在第一位的那件。
它不是一个单独的聊天窗口，而是一条从需求到上线的链路：代码仓库、代码检查、编译构建、测试、部署，都在同一个体系里。CodeArts 里的 Agent 可以在仓库中直接读文件、改文件、执行命令、跑测试。这个能力听起来不新鲜，但真正让它有用的是验证闭环——它改完东西之后，能立刻在同一个环境里跑一遍，而不是把结果丢给我，让我自己去发现哪里不对。
我今天的实际用法是这样的：写一个单文件的 Canvas 小游戏，生成一张 1200×630 的封面，然后用 Playwright 分别打开本地和线上页面，模拟真实操作二十秒，确认没有控制台报错、没有 404，最后用 OnePage CLI 推上线。整个过程我基本没有离开终端。Agent 负责写和改，验证脚本负责说"行"或"不行"，这个分工比"让模型自己保证没问题"可靠得多。
它的局限也很清楚。第一，它更适合有工程形态的任务。 你要它改一个仓库、加一个功能、补一组测试，它很顺；你要它处理一个连需求都还没想清楚的一次性脚本，整条链路反而显得重。第二，它对环境有真实依赖。 CLI、权限、网络，任何一环不通，它就只能停在"我建议你这样做"。这不是模型能力的问题，是工具和环境的接口问题。第三，长链路任务仍然需要人盯着。 它可以连续做很多步，但方向错了，它也会很认真地错下去。
所以我不把它当"全自动程序员"，更像是"一个能动手、也能被检查的同事"。
WorkBuddy：处理那些没有测试的交付物
WorkBuddy 代表另一类产品：面向日常办公场景的 AI 助手。
它处理的对象不是仓库，而是文档、表格、资料、日程这些"人每天都要碰、但很少写测试"的东西。我用它的场景很窄：把散落的会议记录整理成结构化的待办，或者把一份长文档压成能给同事看的摘要。它在这类任务上的优势是门槛低——不需要懂 Git，不需要开终端，打开就能用。
但这类任务有个天然的麻烦：正确性没有自动校验。 文档整理错了不会报错，只会在会议上被问住。所以我的习惯是，让 AI 出第一稿，自己一定重读一遍关键数字、人名和时间。AI 可以负责结构，不能负责事实。
另一个需要自己把握的是数据边界。办公类助手的能力，和它被允许访问的文件、应用范围强相关。具体能读什么、能操作什么，要以你实际安装的版本和授权设置为准，不要假设它什么都能碰。把权限交出去之前，先想清楚哪些东西不该被读到。
它不适合我用来做工程交付，但很适合处理"必须有人做、又不太值得人做"的整理工作。
Trae：上下文就在眼前的编辑器
Trae 是第三种形态：以编辑器为中心。
它的好处很直接——上下文就在你眼前。打开的项目、当前文件、选中的代码，都在同一个窗口里。做单文件原型、改一个中等规模的前端项目、或者边看边改的时候，它比"把代码贴进聊天框"顺手太多。你不需要解释"我的项目长什么样"，编辑器已经知道了。
局限则在于形态本身：编辑器天然偏向"写"，不偏向"交付"。 部署、域名、CI、线上验证，最后还是得回到终端或者平台。它适合做前半程，后半程要换工具。这不是缺点，是分工。
我的组合方式：按交付物切换
我最后留下的，不是三个都天天用，而是按交付物切换：
- 要交付一个能上线、能被验证的工程产物，用 CodeArts；
- 要交付一份给人看的文档或整理结果，用 WorkBuddy 这类办公助手；
- 要交付一个还在探索中的原型，用 Trae 这类 AI IDE。
工具不是越多越好。切换成本本身就是成本。一个工具如果能覆盖你 80% 的交付物，剩下 20% 再考虑加工具，比一开始就装五个要划算。
最后说一个反面
AI 产品最擅长制造"完成感"。代码看起来对，文档看起来很顺，页面看起来很漂亮。但"看起来完成"和"验证通过"之间，往往隔着一次真实的运行。
我现在的习惯是，任何 AI 产出的东西，先问一句：我能在五分钟内验证它吗？ 如果不能，就先别急着说它完成了。能被验证的工具，才配留在工作流里；不能被验证的产出，再漂亮也只是草稿。
选 AI 产品的标准，不是榜单上排第几，也不是参数多漂亮，而是它能不能让你的交付物更容易被验证。这句话听起来朴素，但它帮我删掉了大部分工具，也帮我留住了真正有用的那三个。
评论