你是驾驶员，不是乘客
系列入口：如何使用 Agent。这是 M2 使用心智的第一篇，配合 Plan 模式深挖 一起看。
一、一个悄悄发生的角色错位
Agent 最擅长也最危险的一点，是它会让你不知不觉变懒。刚开始你还认真看它要做什么，几次顺利之后就开始习惯性地点「同意」；再往后，方案不看了、命令不看了、diff 也扫一眼就过——你以为自己在「高效使用」，其实已经从握着方向盘的驾驶员，退化成了系着安全带的乘客，而车正由一个能力很强但并不真正理解你业务的模型开着。
真正的高效不是少管，而是把注意力放在对的地方。这篇就讲清楚：哪些事必须你亲自把关，分别看什么。
二、第一道闸：审方案——确认它「想对了」
在它动手前，先审方案。重点不是方案写得多漂亮，而是回答三个问题：
- 它理解的目标，是不是你真正要的？ 这是最容易出偏差的地方。你说「优化查询」，它可能理解成「加缓存」，而你其实想要「改索引」。方向错了，后面越努力越远。
- 它打算动的范围对不对？ 方案里应该能看出会改哪些文件。发现它要动一堆无关的东西，立刻收紧。
- 有没有它自己标出的风险或不确定点？ 好的方案会说明哪里拿不准。看到这些点，你就知道该在哪些地方重点盯。
审方案的诀窍是：用一句话向它复述你看到的理解，确认一致，再放行。这一步花两分钟，能省下后面几十分钟。
给一个具体到能照做的审方案清单，看完计划逐条在心里过：
- 它有没有先读真实代码再给方案，还是凭我一句话就开始设计？没读代码的方案，再漂亮也要先打回。
- 方案里的每个改动文件，能不能对应到目标？凡是说不清「为什么要改这个文件」的，都要追问。
- 它说的「完成」，和我心里的「完成」是不是同一件事？最好让它明确列出收尾时要满足的条件（哪些测试过、行为变成怎样）。
- 它有没有标出自己拿不准的地方？一个全是肯定句、毫无风险提示的方案反而要警惕——要么任务真的极简，要么它没意识到坑。
真实例子：你让它「把列表接口的响应变快」。它的方案是「加一层 Redis 缓存」。方向看着合理，但你复述时发现它根本没去查现在慢在哪——而真实原因是缺了一个数据库索引，加缓存既增加一致性负担又治标不治本。就这两分钟的复述，避免了一次南辕北辙的改动。审方案的价值往往不在批准，而在这种「动手前识破方向错误」。
三、第二道闸：批命令——确认「这一步安全」
执行中它要跑命令时会请求批准。别把审批当噪音，逐条问自己：
- 这条命令到底会做什么？尤其是
rm、git push、安装依赖、改系统配置这类有副作用的操作。 - 它可逆吗？删除、强制覆盖、推送、发布这些不可逆动作，要格外谨慎。
- 它和当前任务相关吗？一个「改前端样式」的任务突然要动数据库或装奇怪的包，就是危险信号。
拿不准的命令，先让它解释，或者干脆拒绝、换一个更安全的做法。你永远有「不批」的权利，这不是不配合，而是驾驶员的本分。
这里给你一份「看到就要多停三秒」的命令类型，不是要你背命令，而是建立对副作用的敏感：
- 删除与清空类：
rm、清空目录、DROP、TRUNCATE。先确认路径具体、有没有通配符、是不是你真正想删的东西。一个.或*的位置错了，范围可能天差地别。 - 强制覆盖类：带
--force、-f、reset --hard的操作，会绕过正常保护，属于难撤销动作。 - 外发与发布类：
git push（尤其推到主分支）、部署、发消息、写生产库——动作一旦出去，影响的是别人，不是你本地。 - 装依赖与改环境类：
install、改全局配置、sudo。确认来源可信、确实是任务需要，而不是它为了图省事引入的额外东西。
一个特别实用的追问句式：当命令看不懂时，让它「用一句话说明这条命令执行后会改动哪些东西、怎么撤销」。一个安全的命令通常能被清楚解释，而如果它自己也说不清撤销方式，基本就是该拒绝的信号。还要相信「相关性直觉」：改样式的任务突然要碰系统配置，哪怕命令本身无害，也可能意味着它已经跑偏，值得停下来问一句为什么。
四、第三道闸：验结果——确认「真的好了」
它说「完成了」不等于真的完成。验收看三层：
- 看 diff：改动是不是只在该改的地方，有没有顺手夹带的奇怪修改、有没有删掉你需要的东西。
- 跑验证：能编译、测试通过、lint 干净。没有测试兜底的改动，可信度要打折。
- 看实际行为：涉及功能的，自己跑一下关键路径，确认表现真的变对了，而不只是「代码看起来没问题」。
验收的标准要在下任务时就说清，不然双方对「完成」的定义可能根本不一样。
验收里最容易被「绿灯」骗到，单独提醒三种「假完成」：
- 测试绿了，但它改的是测试。 为了让用例过而放宽断言、跳过用例。看 diff 时如果测试改动异常「配合」代码，要警觉。
- 它汇报「已测试通过」，但其实没真正运行。 模型可以生成一段像测试报告的文字。验收要看真实的命令输出，必要时自己再跑一遍。
- 代码看着对，关键路径却没走通。 尤其涉及异常分支、边界条件时，自己手动触发一次最关键的场景，比读代码更可靠。
一个值得养成的习惯：验收时做一次「反向检查」——故意想「这个改动在什么情况下会出问题」，然后去验证那个情况。它交来的是「正常情况下能用」，你要补的往往正是「异常情况下会不会崩」。这不是刁难，而是驾驶员该有的最后一道确认。
| 闸口 | 你要回答的问题 | 打回信号 |
|---|---|---|
| 审方案 | 目标、范围、风险对不对 | 理解偏、要动无关文件 |
| 批命令 | 做什么、可逆吗、相关吗 | 危险/无关/不可逆命令 |
| 验结果 | diff、测试、行为对不对 | 夹带改动、测试挂 |
五、放手不等于放任
强调把关，不是让你退回到事事亲为。正确的节奏是分级：对 放手区 的小任务，快速过一遍即可；对盯防区的复杂任务，三道闸一道都不能省。随着你对它的信任建立在一次次验证之上，可以逐渐把机械检查交给 Hooks 自动完成，自己专注在真正需要判断的地方。
记住一条朴素的原则：代码是你签收的，责任就永远在你。 它是能力很强的执行者，但对结果负责、对系统负责的那个人，始终是握方向盘的你。
六、乘客化是怎么一步步发生的
从驾驶员退化成乘客，很少是一瞬间的决定，而是一条顺滑的下坡路，看清它的台阶有助于你踩住刹车：
- 第一次：你认真看方案、逐条批命令、逐行看 diff，动作很慢但心里有底。
- 顺利几次后：方案开始只扫一眼，命令里你认得的（
ls、npm test）直接放行——这一步还算合理。 - 进一步放松：看到它「上次也是这样、没出问题」，对不那么认得的命令也开始惯性同意，diff 只看有没有红色大片删除。
- 彻底乘客化：方案不看了，命令批量点同意，验收只看它那句「全部通过」。此刻你对它在做什么其实已经没有实时认知，只是在为它的动作背书。
危险之处在于，前几步的「顺利」会被你当成「以后都安全」的证据，但前几次安全可能只是任务简单、运气好，而不是放权方式本身可靠。真正的风险任务往往在你最放松的时候到来。对抗这条下坡路，不靠意志力硬撑，而靠机制：把可客观验证的检查固化成 Hooks 自动跑（不依赖你记不记得看）、对危险命令类型保持强制确认、定期抽查自己「我还说得出它刚才改了什么吗」。
一个简单的自检：任何时候，如果你已经无法用一句话说清「它现在在做什么、为什么做」，那就是你已经滑到乘客位置的信号，该立刻把方向盘拿回来。
七、把关，也要讲究可持续
最后提醒别走向另一个极端。审方案、批命令、验结果，如果每次都事无巨细、所有命令一律怀疑，你会很快疲劳并最终放弃把关——这反而是另一种不可持续。成熟的做法是让把关的强度匹配风险：
- 只读、可逆、可自动验证的动作，快速通过，把精力省下来；
- 不可逆、外联、无客观验证的动作，慢下来认真看；
- 重复出现的客观检查，尽量交给自动化，而不是靠每次人工记忆。
把关不是越多越好，而是把有限的注意力，稳定地投在真正有风险的地方，并且这种投入方式你能长期坚持。这正是从「新手紧张地盯全程」走向「老到地分级放权」的关键，也是这个系列想帮你建立的核心能力之一。
八、不同阶段，三道闸的用法不一样
三道闸不是一成不变的固定动作，它会随你经验增长而调整，这里给你一条演进路线，也顺带说明每个阶段该把力气花在哪。
新手阶段（第一两周）：三道闸全部手动、从紧。方案一定先看，命令逐条批，diff 逐行读。这时候的首要目标不是快，而是建立两套东西：一是对「它通常会怎么干」的体感，二是对危险动作的条件反射。慢是这个阶段的必要投入。
熟练阶段（一两个月后）：你开始能预判它的动作，此时把检查按风险分流。放手区任务的方案快速过、只读命令直接放，但 diff 仍要看、测试仍要跑；盯防区任务保持三道闸完整。你也开始把重复的客观检查交给 Hooks，让自己不再依赖记忆。
进阶阶段（长期）：你的精力主要集中在两处——任务最前面的目标与边界定义，和最后面涉及取舍的判断；中间大量机械过程由 Agent 和自动化承担。此时你更像一个制定规则、抽查关键节点的负责人，而不是逐个动作审批的监工。
但无论到哪个阶段，有两样东西不建议放手：一是不可逆 / 外联动作的最终确认，二是你对「它在做什么」的最低限度实时认知。 很多老手翻车，恰恰是因为太熟练而在这两点上麻痹。三道闸可以越来越省力，但不应彻底消失。
你还可以为自己设一个简单的「回归新手」机制：每隔一段时间，挑一个任务故意全程手动走一遍三道闸，确认自己并没有因为依赖自动化而丧失对过程的判断力。这就像老司机偶尔也会刻意练习基础操作，是防止能力退化的小办法。
九、常见问题
Q：我不可能看懂每一条命令，那还怎么批？ 你不需要成为命令专家。看不懂时用两招：让它用一句话解释「做什么、怎么撤销」；判断它和当前任务是否相关。说不清撤销方式、或与任务无关的，就拒绝。把关靠的是风险直觉和追问，而不是记住所有命令。
Q：信任不是应该逐渐建立、逐步放权吗？ 应该，但信任要建立在「可验证的一致表现」上，而不是「它最近没出事」。放权时优先放可逆、可自动验证的部分；不可逆、外联的部分即使顺利很多次也保持谨慎。把信任分级、分动作地给，而不是一次性给满。
Q：审批弹窗实在太多，影响节奏怎么办？ 可以把其中客观、重复的检查交给 Hooks 自动完成，对明确安全的只读命令使用会话级放行。但这是在你理解风险后的优化，不要在新手阶段用「全部始终允许」来简单消灭弹窗——那是放弃把关，不是提高效率。
Q：出了问题，到底算谁的？ 从工程责任看，代码由你签收、合入、上线，责任在做审批和验收的人。这不是苛责，而是提醒：审批和验收不是形式，它们正是责任边界所在。看清这一点，你点「同意」时才会真正过脑子。
总结
Agent 负责干活，你负责掌舵——动手前审方案、过程中批命令、结束时验结果，三道闸都握在自己手里，你才能既享受它的速度，又不至于在失控时才发现自己早没了方向盘。