我的AI采用之旅

# 我的人工智能采纳之旅 来源：https://mitchellh.com/writing/my-ai-adoption-journey 目录 - 第一步：放弃聊天机器人（https://mitchellh.com/writing/my-ai-adoption-journey#step-1-drop-the-chatbot） - 第二步：复制自己的成果（https://mitchellh.com/writing/my-ai-adoption-journey#step-2-reproduce-your-own-work） - 第三步：日终代理（https://mitchellh.com/writing/my-ai-adoption-journey#step-3-end-of-day-agents） - 第四步：外包稳赢任务（https://mitchellh.com/writing/my-ai-adoption-journey#step-4-outsource-the-slam-dunks） - 第五步：工程化工具链（https://mitchellh.com/writing/my-ai-adoption-journey#step-5-engineer-the-harness） - 第六步：始终运行一个代理（https://mitchellh.com/writing/my-ai-adoption-journey#step-6-always-have-an-agent-running） - 今日（https://mitchellh.com/writing/my-ai-adoption-journey#today） 我采用任何有意义的工具的经验是，我必然经历三个阶段：(1) 低效率期，(2) 够用期，最后 (3) 改变工作流程和生活的发现期。 在大多数情况下，我不得不强迫自己度过第一阶段和第二阶段，因为我通常已经有了自己满意且舒适的工作流程。采用新工具感觉像是一种负担，而我*不想*付出这种努力，但为了成为一名全面的工匠，我通常还是会去做。 这是我如何从 AI 工具中找到价值，以及下一步打算尝试什么的旅程。在海量过度戏剧化、炒作化的观点中，我希望这能代表我对 AI 及其随时间演变的看法，提供一种更细致、更审慎的视角。 这篇博文完全由我手动撰写，使用我自己的语言。我讨厌不得不这么说，但鉴于主题，我想明确声明这一点。 --- ## 第一步：放弃聊天机器人 立即停止试图通过聊天机器人（例如 ChatGPT、网页版 Gemini 等）进行有意义的工作。聊天机器人确实有价值，并且是我 AI 工作流程中的日常部分，但它们在编码方面的实用性非常有限，因为你主要希望它们基于先前的训练得出正确结果，而纠正它们需要人类（你）反复告诉它们错了。这效率低下。 我认为每个人对 AI 的初次体验都是聊天界面。而每个人第一次尝试用 AI 编码，也往往是让聊天界面写代码。 在我仍然是一个坚定的 AI 怀疑论者时，我的第一个“哇哦”时刻是：我将 Zed 的命令面板截图粘贴到 Gemini 中，要求它用 SwiftUI 复现，结果它*做得非常好*，让我目瞪口呆。如今 Ghostty 在 macOS 上附带命令面板，与 Gemini 几秒钟内生成的版本相比，改动非常轻微。 但当我试图在其他任务上复现这种行为时，结果却让我失望。在棕色地带项目（已有代码的项目）中，我发现聊天界面经常产生糟糕的结果，我发现自己因来回复制粘贴代码和命令输出而非常沮丧。显然，这比我自己动手效率低得多。 要找到价值，你*必须*使用**代理**。代理是行业术语，指代能够聊天并在循环中调用外部行为的 LLM¹（https://mitchellh.com/writing/my-ai-adoption-journey#user-content-fn-1）。最低限度，代理必须能够：读取文件、执行程序和发出 HTTP 请求。 --- ## 第二步：复制自己的成果 我旅程的下一个阶段是尝试了Claude Code（https://github.com/anthropics/claude-code）。开门见山：我最初并不以为意。我从未从中获得好的结果。我觉得自己必须修饰它产出的所有内容，这个过程比我亲自做还要耗时。我读了博客文章，看了视频，但就是不太满意。 我没有放弃，而是**强迫自己用代理式提交来重现我所有的手动提交。** 我 literally 做了两次工作。我先手动完成工作，然后与一个代理斗争，让它产生质量和功能完全相同的结果（当然，它看不到我的手写方案）。 这*极其痛苦*，因为它妨碍了简单地完成事情。但我与非 AI 工具打交道足够久，知道摩擦是自然的，而且如果不竭尽全力，我无法得出可靠且可辩护的结论。 但专业知识形成了。我很快从第一性原理出发，发现了别人早已在说的东西，但自己发现让我有了更坚实的基础理解。 1. 将会话分解为独立的、清晰、可操作的任务。不要试图在一个大型会话中“画猫头鹰”（即一步到位）。 2. 对于模糊的需求，将工作分成独立的规划会话和执行会话。 3. 如果你给代理一种验证其工作的方法，它多半会自行修正错误并防止倒退。 更一般地说，我还发现了当时代理擅长与不擅长的边界，以及对于它们擅长的任务，如何实现我期望的结果。 所有这些都带来了显著的效率提升，以至于我开始自然地使用代理，感觉并不比我亲自做慢（但我仍然不觉得更快，因为大部分时间我都在 babysit 代理）。 这里的负面空间值得重申：部分效率提升在于理解何时*不*使用代理。在代理很可能失败的事情上使用它显然会浪费大量时间，而有能力完全避开这一点则能节省时间²（https://mitchellh.com/writing/my-ai-adoption-journey#user-content-fn-3）。 在这个阶段，我发现代理已经足够有价值，我乐意在工作中使用它们，但仍然没有看到净效率提升。不过我并不在意；此时我已满足于将 AI 作为一种工具。 --- ## 第三步：日终代理 为了尝试找到一些效率，我接下来启动了一个新模式：**每天最后 30 分钟留出来启动一个或多个代理。** 我假设*也许*如果代理在我无法工作的时间里能取得一些*积极进展*，我就能获得一些效率。基本上，不是试图在我已有的时间里做更多，而是试图在我没有的时间里做更多。 与上一个步骤类似，我最初发现这样做既不成功又令人烦恼。但同样，我很快发现了确实有帮助的不同工作类别： - **深度研究会话**：我让代理调查某个领域，例如找出特定语言中具有特定许可证的所有库，并为每个库生成多页摘要，包括优缺点、开发活跃度、社区情绪等。 - **并行代理尝试我脑海中不同模糊的想法，但我没有时间去着手。** 我不指望它们产出能直接上线的东西，但也许能为第二天我处理该任务时揭示一些未知的未知。 - **问题和 PR 分类/审查。** 代理擅长使用 `gh`（GitHub CLI），因此我手动编写了一个快速脚本，并行启动多个代理来分类问题。我不允许代理回复，我只希望第二天能看到报告，引导我找到高价值或低工作量的任务。 澄清一下，我没有像其他人那样让代理整夜循环运行。大多数情况下，代理在不到半小时内完成了任务。但是，在工作日的后段，我通常很累，已经脱离了心流状态，发现自己效率低下，所以把精力转移去启动这些代理，让我第二天早上有一个“热启动”，能比平时更快地进入工作状态。 我很高兴，我开始感觉到自己比使用 AI 之前做得更多了，尽管只是略微多一些。 --- ## 第四步：外包稳赢任务 到了这个时候，我非常清楚我的 AI 擅长和不擅长哪些任务。对于某些任务，我非常确信 AI 能给出大部分正确的解决方案。因此，我旅程的下一步是：**让代理去做所有这些工作，而我则专注在其他任务上。** 具体来说，我每天开始时会查看前一夜分类代理的结果，手动筛选出那些代理几乎肯定能解决好的问题，然后让它们一个接一个地在后台运行（不是并行）。 与此同时，**我会做别的事情。** 我不会上社交媒体（比平时没有 AI 时多），不会看视频等等。我处于自己正常的、前 AI 时代的深度思考模式，做我想做或必须做的事情。 **在这个阶段非常重要的一点：关闭代理的桌面通知。** 上下文切换代价高昂。为了保持效率，我发现人类的工作是控制何时中断代理，而不是反过来。不要让代理通知你。在你工作中自然的休息时间，切换过去检查一下，然后继续。 重要的是，我认为“做别的事情”有助于抵消备受关注的Anthropic 技能形成论文（https://www.anthropic.com/research/AI-assistance-coding-skills）所提到的效果。也就是说，你在进行权衡：对于委托给代理的任务你不形成技能，而对自己继续手动处理的任务你自然形成技能。 此时，我已经坚定地进入了“无法回头”的领域。我感觉更高效了，但即使不高效，我最喜欢的一点是：我现在可以把编码和思考集中在我真正热爱的任务上，同时仍然能充分完成我不喜欢的任务。 --- ## 第五步：工程化工具链 显然：当代理第一次就能产生正确结果，或者至多产生需要最少修正的结果时，效率最高。实现这一目标最可靠的方法就是给予代理快速、高质量的工具，让它自动知道自己错了。 我不知道这有没有一个广泛接受的行业术语，但我已经开始称之为“工具链工程”。其理念是：任何时候你发现代理犯了错误，你就花时间工程化一个解决方案，使得代理再也不会犯同样的错误。我不需要发明新术语；如果已经有其他术语存在，我会跟随潮流。 这有两种形式： 1. **更好的隐式提示（AGENTS.md）。** 对于简单的情况，比如代理反复运行错误的命令或找到错误的 API，更新 `AGENTS.md`（或等价文件）。这是 Ghostty 的一个例子（https://github.com/ghostty-org/ghostty/blob/ca07f8c3f775fe437d46722db80a755c2b6e6399/src/inspector/AGENTS.md）。该文件中的每一行都基于一个不良代理行为，并且几乎完全解决了这些问题。 2. **实际的编程工具。** 例如，用于截图、运行过滤测试等的脚本。这通常与 `AGENTS.md` 的更改配对，让代理知道这些工具的存在。 **这就是我现在的状态。** 每当看到代理做了坏事，我都会认真努力去防止它再次做那件坏事。或者说，我认真努力让代理能够验证自己是否在做好事。 --- ## 第六步：始终运行一个代理 与第五步同时进行的，我还有一个目标：**始终保持至少一个代理在运行。** 如果没有代理在运行，我会问自己：“现在有没有什么事情是代理可以为我做的？” 我特别喜欢将这一点与更慢、更经过深思熟虑的模型结合，例如 Amp 的deep mode（https://ampcode.com/news/deep-mode）（基本上就是 GPT-5.2-Codex），它可能需要 30 多分钟才能做出小改动。但另一方面，它往往能产生非常好的结果。 **我（现在？）不运行多个代理，目前也不太想。** 我发现运行一个代理目前对我来说是个很好的平衡：既能够做我喜欢的深度手动工作，又能照看我这有点愚蠢却又莫名高效的机器人朋友。 “始终运行一个代理”的目标目前仍然只是一个目标。可以说，目前我大概只在正常工作日的 10% 到 20% 的时间里成功运行了一个后台代理。但我正在积极努力改善这一点。 **我不想为了运行代理而运行代理。** 我只在认为某个任务真正对我有帮助时才运行它们。这个目标的部分挑战在于改进我自己的工作流程和工具，以便我能有一个持续的高质量任务流可以委托。即使没有 AI，这本身也很重要！ --- ## 今日 这就是我现在的状态。 通过这段旅程，我个人已经达到了一个能够利用现代 AI 工具成功的阶段，并且我相信我正在以适当的、基于现实的审慎态度来对待它。我真的不在乎 AI 是否会长期存在³（https://mitchellh.com/writing/my-ai-adoption-journey#user-content-fn-4），我是一名软件工匠，只是想为了热爱而构建东西。 整个领域发展如此迅速，我相信很快我就会回顾这篇文章并嘲笑自己的天真。但正如他们所说，如果你不能为自己过去的自己感到尴尬，那你可能就没有成长。我只希望自己朝着正确的方向成长！ 我在这里没有利益关系⁴（https://mitchellh.com/writing/my-ai-adoption-journey#user-content-fn-5），当然，除了实用性之外，还有其他理由避免使用 AI。我完全尊重每个人关于它的个人决定。我不是要说服你！对于感兴趣的人，我只是想分享我个人驾驭这些新工具的方法，并让人们一窥我*一般*是如何处理新工具的——无论是不是 AI。 1. 现代编码模型（如 Opus 和 Codex）经过专门训练，相比对话模型更倾向于使用工具。↩（https://mitchellh.com/writing/my-ai-adoption-journey#user-content-fnref-1） 2. 由于模型创新速度很快，我不得不经常重新审视自己对此的看法。↩（https://mitchellh.com/writing/my-ai-adoption-journey#user-content-fnref-3） 3. 然而，我深深担忧技能形成问题，尤其是在缺乏扎实基础技能的新手身上。↩（https://mitchellh.com/writing/my-ai-adoption-journey#user-content-fnref-4） 4. 我不为任何 AI 公司工作、投资或提供咨询。↩（https://mitchellh.com/writing/my-ai-adoption-journey#user-content-fnref-5）