核心思想
AI 工具的价值不在聊天框里，而在 agent 化的工作流里。作者用「自己手做一遍 + agent 再做一遍」的笨办法逼自己穿过痛苦的适应期，最终走到第 5 阶段——把 agent 的每个错误都固化成一条
AGENTS.md规则或一个验证工具，让脚手架替自己长记性。承认权衡：被外包出去的任务里你不再练手艺，但你能把脑力留给自己真正热爱的部分。
我采用任何一件称得上”有意义”的工具时，都不可避免地要走过三个阶段：(1) 一段不顺手的低效期，(2) 一段够用的适应期，(3) 一段彻底改变工作流甚至生活方式的发现期。
大多数情况下，我得逼着自己挺过第 1 和第 2 阶段，因为我手头通常已经有一套用得顺手、自己也满意的工作流。学新工具感觉像在干苦差事，我真心不想费这个劲，但通常还是会硬上——为了不让自己作为手艺人有短板。
这篇文章讲的就是我如何在 AI 工具里找到价值的过程，以及我接下来打算拿它做什么。在一片对 AI 极尽夸张吹捧的论调海洋里，我希望它能呈现一种更细致、更克制的视角，记录我对 AI 的看法是如何随时间演变的。
这篇博客是我亲手、用自己的话一字一句写出来的。我讨厌自己居然得专门声明这一点，但鉴于话题特殊，我想说清楚。
第 1 步：抛掉聊天机器人
立刻停止用聊天机器人（比如 ChatGPT、网页版 Gemini 等）做正经活。聊天机器人确实有价值，也确实是我每天 AI 工作流里的一环，但它们在写代码这件事上用处非常有限——你基本上只能祈祷它根据自己的训练数据恰好给出对的结果，而要纠正它，得靠你这个人类一遍一遍地告诉它错在哪。效率太低。
我猜每个人接触 AI 的第一站都是某个聊天界面。我也猜每个人尝试用 AI 写代码的第一次，都是在某个聊天框里让它”帮我写点代码”。
我那时候还是个重度 AI 怀疑者，第一个让我”哇哦”的瞬间，是把 Zed 命令面板的截图丢给 Gemini，让它用 SwiftUI 复现一遍——它做得非常好，好到我目瞪口呆。今天 Ghostty 在 macOS 上自带的命令面板，跟当时 Gemini 几秒钟之内丢给我的版本相比，也只是非常轻微的改动。
但当我试着把这种体验复制到别的任务上，就只剩失望了。在已有代码库（也就是棕地项目）的语境下，聊天界面经常给出质量很差的结果，我一直在两边来回复制粘贴代码和命令输出，自己都觉得烦。这显然比我自己动手干要低效得多。
要从 AI 里找到价值，你**必须**用 **agent**。 agent 是行业里对一类东西的通用叫法——能聊天，并能在一个循环中调用外部行为的大语言模型 1。一个 agent 最起码得能做到：读文件、执行程序、发 HTTP 请求。
第 2 步：复刻你自己的工作
旅程的下一站，我开始试 Claude Code。直说吧：起初我并不觉得它惊艳。我用得不顺，每次会话之后我都觉得它产出的东西到处都得我返工，加起来花的时间比我自己写还多。我读博客、看视频，但就是没被打动。
但我没放弃，而是逼自己用 agent 重做每一笔手工提交。我真的把同一份活做了两遍——先手工写一遍，然后再跟 agent 较劲，让它产出在质量和功能上跟我手工写出来的东西完全等价（当然，不能让它看到我手工写的版本）。
这个过程痛苦得要命，因为它直接挡在”把事情办完”这条主路上。但我跟非 AI 工具打过太多次交道，知道摩擦是天然的，不耗到精疲力尽就得不出一个站得住脚的结论。
但是，经验慢慢攒了起来。我很快就从第一性原理出发，独立发现了别人早就总结过的那些规律——但因为是自己悟出来的，理解扎实得多。
- 把会话拆成清晰可执行的独立任务。别想着用一个超大会话搞定全部。
- 对模糊的需求，把规划和执行拆成两个独立的会话。
- 如果你给 agent 一种自我验证的途径，它多半能修好自己的错，也能防住回归。
更宽泛地说，我也摸到了当时 agent 的边界——它擅长什么、不擅长什么，以及对于擅长的那些任务，怎样才能拿到我想要的结果。
这些东西累积下来带来了显著的效率提升，让我开始自然而然地在工作流里使用 agent，速度上至少不比我自己干慢（不过我也没觉得变快了多少，因为我大部分时间还是在盯着 agent）。
这件事反过来值得再说一句：效率提升的一部分，恰恰来自于知道什么时候不该伸手去找 agent。让 agent 去做它八成会搞砸的事情显然是浪费时间，知道怎么完全避开这类场景，本身就是省时间 2。
到了这个阶段，我对 agent 的价值认可已经足够让我心甘情愿把它纳入工作流，但还是没感觉到净效率提升。我也不在意，那时候我已经心满意足地把 AI 当一件工具用了。
第 3 步：日终 agent
为了继续寻找效率突破，我开始尝试一种新模式：每天最后 30 分钟专门用来挂起一两个 agent 跑活。 我的假设是：也许我能在自己反正也工作不动的那段时间里，让 agent 推进一点正向进展，就此挤出点效率。说白了：与其想办法在我能干活的时间里多干点，不如想办法在我干不动活的时间里多干点。
跟前一步一样，一开始我觉得这条路既没成果又烦人。但我又一次很快摸到了几类真正有用的任务：
- 深度调研类会话：让 agent 把某个领域整体调研一遍，比如查找某门语言里所有满足某种许可证类型的库，并对每一个生成多页的总结，覆盖优缺点、开发活跃度、社区口碑等。
- 并行 agent 试探各种模糊点子：有些想法我有，但还来不及上手。我不指望它们产出什么能上生产的东西，但也许能在第二天我真正动手时帮我照亮一些”未知的未知”。
- issue 和 PR 的 triage（分诊）/ review：agent 用
gh（GitHub CLI）很顺手，所以我手写了一段脚本，并行起一批 agent 去给 issue 分诊。我不允许 agent 回复任何人，只要它们第二天给我一份报告，帮我挑出高价值或低成本的任务。
需要澄清的是，我没有像别人那样让 agent 整夜挂在循环里跑。大多数情况下，agent 半小时之内就把任务跑完了。但工作日的后半段，我通常已经累了、心流也散了，那时候硬干很低效；把精力转去把这些 agent 启起来，能让我第二天早上有一个”温启动”，比平常更快进入状态。
这一阶段我挺满意的，开始隐隐感觉自己比用 AI 之前确实多干了一点活，哪怕只是一点点。
第 4 步：把稳赢的活外包出去
到这个阶段，我对自家 AI 擅长什么、不擅长什么已经非常有数。有些任务我可以非常笃定地预测 agent 能拿出大体正确的结果。所以旅程的下一步是：让 agent 在后台跑掉这些活，自己去干别的。
具体一点说，我每天开工就先把前一晚 triage agent 的输出拉出来，手工筛一遍，挑出那些”agent 几乎必然能搞定”的 issue，然后让 agent 在后台串行去做（一次一个，不并行）。
与此同时，我自己去干别的事。我不去刷社交媒体（至少不比没 AI 时多刷），不去看视频。我就以自己平常那种、AI 之前的深度思考模式，去做某件我想做或者必须做的事。
**这个阶段非常关键的一点：关掉 agent 的桌面通知。** 上下文切换的代价非常高。要保持高效，我发现必须由我这个人类来决定什么时候去打扰 agent，而不是反过来。别让 agent 来通知你。在你工作自然的间隙里，切过去看一眼，然后继续干你自己的。
更重要的是，我觉得”去干别的事”这个动作能在一定程度上抵消 Anthropic 那篇广为流传的关于技能养成的论文 提出的隐忧。当然，这是一种权衡：你确实没能在被外包出去的那些任务上养成技能，但你在自己继续手工做的那些任务上，技能养成还是在自然进行的。
到这个阶段，我已经牢牢站在”绝对回不去了”的领地上。我感觉自己更高效了，但就算没有，我最喜欢的一点是：现在我可以把自己的写代码时间和脑力，专注放在我真正热爱的任务上，同时让那些我不喜欢的任务也能被体面地完成。
第 5 步：打磨脚手架
冒着说一句废话的风险：agent 越是能一次性把活干对、或者最多需要轻微返工，就越高效。要达成这一点，最稳的路子就是给 agent 配上快速、高质量的工具，让它能自动知道自己什么时候做错了。
我不知道业界有没有公认的术语，反正我管这件事叫”harness engineering”（脚手架工程）。意思是：每次你发现 agent 犯了个错，就花点时间设计一个方案，让它以后再也不会在同一个地方栽跟头。 我也没必要在这儿造新词，如果已经有现成的叫法，我立马跟着用。
这件事有两种形态：
- 更好的隐式提示（AGENTS.md）。对于简单的情况，比如 agent 反复跑错命令、找错 API，就更新
AGENTS.md（或类似的文件）。这里有一份来自 Ghostty 的例子。文件里的每一行都是从一次 agent 的坏行为里反推出来的，写好之后，这些行为几乎全消失了。 - 真正的、写好的工具。比如截图脚本、跑过滤过的测试的脚本等等。这通常要配套改一下
AGENTS.md，告诉 agent 这玩意儿存在。
我现在就在这一步。 每次看到 agent 干了件坏事，我都会认真地去想办法让它今后不再干这件坏事；反过来，我也会认真地去想办法让 agent 能自己验证它干了一件好事。
第 6 步：让 agent 永远有活干
与第 5 步同步推进的，是另一个目标：让 agent 任何时候都在跑活。 如果当下没有 agent 在跑，我就问自己一句：“现在有没有什么活，是 agent 可以替我做的？”
我特别喜欢把这个目标跟那些更慢、更深思熟虑的模型搭配使用，比如 Amp 的 deep mode（本质上就是 GPT-5.2-Codex），它有时候要花 30 多分钟才能改一点小东西。代价是耗时；不过反过来说，它产出的质量确实非常好。
我现在[暂时？]还没在跑多个 agent，也暂时不太想这么干。 我觉得只跑一个 agent 是目前对我来说很好的平衡点：既能让我专心做那些我喜欢的、深度的手工活，又能让我有余力去看护我这位有点蠢却莫名其妙挺能干的机器人朋友。
“让 agent 永远有活干”这件事，目前还只是一个目标。我大概可以说，现在一个普通工作日里，我大概只能让后台 agent 真正有活干 10% 到 20% 的时间。但我在主动改进这件事。
我并不想为了跑 agent 而跑 agent。 我只想在那些”agent 确实能帮上忙”的任务上让它跑起来。这个目标的难点之一，就是不断改进自己的工作流和工具，让自己手上始终有一条高质量任务的稳定流，可以分发给 agent。这件事，就算没有 AI，也很重要。
今天
这就是我目前的状态。
走完这段旅程，我个人已经走到了一个真正能从现代 AI 工具里拿到收益的地方，也相信自己是用一种贴近现实、有分寸的态度在使用它。AI 会不会留下来，老实说我并不在乎 3，我就是个软件手艺人，单纯出于对这门手艺的热爱想做点东西。
整个行业变化太快，我相信用不了多久回过头来看这篇博客，我会嘲笑自己当时的天真。但正如那句老话所说，如果你不能为过去的自己感到难为情，那大概说明你没在成长。我只希望自己能往对的方向长。
我在这件事上没有任何利益相关 4，而且当然，也存在其他出于功用考虑而不去用 AI 的理由。我完全尊重任何人的个人选择，我不是来劝你的！只是写给那些感兴趣的人——分享一下我在新工具面前的个人思路，也顺带让你看一眼我面对任何新工具时通常是怎么做的，不限于 AI。
2026 年 2 月 5 日
相关笔记
- Harness 工程：智能体时代真正的护城河 —— Addy Osmani 把作者第 5 步的”脚手架工程”系统化展开的姊妹篇
- 解剖智能体Harness —— 拆解 harness 各组件（提示、工具、钩子、子智能体）的工程细节
- Harness 工程：在智能体优先的世界里驾驭 Codex —— 同主题的 Codex 视角实战
- 用了 3 个月 Claude Code，这 9 条最佳实践让我少走了无数弯路 —— 与作者”日终 agent + 后台跑活”思路高度互补的 Claude Code 实践集
- Claude Code 使用实践 - boristane —— 另一份个人化的 Claude Code 工作流复盘