只要认真用起 Claude Code，就一定会碰上「已达到上限」。这一章讲的是为了避开它而需要的运营方法。
不过目的并不是省本身，而是造出关键时刻额度还有富余的状态。省过了头把成果拉低，那就本末倒置了，所以最后还要谈一谈怎么划线。
消耗为什么会涨
消耗的计量单位是令牌。很多人在这里的误解是，以为它只由「你发出去的指令有多长」决定。
Claude 自己跑去读的文件，全都会计入输入。让它整份读一个大文件，量就一下子上去了。
每来回一次，此前的历史也会一并发过去。对话越长，单次来回的单价就越高。
一直改到测试通过的这种做法，每失败一次就多花一个来回。这是它那份强项的背面。
这三项里，你最动得了的是 FACTOR 2。读哪些文件由工作内容决定，尝试次数由难度决定，而历史的长度是可以靠用法调整的。
「指令写短一点就便宜」是个误解。 指令短到意图传达不到位，Claude 就会加大探索、做出跑偏的实现，然后返工。结果是来回变多，反而更贵。便宜的不是短指令，而是一次就能通过的指令。
额度不止一种
第 4 章也提到过，而这里是运营上最要紧的一处。短周期的额度和长周期的额度是分开存在的。
短的那份恢复得比较快，等一等就能接着干。长的那份要按天算，把它用光，你就得好几天动不了。「刚才明明恢复了怎么马上又停」，说的就是短的那份回来了、长的那份还没回来的状态。
额度本身的行为整理在 usage limit reached 的处理，而对「周额度比预想更早恢复」这一现象的实测结果，整理在 周上限提前重置的真相 里。
把截止日前的重活先干掉，探索性的试验挪到额度宽裕的时段去做。
拿长周期的额度去反复试错，结果到了真正要干活的那天动不了。除了等恢复别无他法。
effort 设置 —— 在快和聪明之间做选择
Claude Code 里有一个让你选择要它思考到什么程度的设置。让它想得越深，准确度越高，但相应地时间和消耗也都会上去。
在这件事上，「永远开到最大」和「永远开到最小」都要吃亏。正确的做法是按任务的难度来切换。
模式固定的替换、格式化、补测试、方针已经定好的实现。没有什么可琢磨的活。
查不出原因的缺陷、设计上的取舍、影响面看不清的改动。一旦做错返工代价很大的活。
这项设置的内容和用法在 effort 是什么？快与聪明之间怎么选 里讲。判断的轴是拿它和返工的代价去比。让它深想一次就通过，比开轻了返工三次要划算。
折叠上下文，同时也是一笔成本账
第 3 章是在「想不起来了所以要折叠」这个语境下讲的，但折叠还有另一个动机。长长的历史每次都要发过去，不折叠就一直干下去，单次来回的消耗只会不断膨胀。
话说回来，折叠本身也是要花消耗的。折叠过头，连需要的前提也一起丢了，还得重新解释一遍，反而更贵。判断标准整理在 /compact 该不该手动执行 里。
折叠时机的判断标准
好 ：一件工作刚做完的时候
要转到另一批文件之前
坏 ：工作做到一半（连马上要用的前提都被抹掉）
「感觉有点长了」（这不算判断）
容易白白浪费的用法
消耗的大头，来自没能转化成成果的来回。下面列几种常见的形态。
没有测试，它就没法确认「做好了」是真是假，于是变成你去看、你去指出、它再返工的来回。
几千行里真正需要的只有几十行。只给相关那一段，同样的结果会便宜得多。
连不相干的工作也堆进同一份历史，之后就得一直背着它走。
项目特有的那些约定，放进第 6 章讲的持久记忆里，就不用每次重写了。
掌握自己的消耗情况
在动手减之前，先搞清楚现在是什么在花、花了多少更要紧。凭感觉去省，削掉的多半是没用的地方。
要看的有两样：当前这轮对话膨胀到什么程度了，以及额度还剩多少。前者用来判断要不要折叠，后者用来判断「今天这件活能不能开工」。
看剩余额度，决定能不能开始一件重活。剩得不多，就换成轻活，或者等恢复。
看对话膨胀的程度，决定转到下一件活之前要不要折叠。一件活做到一半时不用看。
要紧的是不要提高查看的频率。每隔几分钟去看一眼余量，消耗并不会因此变少。在工作的交界处看一下就够了。
不该做的那几种「省」
有些做法自以为在省，其实是反效果。而且都很常见。
前提传达不到，做出跑偏的实现，返工次数变多。要删就删贴进去的量，别删说明。
在活做到一半时折叠，连马上要用的前提都被抹掉。重新解释的开销更贵。
让它浅浅地想一个查不出原因的缺陷，它就会反复去试跑偏的假设。时间和消耗都会涨。
停着的状态下改来改去，你根本验证不了效果。等恢复之后，再一项一项试。
团队使用时会多出来的东西
一个人用的时候没在意的消耗，推广到团队之后会换一种形式冒出来。
最常见的是每个人都在各自解释同一套前提。项目的约定、命名规范、不能碰的地方——如果各人每次都要写一遍，就按人数重复了多少份。放进第 6 章讲的持久记忆里，通过代码仓库共享出去才是正解。
另一种是有人拿探索性的用法把额度耗掉，另一个人在正经活上被卡住。用的是个人额度还是组织额度，行为会不一样，所以推广之前至少要把这一点确认清楚。
比起用规章去约束，把共享的东西整备好更管用。 喊一句「要节省令牌」，换来的只是各人标准不一；而持久记忆和验证手段都齐备在代码仓库里之后，所有人的来回都会自然而然地变少。
实践 —— 减少消耗的七招
按效果从大到小排。靠前两招就能解决大半问题。
历史越短，单次来回越便宜。这一招最管用。
让它能自己确认、自己改，和你之间的来回就少了。
指定目标目录或文件。探索的那一份开销整块省下来。
套路活用不着开到最大。难关上则不要吝啬。
凡是你每次都要解释的内容，就该被写下来存好（第 6 章）。
在一件活刚做完的时候折。做到一半折，就得重新解释。
把调查切到另一个上下文里，主线的历史就不会被弄脏（第 6 章）。
关于 AI 编程整体的成本优化，AI 编程成本优化大全从更宽的视角做了整理。
为了不省过头，得划一条线
最后是这一章最想说的一句话：省钱不是目的。
太在意额度，连难活也用轻设置硬扛，然后一遍遍去修跑偏的实现——这会让消耗和时间双双上涨。这正是「以为在省、其实在浪费」的典型。
判断标准是「返工的代价有多大」。 做错了几分钟就能退回来的活，开轻、跑快。做错了要赔进去半天的活，一开始就让它深想。额度就是要留给后者的。
还有一点：停了就休息，这也是运营的一部分。撞上上限时与其把设置翻来覆去地改，不如等它恢复、以最好的状态重新开始，结果反而更快收工。
小结
- 消耗由读过的文件、对话的历史、尝试的次数决定。你动得了的主要是历史
- 「指令短＝便宜」是误解。一次就能通过的指令才便宜
- 额度分短周期和长周期两种。把长的那份用光，就好几天动不了
- effort 要按难度切换。永远最大和永远最小，都吃亏
- 折叠既是记忆的事，也是成本的事。但做到一半折叠反而更贵
- 效果最大的是两招：把对话切开，以及先把验证手段交给它
- 省钱不是目的。按返工的代价来判断，把额度留给难关