写在前面
Mitchell Hashimoto 是 HashiCorp 的联合创始人，也是 Terraform 和 Ghostty（一个终端模拟器）的作者。
前段时间他写了篇 My AI Adoption Journey，聊了聊自己怎么从对 AI 工具不熟练，到后来慢慢离不开 Agent 的。一个做了这么多年基础设施工具的人，老老实实地讲了自己接受新工具的过程。他还专门声明了：这篇文章是手写的，没用 AI。读完觉得挺值得分享的，就提炼了一下。
三个绕不开的阶段
Mitchell 的出发点不是 AI，而是对所有工具的经验：任何值得用的工具，都得经历三个阶段。
- 低效期——学习曲线带来的阵痛，干什么都比以前慢
- 磨合期——勉强上手，但感觉也没比以前强多少
- 顿悟期——工作方式彻底改变，回不去了
大多数人在第一个阶段就放弃了。他自己也一样，已经有顺手的工作方式了，学新工具就是给自己找麻烦。但他还是逼自己往下走了——不想因为懒得学，错过真正有用的东西。
慢慢上手
别用 ChatBot 写代码了
大多数人接触 AI 编程，第一反应都是打开 ChatGPT，贴一段需求，让它写代码。
Mitchell 也是这么开始的。他第一次被 AI 惊到，是把 Zed 编辑器的命令面板截了个图丢给 Gemini，让它用 SwiftUI 复现，结果出奇的好。Ghostty 现在的 macOS 命令面板就是在那个基础上稍微改的。
不过这种惊喜没能持续。一旦换到有一定复杂度的项目，ChatBot 就不灵了。它本质上是在靠训练数据猜答案，猜错了你只能反复纠正，再加上来回复制粘贴代码和报错，折腾半天还不如自己写来得快。
所以他的结论很直接：ChatBot 有 ChatBot 的用处，但写代码得用 Agent，能读文件、能跑命令、能发请求，真正跟你的项目交互的那种。
把活干两遍
用上 Claude Code 之后，Mitchell 一开始也没觉得多好。写出来的东西总得自己改，改来改去比自己写还慢。
但他没放弃。他的做法是：每天的工作先手动写一遍，再用 Agent 重做一遍，同样的活真的干了两遍。过程很痛苦，但他觉得：
没有认真试过，就没资格下结论。
扛过来之后，几个技巧自然就清晰了：
- 任务要拆小。 别指望一个巨大的会话能让 Agent 把整件事做完
- 模糊的需求，规划和执行分开。 一个会话理清楚要做什么，另一个会话去做
- 给 Agent 验证手段。 能跑测试、能检查结果，它多数时候能自己修好自己的错
同样重要的是知道什么时候不该用 Agent。明知它搞不定还硬用，纯粹浪费时间。
到这里，用 Agent 的速度跟自己手写差不多了。但也仅此而已，大部分时间还是在旁边盯着。
从盯着到放手
下班前启动 Agent
到上一步为止，Mitchell 用 Agent 的速度跟手写差不多，但也仅此而已。他开始想：能不能在自己不工作的时间让 Agent 跑？
做法很简单，每天下班前留 30 分钟启动一个或几个 Agent。不用跑一整晚，多数任务半小时内就能跑完。第二天早上过来直接有产出可以看，省去了冷启动的时间。
他发现有三类任务特别适合这么干：
- 深度调研。 让 Agent 扫一遍某个领域，把符合条件的库都找出来，生成优缺点对比、社区评价、开发活跃度这些摘要
- 试探模糊的想法。 有个念头但没时间展开，让几个 Agent 并行去试不同方向。不指望直接能用，但能帮你发现自己没想到的问题
- Issue 和 PR 分类。 用 Agent 批量扫 GitHub issue，不让它回复，只要分类报告。第二天早上一看就知道哪些值得优先处理
这样下来，他觉得自己能做的事确实比以前多了，虽然也就多那么一点。
各干各的
用久了之后，哪些任务 Agent 能搞定、哪些搞不定，Mitchell 心里已经很清楚了。那些有把握的任务就直接让 Agent 在后台跑，自己同时去做需要深度思考的工作。
TIP
关掉 Agent 的桌面通知。 人的上下文切换代价很高，应该是你决定什么时候去看 Agent 的进度，而不是让它来打断你。手头的事告一段落了，切过去看一眼就好。
他也聊到了一个取舍：交给 Agent 的那些任务，你在那方面的技能成长确实会变慢。Anthropic 之前有篇关于 AI 影响技能形成的研究，我之前也写过一篇《用 AI 写代码越来越快，但我学到东西了吗？》。Mitchell 觉得不用太担心自己的技能成长，他又不是什么都丢给 Agent，需要动脑子的活一直自己在做。不过他也说了，对基础还没打牢的初级开发者来说，这事确实让人担心。而且更重要的是，你终于可以把精力花在自己真正想做的事情上，那些必须干但不想干的活，让 Agent 去跑就好了。
到这里，他说“已经回不去了”。
越用越顺手
别让 Agent 犯同样的错
Agent 最省心的状态就是一次做对。要做到这一点，靠的不是运气，而是工程化。Mitchell 的做法是：每次发现 Agent 犯了错，就花时间想办法让它以后不再犯同样的错。他管这个叫“Harness Engineering”。
具体有两种方式：
- 更新 AGENTS.md。 Agent 老是跑错命令、调错 API，就写进配置文件里明确告诉它。他在 Ghostty 项目里的 AGENTS.md，每一行都对应一个踩过的坑，加上之后基本都解决了
- 写工具脚本。 截图脚本、跑特定测试的脚本、格式检查脚本。给 Agent 更好的工具，它就能更好地验证自己的产出
这件事本身不复杂，关键是愿意花这个时间。每次多投入几分钟，后面能省掉大量重复纠错的成本。
Agent 成了日常
Mitchell 现在的习惯是：只要没有 Agent 在跑，就会问自己一句“现在有什么事可以交给 Agent 做的？”
他喜欢搭配那些跑得慢但质量更高的模型，一次改动可能要等 30 分钟以上，但产出往往不错。他管自己的 Agent 叫“又笨又莫名能干的机器人朋友”。
不过他对自己的要求也很明确：
- 目前不同时跑多个 Agent，一个就够了，多了盯不过来
- 不为了跑而跑，没有真正值得做的任务就不启动
- 目前一天里大概有 10-20% 的时间后台跑着 Agent，他希望能继续提高
他还提到一个更深层的问题：瓶颈不在 Agent，在于你手上有没有源源不断的、适合交给它的活。想办法改进自己的工作流，让更多事情能交出去，这件事哪怕没有 AI 也一样重要。
写在最后
Mitchell 在文末说了一句话挺打动我的：
我不太关心 AI 是不是会长期存在。我就是一个喜欢写代码的人，纯粹因为热爱这件事而做东西。
他跟 AI 行业没有利益关系，也不是在推销什么，完全尊重任何人不用 AI 的选择。他只是分享了自己探索新工具的过程。而这个过程本身跟 AI 无关，换成任何新工具都一样：熬过低效期，找到正确的用法，让工具真正为自己服务。
