原文：My AI Adoption Journey by Mitchell Hashimoto
引言：Mitchell Hashimoto 是 HashiCorp 的联合创始人，也是终端模拟器 Ghostty 的作者。这篇文章没有任何 AI 公司的利益背景，记录的是一个资深工程师从 AI 怀疑论者到熟练使用者的真实历程。他把这段经历拆成了六个清晰的阶段，每一步都有具体的方法论和踩过的坑。对那些还在纠结 AI 到底能不能帮上忙，或者已经试过但觉得不过如此的开发者来说，这可能是目前最务实的一份参考。
我使用任何一款有分量的工具，基本都会经历三个阶段：一开始效率反而变低，然后慢慢用得顺手，最后才真正发现它能改变工作方式，甚至生活方式。
大多数时候，前两个阶段我都得逼自己往前走。毕竟手头已经有一套用着顺手的工作流了，学新东西本身就是一种负担。但为了不让自己的技术视野变窄，我通常还是会硬着头皮去试。
这篇文章记录的，就是我从 AI 工具中找到价值的整个过程，以及接下来的一些计划。在一片夸大和炒作的声音里，我希望它能代表一种更务实、更有分寸的视角。
这篇文章完全是我手写的，每个字都是我自己的。很讨厌必须声明这一点，但考虑到文章主题，还是说清楚比较好。
第一步：放下聊天窗口
首先要做的，是停止试图通过聊天机器人（ChatGPT、网页版 Gemini 之类的）来完成真正的编码工作。聊天机器人有它的价值，也是我日常 AI 工作流的一部分，但用它来写代码效率很有限——你基本上是在赌它能凭训练数据给出正确答案，而纠错方式就是你反复告诉它哪里不对。这太低效了。
我想，大多数人接触 AI 的第一站都是聊天界面，第一次尝试用 AI 写代码也是在聊天界面里。
我还是个重度 AI 怀疑论者的时候，有过一个让我大为震惊的瞬间：我把 Zed 编辑器的命令面板截了个图扔给 Gemini，让它用 SwiftUI 复刻出来，结果做得相当好。今天 Ghostty macOS 版里的命令面板，就是在 Gemini 几秒钟生成的结果上稍加修改而来的。
但当我想在其他任务上重现这种体验时，就很失望了。在已有项目的代码库里，聊天界面给出的结果经常很差，来回复制粘贴代码和命令输出的过程让我非常烦躁。很明显，这比自己动手写要慢得多。
要真正从 AI 中获得价值，你得用 Agent。这是行业里通用的叫法，指的是一个能对话、能循环调用外部工具的大模型。最起码，它得能读文件、执行程序、发 HTTP 请求。
像 Opus 和 Codex 这样的现代编码模型，经过专门训练，在工具调用上的倾向性远强于普通对话模型。
第二步：用 AI 复现自己的手动工作
接下来我试了 Claude Code。直说吧：一开始没觉得有多厉害。几次会话下来结果都不太理想，产出的东西每个都要修，修完发现还不如自己从头写来得快。读了不少博客、看了不少视频，还是没被打动。
但我没放弃。我强迫自己把每次手动提交的工作，都用 Agent 重新做一遍——字面意义上的做两遍。先手动完成，再让 Agent 在看不到我方案的前提下，产出同等质量和功能的结果。
这个过程非常折磨人，严重拖慢了实际产出。但我用非 AI 工具的经验够多了，深知这种摩擦是自然的，不把劲使完就下结论，是站不住脚的。
然后，经验慢慢长了出来。我通过自己的实践，从头验证了那些别人早就在说的东西，但正因为是自己摸出来的，理解要深刻得多：
- 把任务拆成独立的、目标明确的小块，别想在一个大会话里一步到位。
- 模糊的需求，先拆成「规划会话」和「执行会话」两步走。
- 如果你给 Agent 提供验证自身输出的手段，它多半能自己修错、防止回退。
更宏观地说，我也摸清了 Agent 当时擅长什么、不擅长什么，以及在它擅长的任务上，应该怎么引导才能拿到想要的结果。
这些积累带来了明显的效率提升。到后来，我用 Agent 已经自然到不觉得比自己做慢了——虽然也没觉得更快，毕竟大部分时间还是在盯着 Agent 干活。
这里值得强调一下反面：效率提升的一部分，恰恰来自于知道什么时候不该用 Agent。让 Agent 去做它大概率搞砸的事，显然是巨大的时间浪费，而避开这些场景，本身就是在省时间。
由于模型迭代速度极快，我对什么该用、什么不该用 Agent 的判断也在不断更新。
走到这一步，我已经能从 Agent 身上获得足够的价值，愿意把它纳入日常工作流了，但还没感觉到净效率增长。不过我不介意——把 AI 当作工具，我已经满意了。
第三步：下班前启动 Agent
为了再挤出一些效率，我开始了一个新习惯：每天留出最后 30 分钟来启动一个或多个 Agent。我的设想是，与其在工作时间里试图做更多，不如在我本来就做不了什么事的时间里，让 Agent 替我干活。
跟之前一样，一开始又是既不成功又烦人。但很快我发现了几类特别有用的场景：
- 深度调研。比如让 Agent 扫描某个编程语言下的所有库，按特定许可证类型筛选，然后为每个库产出多页总结，涵盖优缺点、开发活跃度、社区评价等。
- 并行探索模糊想法。让多个 Agent 各自尝试我脑子里还不成形的方案。不指望它们产出能上线的东西，但也许能帮我发现一些盲点，方便第二天正式开工。
- Issue 和 PR 的分诊。Agent 能很好地操作
gh（GitHub CLI），所以我写了个简单的脚本，批量并行启动 Agent 来分类 issue。我不让 Agent 直接回复任何人，只要第二天早上给我一份报告，帮我定位高价值或低成本的任务就行。
说清楚一点，我没有像有些人那样让 Agent 整夜循环运行，大部分任务半小时以内就跑完了。但到了一天的后半段，我通常已经比较疲惫，心流也断了，个人效率其实很低。把这段时间用来启动 Agent，能让我第二天早上有个「热启动」，进入状态比平时快不少。
到这个阶段我已经很满意了，开始感觉自己比用 AI 之前做得更多——虽然幅度不大。
第四步：把稳赢的任务交出去
到这时候，我对 AI 擅长什么、不擅长什么已经非常有把握了。有些任务我信心很高，Agent 几乎肯定能给出基本正确的方案。所以下一步就是：让 Agent 在后台处理这些事，我同时去做别的。
具体来说，每天早上我会看前一晚分诊 Agent 的报告，手动筛出那些 Agent 大概率能搞定的 issue，然后一个一个地丢给后台 Agent 处理（不是并行）。
与此同时，我自己在做别的事。不是刷社交媒体（至少不比没有 AI 的时候刷得多），也不是看视频，而是进入我 AI 之前就有的那种深度思考模式，处理我想做的或者必须做的工作。
这个阶段有一点很重要：关掉 Agent 的桌面通知。上下文切换的代价非常大。要保持效率，应该由人来决定什么时候去看 Agent 的进展，而不是让 Agent 来打断你。在你自己工作的自然间隙里切过去看一眼就好。
还有一点值得说。这种「自己做一件事、Agent 做另一件事」的模式，我觉得能在一定程度上对冲 Anthropic 那篇广为讨论的技能形成论文带来的担忧——你确实不再为交给 Agent 的任务积累技能了，但你仍然在为亲手做的任务正常地磨练手艺。
走到这里我已经完全回不去了。就算效率提升不明显，我最喜欢的一点是：我可以把编码和思考的精力集中在自己真正热爱的任务上，而那些不那么有趣的事情也能被妥善完成。
第五步：打造工程化约束（Harness Engineering）
这一步可能有点显而易见：Agent 第一次就做对——或者只需要最少量修正——的时候效率最高。而达成这一点最靠谱的方式，就是给 Agent 提供快速、高质量的反馈工具，让它能自动发现自己做错了。
我不确定行业里有没有统一的叫法，我自己管这个叫 harness engineering。核心思路是：每当发现 Agent 犯了一个错，就花时间做一个工程化的方案，让它以后不再犯同样的错。如果已经有更好的术语，我随时切换。
这大致分成两种形式：
- 优化隐式提示，也就是
AGENTS.md。对于简单的问题——比如 Agent 老是跑错命令或者调错 API——直接更新AGENTS.md就行。Ghostty 项目里就有一个，每一行都对应 Agent 曾经犯过的某个错误，效果立竿见影，几乎把那些问题全部解决了。 - 编写专用工具。比如自动截图脚本、过滤测试脚本等，通常配合
AGENTS.md的更新来使用，让 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 是否会长久存在下去——我就是一个热爱造东西的手艺人，纯粹因为喜欢才做这件事。
不过，「技能形成」的问题确实让我担忧，特别是对那些基础还不牢固的初级开发者来说。
整个领域变化太快了，我确信很快就会回头看这篇文章，然后笑自己当时多幼稚。但话说回来，如果你对过去的自己不觉得尴尬，那你可能没在成长。我只希望自己是在朝对的方向长。
我在这件事上没有利益关系——不为任何 AI 公司工作，也没有投资或顾问关系。当然，除了实用性以外，还有很多理由让人选择不用 AI，我完全尊重每个人的决定。写这篇不是为了说服谁，只是想分享一下我个人应对新工具的方式和思路。