译者注：本文为翻译文章，原文作者是 @mitchellh 原文标题：My AI Adoption Journey 原文链接：https://mitchellh.com/writing/my-ai-adoption-journey
我在采用任何真正有分量的工具时，几乎都会经历三个阶段：（1）低效期，（2）勉强够用期，最后才是（3）工作流乃至生活都被改变的发现期。
多数时候，我都得逼着自己熬过前两个阶段，因为我通常早就有一套自己满意、也用得顺手的工作流。学习新工具本身就像一项工作，而我其实并不想为此投入额外精力；但为了让自己在这门手艺上更全面一点，我通常还是会去做。
这篇文章写的是：我是怎么在 AI 工具里找到价值的，以及接下来还想怎么继续尝试。在满是夸张、煽动、过度吹捧观点的海洋里，我希望这篇文章能代表一种更细腻、更克制的态度——关于我如何看待 AI，以及这种看法又是怎样随着时间变化的。
这篇博文完全是我亲手写的，全部出自我自己的表达。说实话，我很讨厌自己还得特意说明这一点；但考虑到这篇文章的主题，我还是想把这件事讲清楚。
第一步：放下聊天机器人
立刻停止试图通过聊天机器人来完成真正有意义的工作（比如 ChatGPT、网页版 Gemini 之类）。聊天机器人确实有实际价值，它们也是我每天 AI 工作流的一部分；但它们在编码上的用处其实很有限，因为你大多只是寄希望于它们能凭借既有训练“碰巧”给出正确结果，而一旦它们做错了，就得由人类——也就是你——反复告诉它哪里错了。这个过程很低效。
我觉得，大多数人第一次接触 AI，都是从聊天界面开始的；而大多数人第一次尝试用 AI 写代码，也都是让聊天界面直接帮自己写代码。
在我还是一个强烈怀疑 AI 的人时，我第一次真正“哇靠”的时刻，是我把 Zed 命令面板的截图贴给 Gemini，让它用 SwiftUI 复刻出来。它做得非常好，好到让我真的有点震惊。今天 Ghostty 在 macOS 上自带的那个命令面板，基本就是在 Gemini 几秒钟生成出来的版本上，稍微改了一点点。
但后来我想把这种表现复制到其他任务上时，就失望了。在已有项目的语境里，我发现聊天界面给出的结果经常很差；而且我也越来越受不了来回复制粘贴代码和命令输出。很明显，这比我自己直接动手还要低效得多。
如果你想真正从中获得价值，你必须使用智能体（agent）。所谓智能体，是业内对这样一种 LLM 的通用称呼：它不仅能聊天，还能在循环中调用外部能力。至少最基本地说，它必须能够：读取文件、执行程序、发起 HTTP 请求。
第二步：复现你自己的工作
在接下来的阶段里，我开始尝试 Claude Code。先说结论：我一开始并不觉得它有多惊艳。我的会话效果就是不够好。我感觉它产出的每个东西我都得自己再修一遍，而这整个过程花的时间，比我直接自己做还多。我看了很多博文，也看了很多视频，但还是没有被说服。
于是我没有放弃，而是强迫自己用智能体去复现我所有原本手工完成的提交。我是真的把同一份工作做了两遍：先自己手动完成一次，然后再和一个智能体“缠斗”，让它在质量和功能上做出几乎一模一样的结果——当然，前提是它不能看到我手工写出来的答案。
这过程非常折磨人，因为它妨碍了我单纯把事情做完。但我在非 AI 工具上也算见过不少世面了，所以我知道：磨合带来的阻力是很正常的；如果我没有把各种努力都做尽，就没法得出一个坚定、站得住脚的结论。
但能力也正是在这个过程中形成的。我很快就从第一性原理出发，亲自发现了那些别人早就在说的事。而“自己发现”这件事，会让我对底层规律有更扎实的理解。
- 把一次会话拆成多个清晰、可执行的独立任务。
- 不要试图在一个超大号会话里“一步画出整只猫头鹰”。
- 对于模糊的需求，把“规划”和“执行”拆成不同的会话。
- 如果你能给智能体一个验证结果的方法，它往往就能自己修掉错误，并且避免引入回归。
更广义地说，我也开始摸清智能体——至少在当时——擅长什么、不擅长什么；以及对于它擅长的任务，我该怎样才能拿到自己真正想要的结果。
这一切都带来了明显的效率提升。提升到什么程度呢？提升到我开始自然而然地以一种我觉得“不比自己亲手做更慢”的方式使用智能体了——虽然我仍然不觉得它更快，因为大部分时候我还是在一旁盯着它、照看它。
这里有个反面空间，值得再强调一次：效率提升的一部分，恰恰来自于我知道什么时候不该用智能体。把智能体用在它大概率会失败的事情上，显然是在浪费时间；而具备识别并回避这些场景的能力，本身就能节省大量时间。
到了这个阶段，我已经从智能体上获得了“足够可用”的价值，我也乐意把它们纳入自己的工作流里。可即便如此，我还是不觉得自己获得了净效率收益。不过我已经不太在意了，因为到那时，我已经愿意把 AI 当成一种工具来使用了。
第三步：下班前启动智能体
为了进一步挤出一些效率，我接着开始尝试一种新模式：每天最后 30 分钟，专门留出来启动一个或多个智能体。我的假设是：如果智能体能在我本来就没法工作的时间里，推进一些有价值的进展，那也许我就能获得一些额外效率。说白了，就是：与其想办法在我“有时间”的时候做更多，不如试着在我“没时间”的时候也做更多。
和前一步类似，我一开始也觉得这事既不成功又挺烦人。但很快我又发现了一些特别有帮助的工作类型：
- 深度研究类任务。比如让我让智能体去扫描某个领域，找出某种语言下、带某种许可证类型的所有库，并分别写出多页摘要，分析它们的优点、缺点、开发活跃度、社区舆论等等。
- 并行尝试我脑子里一些模糊的想法——那些我没时间亲自起步的点子。我并不指望它们产出什么我会直接上线的成果，但也许能在第二天我真正开始做这个任务时，帮我照亮一些原本根本没意识到的未知问题。
- Issue 和 PR 的分流、审查。智能体很会用 gh（GitHub CLI），所以我手动写了个小脚本，能很快并行拉起一堆智能体去分流 issue。我要强调的是：我不会允许智能体直接回复 issue；我只是想在第二天收到一些报告，帮助我把注意力引向那些高价值或者低成本的任务。
需要说清楚的是，我并没有像有些人那样，让智能体整夜在循环里跑。大多数情况下，智能体在半小时内就能把任务做完。不过，一天工作接近尾声时，我通常已经累了，也从专注状态里出来了，那时我个人效率本来就很差；所以把这段时间用来启动这些智能体，反而让我第二天早上能以一种“热启动”的状态更快进入工作，比原本更容易开工。
我对此很满意，而且我开始感觉自己做的事情，确实比没有 AI 之前稍微多了一点。
第四步：把十拿九稳的活外包出去
到了这个阶段，我已经非常清楚哪些任务 AI 擅长，哪些不擅长。对某些任务，我已经有了很高的把握：AI 基本能做出一个大体正确的方案。于是我旅程中的下一步就变成了：让智能体把这些活全做了，而我自己去做别的事。
更具体地说，我会每天一早先看前一晚那些分流智能体产出的结果，手动筛选出那些“智能体几乎肯定能解决得不错”的 issue，然后让它们在后台继续跑——一次只跑一个，不并行。
与此同时，我去做别的事情。我不会去刷社交媒体（至少不会比没有 AI 时刷得更多），也不会去看视频之类。我仍然是在自己原本那种、AI 出现之前就有的深度思考模式里，做那些我想做或者必须做的工作。
这个阶段有个非常重要的点：把智能体的桌面通知关掉。上下文切换非常昂贵。为了保持效率，我发现作为人类，我的职责就是自己掌控“什么时候打断智能体”，而不是反过来。不要让智能体通知你。等你工作中自然出现停顿时，再切过去看它一下，然后继续你的事。
更重要的是，我觉得“我去做别的事”这一点，在某种程度上抵消了那篇被广泛讨论的 Anthropic 技能形成论文所担忧的问题。你当然是在权衡：对于那些你交给智能体的任务，你不再亲自形成技能；但与此同时，对于那些你依然手动完成的任务，你仍然在自然地形成技能。
到了这一步，我已经彻底进入“我不可能再回去了”的状态。我觉得自己更高效了；但即便事实并非如此，我最喜欢的一点也仍然是：我终于可以把自己的编码和思考，集中在那些我真正热爱的任务上，同时又能把那些我不那么喜欢的任务，依然以足够合格的方式完成掉。
第五步：为“缰绳”做工程
说一句显而易见的话：当智能体第一次就做对了，或者最差也只是给出一个只需稍微修修补补的结果时，它的效率会高得多。而要实现这一点，最可靠的方法，就是给它快速、高质量的工具，让它能够自动知道自己什么时候错了。
我不知道业内现在有没有一个被广泛接受的正式术语，但我自己渐渐把这件事称作“缰绳工程”（harness engineering）。它的核心理念是：每当你发现智能体犯了一个错，你就投入一点时间，设计出一个方案，让它以后再也不会犯这个错。或者反过来说，你要尽量让智能体能够验证：自己现在确实是在做一件正确的事。这个词不一定非得由我来发明；如果已经有更通行的说法，我也乐意跟着用。
这件事大体上有两种形式：
第一种，是更好的隐式提示（比如 AGENTS.md）。对于一些简单问题，比如智能体总是跑错命令，或者总是去找错 API，那就更新 AGENTS.md（或者等价的文件）。Ghostty 里就有一个这样的例子。那个文件里的每一行，几乎都是针对某种糟糕的智能体行为写进去的，而它几乎把这些问题都解决掉了。
第二种，是真正写出来的程序化工具。比如用来截图的脚本、跑过滤测试的脚本，等等。这通常会和 AGENTS.md 的修改配套出现，让智能体知道这些工具已经存在。
这就是我现在所处的位置。每当我看到智能体干了件坏事，我都会认真想办法，尽量让它以后永远别再干这种坏事。反过来，我也会认真想办法，让智能体有能力验证自己是否正在做一件好事。
第六步：始终让一个智能体跑着
和第五步并行进行的，是我现在给自己设下的另一个目标：任何时候都尽量让一个智能体在运行。如果此刻没有智能体在跑，我就会问自己一句：“现在有没有什么事，是智能体可以替我去做的？”
我尤其喜欢把这个目标和更慢、更谨慎的模型搭配起来，比如 Amp 的 deep mode（本质上就是 GPT-5.2-Codex）。这类模型可能要花 30 多分钟，才能做出一些很小的改动；但反过来说，它们给出的结果往往也确实很好。
我现在还没有——至少暂时还没有——同时跑多个智能体，而且目前也不是很想这么做。对我来说，始终只跑一个智能体，是一个很好的平衡点：既能让我继续做那些我乐在其中的、深入的手工工作，也能顺手照看一下这个有点笨、却又神秘地挺能干的机器人朋友。
“始终让一个智能体跑着”现在还只是个目标。就我目前的状态来说，在正常工作日里，大概只有 10% 到 20% 的时间，我是真的有效地让后台有智能体在工作。但我确实在积极改进这件事。
我并不想为了“让智能体跑着”而让智能体跑着。我只想在我真心觉得它会对我有帮助的任务上使用它。