读完第 1 章和第 2 章，你应该已经清楚 Claude Code 是什么、怎么运转。这一章要建立的是每天都能照样转一遍的节奏——探索 → 计划 → 实现 → 提交这四拍。
为什么需要套路，理由很明确：不顺利的那些日子，原因几乎都是「漏掉了某一拍」。没让它读就让它写，没给验证手段就把活交出去，不打断点就一路跑下去——症状各不相同，但要退回去的地方是同一个。
一天的套路 —— 用四拍转起来
让它读相关的文件，并把现状用话讲出来。这时还不让它写。
让它先把步骤列出来，由你来改。这是唯一便宜的修正点。
让它写，并当场把验证跑一遍。让第 1 章那个循环完整转起来。
跑通的那一刻就钉下一个可以退回来的点。下一轮探索从这里开始。
一轮该有多大，判断标准是「想不起中间过程了，就说明太大了」。半天转一轮，几乎总是不如一小时转一轮、转四次稳。
这不是说每次都要走完全部四拍。 改个错别字用不着计划。要判断的是哪一拍可以省，而初始设定是「全部都做」。
开工之前，先把验证手段交给它
进入四拍之前，有一件事要先做一次：把「Claude 能自己检查自己」的手段先交给它。
正如第 1 章所见，它内部是收集 → 执行 → 验证的循环。它之所以强，是因为有 STEP 3，能一直自己改到测试通过。反过来说，没有验证手段，这个循环转一圈就停了——写完，大概是对的，结束。跟聊天型没有区别。
一句「把测试跑通」就够了。失败的输出成为下一轮的输入，你不盯着，循环也照样转。
你来跑，你来报结果，再让它接着写。你自己成了瓶颈。所谓交出去，只是你以为交出去了。
交给它的东西不必多隆重。「敲这条命令就知道对不对」这么一行就够了。而且这件事写进文件比用嘴说更可靠——因为项目根目录下的 CLAUDE.md，即使经历了压缩也会重新从磁盘读一遍。
写进 CLAUDE.md 会见效的内容（示例）
- 改动之后要跑通的命令：测试 / 类型检查 / 代码检查工具
- 没跑通就不要报告「做好了」
- 不能碰的地方（生成物、生产环境配置等）
这样写下来，你不用每次都说「测一下」，它每改一次就会自己去确认。这不是你发指令的次数变少了，而是需要发指令的场合变少了——这就是套路起作用的方式（怎么写在第 6 章）。第 1 章里归到「不适合」的那些任务之所以在这里掉队，也正是因为没有能交出去的验证手段。
探索 —— 让它先读，再让它写
第一拍。要做的只有一件事——让它读相关文件，并说明现在是什么状况。这时还不让它写。跳过这一拍，Claude 就会用猜测去填补它没读过的部分。返回来的代码看着像模像样，却和现有写法有微妙的出入，而你发现这个出入，往往要等到评审或上线。
糟糕的探索：「把认证那块修一下」
→ 它直接开始改。你不知道它是基于什么前提改的
好的探索：「找出并读完与认证有关的文件。
说明现在登录是怎么处理的，
并把相关文件列一份清单。
暂时什么都不要改」
→ 前提摆在屏幕上。有偏差可以当场纠正
它返回的说明，请你读一遍。这里是成本最低的介入点。「那个文件已经不用了」这一句话的代价，只有在评审阶段才发现实现做错了的几十分之一。
还有一点：探索是有代价的。读过的文件会占进上下文，探索的范围越大，后面的余量就越少——第 1 章说的「填满之后会变迟钝、会忘掉前半段」，就是从这里开始的。控制的办法有三个。
- 划定范围——说清「先只看认证这一块」。全局观是需要的，但不需要读全部文件
- 超大文件让它分段读——整份读进来会一下子把上下文填满。按行区间或按函数读通常就够了
- 输出量大的调查单独拆出去——查日志、大批量搜索交给子智能体。它有自己的上下文，回来的只有摘要，所以主会话不会被撑大（第 6 章）
计划 —— 计划模式什么时候管用，什么时候是累赘
第二拍。在动笔之前，先让它给出要改什么、按什么顺序改。 Claude Code 里有专为这一拍准备的计划模式：它会调查并给出计划，然后停在那里，在你批准之前不会进入写入。切换方式随版本而变，请在你手上这个版本的帮助里确认。
它的实质是把权限的关卡从「每次编辑」挪到「工作的入口」。默认设置下每调用一次工具都会要确认，而计划模式把这些合并成一次，提前到最前面。你批准的对象也从「这一行」变成了「这项工作的方针」。
改动跨多个文件／做法有两种以上／需要迁就已有的设计／改错了回退起来很麻烦／连你自己都还没定下最优解
要做的只有一件事／步骤早就定好了／失败了也能立刻退回／读计划花的时间比实现还长
右边那一列，就痛快地跳过。计划不是免费的，它要花生成的时间、阅读的时间和上下文。拿到计划后只需要看三点。①前提对不对（第一拍偏了，计划就整个偏了）②里面有没有验证（没有「把测试跑通」就补上）③切得够不够细（一步做完全部的计划，失败时你定位不到原因）。
工作时间长的话，就把计划落到文件里。 只存在于对话中的计划，会话一长就会被压进摘要里。让它写到 PLAN.md 之类的地方，折叠上下文之后还能重新读，中途离开再回来时也有个续上的位置。
实现 —— 切小块，边跑边改
第三拍。到这里才让它动笔。原则有两条。
第一条，每走一步就跑一次验证。 攒够五处改动再测，一旦挂了，你就多出一份「到底是哪一处引起的」的排查工作。写一处、通一处，那出问题的就是刚才那一步。这条规矩与其说是为 Claude，不如说是为你自己。
第二条，失败的输出原样交给它。 不需要你先总结再转述。STEP 3 本来就是「读输出，回到 STEP 1」，所以原始输出才是信息量最大的输入。嚼碎了给，反而线索更少。
实现过程中的一轮（把它切碎，反复转）
[编辑] 只改计划里的一个条目
↓
[执行] 跑测试／类型检查
↓
绿 → 进入下一个条目（或者提交）
红 → 读完输出，再回到 [编辑]
同一个地方连红三次，就别让它继续改了
→ 停手，转入排查（第 4 章）
最后一行是经验之谈。开始反复出同一个错，通常不是「快修好了」的意思，而是「前提本身就错了」的信号。
验证很耗时的时候——比如漫长的构建、等 CI 跑完——也可以不盯着，交给它去跑。Claude Code 有让指令按固定间隔重复执行的机制；如果省略间隔，下次什么时候来看由 Claude 自己决定，它判断已经完成就会停止循环。机制和限制见 /loop 命令是什么。要注意的是，关掉会话它就停了。
提交 —— 断点由你自己来打
第四拍。测试一通过，当场就提交。不是「等做到一个段落再说」，而是跑通的那一刻，就是一个段落。
- 它成了可以退回来的点——下一步就算失败，也能退回到确定是绿的地方
- 差异保持在读得完的大小——半天的改动量是读不完的。读不完的差异，实际上等于没被评审
- 可以放心切掉对话——成果已经进去了，丢掉一个会话就不再让人害怕
提交信息也可以让它写，但不要不看差异就批准。把关注点定成不是「改了什么」，而是「有没有混进你本来没打算改的东西」，眼睛就不会滑过去。
另外，提交和推送是两个不同的判断。像部署这种难以撤销的操作要放手到什么程度，放在第 5 章讲。
会话怎么折叠，怎么回退
四拍转上几轮，一定会撞上上下文快满了这个问题。第 1 章说的那两个症状——反应变迟钝、忘掉前半段——一出现就该折叠了。手段有压缩和重新开始两种，分界点只有一个。
接下来是「续着做」，就压缩——经过可以以摘要的形式带过去，而且你能指定保留什么，这正是它和自动触发的区别。接下来是「另一件事」，就重开——连摘要都不需要，那就连生成摘要的开销也省了。不拖着无关的工作，准确度也更好。
时机也有讲究。不是看时钟或百分比，而是在工作的段落处按下去——一轮结束、正要进入下一段长活之前。中途按下去，后面要用的细节会一起被压进摘要里。依据见 /compact 该不该定期执行。
折叠之前，把不能丢的东西写进文件。 项目根目录下的 CLAUDE.md 和自动记忆是从磁盘重新读取的，折叠多少次都活得下来；但只存在于对话里的决定，会在摘要里被冲淡。
还有一个机制，会改变你放手的方式本身。Claude Code 会为每一条提示词自动建立一个可以退回来的点，出了岔子就能倒回去。回退的对象可以从只回退代码、只回退对话、两者都回退里选，用得最多的是「只把代码退回去，对话留着」——改动当作没发生过，同时还记得刚才哪里不对，于是可以重新说一遍。
它真正的价值不在操作省事，而在你敢怎样冒险。以为退不回去，你就会一步一确认，用智能体的意义也就淡了。知道退得回去，就敢一次交出去一大块，试了不行就丢掉也成了一个选项。
但能退回来的，只有「Claude 用编辑工具改写过的文件」。 用 shell 命令建立或删除的文件、你自己做的编辑、数据库的状态，都退不回来。它替代不了 Git，前提是要和关键节点上的提交配合使用。线可以这样划——在文件编辑范围内能完成的工作，就大胆交出去；会经由 shell 改变状态的工作，交出去之前先提交。细节见 检查点与回退。
让它做评审 —— 把写的人和读的人分开
测试通过的代码，不一定就是好代码。测试只保证「没有坏掉」，回答不了「这样写是不是合适」。
原则只有一条：把写的语境和读的语境分开。 在刚刚写完那段实现的同一个对话里说「评审一下」，它多半会给自己的判断背书。所有的取舍理由都还摆在眼前的状态，并不适合挑毛病。具体做法有三个。
- 换一个会话来读——先提交生成差异，然后只把差异交给一个全新的对话。让不知道来龙去脉的眼睛去读
- 指定视角——不要说「改好一点」，而是给出「边界条件」「与现有写法是否一致」这样的轴。含糊的要求只会换来含糊的意见
- 不要全盘照收它的意见——对不对要拿实物核对。让它改之前，先自己读一遍
第三点和本章别处是连着的。评审正是「没有验证手段的任务」的典型，对错不会自动判定，所以 Claude 会用很有把握的语气说出跑偏的话。照单全收地转成修改指令，就会把本来正确的代码改坏——请把它的意见当作候选，一条一条判定。如果你发现自己每次都在用同一套视角，那就是该把它固化成机制的信号（第 6 章）。
多会话并行 —— 划算到哪一步为止
这边在跑一长串测试，那边想同时推进另一件事——这想法很自然。Claude Code 里有一套机制，可以在后台同时开起多个独立会话，并在同一个界面里管理。它的要点是隔离：后台会话在编辑文件之前会先转到自己专用的工作目录。于是就成了读共享、写分离，从结构上杜绝了互相覆盖同一个文件的事故。细节见 agent view 与派发。
任务彼此独立／中间过程不必盯着看／拿到结果再判断就够了／其中一边是等待时间很长的活
都依赖同一个设计决定／中途需要重新定方向／包含无法撤销的操作／数量多到你根本确认不过来
右边最后一条是最要命的约束。并行会把评审的总量放大。 一次抛出三个，回来的就是三份「真的是这样吗」，而确认的工夫并不会跟着并行。能抛出去的数量上限，就是你能验证得过来的数量。费用同样会涨——不会因为跑在后台就便宜（第 7 章）。
开始并行之前，请先回头看一眼权限设置。 在后台跑的会话不是当场选权限，而是从配置里继承。平时设得越松的人，就越会一下子多出好几个「权限很松、又没人盯着的会话」。请先看第 5 章。
还有一件不起眼却常出事的事：收尾。后台会话建立的工作区，在你删除该会话时会一起消失。「做完了」和「已经收进来了」是两回事——删之前先提交。
小结
- 一天的节奏是探索 → 计划 → 实现 → 提交四拍。不顺利的原因，多半是漏掉了某一拍
- 开工前先把验证手段交给它。没有的话，收集 → 执行 → 验证的循环转一圈就停
- 探索要先读再写。但读得越多余量越少，所以要划定范围
- 计划是把权限关卡合并到工作入口的机制。一步就能完成的活，用它太重
- 实现每走一步就验证一次，连错三次就转入排查。提交在跑通的那一刻打下去
- 折叠还是重开，看「接下来是续着做，还是另一件事」。折叠之前先写进文件
- 回退只退文件编辑。经由 shell 的改动退不回来，所以要和提交配合
- 评审要和写的语境切开，意见当作候选看待。并行的上限是你验证得过来的数量
套路有了，该卡住的时候还是会卡住。下一章我们来准备一套排查的顺序。请前往 第 4 章「走出卡壳」。