所属阶段：第三阶段「工作流实战」（第 12-20 课） 前置条件：第 10-11 课（Hooks 系统、脚本层） 本课收获：能根据任务选模型，能在三种动态上下文间切换
一、本课概述
前面几课聚焦于"怎么写代码"。本课聚焦于一个同样重要但常被忽视的问题：怎么管理你的 AI 助手。
AI 编程助手有两个关键限制：
- 上下文窗口有限 --- 不是无限记忆，信息会被挤出去
- 模型选择影响成本和质量 --- 用错模型要么太贵要么太弱
本课回答三个问题：
- 上下文窗口怎么管理？ --- 安全区 vs 危险区，Strategic Compact
- 模型怎么选？ --- 三层模型策略
- 会话状态怎么持久化？ --- 三件套 Hook 系统
学完本课，你将能根据任务类型选择合适的模型，管理上下文窗口避免信息丢失，并在会话之间保持工作连续性。
二、上下文窗口管理
2.1 安全区与危险区
AI 编程助手的上下文窗口不是一个均匀的空间。越接近上限，模型的表现越不稳定：
erlang
┌────────────────────────────────────────────────┐
│ 上下文窗口（200K tokens） │
│ │
│ ┌───────────────────────────────────────────┐ │
│ │ 安全区 0% - 80% │ │
│ │ │ │
│ │ ✓ 多文件重构 │ │
│ │ ✓ 功能实现（跨文件） │ │
│ │ ✓ 复杂调试 │ │
│ │ ✓ 架构讨论 │ │
│ │ │ │
│ ├───────────────────────────────────────────┤ │
│ │ 危险区 80% - 100% │ │
│ │ │ │
│ │ △ 仅限单文件编辑 │ │
│ │ △ 独立工具创建 │ │
│ │ △ 文档更新 │ │
│ │ △ 简单 Bug 修复 │ │
│ │ ✗ 不要做多文件重构 │ │
│ │ ✗ 不要做复杂调试 │ │
│ └───────────────────────────────────────────┘ │
└────────────────────────────────────────────────┘关键规则：避免在上下文窗口的最后 20% 做复杂任务。
当你感觉 AI 开始"忘记"前面讨论过的内容、重复已经做过的事情、或者答非所问，很可能是上下文窗口接近满了。
2.2 MCP 的上下文陷阱
这是一个很多人不知道的陷阱：
启用超过 10 个 MCP 服务器时，有效上下文从 200K 压缩到约 70K。
每个 MCP 服务器的工具定义会占用上下文空间。10 个 MCP 各带 10 个工具 = 100 个工具定义，每个定义几百 tokens，光是工具声明就占去了大量空间。
| MCP 数量 | 有效上下文 | 建议 |
|---|---|---|
| 0-3 个 | ~200K | 安全 |
| 4-7 个 | ~150K | 注意 |
| 8-10 个 | ~100K | 警告 |
| >10 个 | ~70K | 危险 --- 优先用 CLI + Skills 替代 |
解决方案：
- 优先使用 CLI 工具和 Skills 替代 MCP
- 只启用当前任务需要的 MCP
- 使用
/context-budget命令监控上下文使用情况
2.3 Strategic Compact --- 手动压缩
当上下文接近 80% 时，你有两个选择：
-
自动压缩 --- 系统自动丢弃"不重要"的信息（不可控，可能丢失关键上下文）
-
Strategic Compact --- 在逻辑断点手动触发压缩（可控，保留关键信息）
自动压缩（被动）：
上下文满了 → 系统自动裁剪 → 可能丢失你需要的信息 → 质量下降Strategic Compact（主动）：
完成一个逻辑阶段 → 手动压缩 → 保留关键结论 → 开始下一阶段
最佳时机：
- 完成一个功能的 TDD 循环后
- 代码审查结束，修复所有问题后
- 切换到不同的功能/文件时
- 讨论完架构方案、做出决策后
核心原则：Strategic Compact 优于自动压缩。在每个逻辑断点主动压缩，而不是等到系统被迫压缩。
三、模型分层选择
3.1 三层模型表
ECC 在 performance.md 中定义了三层模型选择策略：
| 模型 | 定位 | 能力占比 | 成本 | 适用场景 |
|---|---|---|---|---|
| Haiku 4.5 | 轻量高频 | Sonnet 的 90% | 最低（Sonnet 的 1/3） | 高频调用的 Worker Agent、Pair Programming、代码生成 |
| Sonnet 4.6 | 主力开发 | 最佳编程模型 | 中等 | 日常开发、编排多 Agent、复杂编码 |
| Opus 4.5 | 深度推理 | 最强推理 | 最高 | 架构决策、复杂分析、研究任务 |
3.2 选择决策树
markdown
任务到来
│
├─ 是否需要深度推理/架构决策？
│ └─ 是 → Opus 4.5
│
├─ 是否是日常开发/代码审查/编排？
│ └─ 是 → Sonnet 4.6
│
└─ 是否是高频轻量任务/Worker Agent？
└─ 是 → Haiku 4.53.3 ECC Agent 中的模型选择
看看 ECC 的 Agent 是怎么选模型的：
| Agent | Model | 原因 |
|---|---|---|
planner |
opus | 规划需要最强推理能力 |
architect |
opus | 架构决策需要深度分析 |
tdd-guide |
sonnet | 日常开发任务 |
code-reviewer |
sonnet | 代码审查是常规操作 |
build-error-resolver |
sonnet | 修复错误需要编码能力 |
关键发现：只有需要"想清楚"的 Agent 用 Opus（planner、architect），需要"做出来"的 Agent 用 Sonnet。
3.4 成本优化建议
markdown
成本 = 模型单价 × Token 消耗
降低成本的三个杠杆：
1. 模型降级：能用 Haiku 就不用 Sonnet，能用 Sonnet 就不用 Opus
2. 减少 Token：Strategic Compact、精简 Prompt、减少不必要的上下文
3. 减少 MCP：用 CLI + Skills 替代 MCP，减少工具定义的 Token 消耗四、会话持久化三件套
ECC 通过三个 Hook 实现会话状态的持久化：
4.1 三件套概览
bash
┌────────────────────────────────────────────────┐
│ 会话持久化三件套 │
│ │
│ ┌─────────────────┐ │
│ │ SessionEnd Hook │ 会话结束时自动保存 │
│ │ "保存当前进度" │ → 存储到 .claude/sessions/ │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │SessionStart Hook│ 新会话开始时自动恢复 │
│ │ "恢复上次进度" │ ← 读取 .claude/sessions/ │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │PreCompact Hook │ 压缩前自动保存快照 │
│ │ "压缩前保存" │ → 防止压缩丢失关键信息 │
│ └─────────────────┘ │
└────────────────────────────────────────────────┘4.2 工作流程
css
会话 A：
工作中... → 上下文接近 80%
│
├─ PreCompact Hook 触发 → 保存当前状态快照
│
└─ 继续工作... → 会话结束
│
└─ SessionEnd Hook 触发 → 保存最终状态
会话 B（新的会话）：
│
├─ SessionStart Hook 触发 → 恢复会话 A 的状态
│
└─ 从上次中断的地方继续4.3 手动命令
除了自动 Hook，你也可以手动管理会话：
| 命令 | 作用 |
|---|---|
/save-session |
手动保存当前会话状态 |
/resume-session |
恢复指定的历史会话 |
/sessions |
查看所有保存的会话列表 |
/checkpoint |
创建一个命名检查点（比 save-session 更精细） |
最佳实践：
- 完成一个重要阶段后手动
/save-session - 在做有风险的操作前
/checkpoint - 开始新会话时用
/resume-session恢复上下文
五、动态上下文三模式
ECC 支持根据任务类型切换不同的上下文模式。每种模式会加载不同的指令集，引导 AI 以不同的方式工作：
5.1 三种模式
| 模式 | 上下文文件 | 工作方式 | 适用场景 |
|---|---|---|---|
| dev | contexts/dev.md |
代码优先 --- 快速编码、最小讨论 | 功能实现、Bug 修复 |
| review | contexts/review.md |
审查模式 --- 仔细检查、分级报告 | 代码审查、PR 审查 |
| research | contexts/research.md |
先理解再行动 --- 广泛搜索、深入分析 | 技术调研、架构决策 |
5.2 模式对比
同一个任务在不同模式下的行为差异：
任务："这个函数有性能问题"
| 模式 | 行为 |
|---|---|
| dev | 直接定位瓶颈、写优化代码、跑基准测试 |
| review | 分析代码复杂度、列出所有潜在问题、给出分级建议 |
| research | 搜索类似场景的解决方案、比较多种优化策略、写分析报告 |
5.3 切换时机
markdown
开始新功能 → research 模式（先理解需求和技术方案）
│
▼
方案确定 → dev 模式（快速编码实现）
│
▼
代码写完 → review 模式（仔细审查质量和安全）
│
▼
修复问题 → dev 模式（快速修复审查发现的问题）六、Extended Thinking
6.1 什么是 Extended Thinking
Extended Thinking 允许模型在给出回答之前进行更深入的内部推理。默认开启，预留最多 31,999 tokens 用于思考。
css
普通模式：
问题 → 直接回答
Extended Thinking 模式：
问题 → [内部推理 31,999 tokens] → 更深思熟虑的回答6.2 控制方式
| 操作 | 方法 |
|---|---|
| 切换开关 | Option+T（macOS）/ Alt+T（Windows/Linux） |
| 配置文件 | ~/.claude/settings.json 中设置 alwaysThinkingEnabled |
| 预算上限 | export MAX_THINKING_TOKENS=10000 |
| 查看思考过程 | Ctrl+O 启用 Verbose 模式 |
6.3 Plan Mode
当面对复杂任务时，可以结合 Extended Thinking 使用 Plan Mode：
- 开启 Extended Thinking（默认已开启）
- 启用 Plan Mode --- AI 会先输出结构化计划
- 多轮审查 --- 让 AI 从不同角度检视计划
- 确认后执行
Plan Mode 特别适合：
- 涉及多文件的重构
- 架构变更
- 不确定最佳方案的场景
七、综合策略表
根据任务类型，选择合适的模型、上下文模式和管理策略：
| 任务类型 | 推荐模型 | 上下文模式 | 上下文策略 |
|---|---|---|---|
| 架构决策 | Opus 4.5 | research | 开启 Extended Thinking + Plan Mode |
| 新功能开发 | Sonnet 4.6 | dev | 每个 TDD 循环后 Strategic Compact |
| 代码审查 | Sonnet 4.6 | review | 审查结束后 Compact |
| Bug 修复 | Sonnet 4.6 | dev | 单次会话完成 |
| Worker Agent | Haiku 4.5 | dev | 最小上下文，频繁调用 |
| 技术调研 | Opus 4.5 | research | 广泛搜索，保留结论 |
| 文档更新 | Haiku 4.5 | dev | 低上下文敏感度 |
八、本课练习
练习 1：模型选择判断（10 分钟）
为以下 6 个场景选择合适的模型，并说明理由：
- 为一个 React 组件写单元测试
- 设计一个微服务架构方案
- 批量重命名 20 个文件中的变量
- 审查一个包含安全敏感代码的 PR
- 研究是否应该从 REST 迁移到 GraphQL
- 修复一个 CSS 样式 Bug
练习 2：上下文管理模拟（15 分钟）
假设你正在用 Claude Code 开发一个新功能，上下文窗口已经用到 75%。你需要：
- 决定是否要 Strategic Compact
- 列出你会保留的关键信息
- 列出你可以安全丢弃的信息
- 写出 Compact 后的"恢复摘要"
练习 3：三模式对比（20 分钟）
选一段你自己写过的代码（或本课程前面练习的代码），用三种不同的上下文模式分别处理同一个改进任务：
- dev 模式：直接优化代码
- review 模式：审查并列出所有问题
- research 模式：研究最佳实践后给出建议
对比三种模式的输出差异。
练习 4（选做）：计算 MCP 成本
列出你当前启用的所有 MCP 服务器，估算它们总共占用多少上下文空间。如果超过 10 个，找出哪些可以用 CLI + Skills 替代。
九、本课小结
| 你应该记住的 | 内容 |
|---|---|
| 上下文安全区 | 0-80% 正常工作，80-100% 仅限简单任务 |
| Strategic Compact | 在逻辑断点主动压缩，优于自动压缩 |
| 模型三层 | Haiku（轻量高频）、Sonnet（主力开发）、Opus（深度推理） |
| MCP 陷阱 | >10 个 MCP 时上下文从 200K 压到 ~70K |
| 持久化三件套 | SessionEnd 保存、SessionStart 恢复、PreCompact 压缩前保存 |
| 三种上下文模式 | dev（代码优先）、review（审查模式）、research（先理解再行动） |
| Extended Thinking | 默认开启 31,999 tokens，Option+T 切换 |
十、下节预告
第 16 课：多代理编排 --- 并行、视角与隔离
到目前为止，我们一直在使用单个 Agent。下节课我们将学习如何让多个 Agent 协作：什么时候并行、什么时候顺序、如何用多视角分析同一个问题、如何用 Git Worktree 隔离不同 Agent 的工作区。这是 ECC 最强大也最复杂的能力。
预习建议 ：阅读 rules/common/agents.md，特别是 Parallel Task Execution 和 Multi-Perspective Analysis 两节。