本文原文地址,使用claude进行了翻译，作者是HashiCorp的创始人Mitchell Hashimoto。
作者：Mitchell Hashimoto | 原文日期：2026年2月5日
我在采纳任何一款有价值的工具时，通常都会经历三个阶段：（1）低效期、（2）适应期，最终才到达（3）彻底改变工作流程乃至生活方式的顿悟期。
大多数情况下，我必须强迫自己熬过第一阶段和第二阶段——因为我通常已经有一套令自己满意且顺手的工作流程。引入新工具意味着额外的付出，我实在不想花这份力气，但出于对所在领域的全面性追求，我通常还是会去尝试。
这篇文章记录了我如何在 AI 工具链中找到真正价值的历程，以及我正在探索的下一步方向。在一片夸大其词、充斥炒作的声浪中，我希望这篇文章能呈现一种更细腻、更审慎的视角，如实反映我对 AI 的看法是如何随着时间推移而演变的。
本文完全由我亲手写就，字字出自本人之口。这句话放在这里本不必要，但鉴于文章的主题特殊，我想明确声明。
第一步：放弃聊天机器人
立即停止通过聊天机器人（如 ChatGPT、Gemini 网页版等）完成有实质意义的工作。聊天机器人确实有其价值，也是我日常 AI 工作流程的一部分，但在编程场景下，其效用极为有限——因为你基本上是寄希望于模型凭借预训练知识碰巧给出正确答案，而纠错则需要人工（即你本人）反复告知它哪里错了，效率极低。
我认为，几乎所有人与 AI 的第一次接触都是聊天界面。同样，几乎所有人第一次尝试用 AI 辅助编程，也都是向聊天界面输入需求、让它生成代码。
在我还是个坚定的 AI 怀疑论者时，我第一次发出"哇哦"的感叹，是将 Zed 命令面板的截图粘贴给 Gemini，让它用 SwiftUI 复现出来——它的表现之出色令我真正震惊。如今 Ghostty macOS 版中内置的命令面板，正是在 Gemini 几秒内为我生成的代码基础上，仅做了极少量改动后发布的。
但当我试图将这种成功经验复制到其他任务时，却屡屡失望。在存量代码库（brownfield project）的上下文中，聊天界面产出的结果往往很差，我发现自己在代码和命令输出的复制粘贴上来回折腾，效率明显低于亲自动手。
要真正发掘价值，你必须使用智能体（Agent）。智能体是业界公认的术语，指能够在对话循环中调用外部能力的大型语言模型（LLM）1。至少，该智能体必须具备以下能力：读取文件、执行程序，以及发起 HTTP 请求。
第二步：用智能体重现自己的工作
在探索历程的下一阶段，我尝试了 Claude Code。直说吧：最初我并不买账。每次会话产出的结果都不尽如人意，几乎每次都需要大量的后期修改，这比自己动手还要耗时。我读了不少博客文章、看了不少视频，但依然兴趣寥寥。
没有放弃，我强迫自己用智能体重做所有原本手动完成的提交（commit）。我字面意义上把每件事做了两遍：先手动完成，再与智能体较量，迫使它在质量与功能上达到相同水准（当然，不让它看到我的手动方案）。
这个过程极其痛苦，因为它妨碍了"把事情做完"这一最直接的目标。但我与非 AI 工具打交道的经验足够丰富，深知摩擦阻力是一种自然现象，不把精力耗尽就无法得出坚实可靠的结论。
然而，专业认知在磨砺中逐渐成形。我从第一性原理出发，很快就亲身验证了别人已有的发现——而正因为是自己发现的，底层理解也更为深刻：
- 将会话拆分为若干清晰、可执行的独立任务，切勿试图在一次超长会话中"一步画完猫头鹰"。
- 对于模糊的需求，应将工作分拆为独立的规划会话与执行会话，分步推进。
- 若为智能体提供校验其工作成果的手段，它在大多数情况下能够自主纠错，并有效防止功能退化（regression）。
更宏观地看，我也摸清了当时智能体的能力边界——它们擅长什么、不擅长什么，以及对于它们擅长的任务，如何获得满意的输出。
这一切带来了显著的效率提升——我开始自然而然地使用智能体，感觉不比自己亲手做更慢（尽管也没感觉更快，因为我大部分时间仍在充当"监工"）。
这里有一个值得反复强调的"负空间"：效率提升的一部分，恰恰来自于清楚地知道何时不该使用智能体。让智能体去尝试它很可能失败的任务，显然是巨大的时间浪费；而掌握这种判断力、主动规避，本身就是一种节省2。
第三步：下班前的智能体任务
为了进一步挖掘效率空间，我开始尝试一种新的工作模式：每天预留最后 30 分钟，用于启动一个或多个智能体任务。我的假设是：如果智能体能够在我无法工作的时间里取得实质进展，或许就能在时间之外创造时间。也就是说：与其在现有的工作时间内多做事，不如在原本"空置"的时间里多做事。
和之前一样，起初我觉得这既无效又令人烦躁。但我很快又梳理出了几类真正奏效的工作：
- 深度研究型会话：让智能体梳理某个领域，例如找出某种语言中采用特定许可证的所有库，并为每个库生成多页摘要，涵盖优缺点、开发活跃度、社区口碑等维度。
- 并行探索模糊构想：同时启动多个智能体，分别尝试我还没时间着手的不同想法。我并不指望它们产出可上线的成果，但希望它们能帮我在第二天真正着手时，提前发现一些"未知的未知"。
- Issue 与 PR 的分类梳理：智能体善用
gh（GitHub CLI），我编写了一个简单脚本来并行启动多个智能体做 Issue 分类。我不允许智能体直接回复，只需要隔天早上看到报告，帮助我识别高价值或低难度的任务。
需要说明的是，我没有像某些人那样，让智能体整夜不停地循环运行。大多数情况下，任务在半小时内就会完成。但工作日下午的后半段，我通常已经精力耗尽、离开心流状态，个人效率大打折扣——将这段精力转移到启动智能体任务上，让我第二天早上能够"热启动"，比以往更快进入工作状态。
第四步：把"必进球"外包出去
到这一步，我对 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% 的时间里，真正有一个后台智能体在跑。但我正在积极改进。
我不想为了跑智能体而跑智能体。 我只希望在真正有价值的任务出现时才启动它。这个目标的挑战之一，在于持续改善自己的工作流程与工具体系，以便拥有一个稳定的高质量任务流可供委托——而这一点，即便没有 AI，本身也是重要的！
当下
以上，便是我目前的状态。
经历这段旅程，我个人已经走到了一个能够切实使用现代 AI 工具并取得成效的阶段，我也相信自己正在以一种务实、扎根于现实的方式与它打交道。坦率地说，AI 是否会长期存在对我而言无足轻重3——我只是一个热爱构建事物的软件工匠，做这一切，不过是因为对这门手艺本身的热情。
这个领域变化之快令人咋舌，我相信自己很快就会回望这篇文章，对当时的幼稚莞尔一笑。但正如人们常说的：如果你不会为过去的自己感到难堪，你大概没有真正成长。我只希望，我能向着正确的方向生长。
我在这件事上没有任何利益牵扯4，当然也存在效用之外的理由让人选择不使用 AI。我完全尊重每个人的个人选择，我在这里并不是要说服任何人。对于感兴趣的读者，我只是想分享我个人应对这些新工具的方式，以及我在面对任何新工具时的普遍思路——无论 AI 与否。