第 31 章：效率优化策略
在前两章中，我们探讨了如何写出好的 Prompt 和如何建立高效的人机协作模式。这些是"做对的事"——方向正确、分工合理。而本章要回答的是另一个维度的核心问题：在方向正确的前提下，如何把效率做到极致？
效率优化不是"省几秒钟"的雕虫小技。一个资深 Claude Code 用户和一个初学者的日常产出差距，往往不是 20% 或 30%，而是 2-3 倍甚至更多。这个差距来自四个维度：任务粒度（一次做多少）、上下文管理（如何在有限窗口里效率最大化）、模型选择（花多少钱得到什么质量）、以及并行组织（如何让多个工作流同时推进）。
本章目标：建立 Claude Code 效率优化的完整方法论——掌握任务粒度拆分、上下文预算管理、模型选择经济学、批量与并行策略，以及效率度量和持续迭代的方法。
31.1 任务粒度：一次做多少最合适
任务粒度是效率优化的第一层问题。如果粒度太细，Claude Code 的优势发挥不出来——启动成本（描述需求 + 等待响应 + 审查 Diff）比你自己动手还高。如果粒度太粗，Claude Code 会迷失方向，输出质量下降，审查和修正的成本急剧上升。找到那个"黄金区间"是效率的前提。
粒度的三个区间
先说结论：一个 Prompt 的最佳粒度是 一个清晰目标 + 3-8 个文件的改动。超过 8 个文件容易失控，少于 3 个文件往往不值得启动，不如自己改更快。
┌────────────────────────────────────────────────────────────┐
│ │
│ ❌ 太小： "把这个变量名从 x 改成 userId" │
│ → 浪费时间，自己改 3 秒，Claude 来回 1 分钟 │
│ │
│ ✅ 合适： "重构 src/api/auth.ts，把回调改成 async/await"│
│ → Claude 的优势区间，多个关联文件一致性修改 │
│ │
│ ❌ 太大： "重构整个项目" │
│ → Claude 会迷失，质量下降，审查成本暴增 │
│ │
└────────────────────────────────────────────────────────────┘如何判断粒度过小？
如果你的指令满足以下三个条件中的任意两个，就是粒度过小的信号：
| 信号 | 示例 | 更好的做法 |
|---|---|---|
| 修改范围 ≤ 1 个文件、≤ 5 行 | "把 utils.ts 第 12 行的 const 改成 let" | 手动改，或者把类似的修改合并成批量指令 |
| 不需要 Claude 理解上下文就能完成 | "在这个文件最上面加一行 import React from 'react'" | 编辑器的自动导入功能更快 |
| 审查时间和执行时间都大于手动操作 | 说一句话 5 秒，等响应 10 秒，审查 Diff 10 秒 → 总计 25 秒 vs 手动 5 秒 | 自己动手 |
如何判断粒度过大？
如果出现以下信号，说明你的指令应该被拆分：
| 信号 | 具体表现 |
|---|---|
| 你在不断纠正 Claude | 对话中反复出现"不对，我指的是...""刚才那个不要，改成..." |
| Claude 遗漏了关键要求 | 你列了 8 条要求，Claude 只完成了 5 条，漏掉了 3 条 |
| 审查 Diff 时感到吃力 | 一次改了 15 个文件，你逐文件审查 Diff 花了 20 分钟——比手动改还久 |
| 工具调用出现大量重试 | Claude 反复读取同一个文件，或者反复执行同一个命令——它在困惑 |
拆分大任务的技巧
当你面临一个"太大"的任务时，用以下三种维度中的一种来拆分：
按模块拆分（最常用）：
"重构整个用户系统"
↓ 拆分为
├── 重构 src/models/user.ts（数据层，3 个文件）
├── 重构 src/routes/auth.ts（路由层，2 个文件）
├── 重构 src/pages/Login.tsx + src/pages/Register.tsx（前端，2 个文件）
└── 补充测试（src/__tests__/auth/，3 个文件）按层次拆分（最安全）：
"搭建用户认证功能"
↓ 拆分为
├── 第一步："创建 User 数据模型和数据访问层"（数据层）
├── 第二步："实现注册和登录的 API 路由"（API 层）
├── 第三步："实现前端注册和登录页面"（前端层）
└── 第四步："编写单元测试和集成测试"（测试层）后一步依赖前一步的输出——确保每步验证通过后再进下一步。
按依赖关系拆分（最精确）：
当任务涉及的模块之间有强依赖关系时，按依赖链从上到下拆分。原则是：先改被依赖的基础模块，再改依赖它的上层模块。
"重构 API 调用体系"
↓ 按依赖链拆分
├── 第一步："创建统一的 HTTP 客户端（src/api/client.ts）"
│ → 这一步不依赖任何已有模块，只创建基础设施
├── 第二步："提取 users API 模块，依赖 client.ts"
│ → 依赖第一步创建的 client.ts
├── 第三步："修改所有页面组件，使用新的 API 模块"
│ → 依赖第二步创建的 API 函数拆分后执行的原则：每次对话只完成一个拆分后的子任务。完成一个 → 验证 → Commit → /clear（或 /compact）→ 开始下一个。这个节奏确保每个子任务都在"干净的上下文"和"干净的 Git 状态"中执行。
完整示例：一次典型的拆分
假设你要为现有系统添加"文件上传"功能。如果直接说"帮我添加文件上传功能"，Claude 会需要同时处理文件存储配置、API 路由、前端上传组件、进度展示、错误处理——十几个文件，很容易出错。
正确的拆分：
第一轮对话（数据层 + 配置）：
"在 src/config/upload.ts 中添加文件上传配置（存储路径、大小限制、允许的类型）。
然后在 src/services/storage.ts 中封装文件存储逻辑（写入磁盘、生成访问 URL）。
两个文件，依赖关系是 config → storage。"
验证 → Commit: "feat: 添加文件上传配置和存储服务"
第二轮对话（API 层）：
"基于 storage.ts 的封装，在 src/routes/upload.ts 中创建文件上传 API：
POST /api/upload —— 接收文件、调用 storage 服务、返回文件 URL。
在 src/middleware/upload.ts 中添加 multipart 解析的中间件。
两个新文件，一个修改 src/router.ts 注册路由。"
验证 → Commit: "feat: 添加文件上传 API 路由"
第三轮对话（前端）：
"在 src/components/UploadButton.tsx 中创建文件上传组件：
- 拖拽或点击选择文件
- 上传进度条
- 上传完成后的文件列表展示
- 错误提示
同时在 src/pages/ResourcePage.tsx 中集成这个组件。"
验证 → Commit: "feat: 添加文件上传前端组件"
第四轮对话（测试 + 收尾）：
"为上面实现的文件上传功能编写测试：
- src/__tests__/services/storage.test.ts
- src/__tests__/routes/upload.test.ts
- src/components/__tests__/UploadButton.test.tsx"四轮对话，每轮 2-3 个文件，每轮之间有清晰的边界和验证点。总时间约 40 分钟——比一轮"大而全"的指令（可能 15 分钟得到结果，但审查修正再花 30 分钟）更快、更可靠。
黄金法则：当你犹豫"要不要拆"的时候，做一个快速检查——想象你要手动向一个聪明的同事描述这个任务，如果一句话说不清楚，就拆。一句话能说清楚 = 一个 Prompt。一句话说不清楚 = 多个 Prompt。
31.2 上下文预算管理
任务粒度解决了"一次做多少"的问题，接下来要面对的是另一个硬约束：上下文窗口。不管你的指令多精确，如果上下文满了，Claude Code 就会"失忆"——忘记你之前说过的重要信息、忘记项目约定、甚至忘记当前在做什么。
上下文窗口的本质
把上下文窗口理解为一个固定容量的工作台。在这个工作台上：
- 你的项目文件（通过 Read 工具加载）是"参考材料"
- 对话历史是"工作记录"
- 系统提示和 CLAUDE.md 是"贴在墙上的规则"
- 工具调用的结果（命令输出、Grep 结果）是"笔记"
这些共用同一个容量池。对于 DeepSeek V4 Pro（本书默认模型），这个容量是约 100 万 token（1M）；对于 Claude 模型家族是约 20 万 token。超过这个容量，最早的内容会被截断——就像你在工作台上放了太多东西，最早放的资料被挤掉了。
Token 的实际消耗
/context 命令可以显示当前的 token 消耗分布。典型的长对话 token 分布如下：
┌────────────────────────────────────────────────┐
│ Token 消耗分布（一次 45 分钟的深度协作） │
│ │
│ 系统提示 (System Prompt) ： ~5,000 tokens │
│ CLAUDE.md 项目说明 ： ~2,000 tokens │
│ 已加载的文件内容 ： ~30,000 tokens │
│ 对话历史 ： ~60,000 tokens │
│ 工具调用输出 (各种输出) ： ~20,000 tokens │
│ ───────────────────────────────────────────── │
│ 总计 ： ~117,000 tokens │
│ 窗口上限 (Claude) ： 200,000 tokens │
│ 剩余空间 ： ~83,000 tokens │
│ │
│ 对于 DeepSeek V4 Pro (1M tokens)，剩余空间巨大 │
└────────────────────────────────────────────────┘要注意的是：对话历史是增长最快且最难控制的消耗项。你每对 Claude 说一句话（平均 100 token），Claude 回复一段话（平均 500-1000 token），加上中间的工具调用输出——15 分钟的密集对话就能积累 2-3 万 token。如果使用 Claude 模型（200K 窗口），2 小时后对话历史就占了窗口的 40-60%。
预算分配策略
将上下文窗口视为可分配的预算，有意识地控制各部分的比例：
| 预算项 | 推荐占比 | 内容 |
|---|---|---|
| 核心上下文（CLAUDE.md、关键常量文件） | 30% | 项目架构、编码规范、类型定义等"应该始终在场"的信息 |
| 当前任务上下文（相关文件、近期对话） | 40% | 当前正在修改的文件、最近的讨论方向、未解决的决策 |
| 输出空间（留给 Claude 的生成空间） | 30% | Claude 生成代码、解释、计划的 token 空间 |
30-40-30 的实操指南：
- 核心上下文（30%）：通过 CLAUDE.md 和 Memory 系统固化（详见第 12 章）。不要让对话历史承担"记住项目约定"的职责——这种东西写在文件里，每次通过 CLAUDE.md 自动加载。
- 当前任务上下文（40%）：只加载与当前任务直接相关的文件。不要因为"可能用到"而加载几十个文件——用到的时候 Claude 会自己去 Read。对话历史保持在最近 20 轮以内最理想。
- 输出空间（30%）：确保 Claude 有足够的 token 来生成完整的代码和解释。如果输出空间不足，Claude 的回复会被截断，导致代码不完整或解释中途断开。
上下文即将耗尽的信号
即使有 /context 命令，实际工作中你更可能先感受到以下信号：
| 信号 | 原因 | 应该做什么 |
|---|---|---|
| Claude 重复问题或方案 | 之前的决策从"当前上下文"中被挤掉了 | 立即 /compact |
| Claude 开始做违背之前约定的事 | 它"忘了"你之前说的要求 | /compact 并在提示中强调关键约定 |
| 回复截断或不完整 | 输出空间不足 | 清掉对话历史的前半段 |
| 工具调用明显变多但没进展 | Claude 在反复了解它"应该已经知道"的信息 | /compact 或 /clear 重来 |
| 回答质量下降（方案变浅、遗漏细节） | 整个上下文过度拥挤 | 果断 /clear 重来 |
/compact 的正确使用
/compact 会分析当前对话，保留关键决策和信息，丢弃冗余的中间步骤。但它的效果很大程度上取决于你的引导：
# ❌ 简单的 compact——让 Claude 自己判断保留什么
/compact
# ✅ 带引导的 compact——告诉 Claude 什么是重要的
/compact 只保留以下信息：
- 项目使用 React 18 + TypeScript 5
- API 响应格式统一为 { code, data, message }
- 用户认证模块已完成，不要重复修改
- 当前正在重构的文件列表及进度
其余所有中间讨论、已完成的步骤、不相关的对话都可以舍弃。什么时候用 /compact vs 什么时候用 /clear：
| 场景 | 使用 |
|---|---|
| 对话中有重要的决策和结论，需要保留 | /compact |
| 任务完全变了，之前的对话与当前无关 | /clear |
| 对话很长但 Claude 表现还好 | 暂时不需要操作 |
| Claude 开始"忘记"重要信息 | 立即 /compact |
| Claude 在错误方向上越走越远 | /clear，拒绝这次对话中未提交的改动 |
DeepSeek V4 Pro 的 1M 上下文优势
对于使用 DeepSeek V4 Pro 的读者（本书的默认推荐配置），1M token 的上下文窗口意味着：
- 更宽松的预算：不需要像在 Claude 200K 窗口中那样精打细算。你可以在一次对话中加载更多文件、保留更长的对话历史。
- 更少的中断：很少需要
/compact。在一次对话中完成更大的任务（如完整实现一个功能模块的全部代码）而不担心上下文不够。 - 更好的长文本处理：可以一次加载完整的 API 文档、数据库 schema、甚至多个完整文件，而不需要"分批加载、分批处理"。
但要注意：上下文大不等于不需要管理。即使在 1M 窗口下，不相关的信息挤占空间仍然会降低 Claude 的注意力质量——类似你在一个堆满资料的桌子上工作，虽然桌子够大，但杂乱的资料仍然干扰思考。
使用 1M 上下文的建议：
- 不需要过度压缩，但保持对话围绕核心任务
- 完成一个大阶段后，还是建议
/clear开启新对话——干净的上下文 > 满的上下文 - 如果发现 Claude 的回复质量下降，即使上下文只用了 30%（30 万 token），也尝试
/compact
上下文管理的本质：不是为了省钱（token 不贵），而是为了保证 Claude 的"注意力质量"。一个干净的上下文，就像一张整洁的桌子——你能立刻找到需要的工具和资料，不会被不相关的杂物干扰。
31.3 模型选择经济学（成本 vs 质量）
效率不只是速度——还包括投入产出比。同样的任务，选择正确的模型可以让你省下 60-70% 的费用而不牺牲质量（或者相反，在关键任务上用更贵的模型换取更可靠的结果）。
模型成本速查
以下是本书涉及的四个核心模型的基本对比（以 2026 年 5 月为参考）：
| 特性 | DeepSeek V4 Flash | DeepSeek V4 Pro | Claude Haiku 4.5 | Claude Sonnet 4.6 | Claude Opus 4.7 |
|---|---|---|---|---|---|
| 上下文窗口 | 1M tokens | 1M tokens | 200K tokens | 200K tokens | 200K tokens |
| 推理能力 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 速度 | 极快 | 快 | 极快 | 快 | 中 |
| 成本级别 | ¥ | ¥¥ | ¥ | ¥¥¥ | ¥¥¥¥ |
| 单次对话成本 (约) | 0.01-0.05 元 | 0.05-0.3 元 | 0.01-0.03 元 | 0.1-1 元 | 0.5-5 元 |
| 适合的复杂度 | 低-中 | 低-高 | 低 | 中-高 | 高 |
成本说明：以上为典型的一次中等复杂度的对话（15-30 轮）的估算，实际费用取决于 token 消耗量、模型定价策略的变化和 API 提供商的定价。DeepSeek V4 系列的成本约为同级别 Claude 模型的 1/10 到 1/5。
任务-模型映射：什么时候用什么
不是所有任务都需要"最强模型"。以下映射表是基于实际使用经验的推荐：
| 任务类型 | 推荐模型 | 成本级别 | 理由 |
|---|---|---|---|
| 简单问答、代码解释 | V4 Flash / Haiku | ¥ | 只需要理解代码，不需要深度推理 |
| 添加注释、格式化 | V4 Flash | ¥ | 规则明确，不需要推理 |
| 日常编码、中小规模重构 | V4 Flash / V4 Pro | ¥¥ | 性价比最优区间 |
| 多文件协调修改（3-8 个文件） | V4 Pro / Sonnet | ¥¥ | 需要保持跨文件的一致性 |
| 复杂架构设计、多方案对比 | V4 Pro / Opus | ¥¥¥ | 需要深度推理和权衡 |
| 调试棘手 Bug（无明显线索） | V4 Pro / Opus | ¥¥¥ | 需要多条线索交叉推理 |
| 安全审计、关键业务代码 | Opus | ¥¥¥¥ | 错误代价高，值得投入最强模型 |
| 批量生成文档、测试用例 | V4 Flash | ¥ | 量大但单次推理简单 |
| 代码审查（全面扫描） | V4 Pro | ¥¥ | 需要覆盖多种问题类型 |
| Code Review（深度审查） | Opus / V4 Pro | ¥¥¥ | 需要发现隐蔽问题 |
混合策略：不要只用一个模型
经验表明，最经济的策略是 90% V4 Flash + 10% V4 Pro/Opus：
日常开发节奏：
上午 09:00 → V4 Flash → 处理 5 个常规任务（代码解释、小重构、添加测试）
成本：约 0.1 元
下午 14:00 → V4 Pro → 处理 1 个复杂任务（架构重构、跨模块协调）
成本：约 0.2 元
紧急 Bug → V4 Pro / Opus → 深度推理调试
成本：约 0.3 元
一天总计约 0.6 元，一个月约 15-20 元对比：如果所有任务都用 Opus，一天的成本可能是 5-20 元，一个月 150-600 元——差别是 10-30 倍。
实用切换规则：
规则 1（默认规则）：日常任务用 V4 Flash（或 Haiku）
规则 2（升级规则）：遇到以下情况立即切 V4 Pro（或 Sonnet/Opus）：
- Claude 连续两次尝试都没解决问题
- 任务涉及 5 个以上文件的协调修改
- 需要做架构层面的决策或方案对比
- 代码的正确性要求极高（认证、支付、数据完整性）
规则 3（降级规则）：批量任务用 V4 Flash：
- 生成 50 个单元测试
- 为 20 个文件添加类型标注
- 生成 API 文档
（量大、规则明确、单个推理简单的任务）批量策略：Flash 做初稿，Pro 做终审
对于质量要求高的批量任务，使用"两阶段法"：
第一阶段（V4 Flash，低成本）：
目标：批量生成初稿
例如："为 src/api/ 下的所有 15 个模块添加完整的 JSDoc 注释"
产出：15 个文件，每个都有了注释（但质量可能参差不齐）
第二阶段（V4 Pro，高质量审查）：
目标：审查和修正
例如："审查 src/api/ 下所有文件的 JSDoc 注释：检查参数类型是否准确、
返回值描述是否正确、是否有遗漏的关键说明。逐个文件给出修正。"
产出：修正后的一致高质量注释两阶段总成本约 0.5 元，但如果全程用 V4 Pro 则可能花费 2-3 元。对于一次性的批量任务差别不大，但如果你每周做 5 次批量操作——一个月下来能省 30-50 元。
个人开发者月度预算建议
根据使用强度，给出三个档次的预算参考：
| 使用强度 | 月任务量 | 推荐配置 | 月费用（约） |
|---|---|---|---|
| 轻度（业余项目、偶尔使用） | 30-50 次对话 | V4 Flash 为主 | 5-10 元 |
| 中度（日常开发辅助） | 100-200 次对话 | V4 Flash 90% + V4 Pro 10% | 15-30 元 |
| 重度（全栈开发、多项目管理） | 300-500 次对话 | V4 Flash 80% + V4 Pro 15% + Opus 5% | 40-80 元 |
成本 vs 时间思考：一个思维练习——如果你用 V4 Pro（0.3 元/次）替代 V4 Flash（0.05 元/次）处理一个任务，多花了 0.25 元，但节省了 15 分钟的反复纠正和重试时间。假设你为自己定的时薪是 100 元，15 分钟 = 25 元。省了 24.75 元。在关键任务上，贵的模型往往更便宜——因为它减少了你审查、纠正、重试的时间。
模型选择的三个原则
默认从便宜的模型开始：大部分任务的复杂度不需要最强模型。用 V4 Flash 试试——如果一次通过，省了钱；如果需要第二次尝试，再考虑切 V4 Pro。
错误成本决定模型投入：如果这个任务失败了会导致什么后果？如果是"少了一个注释"——无所谓，用 Flash。如果是"用户的支付数据可能出错"——无论花多少 token 都值得最强的 Opus。
复杂度和文件数成正比时升级模型：当一个任务涉及 5 个以上文件的协调修改时，模型需要在改文件 A 时记住文件 B 中的细节——这需要更强的推理能力。触及这个阈值时，切 V4 Pro 或以上。
31.4 批量任务策略
效率优化的第三个维度是批量思维：不要把可以合并的事情拆成多次对话。每次开启新对话都有"冷启动成本"——Claude 需要重新加载项目文件、理解任务背景、建立工作状态。把同类的、共享上下文的任务放在一起批量处理，能显著减少这种重复成本。
上下文复用：Prepare Once, Ask Many
在一个对话中完成一组相关的多个操作，而不是为每个操作开启新对话：
# ❌ 三次独立的对话——每次都重新加载、重新理解
对话 1："给 User.ts 中的 5 个函数添加 JSDoc 注释"
对话 2："给 Post.ts 中的 8 个函数添加 JSDoc 注释"
对话 3："给 Comment.ts 中的 6 个函数添加 JSDoc 注释"
# ✅ 一次对话、批量处理——加载一次，理解一次，连续执行
对话："在理解 src/models/ 结构的基础上，请依次为以下文件的所有公开函数添加 JSDoc：
1. src/models/User.ts
2. src/models/Post.ts
3. src/models/Comment.ts
每个文件完成后 pause，等我确认再继续下一个。"三个文件共享同一个模型类结构（field → type → validation），Claude 在第一个文件中建立的"理解"可以直接复用到后两个文件。如果在三个独立对话中，Claude 每次都重新推断项目的类型约定和命名规范——不仅慢，而且可能出现不一致。
流水线（Pipeline）模式：Q1 输出 → Q2 输入
当一个任务的输出是下一个任务的输入时，在同一次对话中串联执行：
"请为 src/api/users.ts 梳理所有 API 接口（函数名 + 参数 + 返回值）。
然后基于整理出的接口列表，为每个接口编写单元测试。"
Claude 的执行流程：
1. [Read] 读取 users.ts
2. 梳理出 5 个接口的完整签名
3. 基于签名为每个接口设计测试用例
4. [Write] 创建 users.test.ts在同一个对话中，Claude 对 API 接口的理解是"新鲜"的——不需要第二次加载和重新理解。通过 /compact 在中间步骤压缩已经被使用过的上下文，为后续步骤腾出空间。
更复杂的流水线示例：
"实现用户搜索功能，分三个步骤：
Step 1: 在 src/api/search.ts 中创建搜索 API 接口（接收 query + filters，返回分页结果）
Step 2: 在 src/hooks/useSearch.ts 中封装搜索 Hook（管理 loading/error/results 状态）
Step 3: 在 src/components/SearchBar.tsx 中实现搜索组件（输入框 + 下拉结果）
每个 Step 完成后告诉我结果，经我确认再执行下一步。"后台任务：长操作的异步处理
某些操作（如对整个代码库的全面分析、大量文件的批量修改）可能需要较长时间执行。这时可以使用后台任务让 Claude 在后台工作，你继续做其他事情：
# 让 Claude 在后台分析整个项目
"启动后台任务：扫描 src/ 下的所有 .ts 文件，分析每个文件的复杂度（行数、函数数、依赖数），
输出一个按复杂度排序的列表，标注出复杂度最高的 10 个文件。
结果保存为 src/docs/complexity-report.md。"
# 或者使用 /loop 定时检查
"/loop 2m /tasks" # 每 2 分钟查看一次后台任务的状态关于后台任务和 /loop 命令的详细用法，见第 19 章：命令系统进阶。
并行 Agent 调度 vs 顺序执行
当你有多个互不依赖的子任务时，使用并行 Agent 分发（Subagent Dispatch）可以在等待一个 Agent 完成的同时让另一个 Agent 开始工作：
顺序执行（三次等待）：
Agent 处理 Auth 模块 ────→ 等待结果
Agent 处理 DB 模块 ────→ 等待结果
Agent 处理 UI 模块 ────→ 完成
并行分发（一次等待）：
Agent 1 ──→ 处理 Auth 模块 ──┐
Agent 2 ──→ 处理 DB 模块 ──┼──→ 汇总审查 → 完成
Agent 3 ──→ 处理 UI 模块 ──┘并行分发的前提条件：
- 三个子任务互不修改相同的文件（否则产生冲突）
- 三个子任务没有逻辑依赖（Auth 不依赖 DB、DB 不依赖 UI）
- 你有能力同时审查三个 Agent 的输出
如果子任务之间有依赖（如 DB 模块被 Auth 和 UI 依赖），那必须先完成 DB 模块，否则后续任务可能基于错误的基础。
并行代理调度的详细用法和配置见第 32 章：高级工作流。
批量选择的决策框架
| 场景 | 策略 | 效率提升 |
|---|---|---|
| 3 个独立模块的同类操作 | 一次对话串行完成 | 30-40%（省去两次冷启动） |
| 有依赖关系的多步操作 | 一次对话流水线完成 | 40-50%（省去重新加载上下文） |
| 3 个真正独立的子任务 | 并行 Agent 分发 | 60-70%（三个 Agent 同时工作） |
| 大量文件的同类操作 | 后台任务 | 不占用你的注意力时间 |
核心原则：能复用上下文就不要新建对话，能并行就不要串行，能后台就不要前台等待。但前提是子任务之间没有隐式依赖——如果存在依赖而你误判为独立，并行执行的结果可能互相矛盾。
31.5 并行工作流的组织
并行工作流是效率提升的顶级玩法——不仅是让 Claude Code 并行工作，更是让你自己管理多个并行的开发流。这是从"一个人用 AI 辅助工作"到"一个人管理多个 AI 工作流"的跨越。
多会话并行：一个开发者、三个工作流
在日常开发中，经常会同时面对多个独立的工作线。例如：
当前需要做的事情：
1. Feature A：继续开发用户导出功能（前端 + API）
2. Feature B：修复一个紧急的生产 Bug（登录超时）
3. Code Review：审查同事提交的 PR #234
传统的做法：串行完成——先修 Bug（紧急），再开发 Feature A，最后 Review PR。
→ 上下文频繁切换，效率低
多会话并行的做法：
会话 1：Feature A 的开发
会话 2：Bug 修复
会话 3：PR Review
→ 三个会话各保持独立的上下文，互不干扰在 VSCode 扩展中，每个会话有独立的对话历史和文件上下文。切换任务时，切换到对应的会话——不需要回忆"这个 Bug 我们上一次讨论到哪了？"——所有上下文完好保存。
多会话的组织建议：
| 会话 | 命名 | 使用频率 |
|---|---|---|
| 主开发会话 | "Feature: 用户导出功能" | 每天 8-10 次 |
| 紧急修复会话 | "Hotfix: 登录超时 Bug #342" | 需要时随时切换 |
| 代码审查会话 | "Review: PR #234" | 每天 2-3 次 |
| 学习/探索会话 | "Exploration: 尝试新架构方案" | 每周 2-3 次 |
| 通用助手 | "General: 日常问答" | 每天多次 |
命名会话：不要保留 "Session 1" 这种默认名。好的命名让你在会话列表中一眼就能找到目标——尤其是在 10 个并发会话中。
Git Worktree 隔离并行开发
当多个工作流涉及修改相同的文件时，多会话会互相干扰——一个会话改动了一个文件，另一个会话也在同一个文件上做了不同的修改。Git Worktree 是解决这个问题的标准方案：
# 主项目工作在 main 分支
git worktree add ../project-feature-a feature/user-export
git worktree add ../project-hotfix feature/fix-login-timeout
# 目录结构：
# ~/project/ → 主项目（不动，或做小型日常修改）
# ~/project-feature-a/ → Feature A 的隔离开发环境
# ~/project-hotfix/ → Hotfix 的隔离开发环境每个 Worktree 有独立的文件系统和 .git，但在同一个仓库下（共享提交历史、分支）。在 Worktree A 中让 Claude Code 重构 15 个文件，切换回主项目时你是干净的——没有未提交的变更污染工作区。
何时使用 Worktree：
| 场景 | 是否需要 Worktree |
|---|---|
| 两个独立的新功能互不修改相同的文件 | 不需要，多会话+同目录即可 |
| 两个功能会修改重叠的文件 | 需要 Worktree 隔离 |
| 大规模重构可能破坏项目 | 必须 Worktree 隔离 |
| 想在不稳定的分支上试验 | 必须 Worktree 隔离 |
| Code Review 不需要修改代码 | 不需要 |
Claude Code 的 Worktree 模式通过 /worktree 或相关工具自动管理（详见第 32 章和 第 22 章中关于 Worktree 回退的讨论）。
Subagent 分发：一个人同时推进多个方向
Subagent 是 Claude Code 内置的并行工具——在一个对话中向多个子 Agent 分发独立的任务，等待它们分别完成后汇总结果。
场景：要为新项目搭建完整的目录结构和基础设施
主对话中的指令：
"请使用 Subagent 并行搭建以下模块，每个 Subagent 独立工作：
Subagent 1: 搭建后端项目骨架
- 初始化 Express.js 项目
- 创建 src/routes/、src/models/、src/middleware/ 目录结构
- 配置 TypeScript、ESLint
- 添加基础的 app.ts 入口文件
Subagent 2: 搭建前端项目骨架
- 初始化 React + Vite 项目
- 创建 src/pages/、src/components/、src/hooks/ 目录结构
- 配置路由（react-router）
- 添加基础的 App.tsx
Subagent 3: 搭建数据库和配置
- 创建 database schema 文件（SQL）
- 配置环境变量模板（.env.example）
- 创建 Docker Compose 配置
三个 Subagent 完成后，汇总结果并输出项目初始化报告。"Subagent 分发的核心价值：
- 并行速度：三个 Agent 同时工作，总等待时间是单个 Agent 的 1/3
- 上下文隔离：每个 Subagent 有独立的上下文，不会互相干扰
- 质量一致性：由主对话统一审查三个输出，确保风格和约定一致
Subagent 的适用条件：
- 子任务之间互不依赖、互不修改相同的文件（和并行分发一样的约束）
- 每个子任务有清晰的独立输出（如"创建一个目录结构"、"生成一个配置文件"）
- 你的需求描述足够精确，每个 Subagent 能独立理解要做什么（不需要主对话在中间纠正）
更详细的 Subagent 使用指南和编排策略见第 32 章：高级工作流。
并行工作流的完整示例
以一个全栈功能为例，展示如何组织并行工作流：
项目：为博客系统添加"评论"功能
并行组织方案（4 个并发工作流）：
┌─────────────────────────────────────────────────────┐
│ │
│ Worktree 1（后端 API） │
│ 分支：feature/comment-api │
│ 会话 1：实现 Comment 数据模型 + API 路由 │
│ (src/models/Comment.ts, │
│ src/routes/comment.ts, │
│ src/middleware/auth.ts 更新) │
│ 负责人：你 + Claude Code (V4 Pro) │
│ │
│ Worktree 2（前端组件） │
│ 分支：feature/comment-ui │
│ 会话 2：实现评论前端组件 │
│ (src/components/Comment/*, │
│ src/pages/Post.tsx 集成) │
│ 负责人：Subagent A (V4 Flash) │
│ │
│ Worktree 3（测试） │
│ 分支：feature/comment-tests │
│ 会话 3：编写评论功能的测试 │
│ (src/__tests__/models/Comment.test.ts, │
│ src/__tests__/routes/comment.test.ts, │
│ src/__tests__/components/Comment.test.tsx) │
│ 负责人：Subagent B (V4 Flash) │
│ │
│ 主会话（编排和审查） │
│ 会话 4：协调进度、审查输出、合并 │
│ 负责人：你 │
│ │
└─────────────────────────────────────────────────────┘
执行顺序：
Day 1 上午：Worktree 1 完成后端 API（2 小时）
Day 1 下午：Worktree 2 和 Worktree 3 并行启动（分别 1.5 小时）
Day 1 傍晚：合并三个分支，解决冲突，集成测试（1 小时）
总计：4.5 小时完成全栈功能（对比串行方式 8-10 小时）这个工作流的效率提升源自三个并行层：
- Worktree 隔离：三个方向的代码修改互不干扰，可以同时进行
- Subagent 分发：前端和测试部分委托给 Subagent，你不必亲自跟踪每个文件
- 你的角色转换：从"自己写代码"变成"编排工作流 + 审查输出"——你同时管理三个工作线，但实际"动手"的部分只有后端 API
31.6 效率度量
效率优化如果没有度量，就变成了"感觉上快了"的主观判断。建立简单的度量体系，你才能知道哪些优化真正有效，哪些只是心理安慰。
度量什么：四个核心指标
| 维度 | 度量指标 | 如何记录 |
|---|---|---|
| 速度 | 单个任务从"提出需求"到"验证通过"的时间 | 简单计时（开始 → 完成） |
| 质量 | 产出中需要你亲自修正的次数和程度 | "0 修改接受" vs "改了 3 处" vs "重写了大半" |
| 决策质量 | Claude 的方案有多少次你选择调整方向 | "照单全收" vs "方向对但细节改" vs "方向错了重来" |
| 学习 | 你是否学到了新东西（新的模式、新的思路） | 每周回顾时记录 1-3 个学到的东西 |
每日检查（2 分钟）
每天结束时快速记录：
今天完成了 __ 个任务（使用 Claude Code 辅助）
其中：
- __ 个任务一次通过（无需修正）
- __ 个任务有小改（改了几个文件的部分逻辑）
- __ 个任务有大改（重写了大部分）
- __ 个任务 Claude 无法完成（你手动接手）
感觉今天最顺畅的时刻：_______
感觉今天最卡顿的时刻：_______
明天想尝试不同的：_______每周回顾（15 分钟）
基于每日检查的数据，每周做一次回顾：
本周数据汇总：
- 完成任务：__ 个
- 一次通过率：__%
- 平均任务粒度：__ 个文件/任务
- 使用的模型分布：V4 Flash __ 次 / V4 Pro __ 次 / Opus __ 次
- 估计总费用：__ 元
反思：
1. 哪个任务特别适合让 Claude 做？（记录下来作为模板）
2. 哪个任务特别不适合？（记录下来，以后手动处理或改变策略）
3. 任务粒度是否在"黄金区间"（3-8 个文件）？是否需要调整拆分策略？
4. 模型选择是否合理？有没有"过度使用 Opus"或"该用 V4 Pro 却用了 Flash"的情况？
下周行动：
1. ___
2. ___
3. ___效率提升的迭代循环
度量 → 发现问题 → 调整策略 → 再度量 → 确认改善（或再调整）
示例迭代：
第 1 周：度量发现"一次通过率"只有 40%（太低了）
→ 分析原因：任务粒度过大（平均 10 个文件/任务）
→ 调整策略：严格控制在 5 个文件以内
第 2 周："一次通过率"提升到 65%
→ 继续调整：发现 V4 Flash 处理复杂重构时的一次通过率低
→ 调整策略：3 个文件以上的重构自动切 V4 Pro
第 4 周："一次通过率"达到 80%，平均任务时间从 15 分钟降到 8 分钟关键不是每周都有巨大的突破，而是持续地发现问题并调整。一个月后回顾，你会发现自己的使用效率相比第一个月有 2-3 倍的提升。
分享你的经验
效率优化是一个社区驱动的过程。你发现的"一个技巧让你效率提升了 30%"——对其他用户可能是从未想过的突破点。反之亦然。
与团队或社区分享：
- 你的任务拆分模板（"这样拆最有效"）
- 你的模型选择经验（"这种任务用 V4 Flash 就够了"）
- 你的度量数据（"这周一次通过率提升了 10%，因为..."）
这些分享不仅帮助别人，也帮助你整理和沉淀自己的经验。Claude Code 的用户社区（GitHub Discussions、Discord 频道等）是分享和获取经验的好地方。
31.7 本章小结
本章是第六篇"方法论篇"的最后一章，建立了 Claude Code 效率优化的完整框架。效率不是靠"按得更快"，而是靠五个维度的系统优化：
任务粒度：找到"黄金区间"——一个 Prompt 一个清晰目标，3-8 个文件的改动。太少浪费启动成本，太多 Claude 迷失方向。大任务按模块、按层次、按依赖关系拆分。
上下文预算管理：将上下文窗口视为可分配的资源，用 30-40-30 预算策略控制各部分的比例。识别上下文即将耗尽的信号（重复问题、忘记约定、回复截断），在正确时机使用
/compact或/clear。DeepSeek V4 Pro 的 1M 上下文是巨大优势，但大窗口不等于不需要管理。模型选择经济学：90% 日常任务用 V4 Flash（低成本快速），10% 复杂任务用 V4 Pro / Opus（高质量确保）。在批量任务中采用"Flash 做初稿，Pro 做终审"的两阶段策略。记住核心原则：默认从便宜的模型开始，但错误成本高时毫不犹豫切最强模型——贵的模型往往更便宜，因为它减少了你的纠正时间。
批量任务策略：共享上下文的任务放在一次对话中完成（冷启动成本的节省）；有依赖关系的任务用流水线模式串联（前一步的输出作为后一步的输入）；真正独立的子任务用并行 Agent 分发（同时推进多个方向）。
并行工作流组织：多会话保持不同任务线的独立上下文；Git Worktree 在需要隔离文件系统时防止冲突；Subagent 分发让你同时管理多个工作线而不必亲自跟踪每个文件。
效率度量：记录速度（任务时间）、质量（一次通过率）、决策质量（方案采纳率）、学习（每周收获）。通过每周回顾识别问题、调整策略、在下周验证改进。效率优化的本质是一个持续迭代的反馈循环。
从方法论篇到精通篇
本章是方法论篇的收官。回顾方法论篇的完整脉络：
- 第 28 章：Prompt 工程 — 如何写出精确、高效的指令
- 第 29 章：让 AI 理解你的项目 — 如何设计 AI 友好的项目结构
- 第 30 章：人机协作模式 — 建立与 AI 的高效分工和信任
- 第 31 章（本章）：效率优化策略 — 在正确方向上把效率做到极致
这四章构建了 AI 编程方法论的完整框架：说清楚（Prompt）→ 准备好（项目结构）→ 配合好（人机协作）→ 做到位（效率优化）。掌握了这四层，你已经不是"使用 Claude Code"——你已经建立了一套以 Claude Code 为核心的、可度量、可优化的开发工作流。
下一步：第七篇"精通篇"将带你进入 Claude Code 的高级工作流——多 Agent 编排、自定义扩展开发、团队推广策略、模型深度对比和前沿趋势探索。这些是少数 Claude Code 专家用户掌握的领域——也是真正的生产力飞跃的起点。
章节小结：本章建立了 Claude Code 效率优化的完整方法论，涵盖任务粒度拆分、上下文预算管理、模型选择经济学、批量与并行策略、以及效率度量和持续迭代。核心思想是：效率不是碰运气，而是有意识地管理每个维度的投入产出比——拆对粒度、管好上下文、选对模型、组好工作流、记好数据。这五者的协同效应，远比任何单一技巧的改进更大。