# 教会 Agent 写代码，比自己用 AI 写代码难十倍，也值十倍

- URL: https://davidyin.dev/writing/ai-coding-two-modes/
- 作者: David Yin
- 发布: 2026-05-29
- 标签: x-article
- 摘要: 上周一个做了十几年后端的朋友丢过来一句：你天天折腾那套让 agent 互相盯着的东西，跟我用 Cursor 到底有啥不一样，不就是更自动一点？

上周一个做了十几年后端的朋友丢过来一句：你天天折腾那套让 agent 互相盯着的东西，跟我用 Cursor 到底有啥不一样，不就是更自动一点？

这句话我听过太多遍。它把一件分层的事，压扁成一条直线上的快慢。

差别不在工具新旧，在你站的位置。

## 工具新旧不是差别，姿势才是

AI 编程现在有两种玩法。

第一种我叫它**面向工具开发**。打开 Claude Code、aider、Cursor、Copilot，人是主驾驶。代码摆在你眼前，你读、你判断、你拍板，工具补全、生成片段、回答疑问。工作的最小单位是一次补全、一次对话，你的注意力从头到尾黏在代码本身上。

第二种我叫它**调教 agent 开发**。人往后退一步，退到编排和架构那一层。你不写代码，你定义任务、写约束、订验收标准。开发 agent 自己跑循环——计划、执行、自查；跑完，再派另一个 agent 当 reviewer，专门挑它毛病。工作的最小单位变成了一个任务、一条流水线，注意力不在某一行代码，在系统怎么搭、约束怎么写、验收门怎么卡。

说清楚一点：**A 和 B 是使用姿势，不是工具阵营。** 同一个 Claude Code，既能当补全使，也能放它自己跑循环。差的不是版本号，是你坐的位置。

*同一批工具，坐的位置不同，就是两种活法。*

## 失败的时候，模式 B 不喊疼

但真正把两种姿势拉开差距的，是失败的时候。

模式 A 的失败很温柔。补全跑偏了，你当场就看见，回车都没敲就改回来了。错误小、可见、当场能纠。

模式 B 的失败是另一个量级。agent 会越界，会在你没盯着的地方悄悄偏离你的本意，会把一个你以为定义清楚的任务，做成一个看起来对、跑起来错的东西。这种偏离不喊疼。**等你发现，它可能已经在三个文件里铺开。**

*模式 A 的错当场冒头，模式 B 的错等你发现时已经铺开三个文件。*

所以这里有个反直觉的点：让 agent 去监督 agent，不是为了让你省事。

它是把你原本即时在做的事——盯着每一步、随手纠偏——前移了，固化成系统的一部分。你以前用眼睛和直觉做的 review，现在必须翻译成另一个 agent 看得懂、执行得了的规则。省下的不是脑力，是把脑力花在了前面。

至于 reviewer 为什么不算套娃：它只判「对不对」，不用「怎么做」，**判别比生成便宜得多**；reviewer 也不是真理机，它的作用只是把验收门前移，让偏离更早被抓出来。

## 真正的门槛，是把肌肉记忆逼成白纸黑字

模式 B 的门槛不是写 prompt。不是。

门槛是你能不能把脑子里那些说不清的判断，**显性化**成约束和验收标准。

我自己搭这套 harness，最难的从来不是让 agent 跑起来，是写验收。我得回答一连串以前从不需要回答的问题：什么样算做完了？哪种改动必须人工签字？reviewer 该用什么标准判一个 PR 过还是不过？这些判断我做了十几年，全靠肌肉记忆，从没逼自己写下来过。一旦要交给 agent，**模糊就是 bug**。

显性化长什么样？举个最小例子。

模糊版：「把这个函数改快一点」。

显性版：「输入超过 10 万条时耗时必须低于 200ms，且不引入新的外部依赖」。

前者你嘴里说说就行，后者得先把场景边界、性能目标、约束一次摆齐。这两句话能不能写出来，决定了一个任务能不能交给 agent 自己跑。

*同一个需求，说不清的版本 agent 做不对，摆得齐的版本它才能自己跑。*

要承认一点：不是所有判断都能这样显性化，有些事你就是说不清。但你以为说不清的那一堆里，大部分只是没逼自己说而已。

**会用工具，门槛是熟练；会编排 agent，门槛是把肌肉记忆逼成白纸黑字。**

## 选哪种？别和稀泥，看你这活要跑几次

我不打太极，分场景看。

**需要人的判断当场在场的活，走模式 A。** 探索一个你自己都没想清楚的方向，小修小补，调一个你说不清规则但一眼能看出对错的 UI——这些场景里，你的即时判断本身就是最值钱的东西，外包出去就是浪费。

**重复的、能被明确定义验收标准的批量活，走模式 B。** 同一套改动要铺到几十个文件，一类边界情况要补一圈测试，一种迁移要在多个模块重复。这些活的判断标准你早就清楚，缺的只是不想一遍遍手动做。把判断写成约束，让 agent 批量跑，reviewer 兜底，才划算。

一条粗略的判别线：**同一类任务你预期会跑十次以上，才值得把判断写成约束；一次性的活，模式 B 是亏的。**

成本结构也跟着分层。模式 A 烧的是你的时间，你坐在那儿一秒一秒地陪。模式 B 烧的是 token，加上前期把判断设计成约束那笔脑力投入——这笔是真金白银，绕不过去。

## 难十倍，是因为前面那笔躲不掉；值十倍，是因为写一次能反复用、还不用你守着

「难十倍」和「值十倍」其实是同一件事的两面。

前期把那套判断认真写一次，本质是把藏在你脑子里的肌肉记忆，逼成一份**白纸黑字、能被反复调用的资产**——它不再随你下班、随你遗忘而消失，这是核心。之后每跑一次，token 照样烧，那是变动成本，不会因为复用次数多就变便宜；真正变便宜的是**你的时间**：模式 A 每做一次都要你人肉盯一份，模式 B 跑起来几乎不占你；而前期那笔一次性投入，跑得越多，分到每一次头上越少。**跨过那个临界点算总账，模式 B 替你省下的时间是倍数级的。** 十倍是数量级，不是测量值。

*判断写一次就沉淀下来，往后每跑一次都替你省一份盯的时间。*

很多人试了一下模式 B，觉得还不如自己写快，就退回了 A。**他们只付了 prompt 的钱，没付验收设计的钱**——更要命的是，他们手里都是一次性的活，根本攒不到让前期投入回本的复用次数。

模式 A 和模式 B 不是新旧替代，是上下分层。模式 A 不会消失，它是你判断必须在场时最锋利的工具。

你能不能用好 AI 写代码，最后拼的不是你会调哪个工具，是你愿不愿意把脑子里那套说不清的标准，老老实实写成别人——也包括 agent——能照着执行的话。