8.5 KiB
title, source, author, published, last_updated, tags, raw_sources
| title | source | author | published | last_updated | tags | raw_sources | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Mitchell Hashimoto 的 AI 采用之旅 | https://mitchellh.com/writing/my-ai-adoption-journey | Mitchell Hashimoto | 2026-02-05 | 2026-04-11 |
|
|
Mitchell Hashimoto 的 AI 采用之旅
本文记录了 HashiCorp 创始人 Mitchell Hashimoto 从 AI 怀疑论者到深度用户的六个阶段采用之旅。他的经历为如何有效采用 AI 工具提供了实用的指导框架。
核心论点
Mitchell 认为，任何有意义的工具采用都必然经历三个阶段：
- 低效期 - 初期感觉不如现有工作流高效
- 胜任期 - 逐渐掌握，达到与手动工作相当的效率
- 变革期 - 发现新的工作方式，彻底改变工作流和生活
关键洞察：必须强迫自己度过前两个阶段，才能发现 AI 的真正价值。
六个采用阶段
阶段 1：放弃聊天机器人界面
立即停止尝试通过聊天机器人执行有意义的工作。
聊天机器人（如 ChatGPT、Gemini 网页版）有其实际价值，是日常 AI 工作流的一部分，但在编码方面的效用非常有限。你大多只是希望它们基于先前训练得出正确结果，而纠正它们需要你（人类）反复告诉它们错了。这种方式效率低下。
关键发现：
- 聊天界面在棕色地带（brownfield）项目中效果很差
- 复制粘贴代码和命令输出的过程令人沮丧
- 必须使用**智能体（Agent）**才能找到价值
智能体的最低要求：
- 读取文件
- 执行程序
- 发出 HTTP 请求
个人转折点：将 Zed 命令面板的截图粘贴到 Gemini，要求它用 SwiftUI 重现，结果非常好。Ghostty 的 macOS 命令面板仅在此基础上做了轻微修改。
阶段 2：重现自己的工作
强迫自己用智能体重现所有手动提交。
Mitchell 最初使用 Claude Code 时并不满意，觉得必须润色它生成的所有内容，这比自己动手花的时间还多。但他没有放弃，而是强迫自己用智能体重现所有手动提交—— literally 把工作做两遍。先手动完成工作，然后与智能体斗争以产生相同质量和功能的结果（当然不让它看到手动解决方案）。
这一过程的收获：
- 分解任务 - 将会话拆分为独立、清晰、可操作的任务。不要试图在一个大型会话中"画出整只猫头鹰"。
- 规划与执行分离 - 对于模糊的请求，将工作分为规划会话和执行会话。
- 自我验证 - 如果给智能体一种验证其工作的方法，它通常会修正自己的错误并防止回归。
更重要的收获：
- 了解了智能体擅长什么、不擅长什么
- 对于擅长的任务，掌握了如何获得想要的结果
- 知道了什么时候不应该使用智能体——这本身就是巨大的时间节省
阶段 3：日终智能体
每天最后 30 分钟启动一个或多个智能体。
Mitchell 的下一个模式是：留出每天最后 30 分钟来启动一个或多个智能体。 他的假设是，也许可以让智能体在他无法工作的时间取得一些积极进展。基本上：不要试图在已有时间内做更多事情，而是尝试在没有的时间内做更多事情。
发现的高价值任务类别：
- 深度研究会话 - 要求智能体调查某个领域，例如查找特定语言中具有特定许可证类型的所有库，并为每个库生成多页摘要，包括优缺点、开发活动、社会情绪等。
- 并行智能体尝试不同的模糊想法 - 不期望它们产生可交付的成果，但也许可以在第二天处理任务时揭示一些未知的未知。
- Issue 和 PR 分类/审查 - 智能体擅长使用
gh（GitHub CLI），因此手动编写了一个快速方法来并行启动一堆智能体来分类问题。不允许智能体回应，只需要第二天的报告来指导高价值或低工作量的任务。
关键洞察：这不是让智能体整夜循环运行。大多数情况下，智能体在半小时内完成任务。但在工作日的后半段，通常会感到疲惫，脱离心流状态，个人效率低下，因此将精力转移到启动这些智能体上，第二天早上可以"热启动"，比平时更快地开始工作。
阶段 4：外包确定的任务
让智能体做所有它几乎肯定能正确完成的工作，同时你处理其他任务。
到了这个阶段，Mitchell 对 AI 擅长和不擅长的任务非常有信心。对某些任务，AI 会取得基本正确的解决方案有很高的信心。因此，旅程的下一步是：让智能体做所有这些工作，同时你处理其他任务。
具体做法：
- 每天从昨晚分类智能体的结果开始
- 手动过滤出智能体几乎肯定能很好解决的问题
- 让它们在后台运行（一次一个，不是并行）
- 同时处理其他事情——不是刷社交媒体，而是处于正常的、AI 前的深度思考模式
关键规则：
- 关闭智能体桌面通知 - 上下文切换非常昂贵。为了保持效率，人类应该控制何时中断智能体，而不是相反。
- 在工作的自然休息时间，切换过去检查一下，然后继续。
技能形成的权衡：这很好地抵消了 Anthropic 技能形成论文 中提出的问题。你在权衡：不为委托给智能体的任务形成技能，同时继续在手动处理的任务中自然形成技能。
阶段 5：工程化 Harness
每次发现智能体犯错时，花时间设计一个解决方案，让智能体永远不会再犯那个错误。
显而易见的事实：当智能体第一次就产生正确结果，或最坏情况下只需要最少润色时，效率会高得多。实现这一点的最可靠方法是给智能体快速、高质量的工具来自动告诉它什么时候错了。
Harness 工程的两种形式：
-
更好的隐式提示（AGENTS.md） - 对于简单的事情，比如智能体反复运行错误的命令或找到错误的 API，更新
AGENTS.md（或等效文件）。每一行都基于一个糟糕的智能体行为，而且几乎完全解决了所有问题。 -
实际的编程工具 - 例如，截图脚本、运行筛选测试等。这通常与 AGENTS.md 更改配对，让它知道这个工具的存在。
这就是我今天的位置：每当看到智能体做了坏事，就真诚地努力防止它再做那件坏事。或者，相反地，真诚地努力让智能体验证它们在做正确的事。
阶段 6：始终有一个智能体在运行
如果智能体没有在运行，问问自己"现在有什么是智能体可以为我做的吗？"
Mitchell 同时也在始终有一个智能体在运行的目标下运作。他特别喜欢将这与较慢、更周到的模型（如 Amp 的深度模式，本质上就是 GPT-5.2-Codex）结合使用，这些模型可能需要 30 多分钟来进行小的更改。但另一面是，它确实倾向于产生非常好的结果。
当前状态：
- 还没有运行多个智能体，目前也不想这么做
- 有一个智能体在运行是一个很好的平衡
- 目前正常工作日中可能只有 10-20% 的时间有效地让后台智能体运行
- 正在积极努力改善这一点
关键原则：不想为了运行智能体而运行智能体。只有当有一个认为对自己真正有帮助的任务时才运行它们。这个目标的一部分挑战是改善自己的工作流和工具，以便可以有源源不断的高质量工作来委托。即使没有 AI，这也很重要！
今天的状态
这就是 Mitchell 今天的位置。
通过这段旅程，他个人达到了一个点：成功使用现代 AI 工具，并相信自己以基于现实的适当、审慎的观点来处理它。他完全不在乎 AI 是否会留下来——他是一个软件工匠，只是出于对这个行业的热爱而构建东西。
整个领域发展得如此之快，他确信很快就会回头看这篇文章，嘲笑自己的天真。但正如他们所说，如果你不能为过去的自己感到尴尬，你可能就没有成长。只希望能朝着正确的方向成长！