【译】我的 AI 使用之旅
原文：Mitchell Hashimoto，My AI Adoption Journey，发表于 2026 年 2 月 5 日。本文为中文译文，保留关键专有名词、术语、外部引用链接与脚注；目录和脚注链接调整为本文内跳转。
目录
- 第一步：放下 Chatbot
- 第二步：复现你自己的工作
- 第三步：在一天结束前启动 Agent
- 第四步：把十拿九稳的任务交出去
- 第五步：工程化构建 Harness
- 第六步：始终让一个 Agent 运行
- 现在
根据我的经验，每当采用一种真正有用的工具时，我都必然会经历三个阶段：(1) 一段效率低下的时期；(2) 一段够用的时期；最后，(3) 一段发现它足以改变工作流乃至生活的时期。
大多数时候，我得强迫自己熬过第一和第二阶段，因为我通常已经有了一套令自己满意、用起来也很舒服的工作流。采用新工具感觉就像额外的工作，我并不想付出这番努力；但为了成为一名技艺更全面的从业者，我通常还是会去做。
这篇文章讲述了我如何从 AI 工具中找到价值，以及接下来打算尝试什么。在一片过分戏剧化、充满炒作的论调之中，我希望这篇文章能更细致、更审慎地呈现我对 AI 的看法，以及这些看法如何随时间发生变化。
这篇博文完全由我亲手撰写，使用的都是我自己的表达。我很讨厌自己还得专门声明这一点，但尤其考虑到文章的主题，我还是想把这件事说清楚。
第一步：放下 Chatbot
立刻停止尝试通过聊天机器人（Chatbot，例如 ChatGPT、网页版 Gemini 等）完成实质性的工作。聊天机器人确实有价值，也是我日常 AI 工作流的一部分，但它们在编程方面的作用非常有限，因为你基本上是在寄希望于它们根据之前的训练给出正确结果；而要纠正它们，就需要一个人——也就是你——反复告诉它们哪里错了。这很低效。
我想，每个人与 AI 的初次接触，都是通过聊天界面。我也认为，每个人第一次尝试用 AI 编程，都是让聊天界面帮自己写代码。
当我还是一个对 AI 深度怀疑的人时，第一次发出“哇，竟然可以这样”的感叹，是在我把 Zed 命令面板（command palette）的截图贴进 Gemini，让它用 SwiftUI 复现之后。它完成得非常好，着实让我大吃一惊。如今 Ghostty 的 macOS 版本中附带的命令面板，就是在 Gemini 几秒钟内为我生成的结果上，仅做了非常少量的修改。
但当我试图在其他任务中复现这种表现时，结果让我失望了。在已有代码基础的项目（brownfield projects）中，我发现聊天界面经常给出糟糕的结果；而且，在聊天界面与开发环境之间来回复制粘贴代码和命令输出，让我非常烦躁。显而易见，这远不如我自己动手高效。
要找到价值，你必须使用 Agent。Agent 是业界对能够循环进行对话、调用外部行为的 LLM（大语言模型）的称呼。1 最起码，Agent 必须具备这些能力：读取文件、执行程序，以及发起 HTTP 请求。
第二步：复现你自己的工作
在这段旅程的下一阶段，我尝试了 Claude Code。我就直说了：起初，它并没有让我觉得惊艳。我在会话里总是得不到好的结果。我觉得它生成的每样东西，我都得再修修补补，而这个过程比我直接自己动手还要耗时。我读了博文，也看了视频，但依然没有觉得它有多出色。
我没有放弃，而是强迫自己用 Agent 复现所有手工完成的提交。我真的把同一份工作做了两遍：先手工完成，然后再跟 Agent 较劲，让它产出在质量和功能上相同的结果——当然，不能让它看到我的手工解决方案。
这个过程非常煎熬，因为它妨碍了我直接把事情做完。但我在非 AI 工具上已经有足够多的经验，知道这种阻力很正常；如果不尽全力尝试，我就无法得出一个坚定、经得起推敲的结论。
不过，专业能力也在这个过程中形成了。我很快就从第一性原理（first principles）出发，亲自发现了别人早已在说的那些道理；而自己发现这些道理，让我对它们有了更扎实的根本性理解。
- 把工作拆成彼此独立、清晰且可执行的任务，分别开展会话。不要试图在一次超大会话里“画出整只猫头鹰”（draw the owl）。
- 对于模糊的请求，把规划和执行拆成不同的会话。
- 如果你给 Agent 提供一种验证自身工作的方法，它通常就能修正自己的错误，并防止回归问题。
更广泛地说，我也摸清了 Agent 在当时的能力边界：它们擅长什么、不擅长什么，以及对于它们擅长的任务，怎样才能得到我想要的结果。
这一切带来了明显的效率提升。我开始自然而然地使用 Agent，并且感觉这样做已经不比自己动手慢了——但我依然不觉得它更快，因为大多数时候，我仍然需要看着 Agent 干活。
这里有一点值得再次强调：部分效率提升，来自理解什么时候不该使用 Agent。让 Agent 去做一件它很可能会失败的事情，显然非常浪费时间；而知道如何彻底避开这种情况，本身就能节省时间。2
到了这个阶段，我已经从 Agent 身上找到了足够的价值，愿意把它们纳入自己的工作流，但仍然不觉得自己获得了任何净效率提升。不过，我并不在意；到这里，我已经满足于把 AI 当作一种工具来使用了。
第三步：在一天结束前启动 Agent
为了尝试提高效率，我接着开始了一种新模式：把每天最后 30 分钟留出来，启动一个或多个 Agent。我的假设是，如果 Agent 能在我本来就无法工作的时段取得一些有益进展，也许就能提升效率。说白了，就是不再试图在我有时间的时候做更多事，而是试着在我没有时间的时候做更多事。
和上一步类似，起初我发现这种做法既不成功，也让人烦躁。但我又一次很快找到了几类真正有帮助的工作：
- 深度研究会话：让 Agent 调研某个领域。例如，找出某种编程语言中采用特定许可证类型的所有库，并为每个库生成一份数页长的总结，说明各自的优缺点、开发活跃度、社区口碑等。
- 让多个 Agent 并行探索一些我想过、却没有时间着手的模糊点子。我并不指望它们在这里产出任何可以直接交付的东西，但当我第二天开始处理这项任务时，它们或许能帮助我看清一些“未知的未知”（unknown unknowns）。
- 对 Issue 和 PR 进行分流与审查（triage/review）。Agent 很擅长使用
gh（GitHub CLI），所以我自己写了脚本，可以快速并行启动一批 Agent，对 Issue 进行分流。我不会允许 Agent 回复；我只想在第二天拿到报告，帮助自己找到高价值或低投入的任务。
说清楚一点，我并没有像有些人那样，让 Agent 整夜循环运行。大多数时候，Agent 不到半小时就完成了任务。但在工作日的后半段，我通常已经很累，也逐渐退出了心流状态，个人效率明显下降。因此，我发现，把精力转移到启动这些 Agent 上，可以让我第二天早上获得一次“热启动”（warm start），比原本更快地进入工作状态。
我很满意，而且开始觉得，自己确实比使用 AI 之前做得更多了——哪怕只多了一点。
第四步：把十拿九稳的任务交出去
到了这时，我已经非常清楚，自己的 AI 擅长和不擅长哪些任务。对于某些任务，我有很高的把握，知道 AI 能给出一个基本正确的解决方案。因此，我的下一步就是：让 Agent 完成所有这些工作，而我去处理其他任务。
具体来说，每天开始工作时，我都会拿出前一晚负责分流的 Agent 给出的结果，手动筛选出那些 Agent 几乎肯定能妥善解决的 Issue，然后让它们在后台继续运行——一次一个，而不是并行运行。
与此同时，我会去做别的工作。我没有去刷社交媒体——至少没有比不使用 AI 时刷得更多——也没有去看视频。我会回到自己正常的、使用 AI 之前的深度思考模式，处理那些我想做或者必须做的事情。
这一阶段有一点非常重要：关闭 Agent 的桌面通知。上下文切换（context switching）的代价非常高。为了保持效率，我发现，作为人类，我的职责是掌握自己何时去打断 Agent，而不是反过来。不要让 Agent 来通知你。在工作自然出现间歇时，切换过去看看它的进展，然后继续做自己的事。
我认为，“去做别的工作”有助于抵消那篇广受关注的 Anthropic 技能形成研究论文所指出的问题。当然，这里面有取舍：对于委托给 Agent 的任务，你不会在这些任务上形成相应技能；但对于继续亲自动手完成的任务，你仍然会自然地形成技能。
到了这一步，我已经彻底进入了“不可能再回到从前”的状态。我觉得自己更高效了；但即便没有变得更高效，我最喜欢的一点仍然是：现在，我可以把编程和思考的精力集中在自己真正喜欢的任务上，同时又能妥善完成那些自己没那么喜欢的任务。
第五步：工程化构建 Harness
冒着说一句显而易见的话的风险，我还是要强调：如果 Agent 第一次就能产出正确结果，或者最差也只需要做一点点修补，它们的效率就会高得多。要实现这一点，最可靠的办法，就是给 Agent 提供快速、高质量的工具，让这些工具自动告诉它哪里做错了。
我不知道业界是否已经有一个广泛接受的术语，但我逐渐开始把它称为“Harness 工程（harness engineering）”。它的理念是：每当你发现 Agent 犯了一个错误，就花时间通过工程手段找到一种解决方案，让 Agent 此后不再犯同样的错误。我并不想在这里发明什么新词；如果已经有别的术语，我很乐意跟着使用。
这有两种形式：
- 更好的隐式提示（implicit prompting，
AGENTS.md）。对于一些简单问题，例如 Agent 反复运行错误的命令、找错 API，就更新AGENTS.md或类似文件。这里有一个来自 Ghostty 的例子。那个文件中的每一行，都源自 Agent 的某种不良行为，而这些规则几乎解决了所有这些问题。 - 真正用代码实现的工具。例如，用于截图、运行经过筛选的测试等的脚本。通常还要配套修改
AGENTS.md，让 Agent 知道这些工具已经存在。
这就是我目前所处的阶段。每当看到 Agent 做错事，我都会认真想办法，避免它再次犯下同样的错误。反过来说，我也会认真想办法，让 Agent 能够验证自己正在做对的事情。
第六步：始终让一个 Agent 运行
在进行第五步的同时，我还在朝另一个目标努力：始终让一个 Agent 运行。如果没有 Agent 在运行，我就会问自己：“现在有没有什么事情，是 Agent 可以替我做的？”
我特别喜欢把这种做法与更慢、思考更深入的模型结合起来，例如 Amp 的 deep mode——它基本上就是 GPT-5.2-Codex。它可能要花上 30 多分钟，才能完成一些小改动。但另一方面，它给出的结果通常确实非常好。
我目前还没有——也许以后会？——同时运行多个 Agent，而且现在也不太想这样做。我发现，只让一个 Agent 运行，对我来说恰好取得了一种平衡：既能让我享受亲自动手的深度工作，也能照看我那个有点笨、却又莫名高产的机器人朋友。
“始终让一个 Agent 运行”，目前仍然只是一个目标。我想，在一个正常工作日中，我现在大概只有 10% 到 20% 的时间，能有效地让一个后台 Agent 保持运行。但我正在积极改善这一点。
我不想为了运行 Agent 而运行 Agent。我只想在存在某项我认为真正对自己有帮助的任务时，才让它们运行。这个目标的一部分挑战，是改进我自己的工作流和工具，让自己能够持续拥有一批高质量、可以委托出去的工作。即使没有 AI，这一点也很重要！
现在
以上就是我目前所处的阶段。
通过这段旅程，我已经能够成功运用现代 AI 工具，而且我认为，自己是以一种适度、审慎、立足现实的态度在使用它们。AI 究竟会不会长期存在，我真的不在意。3 我是一名软件匠人，只是出于对这门手艺本身的热爱，想把东西做出来。
整个领域发展得如此之快，我相信自己很快就会回头看这篇文章，并为当时的天真发笑。但正如那句话所说，如果你无法为过去的自己感到难为情，那你很可能没有在成长。我只希望自己能朝着正确的方向成长！
我在这件事上没有利益关系。4 当然，除了实用性之外，也还有其他理由让人选择不使用 AI。我完全尊重每个人在这件事上的个人决定。我不是来劝服你的！对于感兴趣的人，我只是想分享自己探索这些新工具的方式，也让你们稍微了解一下：无论是否与 AI 有关，我通常会如何对待新工具。