第 32 章：高级工作流

第 31 章结束时我们说过：掌握了效率优化的四个维度，你已经建立了一套以 Claude Code 为核心的、可度量、可优化的开发工作流。但"可优化"不等于"已优化到极致"。

本章是第七篇"精通篇"的开篇。精通和熟练的区别在于：熟练的用户能把单个任务跑通；精通的用户能把一组任务编排起来，让多个工作流在隔离环境中并行推进，用自动化消除重复劳动，用 Plan 模式把"边想边做"变成"先谋后动"，甚至让 Claude Code 在自己离开工位时继续工作。

这些高级工作流不是少数人的"黑魔法"——它们都是 Claude Code 内置的能力。你只需要知道它们存在、知道在什么场景下该用哪个、知道怎么组合它们，就能从"一个人 + 一个 AI 助手"的线性工作模式，进化到"一个人 + 一个 AI 团队"的并行工作模式。

本章目标：掌握 Claude Code 六种高级工作流——Subagent 并行分发、Plan 模式分阶段开发、多会话并行、Git Worktree 隔离、Cron 定时自动化、Workflow 编排——并能在真实项目中根据场景选择和组合它们，构建属于自己的高效工作流体系。

32.1 多 Agent 协作（Subagent）

在效率优化那一章，我们提到过 Subagent 是并行策略的重要工具。但那只是"用起来"的层面。要真正精通 Subagent，你需要理解它的内部机制、知道什么时候该用什么时候不该用、以及如何编排多个 Subagent 协同完成复杂任务。

什么是 Subagent

Subagent 是 Claude Code 的一种内置机制：主会话（你与 Claude Code 的对话）可以在需要时 spawn 出独立的子 Agent，每个子 Agent 拥有独立的上下文窗口和工具权限，去执行一个独立的子任务。完成后，子 Agent 将结果返回给主会话，主会话汇总并继续。

┌─────────────────────────────────────────────────────┐
│                    主会话 (Main Session)              │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐│
│  │  Subagent 1  │  │  Subagent 2  │  │  Subagent 3  ││
│  │              │  │              │  │              ││
│  │ 独立上下文    │  │ 独立上下文    │  │ 独立上下文    ││
│  │ 独立工具权限  │  │ 独立工具权限  │  │ 独立工具权限  ││
│  │ 独立执行      │  │ 独立执行      │  │ 独立执行      ││
│  │              │  │              │  │              ││
│  │ 任务 A       │  │ 任务 B       │  │ 任务 C       ││
│  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘│
│         │                 │                 │         │
│         └─────────────────┴─────────────────┘         │
│                           │                           │
│                    汇总结果，继续主任务                  │
└─────────────────────────────────────────────────────┘

关键特征：

• 上下文隔离：每个 Subagent 有独立的上下文窗口，不会"污染"主会话的上下文。一个 Subagent 读取了 50 个文件，不会占用你主会话的 token 预算。
• 并行执行：多个 Subagent 可以同时运行，总等待时间等于最慢的那个。
• 单向通信：Subagent 执行完毕后将结果返回给主会话，但 Subagent 之间不能直接通信，也不能把中间状态共享给其他 Subagent。

什么时候该用 Subagent

Subagent 不是"越多越好"。它最适合以下三种场景：

场景一：真正独立的并行任务

三个子任务互不依赖、不修改相同的文件、不需要共享中间状态。

✅ 适合 Subagent：
  "请用 Subagent 并行处理：
   1. 重构 src/utils/format.ts（独立工具函数）
   2. 补充 src/components/Button/ 的单元测试（独立组件）
   3. 更新 README.md 中的 API 文档（独立文档）"

❌ 不适合 Subagent：
  "请用 Subagent 并行处理：
   1. 创建 User 数据模型
   2. 基于 User 模型创建 API 路由
   3. 基于 API 路由创建前端页面"
  → 2 依赖 1，3 依赖 2，无法并行。用串行流水线。

场景二：大量独立的信息收集

当你需要同时探查代码库的多个方面，每个探查互不依赖。

"请用 Subagent 并行探查以下信息：
 1. 找出所有使用 deprecated API 的地方（Subagent: 代码扫描）
 2. 分析 package.json 中所有过期依赖的最新版本（Subagent: 依赖分析）
 3. 统计各模块的测试覆盖率（Subagent: 覆盖率统计）"

场景三：多视角交叉验证

同一个问题，从多个角度独立分析，然后汇总对比。

"请用 3 个 Subagent 独立审查 src/api/auth.ts 的安全性：
 1. Subagent 1：从 OWASP Top 10 角度审查
 2. Subagent 2：从数据流和输入验证角度审查
 3. Subagent 3：从依赖库已知漏洞角度审查
 汇总三个审查结果，标出共同发现的问题。"

如何触发 Subagent

Claude Code 会在以下情况自动决定使用 Subagent：

• 你要求同时做多件独立的事情（"同时..."、"一并..."）
• 需要大规模代码搜索，而搜索任务可以被分解为多个独立方向
• 需要多个独立视角的分析

你也可以明确指令：

"用 Subagent 并行处理以下三个任务："
"请启动一个 Subagent 专门负责代码搜索，另一个负责实现"
"对这个文件做安全审查，用两个 Subagent 从不同角度独立分析"

Subagent 的隔离机制详解

理解隔离机制对于高效使用 Subagent 至关重要。

上下文隔离：

• 每个 Subagent 的上下文窗口从零开始（只有系统提示和你的子任务描述）
• Subagent 不会"看到"你主会话中的对话历史
• Subagent 不会"看到"主会话中已加载的文件内容
• 这意味着：你必须在子任务描述中提供足够的上下文信息，不能假设 Subagent "知道"什么

错误的子任务描述（假设 Subagent 已知上下文）：

"重构这个文件" ← Subagent 不知道是哪个文件、为什么重构

正确的子任务描述（自包含的上下文）：

"重构 src/utils/format.ts 中的日期格式化函数。
 当前问题：使用 moment.js（已废弃），需要迁移到 date-fns。
 项目使用 TypeScript 严格模式，禁止使用 any。
 完成后运行 pnpm test -- src/utils/__tests__/format.test.ts 验证。"

文件系统共享：

• Subagent 和主会话操作的是同一个文件系统
• 如果两个 Subagent 同时修改同一个文件，会产生冲突
• 因此：分发任务时必须确保文件集不重叠

工具权限：

• Subagent 继承主会话的工具权限配置
• 如果主会话被允许执行 git commit，Subagent 也可以
• 对于高风险任务，考虑在子任务描述中加入"只读操作"的约束

Subagent 的类型

Claude Code 支持多种专用 Subagent 类型：

类型	用途	典型指令
Explore	代码库探索和信息收集	"用 Explore Agent 找出所有认证相关的代码"
Plan	制定详细执行计划	"用 Plan Agent 为这个重构任务制定分步计划"
General-purpose	通用代码生成和修改（默认）	"用 Subagent 重构 auth 模块"
Code Reviewer	代码审查	"用 Review Agent 审查 src/api/ 下的所有文件"

不同类型的 Subagent 拥有不同的系统提示和工具配置。Explore Agent 擅长搜索和导航但不擅长修改代码；Plan Agent 擅长分析和规划但不擅长执行。为任务选择正确的 Agent 类型是一步重要的效率优化。

Subagent 编排实战

以下是一个完整的 Subagent 编排示例——为新项目搭建完整的基础设施：

主会话指令：

"我需要为新项目 'TaskFlow' 搭建基础设施。请使用 Subagent 并行执行以下任务：

Subagent 1（后端骨架）：
  在当前目录创建 backend/ 子目录，初始化 Node.js + TypeScript 项目。
  包含以下文件：
  - backend/package.json（依赖：express, typescript, @types/express）
  - backend/tsconfig.json（strict 模式，target ES2022）
  - backend/src/index.ts（基础 Express 服务器，端口 3000）
  - backend/src/routes/health.ts（/health 端点返回 { status: 'ok' }）
  - backend/.env.example（PORT=3000, NODE_ENV=development）

Subagent 2（前端骨架）：
  在当前目录创建 frontend/ 子目录，使用 Vite + React + TypeScript。
  包含以下文件：
  - frontend/package.json（依赖：react, react-dom, vite, typescript）
  - frontend/vite.config.ts（代理 /api 到 localhost:3000）
  - frontend/src/App.tsx（基础页面，显示 'TaskFlow' 标题）
  - frontend/src/main.tsx（ReactDOM 入口）
  - frontend/index.html

Subagent 3（数据库和配置）：
  在当前目录创建以下文件：
  - docker-compose.yml（PostgreSQL 16 + Redis 7 服务）
  - database/schema.sql（users 表和 tasks 表的建表语句）
  - .gitignore（忽略 node_modules, dist, .env, *.log）
  - README.md（项目简介、启动步骤、技术栈说明）

三个 Subagent 完成后，请检查各子目录的完整性，输出项目初始化报告。"

预期结果：3 个 Subagent 并行运行，约 2-3 分钟完成全部搭建。
如果串行执行，至少需要 6-9 分钟。

Subagent 的局限与应对

了解 Subagent 能做什么，也要清楚它不能做什么：

局限	说明	应对策略
不共享上下文	Subagent 之间不能直接传递信息	由主会话在汇总阶段传递关键信息
不能实时交互	Subagent 执行期间不能向你提问	子任务描述必须足够清晰和自包含
不能跨 Agent 锁定文件	两个 Subagent 可能同时修改同一文件	严格检查文件集不重叠
错误传播	一个 Subagent 失败不影响其他，但你需要事后发现	主会话必须检查每个 Subagent 的返回状态
费用叠加	多个 Subagent 同时运行 = 多个 token 消耗并行发生	对于低成本任务（如单纯搜索），Flash 模型是更好的选择

核心原则：Subagent 的价值 = 并行速度提升 - 上下文切换和汇总的成本。当并行任务超过 3 个，且每个任务需要 5 分钟以上的工作时，Subagent 的净收益最大。

32.2 Plan 模式驱动的分阶段开发

如果说 Subagent 是在空间上并行化工作，那么 Plan 模式就是在时间上结构化工作。它把"边想边做"的即时响应模式，变成"先谋后动、分步验证"的工程化流程。

Plan 模式的核心理念

在默认的交互模式中，你给 Claude Code 一个任务，它立刻开始执行。这对于简单任务是高效的——想得少、做得快。但对于复杂任务，这种模式有一个根本缺陷：在执行过程中才发现方向错误，前面的工作全部作废。

Plan 模式把这个流程颠倒过来：

默认模式的流程：
  需求 → 边想边做 → 发现问题 → 回退 → 重新做 → 可能再次发现问题 → ...

Plan 模式的流程：
  需求 → 制定详细计划 → 你审核调整计划 → 分阶段执行 → 每阶段验证 → 完成

核心区别在于：在动手写第一行代码之前，先对齐认知。

Plan 模式的三阶段流程

Phase 1：制定计划（Plan）

当你给出一个复杂任务时，指令 Claude Code 进入 Plan 模式：

"请用 Plan 模式为我设计以下功能的实现方案：

功能：为用户系统添加基于角色的权限控制（RBAC）

背景：
- 当前用户系统基于 JWT 认证，用户表只有 role 字段（'user' | 'admin'）
- 需要扩展为：admin / manager / editor / viewer 四种角色
- 每个角色有不同的 API 访问权限和数据可见范围

约束：
- 不引入第三方权限库（如 CASL），保持依赖精简
- 权限检查逻辑需要能单元测试
- 数据库使用 PostgreSQL，已有 users 表

请输出详细的实现计划，包括：
1. 数据模型变更（新的迁移文件）
2. 权限定义和检查中间件的架构
3. 各层（路由、服务、数据访问）的改动范围
4. 测试策略
5. 分步执行顺序"

Claude Code 会输出一份结构化的计划——不是代码，而是设计文档。这个阶段的关键在于你拥有审批权：审阅计划、提出修改、调整方向，直到计划符合你的期望。

Phase 2：执行计划（Execute）

计划确认后，进入执行阶段。关键原则：按计划的步骤顺序执行，每步完成后验证。

"计划已确认。现在请按计划执行。

第一步：创建数据库迁移文件（roles 表和 permissions 表）
  - 文件：database/migrations/003_add_rbac.sql
  - 完成后向我展示迁移内容并等待确认

第二步：实现权限定义模块
  - 文件：src/auth/permissions.ts
  - 定义角色-权限映射表
  - 完成后运行单元测试验证

...逐步骤推进"

执行阶段的纪律：

• 一次只做一步：完成一步 → 验证 → 确认 → 下一步。不要"一口气做完"——那是 Plan 模式要避免的。
• 每步都有验证：编译通过、测试通过、lint 通过。任何一步验证失败，停下来修，不要带着问题往前走。
• 保持计划在视野内：如果执行中偏离了计划，暂停并更新计划，而不是悄悄偏离。

Phase 3：审查回顾（Review）

全部步骤执行完毕后，做一次整体回顾：

"实施完成。请对比最终实现和原始计划，输出差异报告：
1. 哪些部分严格按计划执行了？
2. 哪些部分在执行中做了调整？为什么？
3. 有没有遗漏的需求？
4. 代码质量评估（是否有需要重构的部分）？"

这个回顾的价值在于：让你（和人）从执行细节中抽离出来，回到"战略"层面看整个实现是否完整、是否合理。同时，这次回顾也是下次制定类似计划的参考资料。

Plan 模式实战：完整示例

以下是一个完整的 Plan → Execute → Review 流程，以"重构 API 错误处理"为例。

启动 Plan 模式

"请用 Plan 模式为以下任务制定实施方案：

任务：统一重构项目中所有 API 路由的错误处理

背景：
- 项目有 23 个 API 路由文件，分布在 src/routes/ 下
- 当前问题：错误处理不一致——有的返回 { error: string }，有的返回 { message: string }，
  有的直接 throw（被全局兜底），有的在路由内 try-catch
- HTTP 状态码使用也不一致：有的用 400 表示所有错误，有的用 500

目标：
- 所有 API 返回统一的错误格式：{ error: { code: string, message: string, details?: any } }
- HTTP 状态码遵循 REST 约定
- 减少重复的 try-catch，使用统一的错误处理中间件
- 不能引入运行时破坏性变更（向后兼容 30 天过渡期）

约束：
- 不能引入新的第三方依赖
- 现有的 47 个测试必须全部通过
- 分阶段执行，避免一次改动超过 8 个文件"

Claude Code 输出的计划示例

执行计划：统一 API 错误处理重构

Phase 1：基础设施（2 个文件）
  1.1 创建 src/errors/AppError.ts —— 自定义错误类
      - 包含 code, message, httpStatus, details 字段
      - 预定义常用错误码（NOT_FOUND, VALIDATION_ERROR, UNAUTHORIZED 等）
  1.2 创建 src/middleware/errorHandler.ts —— 统一错误处理中间件
      - 捕获 AppError → 返回统一格式
      - 捕获未知错误 → 返回 500 + 隐藏内部详情
      - 记录错误日志

Phase 2：试点迁移（3-4 个路由文件）
  2.1 选择最简单的 3 个路由（如 health.ts, ping.ts, version.ts）
  2.2 移除路由内的 try-catch，改用 throw new AppError(...)
  2.3 注册 errorHandler 中间件
  2.4 更新相关测试，验证错误格式

Phase 3：逐批迁移（16 个路由文件）
  3.1 按模块分组：用户模块（4 个文件）→ 订单模块（4 个文件）→ ...
  3.2 每组迁移后运行完整测试套件
  3.3 每组单独 Commit

Phase 4：兼容性过渡
  4.1 在 errorHandler 中检测旧格式的请求头（X-API-Version）
  4.2 对旧客户端返回旧格式（过渡期 30 天）
  4.3 30 天后移除兼容代码

Phase 5：清理和文档
  5.1 更新 API 文档中的错误格式说明
  5.2 添加错误码对照表到项目 Wiki
  5.3 移除不再需要的旧错误处理代码

估计总文件改动：25-30 个文件（含测试）
建议执行时间：分 4 个对话会话，每会话 45-60 分钟

你审核后的调整

"计划总体可行。两点调整：
1. Phase 2 试点增加到 5 个路由——health, ping, version 过于简单，
   无法覆盖实际场景。加入 users/me.ts 和 posts/list.ts。
2. 兼容过渡期改为 60 天——我们的客户端升级周期比较长。
3. 在 Phase 1 增加一个步骤：先建一个错误码枚举文件 errors/codes.ts，
   避免魔术字符串散布在各路由中。

调整后请确认最终计划。"

这就是 Plan 模式的核心价值：在代码被写出来之前，先用自然语言讨论清楚。这个讨论的成本（5-10 分钟）远远低于方向错误带来的返工成本（可能是数小时）。

处理计划偏离

再好的计划，执行中也可能出现未预料到的情况。如何处理偏离是关键技能。

场景：执行中发现依赖问题

原计划：
  Phase 2 试点迁移 → 选择 users/me.ts 作为第一批

执行中发现：
  users/me.ts 依赖一个未在计划中的工具函数 parseQuery()，
  该函数的错误处理也需要统一

处理方式：
  "发现 users/me.ts 依赖 parseQuery()。
   建议在 Phase 2 之前插入 Phase 2.5：
   先重构 parseQuery() 的错误处理，再迁移 users/me.ts。
   需要额外 15 分钟。是否批准？"

  ← 不要自己默默处理、偏离计划。让计划偏离可见、可控。

偏离处理原则：

原则	做法
偏离可见化	任何偏离计划的改动，先声明、后执行
评估影响	这个偏离会影响后续哪个步骤？是否需要调整计划？
最小化偏离	只做必需的调整，不要"顺便"扩展范围
更新计划	偏离确认后，更新计划文档（可以是对话中的简版）

Plan 模式 vs 普通模式的决策框架

任务特征	推荐模式	理由
改动 < 3 个文件，逻辑简单	普通模式	Plan 的 overhead 不值得
改动 3-8 个文件，有明确的修改方向	普通模式	方向清晰，直接执行更快
改动 > 8 个文件，或涉及架构变更	Plan 模式	需要先对齐方案，避免大范围返工
需求不够明确，需要探索	Plan 模式	用 Plan 来梳理需求，不是来执行
多人协作，需要评审	Plan 模式	Plan 文档是团队沟通的媒介
紧急 Bug 修复（范围明确）	普通模式	时间优先，Plan 环节会延误修复

经验法则：当你犹豫"要不要用 Plan 模式"时，问自己一个问题——"如果 Claude 第一版方案完全跑偏了，我有多难受？" 难受程度越高，越应该用 Plan 模式。

32.3 多会话并行工作

第 31 章提到过多会话并行是效率优化的手段之一。这里我们从"精通"的角度深入展开——如何管理多个活跃会话、如何在会话间切换而不丢失上下文、以及如何与 Git Worktree 配合实现真正的并行开发。

多会话的核心理念

默认情况下，大多数人使用 Claude Code 的方式是"一个会话做到完"：打开 Claude Code → 做任务 A → 完成 → 关掉。这种方式的问题在于：你的大脑和项目状态都是有"惯性"的——当你被中断或需要切换到任务 B 时，你不得不丢弃任务 A 的上下文，然后重新加载任务 B 的上下文。来回切换的成本很高。

多会话并行的解决思路是：每个独立的开发线拥有自己的对话会话，你在这些会话之间切换，就像在 VSCode 的 Tab 之间切换一样——每个 Tab 保持各自的状态。

时间线视角：

单会话模式（串行）：
  [任务 A ————————] [等待] [任务 B ————————] [等待] [任务 C ——]
  ↑ 任务 A 的上下文在等待期间被浪费          ↑ 新任务需要重新加载上下文

多会话模式（并行推进）：
  会话 1: [任务 A ——][暂停][—— 任务 A ——][暂停][—— 完成]
  会话 2: [—— 任务 B ——————][暂停][—— 任务 B ——]
  会话 3: [—————— 任务 C ———————————————— 完成]
  
  ↑ 每个会话保持各自的上下文连续性
  ↑ 你在会话间切换，而不是丢弃和重建

典型的多会话应用场景

场景一：主线 + 支线

会话 1（主线）：Feature 开发 —— "为博客系统添加评论功能"
  - 每天的主要工作时间在这里
  - 保持连续的开发上下文

会话 2（支线）：Code Review —— "审查 PR #234"
  - 同事的 PR 需要审查，但不能中断主线开发
  - 切到会话 2，完成审查，切回会话 1 继续开发

会话 3（应急线）：Bug Fix —— "生产环境登录超时 Bug"
  - 突发事件，需要立即处理
  - 在会话 3 中和 Claude Code 一起排查和修复
  - 修复完成后，切回会话 1，主线开发的上下文完好无损

场景二：并行功能开发（配合 Git Worktree）

会话 1（Worktree: feature/payment）：
  开发支付模块 —— Claude Code 正在重构 PaymentService.ts

会话 2（Worktree: feature/notification）：
  开发通知模块 —— Claude Code 正在实现 WebSocket 推送逻辑

会话 3（Worktree: feature/export）：
  开发数据导出 —— Claude Code 正在写 CSV 生成和下载逻辑

三个会话可以同时进行，因为每个 Worktree 有独立的文件系统。
你作为"调度者"，在三个会话之间分配注意力。

场景三：开发 + 学习 + 文档

会话 1：核心功能开发（高强度，每天 4-6 小时）
会话 2：技术探索和学习（"帮我理解 WebSocket 的心跳机制"）
会话 3：文档维护（"更新 API 文档，补充新接口的参数说明"）

会话管理实践

命名规范

好的会话命名让你在 10 个并发会话中一眼找到目标：

✅ 好的命名：
  "feat: 支付模块 - 微信支付"
  "review: PR #234 - 用户认证重构"
  "hotfix: 登录超时 #342"
  "explore: WebSocket 重连策略"

❌ 坏的命名：
  "Session 1"
  "Untitled"
  "test"
  "aaa"

命名建议：类型: 模块/功能 - 具体内容。类型包括 feat、fix、review、explore、docs、refactor。

会话切换的最佳时机

不要"随机打断"——在自然断点切换会话：

自然断点	说明
刚完成一个 Commit	工作得到了持久化，切走不会丢失
Claude Code 正在执行长时间操作	等待期间可以切到另一个会话做轻量任务
一个子任务刚验证通过	阶段性完成，心理上容易"放下"
遇到阻塞等待外部反馈	"我发给同事 Review 了，等他回复"

上下文的保持与恢复

当你在会话 1 中暂停，切到会话 2 工作，再切回会话 1 时，Claude Code 的对话历史完整保留——不需要重新解释你在做什么。但为了更快恢复"思维上下文"，建议在暂停时让 Claude Code 做一个简短总结：

"我马上要切到另一个会话处理紧急问题。请用 3-5 行总结当前进度：
- 完成了什么？
- 正在进行什么？
- 下一步做什么？"

Claude Code 输出：
"""
当前进度摘要（feat: 支付模块）：
✅ 已完成：PaymentService 核心逻辑、微信支付 API 对接
🔄 正在进行：退款流程的错误处理（src/services/refund.ts 第 45 行）
📋 下一步：补充退款流程的单元测试，然后提交 PR
"""

下次回到这个会话时，你会看到这个总结在对话末尾——10 秒内恢复思维上下文。

VSCode 多窗口配置

如果你在 VSCode 中使用 Claude Code 扩展，多会话的最佳实践是多窗口配置：

桌面布局建议（双显示器或大屏）：

┌─────────────────────────┬─────────────────────────┐
│  显示器 1（主屏幕）       │  显示器 2（扩展屏）       │
│                         │                         │
│  VSCode 窗口 1          │  VSCode 窗口 2          │
│  主开发分支              │  Review/Hotfix 分支     │
│  Claude Code 会话 1     │  Claude Code 会话 2     │
│                         │                         │
│  ┌───────────────────┐  │  ┌───────────────────┐  │
│  │ 代码编辑区         │  │  │ PR Diff 查看      │  │
│  │ Claude Code 面板   │  │  │ Claude Code 面板   │  │
│  └───────────────────┘  │  └───────────────────┘  │
│                         │                         │
├─────────────────────────┴─────────────────────────┤
│  终端窗口（可选，第三个窗口）                        │
│  - 监控 CI 状态                                     │
│  - 运行定时任务                                      │
└───────────────────────────────────────────────────┘

多窗口 + 多会话的核心优势：物理空间上的隔离对应了逻辑上的隔离——你的大脑不会混淆"左边窗口在做支付功能，右边窗口在审查 PR"。

多会话的注意事项

注意事项	说明
文件冲突	如果两个会话操作相同的文件且不在不同 Worktree 中，后保存的会覆盖先保存的。务必确保并行的会话操作互不重叠的文件集，或者使用 Worktree 隔离
Git 状态混乱	同一目录下两个会话交替 commit/push 可能导致意外的 Git 状态。建议每个会话在开始前 git status 确认状态干净
资源消耗	每个活跃的 Claude Code 会话都消耗 API token。3 个并发会话 = 3 倍的 token 消耗速率。留意 API 账单
注意力分散	多会话是效率工具，但如果导致频繁切换（每 5 分钟换一次），效率反而下降。建议每个会话至少专注 30 分钟再切换

32.4 Git Worktree 隔离开发

Git Worktree 是并行工作流的基石。第 31 章和第 22 章都提到过它，但这里我们要深入掌握它的全部使用模式——从基本操作到与 Claude Code 的深度集成。

什么是 Git Worktree

git worktree 让你在同一个 Git 仓库中创建多个独立的工作目录，每个目录可以在不同的分支上工作。这解决了"我需要在 A 分支上开发，但突然需要切到 B 分支修 Bug，又不想 stash 或 commit 当前未完成的代码"这个经典痛点。

传统方式（单工作目录）：
  ~/project/  → 只有一个工作目录
  切分支时：git stash → git switch → 做其他事 → git switch back → git stash pop
  问题：stash 可能冲突，大型重构无法 stash，上下文被打断

Worktree 方式（多工作目录）：
  ~/project/            → 主工作目录（main 或当前开发分支）
  ~/project-hotfix/     → Hotfix 工作目录（hotfix/login-timeout 分支）
  ~/project-feature-a/  → Feature A 工作目录（feature/payment 分支）
  
  每个目录有独立的文件系统状态和 Git 状态
  共享同一个 .git 仓库（共享提交历史和分支）

基本操作

创建 Worktree

# 基于已有分支创建 Worktree
git worktree add ../project-hotfix hotfix/login-timeout

# 基于远程分支创建 Worktree
git worktree add ../project-feature-a origin/feature/payment

# 创建新分支并同时创建 Worktree
git worktree add -b feature/new-module ../project-new-module main

# 创建后，进入 Worktree 目录即可开始工作
cd ../project-hotfix
git branch  # 确认当前在 hotfix/login-timeout 分支

查看所有 Worktree

git worktree list

# 输出示例：
# /Users/shibin/project             abc1234 [main]
# /Users/shibin/project-hotfix      def5678 [hotfix/login-timeout]
# /Users/shibin/project-feature-a   ghi9012 [feature/payment]

删除 Worktree

# 先删除 Worktree 注册，再删除目录
git worktree remove ../project-hotfix

# 如果 Worktree 中有未提交的更改，需要强制删除
git worktree remove --force ../project-hotfix

# 手动清理目录（如果 git worktree remove 没有删除目录）
rm -rf ../project-hotfix
git worktree prune   # 清理已不存在的 Worktree 引用

Worktree + Claude Code 的工作模式

Worktree 为 Claude Code 提供了物理隔离——这是最安全的并行开发方式。以下是三种典型的组合模式：

模式一：大功能隔离开发

场景：支付模块重构涉及 30+ 个文件，预计需要 2 天

步骤：
1. git worktree add -b feature/payment-refactor ../project-payment main
2. cd ../project-payment
3. 启动 Claude Code，在新的 Worktree 中工作
4. 完成重构 → git add + commit → git push
5. 回到主目录创建 PR → merge
6. git worktree remove ../project-payment
7. git branch -d feature/payment-refactor  # 可选，清理本地分支

全程主目录（~/project/）保持干净——没有任何未提交的文件变更。
如果重构期间需要紧急 Hotfix：切回主目录，正常操作，互不干扰。

模式二：并行功能开发

场景：同时推进三个独立的功能

# 创建三个 Worktree
git worktree add -b feature/payment  ../project-payment main
git worktree add -b feature/notification ../project-notification main
git worktree add -b feature/export ../project-export main

# 在每个 Worktree 中启动独立的 Claude Code 会话
cd ../project-payment    && claude    # 会话 1：支付功能
cd ../project-notification && claude  # 会话 2：通知功能
cd ../project-export     && claude    # 会话 3：导出功能

# 你在三个会话之间分配时间
# 每个会话有独立的 Claude Code 对话历史和文件状态

模式三：实验性修改沙箱

场景：想尝试一个大重构方案，但不确定是否可行

# 创建实验 Worktree
git worktree add -b experiment/radical-refactor ../project-experiment main

# 在实验 Worktree 中让 Claude Code 放手重构
# 不用担心破坏主项目
cd ../project-experiment
claude → "请大规模重构 src/core/ 的数据流架构..."

# 实验结果：
# 成功 → 合并回 main
# 失败 → git worktree remove ../project-experiment + git branch -D experiment/radical-refactor
# 零成本尝试，零风险

Worktree 中的 Claude Code 配置

每个 Worktree 是独立的文件系统，但共享 .git 目录。Claude Code 的项目配置（如 .claude/ 目录中的 settings.json、CLAUDE.md）可能需要在 Worktree 之间保持一致或独立，取决于你的需求：

场景 A：希望 Worktree 共享项目配置
  → .claude/ 和 CLAUDE.md 已提交到 Git，Worktree 自然共享
  → 在主目录更新 CLAUDE.md 后，在 Worktree 中 git pull 即可同步

场景 B：希望 Worktree 有独立的配置
  → 在 Worktree 中修改 .claude/settings.local.json（此文件不提交到 Git）
  → 或者在 Worktree 中本地覆盖 CLAUDE.md（不 commit）

何时用 Worktree，何时用分支切换

场景	推荐方式	理由
两个任务改动的文件完全不重叠	普通分支切换	Worktree 的创建和维护有 overhead
两个任务可能改动重叠的文件	Worktree	避免 stash/commit 冲突
一个任务进行中（有未提交修改），另一个紧急任务来了	Worktree	不用 stash，不中断当前工作
大规模重构（持续数天）	Worktree	长时间保持工作区脏状态，不能用 stash
实验性修改（可能丢弃）	Worktree	失败后直接删除，主工作区零影响
简单的 Bug 修复（15 分钟完成）	普通分支切换	Worktree 的创建时间（10 秒）占任务比例太高
Code Review（只读，不修改代码）	普通分支切换或 GitHub PR 页面	不需要本地文件

Worktree 的清理和维护

随着时间推移，你可能积累大量废弃的 Worktree。定期清理是好习惯：

# 查看当前所有 Worktree
git worktree list

# 删除不需要的 Worktree
git worktree remove /path/to/stale-worktree

# 清理 Git 中已不存在的 Worktree 引用
git worktree prune

# 批量清理建议：每次发布完成后，清理该功能的 Worktree
# 保留主目录和当前活跃功能（最多 2-3 个）的 Worktree

原则：Worktree 是工具，用完就收。不要保留 10 个已完成分支的 Worktree 目录——它们会占用磁盘空间，并让你的 git worktree list 变得难以阅读。

32.5 定时任务与自动化（Cron）

Cron（定时任务）是 Claude Code 的一项独特能力：让你设置定期自动执行的任务，Claude Code 会在你设定的时间自动启动并执行指定的指令。这是"让 AI 在你离开时继续工作"的关键机制。

Cron 的核心理念

Cron 改变了 Claude Code 的使用模式：从"你主动发起"变成"系统自动触发"。

传统模式：你来驱动
  你坐在电脑前 → 打开 Claude Code → 下达指令 → 等待结果 → 审查
  ↑ 你必须在场

Cron 模式：时间驱动
  你设定规则 → 时间到了 → Claude Code 自动执行 → 结果在对话中等待你
  ↑ 你不在场，工作仍然在推进

这种模式最适合周期性检查任务——那些"不做也没关系，但做了会很安心"的重复性工作。

Cron 的使用场景

场景一：CI/CD 状态监控

"每 5 分钟检查一次 CI 状态，如果 main 分支的最新构建失败，分析失败原因并报告。"

Claude Code 的行为：
  - 每 5 分钟自动运行一次
  - 调用 gh 查看 CI 状态
  - 如果构建失败，读取失败日志，分析根因
  - 将分析结果留在对话中，你随时查看

场景二：代码审查提醒

"每天早上 9 点，检查是否有未审查的 PR，列出每个 PR 的标题、作者、文件变更数量。"

Claude Code 的行为：
  - 每个工作日早上 9 点触发
  - 拉取所有 open PR 的列表
  - 筛选出等待你审查的 PR
  - 生成审查优先级建议（根据变更规模和紧急性）

场景三：依赖更新检查

"每天早上 8 点，检查项目依赖是否有更新，如果有，列出更新内容和 Breaking Changes。"

Claude Code 的行为：
  - 运行 pnpm outdated 或 npm outdated
  - 对于有更新的包，查 CHANGELOG 或 release notes
  - 标出有 Breaking Changes 的更新
  - 建议升级优先级

场景四：每日代码变更摘要

"每天早上 9 点，生成昨日的代码变更摘要：
- 列出昨天的所有 commit
- 按模块分组
- 统计新增/删除行数
- 标出需要关注的大变更"

Cron 语法和使用方式

在 Claude Code 中设置 Cron 任务，使用 /cron 命令或在对话中用自然语言描述：

方式一：直接指令
  "请设置一个 Cron 任务：每天早上 9 点检查 CI 状态"

方式二：使用 /cron 命令
  /cron add "每 5 分钟检查 CI 状态"

方式三：标准 Cron 表达式
  /cron add --schedule "*/5 * * * *" --prompt "检查 CI 状态"

Cron 表达式标准格式（5 个字段）：

┌──────────── 分钟 (0-59)
│ ┌────────── 小时 (0-23)
│ │ ┌──────── 日期 (1-31)
│ │ │ ┌────── 月份 (1-12)
│ │ │ │ ┌──── 星期 (0-6, 0=周日)
│ │ │ │ │
* * * * *

常用示例：
  */5 * * * *     每 5 分钟
  0 9 * * *       每天早上 9 点
  0 9 * * 1-5     每个工作日早上 9 点
  0 */2 * * *     每 2 小时
  0 9 1 * *       每月 1 号早上 9 点
  0 9,18 * * *    每天早上 9 点和下午 6 点

Cron 任务的生命周期

创建

# 创建持久化 Cron 任务（保存到项目 .claude/settings.json）
/cron add "每天 9 点检查未审查的 PR"

# 创建会话级 Cron 任务（仅当前会话有效）
/cron add --session "每 5 分钟检查 CI 状态"

查看

# 列出所有 Cron 任务
/cron list

# 输出示例：
# ID       Schedule        Prompt                       Status
# cron_1   */5 * * * *     检查 CI 状态                  active
# cron_2   0 9 * * 1-5     检查未审查的 PR               active
# cron_3   0 9 * * *       生成昨日代码变更摘要            paused

管理

# 暂停任务（保留配置，但不执行）
/cron pause cron_2

# 恢复任务
/cron resume cron_2

# 删除任务
/cron remove cron_3

# 查看任务执行历史
/cron history cron_1

持久化 vs 会话级任务

特性	持久化任务（Durable）	会话级任务（Session-only）
存储位置	项目 .claude/settings.json	仅当前会话内存
生命周期	跨会话持久存在，直到手动删除	当前会话结束时自动清除
会话关闭后	继续在后台执行（如果配置允许）	立即停止
适用场景	长期需要的定期检查（CI 监控、每日摘要）	临时需要的短期监控（今天下午反复检查部署状态）
自动删除	7 天无触发后自动停用（防止废弃任务积累）	会话结束时自动删除

自动删除机制

为防止 Cron 任务无限制积累，Claude Code 对持久化 Cron 任务有自动停用机制：

• 如果一个 Cron 任务连续 7 天没有被触发（因为会话关闭或设备离线），该任务会自动进入 paused 状态
• 你需要在 7 天内至少与 Claude Code 交互一次，让 Cron 有机会执行
• 你可以随时手动 resume 被自动暂停的任务

这一机制确保你不会在三个月后发现有 47 个 Cron 任务在后台空转。

Cron 实战示例

示例一：CI 监控 + 自动分析

"请设置一个 Cron 任务：

调度：每 10 分钟检查一次
指令：检查 GitHub Actions 中 main 分支的最新 workflow run 状态。
      如果失败：
      1. 获取失败日志
      2. 分析失败原因（编译错误 / 测试失败 / 环境问题）
      3. 如果能在 5 分钟内修复，直接创建 fix PR
      4. 如果不能自动修复，生成详细的分析报告

任务名称：CI Monitor - Main Branch
类型：持久化"

示例二：每日技术资讯摘要

"请设置一个 Cron 任务：

调度：每天早上 8:30
指令：检查以下技术动态（仅本项目相关的技术栈）：
      1. React / TypeScript / Node.js 的最新版本和重要更新
      2. 本项目 package.json 中依赖的安全公告
      3. GitHub Trending 中与项目技术栈相关的新项目
      将所有信息汇总为简洁的'每日技术简报'，优先级排序。

任务名称：Daily Tech Brief
类型：持久化"

示例三：会话期间的临时监控

"请设置一个会话级 Cron 任务：

调度：每 2 分钟检查一次
指令：检查本次部署的日志输出文件 /tmp/deploy-output.log，
      如果出现 'Deploy completed successfully' 就通知我，
      如果出现 'Deploy failed' 就立刻提醒我查看错误。

任务名称：Deploy Monitor（临时）
类型：会话级（部署完成后就删除）"

Cron 使用的最佳实践

1. 不要过度使用：Cron 任务会消耗 API token。一个每 5 分钟运行的 Cron 任务 = 每天 288 次 API 调用。确保每次调用的价值大于其成本。

2. 优先用会话级任务做试验：不确定一个 Cron 任务是否有用时，先用 --session 创建会话级任务试用一天。如果确实有用，再升级为持久化任务。

3. 给每个任务清晰的名称和用途描述：一个月后回看 /cron list 时，你还能记得每个任务是做什么的。

4. 定期审查：每月做一次 Cron 任务清理——删除不再需要的，暂停暂时不需要的，保留真正有价值的。

5. 注意时区：Cron 任务默认使用 UTC 时间。如果需要本地时间，在指令中明确说明（如 "每天早上 9 点（北京时间）"）。

32.6 Workflow 编排

Workflow 是 Claude Code 高级能力中的"终极武器"——它把前面几节介绍的 Subagent、Plan 模式、Cron 等能力组合成一个可编排的多阶段流水线。如果说单个 Subagent 是一个工人，Workflow 就是一整条生产线。

什么是 Workflow

Workflow 是一个预定义的、多 Agent 协作的执行脚本，它定义了多个 Agent 如何分工、如何通信、如何汇总结果。Workflow 的执行由 Claude Code 自动编排，你只需要定义规则和检查点。

Workflow = 多个 Agent + 编排规则 + 质量门禁 + 结果汇总

┌─────────────────────────────────────────────────────────┐
│                    Workflow: 发布前审查                    │
│                                                         │
│  Phase 1: 并行审查                                       │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐              │
│  │ Agent A  │  │ Agent B  │  │ Agent C  │              │
│  │ 安全审查  │  │ 性能审查  │  │ 代码风格  │              │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘              │
│       │              │              │                    │
│       └──────────────┴──────────────┘                    │
│                      │                                   │
│  Phase 2: 汇总分析（主 Agent）                            │
│  ┌──────────────────────────────────────┐               │
│  │ 合并三个审查结果                       │               │
│  │ 去重（同一个问题可能被多人发现）         │               │
│  │ 按严重程度排序                         │               │
│  │ 生成可操作的修复建议                    │               │
│  └──────────────────────────────────────┘               │
│                      │                                   │
│  Phase 3: 修复验证（可选）                                │
│  ┌──────────────────────────────────────┐               │
│  │ 针对发现的问题，逐个修复                │               │
│  │ 每个修复后重新运行相关测试              │               │
│  │ 生成修复报告                           │               │
│  └──────────────────────────────────────┘               │
└─────────────────────────────────────────────────────────┘

Workflow 的适用场景

Workflow 不是日常使用的工具——它的设置成本较高，适合以下场景：

场景	为什么用 Workflow	预期收益
全面代码审查	单次 Code Review 容易遗漏。多 Agent 从不同角度独立审查，然后交叉验证	发现 3-5 倍于单次审查的问题
大规模迁移	迁移涉及数百个文件，需要分阶段、分模块、自动验证	数天的工作量压缩到数小时
安全审计	需要多个独立视角：代码静态分析、依赖漏洞扫描、数据流追踪、OWASP 合规	覆盖手动审计难以穷举的攻击面
知识库构建	需要从整个代码库中提取特定信息，汇总成结构化文档	将数周的文档编写工作压缩到数小时
重构前影响分析	改一个核心模块前，需要全面评估影响范围	避免"改了 A 发现 B 崩了"的连锁反应

Workflow 的编排模式

模式一：流水线（Pipeline）

Agent 按顺序执行，前一个的输出是后一个的输入。

Pipeline: 代码生成 → 测试 → 审查 → 修复 → 文档更新

Agent 1: 生成代码    ──→ 输出：src/newFeature.ts
Agent 2: 编写测试    ──→ 输出：src/__tests__/newFeature.test.ts
Agent 3: 审查代码    ──→ 输出：review-issues.md
Agent 4: 修复问题    ──→ 输出：更新后的 src/newFeature.ts
Agent 5: 更新文档    ──→ 输出：docs/newFeature.md

适用场景：有明确前后依赖关系的任务链
优势：每步都可以设置质量门禁（测试不通过 → 不进入下一步）
劣势：总时间 = 所有步骤时间之和（无并行加速）

模式二：并行 + 汇总（Fan-out / Fan-in）

多个 Agent 同时处理不同部分，然后汇总。

Fan-out + Fan-in: 并行代码审查

         ┌──→ Agent 1: 审查安全性 ──┐
         │                           │
主 Agent ──→ Agent 2: 审查性能    ──┼──→ 汇总 Agent: 合并结果
         │                           │
         └──→ Agent 3: 审查可维护性 ──┘

适用场景：同一任务需要多角度分析，各角度互不依赖
优势：并行执行，总时间 = 最慢 Agent 的时间
劣势：可能产生重复发现，需要汇总去重

模式三：循环直到满足（Loop-until）

Agent 反复执行一个操作，直到满足终止条件。

Loop-until: 找 Bug 直到干净

初始化：Bug 计数 = 0

循环：
  Agent: 扫描代码 → 发现 Bug？ → 是 → 修复 → Bug 计数++ → 继续循环
                                → 否 → 终止

终止条件：连续 3 次扫描没有发现新 Bug

适用场景：质量驱动的迭代优化（Bug 修复、性能优化、代码清理）
优势：不留遗漏，直到真正"干净"
劣势：Agent 可能反复修复同一个位置的不同问题，效率较低

模式四：对抗验证（Adversarial Verification）

多个 Agent 从对立角度验证同一个结果。

Adversarial: 安全审计

Agent A（攻击者视角）："假设我是攻击者，如何绕过这段代码的安全检查？"
Agent B（防御者视角）："假设我是安全专家，这段代码有哪些防护不足？"
Agent C（独立审计）："独立审查，不预设攻击或防御立场"

汇总 Agent：三个 Agent 的发现对比 → 共同发现 = 高可信度 / 独立发现 = 值得关注

适用场景：安全审计、关键业务逻辑验证、合规检查
优势：对抗视角更容易发现隐蔽问题
劣势：对 token 消耗较大（多个 Agent 的深度分析）

Workflow 中的 Token 预算管理

Workflow 涉及多个 Agent，每个 Agent 都消耗 token。不加控制的 Workflow 可能一次消耗数十万甚至上百万 token。管理策略：

预算层次：

Workflow 总预算：200,000 tokens（根据任务复杂度调整）

分配：
  - Phase 1（并行审查）：3 个 Agent × 40,000 tokens = 120,000 tokens
  - Phase 2（汇总分析）：1 个 Agent × 40,000 tokens = 40,000 tokens
  - Phase 3（修复验证）：1-2 个 Agent × 20,000 tokens = 40,000 tokens

成本控制原则：

原则	做法
重要任务用大模型	最终汇总和关键决策用 V4 Pro / Opus
机械任务用小模型	代码扫描、格式检查用 V4 Flash
设置停止条件	"如果连续 5 次扫描都没有发现新问题，终止 Workflow"
对有价值的结果才深度分析	先用低成本 Agent 快速扫描，只对标记为"可能有问题"的区域进行深度分析
分批执行	不需要一个 Workflow 做完所有事。分 2-3 个 Workflow 执行，中间你审核输出

定义 Workflow 的方式

在 Claude Code 中，你可以通过对话直接定义 Workflow：

"请按以下 Workflow 执行代码审查：

Phase 1（并行）：
  启动 3 个 Subagent，分别是：
  - Security Agent：从 OWASP Top 10 角度审查 src/api/ 下所有路由文件
  - Performance Agent：识别 src/api/ 下可能的性能瓶颈（N+1 查询、缺少缓存、同步阻塞）
  - Maintainability Agent：评估代码可维护性（函数复杂度、重复代码、命名质量）

Phase 2（汇总）：
  收集 3 个 Agent 的审查结果，生成统一的审查报告：
  - 按严重程度排序（Critical / High / Medium / Low）
  - 合并重复发现
  - 为每个问题提供修复建议

Phase 3（修复）：
  对 Critical 和 High 级别的问题，逐个修复。
  修复后运行测试验证。

Token 预算：总计不超过 150,000 tokens。
模型策略：Phase 1 使用 V4 Flash，Phase 2 和 Phase 3 使用 V4 Pro。

完成后生成审查报告文件：docs/code-review-$(date).md"

Workflow 实战：大规模 API 迁移

以下是一个完整的 Workflow 实战案例——将 REST API 迁移到 GraphQL：

Workflow: REST → GraphQL 迁移（预估 4-6 小时）

Phase 1: 分析（并行，约 30 分钟）
  Agent 1: 分析所有 REST 端点的输入输出结构
    → 扫描 src/routes/ 下 47 个路由文件
    → 提取每个端点的请求参数和响应结构
    → 输出：rest-endpoints.json（结构化数据）

  Agent 2: 分析前端对 API 的调用模式
    → 扫描 src/pages/ 和 src/components/ 下的 API 调用
    → 统计每个端点的调用频率和使用的字段
    → 输出：api-usage.json（调用模式分析）

  Agent 3: 评估迁移风险
    → 分析哪些端点有复杂业务逻辑（不适合简单映射到 GraphQL）
    → 识别破坏性变更的 API（参数变更、响应结构变更）
    → 输出：migration-risks.md（风险评估报告）

Phase 2: 设计（串行，约 1 小时）
  Agent 4（V4 Pro）: 基于 Phase 1 的三个输出，设计 GraphQL Schema
    → 定义 Query、Mutation、Type 结构
    → 优先覆盖高频调用的端点
    → 输出：schema.graphql + schema-design.md

  你审核 Schema → 调整 → 确认

Phase 3: 实现（并行，约 2 小时）
  将 Schema 按业务领域拆分，并行实现：
  Agent 5: User 领域的 GraphQL Resolver（8 个端点 → 5 个 Query + 3 个 Mutation）
  Agent 6: Order 领域的 GraphQL Resolver（12 个端点 → 6 个 Query + 4 个 Mutation）
  Agent 7: Product 领域的 GraphQL Resolver（7 个端点 → 4 个 Query + 2 个 Mutation）

Phase 4: 测试和验证（串行，约 1 小时）
  Agent 8: 为 GraphQL Resolver 编写集成测试
  Agent 9: 更新前端 API 调用（切换到 GraphQL）
  运行完整测试套件 → 验证通过

Phase 5: 文档和清理（约 30 分钟）
  Agent 10: 生成 GraphQL API 文档
  Agent 11: 标记废弃的 REST 端点，添加迁移提示

总 token 预估：250,000 - 400,000 tokens
总时间预估：4-6 小时（对比手动迁移需要 3-5 天）

Workflow 的调试和监控

Workflow 执行过程中可能出现各种问题。以下是调试策略：

常见问题和应对：

问题	症状	应对
Agent 产出质量差	审查结果泛泛而谈，没有具体代码引用	收紧 Agent 指令——要求"每发现一个问题必须引用具体的文件名和行号"
并行 Agent 产出重复	三个 Agent 发现了相同的问题	在汇总阶段增加去重逻辑；或调整各 Agent 的审查范围，减少重叠
Agent 超时或卡住	某个 Agent 执行超过预期时间的 2 倍	设置超时机制——"如果单个 Agent 超过 10 分钟无输出，跳过并标记为未完成"
汇总阶段信息过载	汇总 Agent 收到太多信息，遗漏重要发现	要求各 Agent 在输出前先做一次自过滤——"只输出 Critical 和 High 级别的问题"
Token 超支	总消耗超出预算 50% 以上	在 Workflow 中设置硬性 Token 上限，达到上限时终止并输出已完成部分的报告

监控清单：

Workflow 执行期间，定期检查：

• [ ] 当前哪个 Phase 在执行？进度百分比？
• [ ] 各 Agent 的状态（运行中 / 完成 / 失败）？
• [ ] Token 消耗是否在预算内？
• [ ] 有没有 Agent 的输出明显不符合预期（需要提前终止）？

核心原则：Workflow 是自动化的，但自动化不等于"不用管"。你需要像指挥一个团队一样监控 Workflow 的执行——及时发现偏离、做出调整、在必要时终止或重试。

32.7 本章小结

本章是第七篇"精通篇"的第一章，介绍了六种 Claude Code 高级工作流。这六种能力构成了从"一个人 + 一个 AI 助手"进化到"一个人 + 一个 AI 团队"的完整工具集：

1. Subagent 多 Agent 协作：将独立子任务分发给多个 Subagent 并行执行，利用上下文隔离和并行加速，实现"一人同时推进多个方向"。适用条件：子任务互不依赖、文件集不重叠、每个子任务描述自包含。

2. Plan 模式分阶段开发：将"边想边做"改为"先谋后动"的工程化流程——Phase 1 制定计划并审核、Phase 2 按计划分步执行并逐步验证、Phase 3 整体回顾对比。核心价值在于：在写代码之前对齐认知，避免方向错误导致的大规模返工。

3. 多会话并行工作：每个独立的开发线拥有自己的会话，保持上下文连续性。典型场景包括主线+支线+应急线、并行功能开发、开发+学习+文档。关键纪律：命名规范、在自然断点切换、使用进度摘要快速恢复上下文。

4. Git Worktree 隔离开发：在同一个仓库中创建多个独立工作目录，实现物理级别的文件系统隔离。特别适用于大功能开发（持续数天不改动主目录）、并行功能开发（每个功能独立 Worktree）、实验性修改沙箱（失败零成本丢弃）。

5. Cron 定时任务自动化：让 Claude Code 按时间表自动执行周期性任务，实现"你不在场时工作仍在推进"。适用于 CI 监控、每日代码审查提醒、依赖更新检查、每日变更摘要等场景。关键纪律：不过度使用（每次调用都有价值）、定期清理废弃任务。

6. Workflow 编排：将 Subagent、Plan 模式等能力组合成多 Agent 协作流水线。四种编排模式（流水线、并行汇总、循环直到满足、对抗验证）覆盖了从代码审查到大规模迁移的各种复杂场景。核心挑战是 Token 预算管理和执行监控。

六种工作流的联系与选择

这六种能力不是独立的，而是层层叠加、可以组合使用：

你的工作流工具箱：

  日常开发：
    普通模式（小任务）+ Plan 模式（复杂任务）

  并行加速：
    + Subagent（独立子任务并行）
    + 多会话（多开发线独立推进）
    + Git Worktree（需要文件系统隔离时）

  自动化：
    + Cron（周期性任务自动触发）

  复杂编排：
    + Workflow（多 Agent 协作流水线）

选择工作流的决策树：

你的任务特征是什么？
  │
  ├── 单文件、逻辑简单 → 普通模式，直接执行
  │
  ├── 多文件、有依赖顺序 → Plan 模式，分阶段推进
  │
  ├── 多个独立子任务 → Subagent 并行分发
  │
  ├── 多个开发线（不同功能/Bug/Review）→ 多会话并行
  │   └── 需要修改同一批文件？→ 加上 Git Worktree 隔离
  │
  ├── 需要周期性自动执行 → Cron 定时任务
  │
  └── 端到端的复杂流程（审查/迁移/审计）
      → Workflow 编排（组合 Subagent + Plan 模式）

从精通到创造

高级工作流的最终目标不是"用更多的功能"，而是建立你自己的高效工作模式。这六种能力是积木，你可以根据自己的项目特点、团队规模、个人偏好，组合出最适合你的工作流体系。

一个成熟的 Claude Code 精通用户的典型一天：

08:30 - Cron 自动生成昨日代码变更摘要，你在手机上查看
09:00 - 打开主会话（feat: 支付模块），恢复昨天的上下文
09:15 - 用 Subagent 并行搜索代码库，收集需要修改的文件范围
09:30 - 启动 Plan 模式，为今天的重构任务制定详细计划
09:45 - 审核计划，调整两处细节
10:00 - 按计划执行 Phase 1（数据层重构）
10:45 - 收到 Cron 通知：CI 构建失败 → 切换到 Hotfix 会话
11:00 - 在 Hotfix Worktree 中修复 CI 问题 → Commit → Push
11:15 - 切回主会话，继续 Phase 2（API 层重构）
12:00 - 上午工作结束。主会话的上下文完好保留
14:00 - 下午：审查同事的 PR（切到 Review 会话）
14:30 - 启动 Workflow：全面代码审查（3 个 Agent 并行）
15:00 - 审查 Workflow 输出，标记 2 个 High 问题需要修复
15:30 - 继续主会话的 Phase 3（前端层适配）
16:30 - 所有 Phase 完成 → 进入 Plan 模式的 Phase 3 Review
16:45 - 提交 PR，设置明天早上的 Cron 检查任务
17:00 - 结束

这不是"理想化的未来"，而是现在就可以做到的日常。你需要的只是知道这些能力的存在，并在实践中逐步将它们融入自己的工作流。

---

章节小结：本章开启了第七篇"精通篇"，系统介绍了六种 Claude Code 高级工作流能力——Subagent 多 Agent 协作、Plan 模式分阶段开发、多会话并行工作、Git Worktree 隔离开发、Cron 定时任务自动化、Workflow 编排。这六种能力的组合使用，将你的工作模式从"线性单人协作"升级为"并行多人团队"，实现 Claude Code 生产力的真正飞跃。下一章将深入 Claude Code 的扩展机制——自定义 Commands、Skills 和 Hooks 的开发。