最近关于 AI 的文章很多，但真正值得读的并不多。多数文章要么急着宣布新时代已经到来，要么急着证明这不过是一阵泡沫。Mitchell Hashimoto 的《My AI Adoption Journey》可贵之处在于，它几乎不参与这类表态。它写的是一个原本相当克制、甚至有些怀疑的人，如何在真实工作里一步步把 AI 放到合适的位置。

这篇文章值得读，不是因为它提出了什么惊人的新概念，而是因为它把“采用 AI”讲得很像工程实践：承认工具还不成熟，也承认自己还没用熟，然后在试错里找到能带来净收益的方法。这个视角比“AI 会不会取代程序员”更有用，因为前者今天就能指导工作。

作者给了一条很清楚的主线：新工具的采用通常会经历三个阶段。先是低效期，做什么都别扭；然后进入够用期，已经能覆盖一部分任务；最后才是最关键的阶段，不是工具本身更强了，而是你开始意识到它会改变你的工作流。AI 也是一样。

顺着这条主线，他把自己的采用过程拆成了六步。我觉得这六步里最重要的，不是技巧，而是顺序。

一、先放弃把聊天机器人当成严肃开发工具

作者一开始就承认，纯聊天界面的 AI 在真实项目里并不好用。偶尔它会给出一个很亮眼的回答，但一旦进入日常开发，就会立刻遇到老问题：上下文不完整、复制粘贴麻烦、结果和代码库脱节、建议也没法直接验证。

这里最重要的判断是：真正有价值的不是“会说话的机器人”，而是 agent，也就是能读文件、跑命令、发 HTTP 请求、使用工具的执行者。前者是在对话里请求帮助，后者是在给一个执行者分派任务。

二、先让 agent 复现你本来就会做的事

作者没有一上来就把陌生任务交给 AI，而是反过来，逼自己把已经手工做过的事情再让 agent 做一遍。这个方法很朴素，但很有效。因为你本来就知道正确路径，就能看清 agent 究竟卡在哪。

这一阶段沉淀出几条很实用的经验。任务要拆小；模糊任务最好分成 planning 和 execution；要给 agent 明确的验证手段，比如测试、脚本、截图、接口返回值。它一旦能看到反馈，就更容易自我修正。还有一条反面经验同样重要：知道什么时候不要用 agent，本身就是效率提升。

三、把下班后的时间变成 AI 的工作时间

我觉得这是全文里最有启发的一步。作者会在下班前半小时启动 agent，让它去做那些需要时间、但不一定需要他实时盯着的工作，比如研究某个问题、整理 issue 和 PR，或并行探索几个方向。

这里的价值不一定体现为“速度翻倍”。更现实的收益是，第二天早上不是从零开始，而是站在一个已经预热过的上下文里继续推进。这个“warm start”对需要长时间进入状态的工程工作很有帮助。

四、把高把握度的任务稳定外包出去

等到 agent 的边界逐渐清楚之后，作者开始把那些“大概率能做对”的活交出去。不是最难、最关键、最模糊的那类，而是路径清晰、验证成本低、即使出错也容易纠正的任务。

这一步的意义，不只是节省时间，更是把注意力还给自己。作者特别提到要关掉通知，尽量避免被 agent 频繁打断。我很认同这一点。很多人以为 AI 最大的成本是订阅费，实际上更贵的常常是上下文切换。

五、不要迷信 prompt，要做 harness engineering

这是全文里最像工程师讲话的一部分。作者提出一个很好的说法：与其抱怨 agent 总犯同样的错，不如把这些错变成工程问题来处理。通过 AGENTS.md、脚本、测试、截图工具、固定命令入口、明确目录结构等方式，把环境约束和验证机制补齐，减少同类错误反复出现。

这背后的意思很清楚：问题往往不在“提示词不够玄”，而在缺少可执行的护栏。prompt magic 的上限其实不高，真正可复用、可累积的是 harness。不要要求 agent 凭空变聪明，而要把系统搭到足以让它少犯低级错误。

六、理想状态不是狂开十个 agent，而是始终知道现在能委托什么

最后一步看上去最激进，其实反而最克制。作者的目标是尽量始终有一个 agent 在后台运行。但这不是为了制造热闹，也不是为了同时开一堆窗口。重点是持续问自己：当前有没有一个适合委托、能被验证、且不会制造更多噪音的任务？

这其实是在培养一种新的任务分发习惯。不是所有事情都交给 AI，而是不断判断哪些事情适合留给自己，哪些事情适合交给 agent，哪些事情需要先补脚手架再交。说到底，采用 AI 不是学习怎么提问，而是学习怎么组织工作。

这篇文章最有价值的几个观点

第一，它把 AI 的讨论从能力争论拉回到工作系统。问题不是“它会不会替代你”，而是“你能不能把它安排进一个能持续产生净收益的流程里”。

第二，它承认采用成本，而且不回避低效期。很多失败经验不是因为工具完全没用，而是过早期待第三阶段的收益。

第三，它强调验证和约束的重要性。一个会犯错的 agent 不可怕，可怕的是你没有办法快速发现错、定位错、避免它下次再犯同样的错。

第四，它提醒我们，效率提升不总是更快完成当前任务，也可能是让明天的自己更容易开工，让注意力更多留在真正值得做的部分。

我的评价

我喜欢这篇文章，是因为它比常见的 AI 极端论都更诚实。福音派叙事的问题在于，它默认工具一出现，旧工作方式就会自动失效；悲观派叙事的问题在于，它又常常把今天所有不稳定的体验当成最终结论。Hashimoto 写的不是立场，而是过程。这个过程里既有失望，也有边界感，还有一种很朴素的职业习惯：只接受能在现实里创造净收益的东西。

如果把这篇文章压缩成一句话，我会说：AI 的关键能力不只是生成内容，而是被纳入生产系统。真正拉开差距的，也许不是谁先喊出“未来已来”，而是谁更早学会为 agent 准备上下文、验证、脚手架和安静的执行空间。

这也是为什么我觉得这篇文章比很多热闹观点更值得看。它没有承诺一个宏大的未来，只是认真回答一个更实际的问题：一个想把事情做好的工程师，今天到底该怎样用 AI。这个问题不那么激动人心，但它离工作本身更近。