Mitchell Hashimoto 的 AI 采纳之路：从怀疑到深度依赖

原文：My AI Adoption Journey，Mitchell Hashimoto，2026 年 2 月 5 日 说明：以下为对该文中文解读，事实锚点均来自原文，未额外补写原文之外的经历细节。

前言：工具采纳的三个阶段

Mitchell Hashimoto 是 HashiCorp 联合创始人、Vagrant / Terraform / Packer 等一批开源项目的作者，又以 Ghostty 终端为人所熟知。他对 AI 编程工具不是一见钟情，而是走完了一条"不信 → 受挫 → 强迫自己 → 顿悟 → 依赖"的完整路径。他真正值得读的，不是"AI 很厉害"的结论，而是每一步里具体的操作手段。

Hashimoto 把任何新工具的采纳都归纳成三个阶段：

1. 低效期（inefficiency）——引入新工具反而拖慢进度。
2. 勉强可用期（adequacy）——能用了，但还没比原来的方式快。
3. 工作流与生活改变期（workflow and life-altering）——工具开始重新组织你每天怎么工作。

多数人在阶段 1 和 2 就放弃了，尤其当你已经有一套成熟工作流时，新工具看起来只是添乱。Hashimoto 的策略是坚持把这两个阶段熬过去，否则到不了阶段 3。下面就是他熬过去的过程，一共六步。

第一步：放弃聊天界面

Hashimoto 的第一个正向信号来自一个具体场景：他把 Zed 编辑器的命令面板截图贴给 Gemini，让它用 SwiftUI 复现一个。结果超出预期，今天 Ghostty 的 macOS 版附带的命令面板，就是在那次输出的基础上做了少量修改后上线。这个成功先例让他对"用聊天写代码"怀有期待。

但把同一套做法搬到 brownfield 项目（已有大量存量代码的项目）上时，失望随之而来：结果质量波动很大，而且"把代码和命令输出反复粘贴进聊天窗口"这个过程本身就很折磨人。

他由此得到一个判断：想在编程里真正用上 AI，不能停在聊天界面，必须让 Agent 干活——Agent 是能循环对话并调用外部行为的 LLM，最低限度能读文件、能执行程序、能发 HTTP 请求。换成更直白的说法：聊天界面里，调度是你在做；换到 Agent，调度交回给 AI，你只负责检查和修正方向。

第二步：强制用 Agent 复现你的工作

Hashimoto 第一回用 Claude Code 也说不上好用，每次都要自己润色，算上返工，比纯手工还慢。翻了博客、看了视频，问题依旧。他没有就此放手，而是给自己下了一个很狠的规则：每一次手工提交的 commit，事后都用 Agent 不被剧透地重做一遍，要求产出质量一致的结果。

他承认这个过程"极其痛苦"，因为它实实在在地拖慢了正常开发。但也正是在一遍遍重做的过程中，他摸清了 Agent 的三条工作规律：

1. 把会话拆成小、清楚、可操作的任务，而不是在一个大 Session 里"画一只猫"。
2. 模糊的请求先规划再执行，拆成"先说打算怎么做"和"然后才去做"两个阶段。
3. 给 Agent 一种能验证自己工作的方式，它才有能力自我修正、减少回归。

走过这一阶段，Agent 的产出已经"不比手工慢"，但也还没显得更快——因为他的大量时间仍然花在看护 Agent 上。更重要的是，他借此认识到了 Agent 的边界：知道哪些任务大概率会搞砸，从而避免在这些任务上浪费时间。能提前识别边界，本身就是效率。

第三步：尾盘 Agent

快下班时往往精力不济。Hashimoto 的假设是：把这段时间交给 Agent，把"你低效的时间"变成"Agent 干活的时间"。他每天工作接近结束时，批量启动一个或多个 Agent。

这个尝试一开始也不理想——结果质量差，而且让人烦躁。真正让它成立的是选对任务类型。他发现适合尾盘跑的有三类：

• 深度调研：让 Agent 扫一个技术领域的库，按条件（许可证、语言等）筛选，产出一份多页摘要，包含每个库的优缺点、开发活跃度、社区反馈。
• 并行验证模糊想法：把几个还没动手、也没有明确把握的想法同时丢给 Agent，不指望它产出能直接上线的东西，只要第二天开工时手里有初步方向。
• Issue / PR 分类：写脚本批量启动多个 Agent，把 GitHub 的 Issue 和 PR 分门别类。他明确不允许 Agent 直接回复，只要第二天的报告——告诉他哪些是高价值、低阻力的活。

多数情况下这些任务半小时内就结束，并不会跑一整夜。这个模式的隐性收益很大：第二天早上相当于"热启动"——调研结论、方向判断和待办优先级都提前备好，不必从零找状态。

第四步：委托高确定性的任务（Slam Dunks）

到这一步，Hashimoto 对 Agent 能做什么、不能做什么已经心中有数。他的做法是：每天早上，先把前一天 Agent 分类出来的结果过一遍，挑出那些他确信 Agent 能做得好的任务继续交给它们跑；自己则去做那些需要深度思考、他真正喜欢的部分。

有两处操作细节值得记：

• 关掉 Agent 的桌面通知。上下文切换的成本很高，Agent 不该主动打断你；什么时候去看它，由你决定，而不是它。
• 在自然停顿点查看进度，而不是被一次弹窗拉走。这背后是一种不同的时间管理方式。

他在这里也顺势回应了一个广泛流传的担心——Anthropic 讨论过 Agent 使用过多会导致人的技能退化。他的回应是取舍，不是否定：把任务委托给 Agent，你确实不再积累那项技能；但你亲自做的那些事，技能一直在长。关键在于你委托给 Agent 的到底是什么。

到这个阶段，他自称进入了"回不去"的状态：明显更快，而且精力能集中在他喜欢的任务上，那些他不想做、又必须做的事，也被好好做完了。

第五步：工程化 Harness

第五步是他眼下的重心。他给出的判断是：Agent 效率的最高形态是一次做对，至少是产出只需极少量润色的结果。达到这个目标最可靠的办法，是给 Agent 快速、高质量的自检工具，让它自己知道什么时候做错了。

他把这件事叫 Harness 工程（线束工程）：每次发现 Agent 干了一件糟糕的事，就花时间把它工程化掉——要么让它以后不再犯，要么让它能验证自己做对了。落地形式主要有两种：

1. 更好的隐式提示（AGENTS.md）。针对 Agent 反复跑错命令、用错 API 这类可预期的问题，直接在 AGENTS.md 里补一条规则。他给了 Ghostty 项目的 AGENTS.md 作例子：里面每一条规则，对应的都是一次具体的糟糕行为，加进去之后这类错误几乎全部消失。
2. 程序化工具。例如自动筛选并运行相关测试的脚本、截屏脚本等。工具要配合 AGENTS.md 一起改，让 Agent 知道这些工具存在、该在什么时候用。

他把这条当作长期重心：每发现一次 Agent 出错，就先思考怎么让它不再错，而不是反复手动纠正。

第六步：始终保留一个 Agent 在跑

在第五步之外，他还守着一个原则：没有 Agent 在跑的时候，就问自己一句——“现在有什么 Agent 能帮我做的事？”

这需要一个宽容：允许 Agent 用更长的时间换更高的质量。他提到像 Amp 的 deep mode（大致对应 GPT-5.2-Codex 这一级）这样的慢模型，做一个很小的改动可能要 30 分钟以上，但产出质量非常高。接受这种慢，才能让后台 Agent 真正帮你分担。

目前他也只在工作日约 10%–20% 的时间里有后台 Agent 在跑，他自己承认这个比例还在往上涨。他特意强调，这一部分的难点其实与 AI 无关——它取决于你有没有一条清晰、可委托、值得做的任务流。没有这个基础，给 Agent 再多时间也是空转。

今天的 Hashimoto

走完这六步，Hashimoto 对 AI 编程工具的判断建立在真实使用数据之上，而不是对概念本身的热情。他不太关心"AI 会不会留下来"这类宏观争论——他把自己定位成一个因为喜欢做东西才持续写代码的工程师。他也明说，这个领域变化太快，回头再看此文大概会觉得天真。但他在意的不是姿态是否体面，而是自己是否在进步。

他自述与 AI 公司没有雇佣、投资或咨询关系，写这些只是用户视角的一手经验，不背利益立场。

六步一表

一点读后

它没有喊"AI 取代程序员"，也没有吓唬"AI 会让新人废掉技能"。它讲的是一个有成熟工作流的技术人，怎么一步步把 AI 工具嵌进自己的日常，而不打乱判断的主权。

整条路径的重心落在"委托"上，而不是"提问"上：从学会把一件事正确地交给 Agent 开始，接受迭代而不是指望一次到位，再用工程手段把反复出现的错误按回去。值得照抄的，是这套把工具纳入自身节奏的方法，不是某个具体的模型名。

原文：My AI Adoption Journey – Mitchell Hashimoto