Claude Code 太费额度，我把自己的工作流重新理了一遍

我以前给 Claude Code 安排工作，拆得挺细。

一个节点做完，跑测试、做评审，有问题就修，再检查一遍。单看每一步，都没什么毛病。

后来做长任务，我开始觉得不对劲。明明改的是同一块功能，拆成几个节点以后，每个节点都要把那套流程重新走一遍。

最近看到花书聊省 token，我最想补充的就是这件事。缓存设置值得调，但我自己更想先管管这些重复工作。

这次我把以前的项目记录和现在的设置放在一起，重新理了一遍。哪些验证可以合并，什么活值得派子任务，强模型用在哪儿，下面具体聊。文末也放了一段开工前可以直接改着用的提示词。

一组改动，为什么要反复走整套流程

那时每个节点都单独跑一轮 Workflow，也就是把规划、实现、验证、评审、修复、提交串起来自动执行。功能拆成几个节点，这套流程就跑几轮。

这能帮人守住质量，也会带来开销。尤其是节点拆得很细，而每个节点又调用同一套全量检查的时候。

假设要改同一个表单的三个地方。字段说明、输入校验、错误提示分别开一个节点，每做完一小块，就重新构建整个项目、启动浏览器、跑一遍全部流程。后一个节点改完，前面刚通过的那套又得再跑。

我没做过严格的计时对照，报不出能省多少。但同一套构建和检查反复启动，是可以从执行记录里看出来的。

我的建议是，把紧密相关、风险相近的小改动归在一组。各自保留必要的定向检查，等这一组完成，再统一做构建、集成测试和整体评审。

已经通过的检查，只有在新改动或新问题可能影响它时才重跑。 让 AI 说明重跑的理由，比一句笼统的「再全面检查一下」更有用。

这里也不能走到另一个极端，把所有验证都拖到最后。数据迁移、权限、计费、跨模块接口，一旦方向错了，后面的工作可能都白做。该在中途确认的，还是得确认。

我想减少的是重复的整套流程。验证本身，是为了让后面的工作能放心继续。

强模型盯判断，执行模型把活做完

另一条是我在几个项目里都明确要求过的分工。那时的组合是 Fable 做规划、架构判断和最终检查，Opus 做具体实现、修复、跑命令。

有一轮尝试把实现也交给更强的模型，后来又改了回来。原因很直接，强模型的额度得省着用，批量执行没必要全交给它。

现在模型换了几轮，我还是会这样分工，具体用哪两个模型再看任务。

方案明确、边界清楚的实现，可以先交给较低成本的模型。需求还没想清楚、几个方案代价差很多，或者问题排查了几轮仍找不到原因，再让强模型多花些力气。

尤其是「验证」，里面其实有两种活。运行测试命令、收集失败日志，是执行。判断这些失败是不是暴露了设计问题，是分析。没必要因为它们都叫验证，就全部占用最强模型。

小改动也不值得为了分工专门组一个队。主会话已经读懂了那几个文件，直接改掉就好。再开一个子任务，往往还得重新讲背景、找文件、交接结果。

但如果要读一大份日志，或者调查一个能独立回答的问题，子任务就有用。可以让它把大量中间输出留在自己的上下文里，只返回结论、证据位置和未解决的问题。官方成本指南也建议用这种方式隔离冗长操作。

还有个容易漏的地方。如果在已经很长的主会话里反复切模型，新模型需要重新建立自己的缓存。因此我更倾向在任务开始时决定分工，而不是每过几轮就换一次。官方缓存说明

缓存能调，但先看看任务怎么跑

花书提到子任务的一小时缓存，这个设置确实存在。目前可以在 Claude Code 的设置里加入下面这一项，合并到现有配置中即可，不要把整份文件覆盖掉。

{
  "subagentPromptCacheTtl": "1h"
}

按官方说明，这项设置需要 Claude Code 2.1.242 或更新版本。它适合子任务中间经常等待几分钟，之后还会继续处理的情况。

同时补一个前提。订阅包含额度内，主会话通常默认一小时缓存，子任务通常默认五分钟；API、云服务商和额外付费额度的默认情况不同，不能只看自己用的是不是 Claude Code。

一小时也不是无代价的。按 API 价格，一小时缓存写入是基础输入价的两倍，五分钟是 1.25 倍。如果请求一直连续进行，子任务很快就结束，较长的有效期未必用得上。官方成本分析

所以，我会把它留给经常等待、又会继续的工作，不把它当成人人必开的省钱开关。订阅额度和 API 账单也要分开看，不能拿一个价格倍率直接推算自己能多用多久。

上下文也是类似的取舍。所谓上下文，就是模型这一轮能看到的历史信息，包括对话、文件片段和工具输出。

需要提前压缩时，当前版本支持这样的命令。

/autocompact 500k

它设置当前模型的自动压缩窗口，并保存供后续会话使用。500k 是这里的示例值，不是经过我验证的最佳值；配置优先级或模型实际窗口也可能限制它。官方配置说明

我更在意压缩之后能不能接着干。如果关键决定只藏在长对话里，压缩一次就要重新查文件、重新讨论方案，窗口设得再小也未必省。

做长任务时，留一份简短进度记录就很实用。已经完成什么，哪些决定不必重谈，失败过哪些办法，下一步去哪个文件。需要恢复时，先读这份记录，不用从头勘察。

顺手核对本机设置时，发现 Opus 5.5 保存的思考强度是 high。对于方案已经明确的小任务，这也是可以单独尝试调整的地方。不过本轮只是核对配置，还没有做不同强度的对照测试，不能替它报一个节省比例。

开工前，把这些话说清楚

比起一次改很多开关，我会先把任务的范围和工作方式交代清楚。下面这一段，是把前面的安排收在一起，不是官方提示词，也不保证每次都会更快。

这次只完成我指定的任务，遵守项目现有规范。
先确认目标、修改范围和完成标准，再开始实现。

请把紧密相关、风险相近的小改动合成一组。
组内保留必要的定向检查，共享的全量测试、
构建和整体评审，在这一组完成后集中执行。
高风险变更仍在相关步骤及时验证。
已通过且未受新改动影响的检查，不重复跑。

小任务优先在主会话完成。
只有能独立完成、值得交接的工作才派子任务。
如果工具允许指定模型，明确的执行任务用
较低成本模型，规划和疑难判断用强模型。
不要假装已经完成工具不支持的模型切换。

完整日志留在文件中，返回结果、证据路径和
未解决的问题。长任务维护一份简短进度记录，
恢复时从实际进度继续。

范围外问题单独记录，不自动扩做。
完成约定的工作和验证后收尾，不反复自查。

最后两句，对我尤其有用。

让 AI 自主干活以后，它很容易沿着「再完善一点」继续走。发现一个新问题，再查一圈；修完以后，又想把旁边也整理一下。每件事单独看都有理由，加起来却已经离开了这次任务。

把额外发现记下来，下一次再决定做不做，工作才有一个明确的结束点。

真想比较有没有改善，可以拿相近的任务试一轮，记下完成耗时、是否需要返工，以及可见的用量或账单。缓存命中率很好看，也不代表这次任务一定划算。

你平时更常遇到哪一种，Claude 一直在重新读文件，还是代码早写完了，却一直停在检查和修修补补？