1. 理解新限额规则：从“无限畅饮”到“精打细算”

如果你和我一样，从Claude Code一出来就开始重度使用，那最近几个月的感觉可能像坐过山车。一开始那种“无限畅饮”的畅快感，让写代码的效率直接起飞，一天能干完以前一周的活。但好景不长，Anthropic在去年8月底正式推出了新的使用限制，给这股热潮泼了盆冷水。说实话，刚看到限额通知时，我心里也咯噔一下，感觉又要回到束手束脚的日子了。但用了一段时间后，我发现这未必是件坏事，它反而逼着我们去思考如何更聪明、更高效地使用AI，而不是无脑依赖。

这次调整的核心，是引入了双重限制机制和模型分层策略。简单来说，就是给你上了两道“紧箍咒”：第一道是传统的5小时时间窗口，防止你单次会话无限制地“烧”下去；第二道是新增的每周总限额，按7天滚动计算，防止你一周内过度消耗资源。更关键的是，他们把Opus和Sonnet这两个模型的额度分开了，尤其是Opus，管控得特别严格。我翻了翻自己的订阅账单，Pro计划（20美元/月）大概有40-80小时的Sonnet使用时间，但完全不包含Opus；而Max 100美元档，虽然有140-280小时的Sonnet额度，但Opus只有可怜的15-35小时。这意味着，如果你还像以前那样，不管什么任务都无脑切到Opus，额度可能几天就见底了。

这种变化背后的逻辑其实不难理解。Anthropic面对的算力压力和成本压力是实实在在的，他们必须确保资源能被更公平、更可持续地分配。对于我们开发者来说，这标志着一个时代的结束：那个可以随意让AI“大力出奇迹”的草莽阶段过去了。现在，我们必须从“重量”转向“重质”，从“无脑使用”转向“精准投放”。这听起来像是限制，但换个角度看，它何尝不是一种促使我们优化工作流、提升自身判断力的契机呢？毕竟，最贵的工具，要用在刀刃上。

2. 技巧一：建立任务分级与模型匹配决策树

面对有限的额度，尤其是珍贵的Opus额度，第一要务就是学会“看菜下饭”。你不能让一个顶尖的架构师天天去写简单的CRUD接口，那太浪费了。我的经验是，必须建立一套清晰的决策流程，在动手之前，先判断这个任务到底该派给Sonnet还是Opus。

我给自己画了一个简单的决策树，每次开始新任务前都会快速过一遍。首先问自己：这个任务的复杂度和创造性要求高吗？ 如果只是简单的语法修正、代码格式化、根据现有模式添加一个新函数，或者跑个单元测试，那根本不用犹豫，直接交给Sonnet。它的代码生成和理解能力对于日常琐事完全够用，而且响应速度往往更快。比如，你只是想把一批JSON数据的键名从下划线改成驼峰，这种有明确规则的任务，Sonnet处理起来又快又准。

但是，当遇到下面这些情况时，我就会果断请出Opus：

1. 系统架构设计：需要设计新的微服务模块，规划服务间的通信协议和数据流。
2. 跨文件/跨仓库的重构：比如要把一个庞大的单体应用里的用户模块抽离出来，这涉及到理解分散在各处的代码逻辑和依赖关系。
3. 解决复杂、模糊的Bug：不是那种编译错误，而是运行时出现的、日志信息模糊、可能涉及并发或状态管理的棘手问题。
4. 算法优化与实现：需要设计一个非标准的、性能要求高的算法。
5. 理解陌生的大型代码库：刚接手一个历史包袱重的项目，需要快速理清核心脉络和关键入口。

这里有个我踩过的坑：曾经有一个任务，是优化一个数据库查询。一开始我觉得这挺复杂，直接用了Opus。Opus给出了一套非常“华丽”的方案，涉及多个子查询和临时表。结果Sonnet后来一看，简单地说：“这里加个复合索引就能解决90%的问题。” 我这才意识到，我错误评估了任务的“认知复杂度”。很多任务看似复杂，但其实核心瓶颈是单一的，Sonnet完全能搞定。所以，决策树的第二层问题是：这个任务的核心难点，是“认知理解”层面的，还是“信息检索”与“模式执行”层面的？ 后者交给Sonnet更经济。

为了把这种决策固化下来，我强烈推荐你在项目的 CLAUDE.md 文件里明确写上模型使用指南。比如：

## 模型选择指南 (Model Selection Guide)

请根据任务类型自动选择模型：
- **使用 Sonnet 的场景**：代码补全、单文件bug修复、运行测试/脚本、执行数据转换脚本、编写简单的API端点。
- **必须使用 Opus 的场景**：涉及超过3个文件的架构变更、设计新的领域模型、审查安全关键代码、处理模糊的非确定性bug。

**重要**：除非遇到上述必须使用Opus的情况，否则默认使用Sonnet模型以节省额度。

这样，每次Claude Code启动时都会读到这个规则，能在一定程度上引导它做出更经济的决策，也提醒你自己保持清醒。

3. 技巧二：精细化周计划与额度预算管理

有了按周计算的总额度，就不能再“今朝有酒今朝醉”了。你得像管理项目预算一样，管理你的AI额度。我现在的习惯是，每周一早上，花10分钟做个简单的额度规划。

首先，你得清楚自己这周的主要开发任务是什么。是冲刺一个新功能，还是修复一批技术债，或者是做代码重构？不同的任务类型，对AI的消耗差异巨大。比如，开发新功能，前期设计和探索可能消耗较多Opus额度；而批量修复同类bug，可能用Sonnet写个脚本就能半自动化完成。

我的周计划模板大致是这样的：

• 周一至周三（高强度开发期）：集中处理本周最复杂、最需要创造力的任务。比如周一把新功能的架构设计用Opus做完，周二、周三用Sonnet和Opus混合模式实现核心模块。这段时间会消耗掉大部分Opus额度。
• 周四（缓冲与优化期）：主要使用Sonnet。进行代码审查、补充测试用例、编写文档、优化性能。这些任务对模型要求相对较低，同时也能让“烧脑”的节奏缓一缓。
• 周五（收尾与预备期）：几乎全部使用Sonnet。处理一些琐碎的边角工作，运行完整的集成测试，整理本周工作日志。同时，评估本周额度剩余情况，为下周可能出现的紧急任务预留一点Opus缓冲。

这里的关键是 “预留缓冲”。千万别把额度算得死死的，因为开发中总会冒出意想不到的复杂问题。我一般会预留出每周Opus额度的20%作为应急储备。比如我有35小时的Opus额度，那我最多只计划用掉28小时。

另一个血泪教训是 避免“额度悬崖”。曾经有一次，我在周四下午就把当周的Opus额度用光了，结果周五早上发现一个关键模块的设计存在重大缺陷，需要重新设计。没有Opus可用，只能用Sonnet勉强应付，结果返工了三次，浪费了大量时间。所以，现在我会更均匀地分布额度消耗，确保每天都有“弹药”应对突发情况。

你可以用一个简单的记事本或表格来手动记录，也可以尝试写个简单的脚本，结合Claude Code的API（如果有的话）或日志来估算消耗。核心是建立预算意识，从被动接受限制，变为主动规划资源。

4. 技巧三：利用Subagent与MCP实现“成本分流”

这是应对限额的高级技巧，也是让我感觉“真香”的功能。Claude Code不是一个人在战斗，你可以通过Subagent（子代理）和MCP（模型上下文协议）来组建一个“AI团队”，把不同的任务分配给最合适的“成员”，从而把昂贵的Opus从繁重的体力活中解放出来。

Subagent 就像是你的专属专家团队。你可以在 .claude/agents/ 目录下为不同场景创建不同的代理配置文件。最关键的一点是，你可以为不同的Subagent指定不同的模型。比如：

# .claude/agents/code-reviewer.yaml
name: code-reviewer
description: 专注于代码风格和常见缺陷的审查员
model: claude-3-5-sonnet-20241022 # 指定使用Sonnet
system_prompt: |
  你是一个严格的代码审查员。只关注代码风格、重复代码、明显的逻辑错误和潜在的性能问题。
  不要深入分析复杂架构，那是架构师的工作。
  用列表形式指出问题，并给出具体的修改建议。

# .claude/agents/architect.yaml
name: architect
description: 系统架构设计专家
model: claude-3-5-opus-20241022 # 重要任务才用Opus
system_prompt: |
  你是资深系统架构师。负责评估技术方案可行性、设计系统分层、模块划分和接口协议。
  请从可扩展性、维护性和性能角度给出设计。

在实际工作中，流程就变成了这样：当我完成一个功能开发后，我不会直接用主会话（可能默认是Opus）去审查代码。而是通过 /agent code-reviewer 命令，调用那位用Sonnet模型的审查员。它快速扫描代码，给出风格上的建议。如果它发现了一些深层的设计疑虑，我再手动或通过规则，将问题转交给 architect 这个用Opus模型的专家进行深度评估。这样一来，大量的日常审查工作由便宜的Sonnet消化了，只有真正需要高认知能力的问题才消耗宝贵的Opus额度。

MCP 则更进一步，它能把外部工具和数据源变成Claude的“外挂”。很多耗时的信息检索任务，其实不需要Opus强大的推理能力。例如：

• 通过 mcp-github 查询仓库信息、Issue列表。
• 通过 mcp-postgres 直接查询数据库Schema和数据样本。
• 通过 mcp-jira 获取任务详情。

这些操作通过MCP服务器完成，Claude Code只是发起请求和解析结果，消耗的Token很少，且不区分模型（因为是你本地或网络工具在执行）。这相当于把原本可能需要Opus去“思考”和“生成”的查询过程，变成了廉价的“工具调用”。我经常让Sonnet驱动的Agent去调用MCP工具获取数据，然后基于这些数据进行分析，只有分析遇到瓶颈时，才升级到Opus。

5. 技巧四：优化Prompt与上下文管理以提升单次效率

额度有限，每一次交互的“性价比”就至关重要。糟糕的Prompt会导致来回对话很多轮，浪费大量Token，尤其是浪费Opus的Token。而混乱的上下文则会让你不得不频繁 /clear 重来，之前的工作上下文丢失，又得重新喂给AI，形成恶性循环。

Prompt优化的核心是 “一次性说清楚”。避免开放式提问，要像给资深同事写任务说明一样。对比一下：

• 低效Prompt：“帮我实现用户登录功能。”
• 高效Prompt：“在 src/auth/ 目录下，使用JWT实现用户登录API。已有 User 模型（字段见 src/models/user.py）。请创建 login.py，包含端点 /auth/login（POST，接收email和password），验证成功返回 {“access_token”: “xxx”, “refresh_token”: “xxx”}。使用 argon2-cffi 验证密码，用 python-jose 生成JWT。密钥配置从环境变量 SECRET_KEY 读取。最后，请编写对应的单元测试文件 test_login.py。”

高效的Prompt包含了角色、任务、上下文、技术栈、输入输出格式、甚至文件路径等所有关键约束。这能让AI直接产出可用的代码，减少后续澄清需求的轮次。

上下文管理则是另一个战场。Claude Code有上下文窗口限制，当会话过长时，模型会“遗忘”早期的内容，表现下降。我的策略是 “模块化会话，文档化衔接”。

对于一个大功能，我不会在一个会话里从头做到尾。而是拆分成“设计”、“实现模块A”、“实现模块B”、“集成测试”等多个独立会话。每个会话开始时，我都会让AI先读取之前会话生成的规划文档或核心产出。例如，在“实现模块A”会话开始时，我的第一条Prompt是：“请先阅读 ./design/feature-x-plan.md 文档，了解整体架构和模块A的接口定义。然后，我们开始实现 src/module_a/service.py。” 这样，每个会话都能在清晰的上下文和有限的长度内高效工作。

另外，要善用 /compact 命令。当你完成一个逻辑阶段（比如写完一个类并通过了基础测试），可以主动执行 /compact，让AI帮你总结当前进展并压缩上下文。这比等到上下文快满了自动压缩要更可控，能避免压缩发生在关键修改过程中导致混乱。

6. 技巧五：构建混合工具链与人工兜底

最后，也是最重要的心态转变：Claude Code是你的副驾驶，而不是自动驾驶。限额政策其实是在提醒我们，不能过度依赖任何一个AI。构建一个属于你自己的、包含多种工具的“工作流网”，是保证效率和安全性的关键。

我的工具链现在大概是这样的：

1. 日常主力：Claude Code (Sonnet为主，Opus用于攻坚)。负责核心代码生成、复杂问题调试、架构咨询。
2. 专项补充：GitHub Copilot (在IDE中)。用于极其快速的单行或函数补全，减少切换到命令行的心智负担。
3. 代码库知识库：我搭建了一个简单的内部工具，用RAG技术索引了公司所有核心项目的文档和API说明。当Claude Code需要了解某个内部库的用法时，我会先从这里查，再把精准的文档片段喂给它，而不是让它盲目猜测。
4. 传统工具回归：像 jq、grep -r、sed 这些命令行老伙计，在批量处理文本、查找引用时，比让AI来做更直接可靠。用 rg (ripgrep) 进行全局搜索，再把结果喂给AI分析，是省Token的好办法。

人工兜底体现在两个环节：一是 关键决策点，比如采用哪种设计模式、选择哪个第三方库，AI可以给出建议，但最终决定权要掌握在自己手里，基于团队技术栈和项目长期维护性来拍板。二是 最终审查，AI生成的代码，尤其是涉及核心业务逻辑、安全、资金计算的代码，必须经过人工的、细致的逐行审查。我见过AI生成的代码在大部分情况下运行良好，但却在一个边界条件处理上埋了个大坑。

限额策略下，你可能会发现，自己动手写一些简单、重复的代码，或者花时间仔细设计一个清晰的Prompt和任务规划，从总时间成本和结果质量上看，反而比无节制地使用AI更优。这倒逼我们提升自己的设计能力和问题拆解能力，因为你能给AI的指令越清晰，它的回报就越高，你的额度也就花得越值。说到底，最强大的“模型分层”，是我们自己的大脑与AI模型的有机结合。我们负责战略、规划和关键判断，AI负责战术执行和信息处理，这样的协作模式，才能在有限的资源下创造出最大的价值。