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

原文：My AI Adoption Journey — Mitchell Hashimoto，2026年2月5日
说明：本文为全手工撰写（作者本人声明），是关于 AI 编程采纳最真实的一手经验。

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

Mitchell Hashimoto 是知名的工程师（HashiCorp 联合创始人、多款明星开源项目作者），他在技术圈以严谨著称。这篇博文的有趣之处在于：作者本身对 AI 编程工具经历了一个完整的"不信→试用→受挫→强迫自己→顿悟→依赖"的过程，且每一步都有具体的操作细节，不是空洞的"AI 太牛了"感叹。

他将任何工具的采纳路径概括为三个阶段：

1. 低效期（inefficiency）
2. 勉强可用期（adequacy）
3. 工作流与生活改变期（workflow and life-altering discovery）

大多数时候，阶段 1 和 2 让人想放弃——特别是当你已经有一套成熟工作流的时候，引入新工具感觉是给自己添麻烦。但 Hashimoto 知道，不把这两个阶段熬过去，就无法进入真正有价值的阶段 3。

以下是他在 AI 编程工具上的六步走。

第一步：放弃聊天机器人

核心观点：用聊天界面做有意义的编码工作，效率极低。必须转向 Agent。

Hashimoto 的第一个"Wow"时刻来自一个具体场景：他把 Zed 编辑器的命令面板截图贴给 Gemini，让它用 SwiftUI 复现一个。结果——做得非常好，Ghostty 终端今天 macOS 版附带的命令面板只做了少量修改就上线了。

但当他把这个成功经验复用到其他任务上时，失望了。在brownfield 项目（已有大量存量代码的项目）中，聊天界面给出的结果质量经常很差，而且反复"复制粘贴代码和命令输出到聊天窗口"这件事本身就令人沮丧。

他意识到：想从 AI 编程中获得价值，必须使用 Agent（智能体）。

Agent 的定义：一个可以循环对话并调用外部行为的 LLM。最低限度是：能读文件、能执行程序、能发 HTTP 请求。

这里有个重要的认识转变：从"问 AI 写代码"到"让 AI 自己干活并检查结果"。聊天界面的本质是你在做调度，而 Agent 的本质是 AI 在做调度。

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

核心观点：买了 Claude Code 却效果不好？正常。但你还没有真正学会用它。

Hashimoto 第一次用 Claude Code 时，并不觉得好用——每次都要自己润色，花的时间比纯手工做还多。看了博客、看了视频，依然不满意。

但他没有放弃，而是强迫自己做了一件事：每一次手工提交（commit），都再用 Agent 做一遍。也就是说——同样的任务，先手工完成，然后不给 Agent 看答案的前提下，强迫它产出质量相同的结果。

这个过程用他的话说是"极其痛苦"的，因为严重影响了正常的工作进度。但也正是在这个过程中，他从第一性原理出发，真正理解了 Agent 的工作规律：

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

这个阶段带来的效率提升，让 Agent 使用变得"不比自己动手慢"，但也还没感觉更快——因为他主要是在"看护"Agent。

更重要的是，他在这个阶段形成了对 Agent 边界的认知：知道什么任务 Agent 大概率会搞砸，避免在这种任务上浪费时间本身就是效率提升。

第三步：尾盘 Agent 模式

核心观点：每天最后 30 分钟，批量跑 Agent，把"你不能工作的时间"变成 Agent 的工作时间。

Hashimoto 尝试了一种新模式：每天工作快结束时（大约最后 30 分钟），批量启动一个或多个 Agent。他的假设是：也许在那些他自己无法高效工作的时间段里（比如快下班时精力下降），Agent 可以帮他做些事情。

这个尝试一开始同样不成功——结果质量差，而且令人烦躁。但他很快找到了适合这类 Agent 的任务类型：

• 深度调研：让 Agent 调研某个技术领域的库——找出所有符合特定条件（比如某种许可证、某种语言）的库，并产出多页摘要，包括每个库的优缺点、开发活跃度、社区情绪等。
• 并行验证模糊想法：把他想做但还没时间开始的几个模糊 idea 同时丢给 Agent。他不期望 Agent 产出能直接上线的东西，而是希望得到一些早期反馈，让第二天开始工作时更有方向感。
• Issue 和 PR 的分类/审查：写脚本批量启动多个 Agent 并行处理 GitHub Issue 和 PR 的分类。他不允许 Agent 直接回复 Issue，只是想要第二天的报告——告诉他哪些是高价值低阻力的事。

大多数情况下，Agent 在半小时内就完成了任务，而不是跑一整夜。这个模式给他带来了一个显著的额外好处：第二天早上有一个"热启动"——他已经有了调研结果、方向判断和 issue 优先级，第二天能更快进入工作状态。

第四步：外包" Slam Dunks"

核心观点：把自己有高确定性能处理好的任务全部交给 Agent，然后专注于自己真正喜欢的工作。

到了这个阶段，Hashimoto 对 Agent 能做什么不能做什么已经有了相当高的信心。他的下一步是：每天早上，根据前一天晚上的 Agent 分类结果，手工筛选出那些 Agent 大概率会完美解决的问题，让它们继续跑，同时他自己去做那些需要深度思考、他真正喜欢做的事。

关键操作细节：

• 关掉 Agent 的桌面通知。上下文切换的成本极高。Agent 不应该主动打断你——你决定什么时候去看它。
• 在自然的停顿时检查进度，而不是被通知打断。这是一种完全不同的时间管理哲学。

他还指出了一个有趣的对冲逻辑： Anthropic 那篇关于 Agent 导致技能退化的论文被广泛讨论，但在这里其实是在做取舍——把 Agent 委托给 Agent 的任务，你确实不会再形成技能；但你自己做的那些任务，技能自然在持续积累。

到了这个阶段，他进入了"绝对回不去"的领地——感觉效率明显更高，而且最重要的是：他可以把 coding 和思考的精力集中在那些他真正喜欢的任务上，同时那些他不喜欢但又必须做的任务也被好好完成了。

第五步：工程化 Harness

核心观点：每次 Agent 犯错，花时间设计机制让它不再犯，而不是反复手动纠正。

这是 Hashimoto 目前的重心所在。

他的核心洞察是：Agent 效率的最高表现形式是一次性做对，或者退一步说——产出只需极少量润色的结果。实现这个目标的最可靠方法，是给 Agent 快速、高质量的自动校验工具，让它自己知道什么时候做错了。

他把这件事称为"Harness 工程"（线束工程）。核心思想是：每次发现 Agent 做了件糟糕的事，就花时间工程化地解决它——让 Agent 以后再也不会犯同样的错，或者让 Agent 能够验证自己做的是正确的。

两种具体形式：

1. 更好的隐式提示（AGENTS.md）：针对 Agent 反复跑错命令、用错 API 这类简单问题，直接在 AGENTS.md（或类似的提示规范文件）里加规则。他给出了 Ghostty 项目 AGENTS.md 的具体例子——里面的每一条都对应一次糟糕的 Agent 行为，加进去之后几乎全部解决了。

2. 实际的程序化工具：比如写一个截屏脚本、自动运行筛选后的测试的脚本等。这通常需要配合 AGENTS.md 的修改，让 Agent 知道这些工具存在。

这是他当前的实践重心——每发现 Agent 做了一次坏事，就认真思考如何让这类错误以后不再发生，或者让 Agent 能验证自己在做的是正确的事。

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

核心观点：没有 Agent 在跑的时候，问自己——“现在有什么 Agent 可以帮我做的事？”

除了第五步，他还在实践另一个原则：始终保持至少一个 Agent 在运行。如果没有在跑，他会问自己：“现在有什么 Agent 可以帮我做的事？”

他特别提到了结合较慢但更深入的模型使用，比如 Amp 的 deep mode（本质上是 GPT-5.2-Codex 级别），这类模型可能需要 30 分钟以上来做很小的修改——但结果质量非常高。

目前，他大概只能在一个工作日的 10%-20% 的时间里保持后台 Agent 在跑。但他正在积极提高这个比例。他的目标不是为了让 Agent 跑而跑，而是为了实现一个稳定的、高质量的工作委托流。

这部分工作的挑战其实和 AI 无关——它本质上是你自己有没有一套清晰的、可委托的、值得做的事情流。没有这个基础，给 Agent 再多的时间也是在浪费。

今天的 Hashimoto

经过这个完整的路径，Hashimoto 到达了一个"对 AI 工具真正感到有效"的状态，而且他认为自己是用一种有根据的、落地的视角在看待这件事——不是被 hype 驱动，而是基于真实数据的判断。

他不在乎 AI 是否"会留下来"这种宏观辩论——他只是一个因为热爱这个游戏而 build 东西的软件工匠。整个领域变化太快，他相信很快回头看这篇文章会觉得很天真。但关键是：只要你在进步，尴尬是正常的。

他也没有在 AI 公司工作、投资或咨询——所以没有利益相关，只是真实的用户经验。

核心实践清单

一点感悟

这篇博文最珍贵的地方在于它没有在喊"AI 取代程序员"，也没有在危言耸听"AI 让新人失去技能"。它描述的是一个理性的、有经验的技术人在有一套成熟工作流的前提下，如何逐步把 AI 工具整合进去。

路径很清晰：不要从"聊天"开始，要从"委托"开始。不要幻想一次搞定，要接受迭代。不要只接受错误，要工程化地消除错误。

原文链接：My AI Adoption Journey – Mitchell Hashimoto

🦞 每日08:00自动更新