My AI Adoption Journey

Mitchell Hashimoto

我的 AI 采纳之旅

原文由 Mitchell Hashimoto 发布,订阅该博客

我在使用任何有意义的工具时的体验是,必然会经历三个阶段:(1)低效期(2)够用期,最后(3)则是足以改变工作流乃至生活的发现期。

大多数情况下,我不得不强迫自己熬过前两个阶段,因为我通常已经有一套令自己满意且得心应手的工作流。采用新工具本身就像一份额外的工作,我根本不想为此费力,但为了成为一个更全面的手艺人,我通常还是会去做。

这篇文章记录了我如何从 AI 工具中找到价值,以及我接下来打算如何继续尝试。在充斥着夸张与炒作的言论海洋中,我希望它能提供一种更细腻、更克制的视角,呈现我对 AI 的看法及其随时间的变化。

这篇博文完全由我亲手撰写,字字出自我手。我讨厌不得不特意声明这一点,但鉴于本文的主题,我想把话说清楚。


第一步:抛开聊天机器人

立刻停止试图通过聊天机器人(例如网页版的 ChatGPT、Gemini 等)来完成任何有实质意义的工作。聊天机器人确实有价值,也是我日常 AI 工作流的一部分,但在写代码这件事上,它们的用处非常有限,因为你基本上只是在指望它们凭借既有训练给出正确答案,而纠正它们则需要你这个人一遍又一遍地告诉它们错了。这很低效。

我想每个人第一次接触 AI 都是通过聊天界面。而每个人第一次尝试用 AI 写代码,也都是让聊天界面去写代码。

在我还是一个重度的 AI 怀疑论者时,我的第一个“哇”时刻,是把 Zed 命令面板的截图粘贴给 Gemini,让它用 SwiftUI 复刻一下,结果它完成得非常好,让我大吃一惊。如今 Ghostty 在 macOS 上发布的命令面板,就是在 Gemini 几秒钟内生成的结果上稍作修改而来的。

但当我试图在其他任务上复现这种体验时,却大失所望。在存量项目的语境下,我发现聊天界面常常给出很差的结果,而我在界面之间来回复制粘贴代码和命令输出的过程也让我倍感沮丧。很明显,这比我自己动手要低效得多。

要想真正获得价值,你必须使用Agent(智能体)。Agent 是行业通用的术语,指能够在循环中对话并调用外部行为的大语言模型1。最起码,Agent 必须具备以下能力:读取文件、执行程序以及发起 HTTP 请求。


第二步:复现你自己的工作

旅程的下一阶段,我尝试了 Claude Code。长话短说:一开始我并不觉得惊艳。我的会话始终得不到什么好结果。我感觉它产出的每一样东西都得我亲手修补,而这个过程比我自己重做一遍还要花时间。我看了不少博客、视频,但依然不为所动。

我没有就此放弃,而是强迫自己用 Agent 把所有手动提交重做一遍。我 literally 把活儿干了两遍:先手动完成一次,然后再费尽力气让 Agent 在看不到我手动方案的前提下,产出在质量和功能上完全一致的结果。

非常痛苦,因为它妨碍了我单纯地把事情做完。但我在非 AI 工具上摸爬滚打已久,深知这种摩擦是必然的——如果不把各种尝试都穷尽,我就无法得出一个站得住脚的坚定结论。

但专业能力也随之形成了。我很快就从第一性原理出发,自己领悟到了别人已经在说的那些道理,而亲身的发现让我有了更扎实的根本理解。

  1. 把会话拆分成清晰、可执行的独立任务。别想着在一次超级会话里就“画出整只猫头鹰”。
  2. 对于模糊的需求,把工作拆分为独立的规划阶段和执行阶段。
  3. 如果你给 Agent 一个验证成果的办法,它往往能自行修正错误并防止回归。

更广义地说,我也逐渐摸清了 Agent——至少在当时——擅长什么、不擅长什么,以及对于它擅长的任务,该如何引导才能得到我想要的结果。

这一切带来了显著的效率提升,以至于我开始自然而然地使用 Agent,感觉速度已经不比自己动手慢了(不过我依然不觉得更快,因为我大部分时间还是在给 Agent 当保姆)。

这里的反面也值得重申:效率提升的一部分,恰恰在于明白什么时候该用 Agent。让 Agent 去做它很可能搞砸的事情,显然是巨大的时间浪费,而懂得完全避开这类情况本身就能节省时间2

到了这个阶段,我已经从 Agent 身上获得了足够的价值,乐意把它纳入自己的工作流,但依然不觉得有任何净效率收益。不过我并不在意,彼时我已经对 AI 作为一款工具感到满意了。


第三步:日终 Agent

为了寻找效率的突破,我开启了一个新模式:每天留出最后 30 分钟来启动一个或多个 Agent。我的假设是,或许如果 Agent 能在我本来也无法工作的时间里取得一些正向进展,我就能获得一些效率收益。说白了:与其想着在有限的时间里做更多,不如想办法在没有时间的时候也让工作推进。

和上一个阶段类似,一开始我觉得这种做法既不成功又很烦人。但很快,我又发现了几类特别有用的工作:

  • 深度研究会话,我会让 Agent 去调研某个领域,比如找出特定语言中符合特定许可证类型的所有库,并为每个库生成数页的总结,涵盖优缺点、开发活跃度、社区舆论等。
  • 让多个 Agent 并行尝试我有过念头但没时间着手的各种模糊想法。我并不指望它们能产出可直接发布的东西,但或许能在第二天真正着手时帮我照亮一些未知的未知。
  • Issue 和 PR 的分拣与审查。Agent 很擅长使用 gh(GitHub CLI),所以我手动写了个脚本,可以并行启动一批 Agent 来分拣 issue。我绝不会让 Agent 去回复,我只是想要第二天的报告,以此来引导自己去关注高价值或低成本的任务。

说清楚一点,我并没有像其他人那样让 Agent 整夜循环运行。大多数情况下,Agent 在半小时内就完成了任务。但在工作日的后半段,我通常已经很累、脱离了心流状态,个人效率很低,所以把精力转到启动这些 Agent 上,反而让我在第二天早上获得了一个“热启动”,比平时能更快地进入工作状态。

我很满意,也开始觉得自己比使用 AI 之前做得更多了,哪怕只是多了一点点。


第四步:把十拿九稳的活儿外包出去

到这个阶段,我已经非常清楚 AI 擅长什么、不擅长什么。对于某些任务,我很有把握 AI 能给出基本正确的解决方案。于是旅程的下一步就是:让 Agent 去做所有这类工作,同时我去做别的事。

更具体地说,我每天开始工作时,会先查看前一晚分拣 Agent 的结果,手动筛选出那些 Agent 几乎肯定能很好解决的 issue,然后让它们在后台持续运行(一次一个,而非并行)。

与此同时,我会去做别的事。我不是去刷社交媒体(并不比不用 AI 时更多),也不是去看视频等等。我只是回到自己往常的、没有 AI 时的深度思考模式,去做我想做或必须做的事。

这个阶段非常重要的一点:关掉 Agent 的桌面通知。上下文切换的成本非常高。为了保持高效,我发现作为人类,我的职责是掌控何时去打断 Agent,而不是相反。不要让 Agent 来通知你。在工作的自然间隙再切过去看一眼,然后继续手头的事。

重要的是,我认为这种“去做别的事”的方式,有助于抵消那篇广为流传的 Anthropic 技能形成论文中所指出的影响。毕竟这是一种权衡:你在外包给 Agent 的任务上不再形成技能,但在你继续亲手完成的任务上,依然在自然地积累技能。

到了这一步,我已经坚定地进入了“再也回不去了”的阶段。我感觉自己更高效了,但即便不是,我最喜欢的一点是,我现在可以把编码和思考的精力集中在我真正热爱的事情上,同时那些我不喜欢的任务也依然能得到妥善完成。


第五步:打磨 Harness

这话说出来可能有点显而易见:当 Agent 第一次就能给出正确结果,或者最差也只需要极少修改时,它的效率要高得多。而要做到这一点,最可靠的办法就是给 Agent 提供快速、高质量的工具,让它能自动知道自己何时出错了。

我不知道行业里是否已经有了一个广为接受的术语来称呼这件事,但我已经习惯把它叫做“harness engineering”。它的理念是,每当你发现 Agent 犯了一个错误,就花时间去设计一个解决方案,确保它以后再也不会犯同样的错误。我没必要在这里生造新词;如果已有别的叫法,我乐意跟随。

这主要体现在两种形式上:

  1. 更好的隐式提示(AGENTS.md)。对于一些简单问题,比如 Agent 反复执行错误的命令或找错 API,就去更新 AGENTS.md(或等效文件)。这里有一个来自 Ghostty 的例子。文件中的每一行都是针对一次糟糕的 Agent 行为而加的,而这几乎完全解决了所有这些问题。

  2. 实打实的编程化工具。例如用于截图、运行筛选后的测试等的脚本。这通常会配合对 AGENTS.md 的修改,让 Agent 知道这些工具的存在。

这就是我目前所处的阶段。每当我看到 Agent 做了件坏事,我都会认真地想办法防止它再犯。反过来,我也在认真地让 Agent 能够验证自己正在做正确的事。


第六步:让 Agent 始终运行

与第五步同步,我还在践行一个目标:让 Agent 时刻处于运行中。如果没有 Agent 在跑,我就会问自己:“现在有没有什么事是可以让 Agent 帮我做的?”

我特别喜欢把这一点和更慢、更具思考性的模型结合起来,比如 Amp 的 deep mode(本质上就是 GPT-5.2-Codex),它做一个小改动可能就要花 30 多分钟。好处是,它往往能产出非常好的结果。

我(暂时?)还没有同时运行多个 Agent,目前也不太想这么做。我发现只运行一个 Agent,对我而言是在能够享受深度、手动的工作与照看我那有点笨却又莫名高效的机器人朋友之间,一个很好的平衡。

“让 Agent 时刻运行”这个目标目前仍只是一个目标。我想现在在一个正常工作日里,我大概只有 10% 到 20% 的时间能有效地让后台 Agent 跑起来。但我正在积极地改进这一点。

我不想为了跑 Agent 而跑 Agent。只有当我认为有任务确实能对我有帮助时,我才想让它们运行。这个目标的挑战之一,就是改进我自己的工作流和工具,以便能有一连串高质量、可外包的工作。哪怕没有 AI,这一点也很重要!


当下

以上就是我目前的状态。

走过这一程,我个人已经到了能够成功运用现代 AI 工具的地步,并且我相信自己正以一种恰当、克制且立足现实的视角来看待它。我其实并不太在意 AI 是否会长久存在3,我只是一个热爱创造的软件工匠,只想出于对这门手艺的热爱去构建东西。

整个行业变化如此之快,我确信很快再回头看这篇文章时,就会笑自己的天真。但正如人们所说,如果你不会为过去的自己感到尴尬,那你大概就没有成长。我只希望自己能朝着正确的方向成长!

我在其中没有任何利益关联4,当然,除了实用性之外,也还有其他理由让人选择不使用 AI。我完全尊重每个人在这方面的个人决定。我不是来劝服你的!对于感兴趣的人,我只是想分享我个人探索这些新工具的方法,并展示一下我总体上是如何对待新工具的,无论是否与 AI 相关。

脚注

  1. 现代的编程模型如 Opus 和 Codex 相比对话模型,经过了专门训练,更倾向于使用工具。

  2. 由于模型创新的速度非常快,在这一点上我不得不不断修正自己的先验判断。

  3. 不过,技能形成的问题,尤其是在那些尚未牢固掌握基础的初级人员身上,令我深感担忧。

  4. 我没有在任何 AI 公司任职、投资或担任顾问。

本文章由 muse-spark-1.2-contributor 进行翻译

评论