<!-- title: 上下文工程实战：精准操控对话流 -->

# Claude Code上下文工程实战：精准操控Token与对话流

## 概述

上下文工程（Context Engineering）是2026年AI编程领域最核心的新兴学科。它超越了传统的提示工程，将整个对话过程视为一个可度量、可优化、可分层管理的系统工程。本教程面向有一定Claude Code使用经验的开发者，系统讲解CLAUDE.md三级层级架构设计、对话流精准拆分策略、Token预算管理、Session生命周期控制四大核心能力，帮助你将Claude Code的有效输出质量提升50%以上。

**适用人群**：已使用Claude Code超过1个月、希望从"能用"迈向"精通"的开发者

**学习目标**：
- 掌握CLAUDE.md三层作用域的精确配置方法
- 学会根据任务复杂度选择最佳对话分解策略
- 建立Token预算意识，避免上下文窗口污染
- 构建适合自己项目的上下文管理工作流

## 前置条件

- Claude Code ≥ 1.0.70（支持层级CLAUDE.md和/rules系统）
- 至少有一个正在开发中的项目
- 了解基本的Markdown语法
- 理解LLM上下文窗口的基本概念（Context Window）

---

## 第一部分：上下文工程的底层逻辑

### 为什么"上下文工程"比"提示工程"更重要？

Anthropic在2025年9月发布的工程博客《Effective Context Engineering for AI Agents》中明确指出：**上下文是AI Agent最关键的有限资源**。每个Token都会被模型同时处理，无关信息不仅浪费配额，还会稀释有效信号的浓度。

Claude Code的上下文窗口包含以下几个组成部分：

```
┌──────────────────────────────────────────┐
│           Claude Code 上下文窗口          │
├──────────────────────────────────────────┤
│  系统提示词 (System Prompt)              │ ← 固定，不可控
│  全局 CLAUDE.md (~/.claude/CLAUDE.md)    │ ← 你控制
│  项目 CLAUDE.md (项目根目录)              │ ← 你控制
│  目录 CLAUDE.md (当前工作子目录)          │ ← 你控制
│  .claude/rules/*.md (规则文件)           │ ← 你控制
│  /memory 内容                            │ ← 你控制
│  对话历史 (Conversation History)          │ ← 动态增长
│  工具调用结果 (Tool Results)             │ ← 动态增长
│  当前用户消息                             │ ← 即时输入
└──────────────────────────────────────────┘
```

**核心洞察**：在200K Token的上下文窗口中，真正用于"思考"的空间是有限的。CLAUDE.md写得越多，留给代码理解和推理的空间就越少。上下文工程的本质是**在信息充分性和Token经济性之间找到最优解**。

### 上下文污染的三大症状

1. **指令遗忘**：Claude Code在长对话后半段开始忽略CLAUDE.md中的规则
2. **重复劳动**：反复读取相同文件，工具调用结果占满上下文
3. **回答质量下降**：从精准的代码修改退化为泛泛的建议

当你观察到以上任何一种症状，就是上下文工程介入的时机。

---

## 第二部分：CLAUDE.md三级层级架构

### 2.1 三级作用域体系

Claude Code采用三级CLAUDE.md加载机制，从全局到局部优先级递增：

| 层级 | 文件位置 | 作用域 | 加载时机 |
|------|----------|--------|----------|
| L1-全局 | `~/.claude/CLAUDE.md` | 所有项目 | 每次会话 |
| L2-项目 | `项目根目录/CLAUDE.md` | 当前项目 | 进入项目时 |
| L3-目录 | `子目录/CLAUDE.md` | 当前工作目录 | 操作涉及该目录时 |

当指令冲突时，**更具体的层级覆盖更通用的层级**（L3 > L2 > L1）。Anthropic官方将此称为"specificity over generality"原则。

### 2.2 全局CLAUDE.md（L1）：个人偏好层

这个文件定义你的个人编码风格和通用规则，适用于所有项目。

```markdown
# Global Preferences

## Language
- 默认使用中文回复，代码注释用英文
- 变量命名和函数名保持英文

## Code Style
- 优先使用函数式编程风格
- 使用 const 而非 let，禁止 var
- 单引号优先，行末不加分号（JavaScript）
- 最大行宽 100 字符

## Safety Rules
- NEVER commit .env, credentials, secrets
- NEVER use `any` type in TypeScript
- ALWAYS check for null/undefined before access

## Workflow
- 修改代码后主动运行相关测试
- 不自动 commit，等我确认
- 优先编辑现有文件而非创建新文件
```

**关键原则**：全局文件控制在 **30行以内**。只放跨项目通用的硬性规则。具体的技术栈信息留给项目级。

### 2.3 项目CLAUDE.md（L2）：架构与约定层

这是最核心的配置文件，定义项目的技术上下文。以下是经过实战验证的结构模板：

```markdown
# Project: E-Commerce Platform

## Tech Stack
- Framework: Next.js 15 (App Router)
- Language: TypeScript 5.4 (strict mode)
- Database: PostgreSQL 16 + Prisma ORM
- Auth: NextAuth.js v5
- Testing: Vitest + Playwright
- Styling: Tailwind CSS + shadcn/ui

## Architecture
```
src/
├── app/              # Next.js App Router pages
│   ├── (auth)/       # Auth group route
│   ├── (shop)/       # Shop group route
│   └── api/          # API routes
├── components/       # React components
│   ├── ui/           # shadcn base components (DO NOT EDIT)
│   └── features/     # Feature-specific components
├── lib/              # Utility functions
├── server/           # Server-only code
└── tests/            # Test files mirror src/ structure
```

## Conventions
- API routes: app/api/[resource]/route.ts
- Components: PascalCase files, named exports
- Server actions: co-locate with page, name as actions.ts
- Database queries: always through Prisma, never raw SQL
- Error handling: use Result<T, E> pattern from lib/result.ts

## Critical Rules
- DO NOT modify files in components/ui/ (managed by shadcn)
- ALWAYS use server-side validation with zod schemas
- Payment logic in server/payment/ — ask before modifying
- Run `pnpm test` before suggesting completion
```

**核心原则**：
- 控制在 **60行以内**（经验值：每100行CLAUDE.md消耗约150-200 Token）
- 项目结构用树形图而非文字描述（更省Token，更易解析）
- "Critical Rules"放在最显眼的位置
- 只写AI不知道的信息（框架版本、自定义约定、禁忌操作）

### 2.4 目录CLAUDE.md（L3）：精确指令层

当项目包含多个独立模块时，在每个子目录放置轻量级CLAUDE.md：

**`src/components/ui/CLAUDE.md`**：
```markdown
# UI Components (shadcn/ui managed)
- 这些组件由 shadcn CLI 管理
- 只通过 `npx shadcn@latest add <component>` 修改
- 如需自定义样式，在 components/features/ 中创建包装组件
```

**`src/server/payment/CLAUDE.md`**：
```markdown
# Payment Module - HIGH SECURITY
- 所有金额计算使用 decimal.js，禁止浮点数
- 退款逻辑必须经过双人审查
- 测试覆盖率要求：100%
- 修改前必须先阅读 README-security.md
```

### 2.5 .claude/rules/ 系统补充

除了CLAUDE.md，还可以通过`.claude/rules/`目录添加条件触发规则：

```
.claude/
├── rules/
│   ├── typescript.md      # 所有.ts/.tsx文件操作时加载
│   ├── testing.md         # 涉及测试文件时加载
│   └── database.md        # 涉及prisma/sql文件时加载
```

**`typescrules.md`**示例：
```markdown
- 使用 `interface` 定义对象类型，`type` 用于联合类型和工具类型
- Props 必须用显式 interface 定义，禁止 inline type
- 使用 Zod schema 验证所有外部输入
```

Rules文件的优势是**按需加载**——只在相关文件被操作时才注入上下文，避免全局CLAUDE.md臃肿。

---

## 第三部分：对话流精准拆分策略

### 3.1 对话复杂度分级模型

不是所有任务都需要长对话。根据任务复杂度选择对话策略：

```
┌─────────────────────────────────────────────────┐
│             对话复杂度分级模型                      │
│                                                   │
│  Level 1: 单轮指令     (1-3 轮)                   │
│  ├── 修个 typo                                     │
│  ├── 加个 console.log                              │
│  └── 格式化代码                                    │
│                                                   │
│  Level 2: 聚焦任务     (5-15 轮)                   │
│  ├── 实现一个新 API endpoint                       │
│  ├── 修复一个有明确报错的 bug                       │
│  └── 重构一个函数                                  │
│                                                   │
│  Level 3: 探索性任务   (15-40 轮)                  │
│  ├── 实现一个新功能模块                             │
│  ├── 跨文件重构                                    │
│  └── 性能优化                                      │
│                                                   │
│  Level 4: 架构任务     (拆分为多个 Level 2-3)       │
│  ├── 新增一个完整特性                               │
│  ├── 数据库迁移 + API + UI 全链路                   │
│  └── 模块间接口重构                                 │
└─────────────────────────────────────────────────┘
```

### 3.2 Level 1-2：直接执行模式

对于简单任务，直接用一句话描述清楚：

```
# 好的单轮指令示例
"在 src/api/auth.ts 第42行，将错误日志级别从 warn 改为 error，同时添加错误码 E0042"

# 坏的单轮指令示例
"帮我改一下那个文件"
```

**指令质量公式**：具体位置 + 期望行为 + 约束条件 = 高质量单轮指令

### 3.3 Level 3：Plan-Execute模式

中等复杂度任务，使用Plan Mode拆解：

**Step 1**：进入Plan Mode（`Ctrl+G` 或输入"plan mode"）

```
我需要给商品详情页添加一个"相似商品推荐"模块。
数据源是 /api/recommendations API。
要求：卡片式布局，最多显示6个商品，支持懒加载。
```

**Step 2**：审查Claude Code生成的计划

Claude Code会输出类似：
```
1. 创建 RecommendationCard 组件 (src/components/features/)
2. 创建 useRecommendations hook (src/hooks/)
3. 在 ProductDetail 页面集成 (src/app/(shop)/products/[id]/page.tsx)
4. 添加加载骨架屏
5. 编写单元测试
```

**Step 3**：确认计划后自动进入执行模式

Plan Mode的核心价值：**在写代码前消耗约500-1000 Token做规划，避免后续数千Token的返工**。

### 3.4 Level 4：分而治之模式

这是最关键也最常被忽略的策略。面对复杂任务，**拆分为多个独立Session**：

```
# 错误做法：一个Session搞定全部
"帮我实现用户注册功能，包括表单验证、API端点、数据库表、邮件通知和单元测试"
（消耗 8万+ Token，上下文严重污染，后期质量骤降）

# 正确做法：拆分为5个独立Session
Session 1: "设计用户注册的数据库Schema（Prisma migration）"
Session 2: "实现 /api/auth/register POST端点，含输入验证"
Session 3: "创建注册表单组件，含客户端验证"
Session 4: "集成邮件通知服务（欢迎邮件）"
Session 5: "为以上所有模块编写测试"
```

每个Session保持在 **20-30轮对话以内**，这是经验中的"质量甜蜜点"。

### 3.5 分治策略的Mermaid流程图

```mermaid
flowchart TD
    A[接收复杂任务] --> B{复杂度评估}
    B -->|Level 1-2| C[直接执行<br/>单Session完成]
    B -->|Level 3| D[Plan Mode<br/>先规划后执行]
    B -->|Level 4| E[任务分解]

    E --> F[拆分为3-5个<br/>独立子任务]
    F --> G[每个子任务<br/>独立Session]

    G --> H[Session 1:<br/>数据层]
    G --> I[Session 2:<br/>API层]
    G --> J[Session 3:<br/>UI层]
    G --> K[Session 4:<br/>集成测试]

    H --> L[用 --resume 继续]
    I --> L
    J --> L
    K --> L

    L --> M[最终集成<br/>验收]

    C --> N{质量检查}
    D --> N
    M --> N

    N -->|通过| O[✅ 完成]
    N -->|失败| P[定位问题<br/>开新Session修复]
    P --> O

    style E fill:#f9f,stroke:#333
    style G fill:#bbf,stroke:#333
    style N fill:#bfb,stroke:#333
```

---

## 第四部分：Token预算管理

### 4.1 Token消耗的隐藏真相

Claude Code的Token消耗远不止你看到的文字。以下是典型的Token消耗分布：

| 上下文组成 | Token占比（估算） | 可控性 |
|------------|-------------------|--------|
| 系统提示词 | 5-8% | ❌ 不可控 |
| CLAUDE.md 全层级 | 2-5% | ✅ 高度可控 |
| 工具调用+结果 | 40-60% | ⚠️ 间接可控 |
| 对话历史 | 25-40% | ✅ 可控 |
| 当前用户消息 | 1-3% | ✅ 可控 |

**最大Token黑洞是工具调用结果**。一次文件读取可能返回2000 Token，一次Grep搜索可能返回5000 Token。10轮对话后，累积的工具调用结果可能占据上下文的60%以上。

### 4.2 Token节省的实战技巧

#### 技巧1：精确的文件读取

```
# ❌ 浪费：读取整个大文件
"读一下 src/api/auth.ts"

# ✅ 高效：指定行范围
"读 src/api/auth.ts 第30-50行，只看 validateToken 函数"
```

#### 技巧2：精确的搜索范围

```
# ❌ 浪费：全项目搜索
"搜索所有包含 'user' 的文件"

# ✅ 高效：限定目录和文件类型
"在 src/api/ 目录的 .ts 文件中搜索 'validateToken' 函数定义"
```

#### 技巧3：及时压缩对话

当对话超过30轮或感觉Claude Code开始"遗忘"早期指令时：

```
/compact
```

这会触发上下文压缩，Claude Code会总结之前的对话要点，释放Token空间。**关键时机**：
- 完成一个大步骤后
- 切换到新子任务前
- 感觉输出质量下降时

#### 技巧4：用 /clear 而非继续叠加

当你完成了数据层的开发，准备开始UI层时：

```
/clear
现在开始实现用户列表页面UI。根据 src/types/user.ts 中的 User interface...
```

`/clear`清空对话历史，但**CLAUDE.md和/memory的内容不会丢失**。这比分发污染的旧上下文高效得多。

#### 技巧5：限制Grep结果

```
# ❌ 可能返回海量结果
"搜索所有TODO注释"

# ✅ 限制数量
"搜索TODO注释，只看前10条结果"
```

### 4.3 Token预算规划模板

对于一个200K Token的上下文窗口，推荐的预算分配：

```
Token 预算分配（200K 总量）
├── 系统提示词        ≈ 10K   (5%)    [固定]
├── CLAUDE.md 全层级   ≈ 4K    (2%)    [精简配置]
├── /memory            ≈ 2K    (1%)    [关键决策]
├── 对话历史           ≤ 80K   (40%)   [/compact 控制]
├── 工具调用结果       ≤ 60K   (30%)   [精确指令控制]
└── 留给模型推理       ≥ 44K   (22%)   [必须保障的空间]
```

**铁律**：始终为模型推理保留至少20%的上下文空间。当推理空间被压缩到15%以下，输出质量会显著下降。

---

## 第五部分：Session生命周期管理

### 5.1 Session的核心命令

| 命令 | 用途 | 上下文行为 |
|------|------|------------|
| `claude` | 启动新会话 | 全新上下文 |
| `claude --continue` | 继续最近会话 | 恢复完整上下文 |
| `claude --resume` | 选择历史会话恢复 | 恢复选定的完整上下文 |
| `/compact` | 压缩当前会话 | 保留摘要，释放空间 |
| `/clear` | 清空对话历史 | 只保留CLAUDE.md和/memory |

### 5.2 Session管理的工作流

```text
flowchart LR
    A[claude] --> B[Session 1<br/>数据库设计]
    B --> C{完成?}
    C -->|是| D[/compact<br/>保存关键决策]

    D --> E[claude<br/>Session 2<br/>API开发]
    E --> F{需要回看<br/>Session 1?}
    F -->|是| G[claude --resume<br/>选择Session 1]
    F -->|否| H[继续Session 2]

    G --> I[复制需要的<br/>上下文信息]
    I --> E

    H --> J{完成?}
    J -->|是| K[/compact]

    K --> L[claude<br/>Session 3<br/>UI开发]
    L --> M[...重复流程]

    style A fill:#e1f5fe
    style D fill:#fff3e0
    style G fill:#fce4ec
    style K fill:#fff3e0
```

### 5.3 /memory：跨Session持久记忆

`/memory` 命令将关键信息写入持久存储，在所有新Session中自动加载。这是**跨Session传递上下文的正确方式**：

```
# 在Session 1中（数据库设计完成后）
/memory
添加以下内容：
- 用户表使用 UUID 主键，非自增ID
- 所有时间字段使用 TIMESTAMPTZ 类型
- Prisma schema 位于 prisma/schema.prisma
```

在后续的所有Session中，这些信息会自动出现在上下文中，无需重复说明。

### 5.4 /memory 的最佳实践

1. **只记录决策，不记录过程**：写"使用UUID主键"而非"经过讨论决定使用UUID"
2. **保持精简**：/memory内容超过50行就需要清理
3. **定期审计**：每完成一个大模块，审查并清理过时的/memory条目
4. **用结构化格式**：

```
# /memory 内容示例

## Architecture Decisions
- [ADR-001] UUID as primary key for all user-facing tables
- [ADR-002] Event-driven architecture for order processing
- [ADR-003] Redis for session cache, PostgreSQL for persistence

## API Conventions
- RESTful endpoints: /api/v1/{resource}
- Error format: { code: string, message: string, details?: object }
- Pagination: cursor-based for lists > 100 items

## Current Sprint Focus
- Feature: User notification system
- Priority: Real-time via WebSocket > Email > SMS
- Deadline: Sprint ends 2026-05-30
```

---

## 第六部分：实战案例——电商平台支付模块

### 场景描述

你需要为一个Next.js电商平台实现完整的支付流程，包括：支付方法选择、Stripe集成、订单状态管理、支付失败重试、Webhook处理。

### Step 1：项目级CLAUDE.md准备

在项目根目录的CLAUDE.md中追加：

```markdown
## Payment Module
- Provider: Stripe (use official stripe npm package)
- Currency: CNY (人民币)
- Testing: Use Stripe test mode with test keys
- Security: Payment logic in server/payment/ ONLY
- NEVER log full card numbers or payment tokens
```

### Step 2：拆分为5个独立Session

**Session 1：数据模型设计**

```bash
claude
```

```
我需要设计支付相关的数据库Schema（使用Prisma）。
包含以下实体：
1. PaymentMethod - 用户保存的支付方式
2. Payment - 支付记录
3. Refund - 退款记录

要求：
- 使用 UUID 主键
- 所有金额用 BigInt 存储（单位：分）
- 状态字段用 Enum
- 创建必要的索引
```

完成后：`/compact` → 记录关键决策到 `/memory`

**Session 2：Stripe集成层**

```bash
claude
```

```
基于以下 Prisma schema（提供Session 1的产出），
实现 Stripe 支付集成层：
1. src/server/payment/stripe-client.ts - Stripe客户端初始化
2. src/server/payment/create-payment.ts - 创建支付Intent
3. src/server/payment/confirm-payment.ts - 确认支付
4. src/server/payment/webhook-handler.ts - Webhook处理

参考 /memory 中的架构决策。
所有金额从分转换为Stripe要求的最小单位。
```

**Session 3：API端点**

```bash
claude
```

```
实现支付相关的API路由（Next.js App Router）：
1. POST /api/v1/payments/create - 创建支付
2. POST /api/v1/payments/{id}/confirm - 确认支付
3. GET /api/v1/payments/{id}/status - 查询状态
4. POST /api/v1/payments/stripe-webhook - Webhook回调

要求：
- 使用 zod 验证所有输入
- 错误格式遵循项目约定（见CLAUDE.md）
- Webhook需要验证Stripe签名
```

**Session 4：前端交互**

```bash
claude --continue   # 延续Session 3，因为需要API接口上下文
```

```
基于刚创建的API端点，实现前端支付流程：
1. PaymentMethodSelector 组件 - 选择支付方式
2. PaymentForm 组件 - 输入支付信息
3. PaymentStatus 组件 - 实时状态展示
4. PaymentErrorBoundary - 支付错误处理

使用 shadcn/ui 组件库。
移动端优先的响应式设计。
```

**Session 5：集成测试**

```bash
claude
```

```
为支付模块编写完整的测试套件：
1. 测试文件结构镜像 src/ 目录
2. 单元测试：stripe-client, create-payment, confirm-payment
3. API集成测试：使用 Vitest + MSW mock
4. E2E测试场景：完整支付流程（Playwright）

Stripe mock 使用官方 @stripe/stripe-js 的测试工具。
覆盖率目标：90%+
```

### Step 3：最终集成

```bash
claude
```

```
支付模块各层已开发完成。请执行以下集成检查：
1. 运行 pnpm test 确认所有测试通过
2. 运行 pnpm build 确认编译无错误
3. 运行 pnpm lint 确认代码风格一致
4. 检查是否有TODO或临时hack需要清理
5. 验证 Webhook URL 配置正确
```

### 关键数据对比

| 指标 | 不拆分Session | 拆分Session（本方案） |
|------|--------------|----------------------|
| 总Token消耗 | ~180K+ | ~90K（5×~18K） |
| 代码质量（后半段） | 明显下降 | 全程稳定 |
| 返工率 | 约30% | <5% |
| 调试时间 | 45分钟+ | <10分钟 |

---

## 第七部分：高级对话模式

### 7.1 "上下文预热"模式

在开始复杂任务前，先让Claude Code"热身"：

```
请先阅读以下文件，理解当前代码结构：
- src/types/index.ts
- src/lib/utils.ts
- CLAUDE.md

然后用一句话总结你理解的项目架构。
```

这消耗约2000-3000 Token，但能显著提升后续指令的命中率。

### 7.2 "渐进式展开"模式

面对不确定需求时，不要一次性给出完整指令：

```
# Round 1: 探索
"分析 src/api/orders/ 目录，列出所有现有的订单相关端点及其功能"

# Round 2: 设计
"基于现有端点，设计一个订单退款API。只给出接口设计，不写代码"

# Round 3: 确认
"接口设计看起来不错。现在实现 POST /api/v1/orders/{id}/refund 端点"

# Round 4: 验证
"运行相关测试，确认退款逻辑正确处理了边界情况"
```

### 7.3 "上下文接力"模式

当必须跨Session传递大量上下文时：

```
# Session A 结束前
/compact
请将以下关键信息保存到上下文摘要中：
1. 支付模块使用了Event Sourcing模式
2. OrderEvents表记录所有状态变更
3. Query端通过materialized view读取
4. 当前已完成写入端，读取端待开发

# Session B 开始时
claude --continue
继续开发支付模块的读取端。根据 /compact 摘要中的架构说明...
```

### 7.4 "上下文隔离"模式

使用Worktree实现物理级别的上下文隔离：

```bash
# 在主分支处理紧急hotfix
claude "修复用户登录的空指针异常"
# → 在main分支上工作

# 同时在worktree中开发新功能
claude worktree add feature-payment
cd .claude/worktrees/feature-payment
claude "实现支付模块"
# → 在独立分支上工作，上下文完全隔离
```

---

## 第八部分：常见问题与排错

### Q1：CLAUDE.md修改后不生效怎么办？

Claude Code在每次新消息时重新读取CLAUDE.md。如果修改后不生效：
- 确认文件路径正确（全局：`~/.claude/CLAUDE.md`，项目：`项目根/CLAUDE.md`）
- 用 `/clear` 清除对话历史后重试
- 检查是否有编码问题（确保UTF-8无BOM）

### Q2：如何判断上下文是否已经"爆了"？

观察以下信号：
- Claude Code开始"忘记"刚才说过的话
- 工具调用结果中出现重复读取
- 回答变得笼统，不再引用具体代码
- 出现"based on the general structure"等模糊表述

此时应立即 `/compact` 或 `/clear`。

### Q3：/compact 后丢失了重要上下文怎么办？

`/compact` 后如果关键信息丢失：
- 使用 `/memory` 持久化关键决策（compact不影响memory）
- 在compact后的第一条消息中手动补充丢失的上下文
- 使用 `claude --resume` 回到compact前的状态

### Q4：大型项目如何避免CLAUDE.md臃肿？

- **超过80行的CLAUDE.md就该拆分**
- 将技术栈细节移入 `.claude/rules/` 按需加载
- 用目录级CLAUDE.md处理模块特定规则
- 架构概览用树形图替代文字描述

### Q5：对话中如何引用之前的代码产出？

```
# ❌ 低效
"之前你写的那个用户验证函数..."

# ✅ 高效
"参考 src/lib/auth.ts 中的 validateSession 函数的模式，为支付验证写一个类似的函数"
```

通过文件路径引用而非对话历史，避免重新加载大量历史Token。

---

## 上下文工程自查清单

每次开始新Session前，快速过一遍：

- [ ] CLAUDE.md是否精简（全局<30行，项目<80行）
- [ ] 当前任务的复杂度级别（L1-L4）
- [ ] 是否需要拆分为多个Session
- [ ] /memory中是否有需要更新或清理的条目
- [ ] 是否需要先"预热"让Claude Code理解项目结构
- [ ] 对话超过30轮时，是否该/compact或/clear
- [ ] 完成一个阶段后，是否记录了关键决策到/memory

---

## 延伸阅读

- [Anthropic官方：Effective Context Engineering for AI Agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) — 上下文工程的理论基础
- [Claude Code官方最佳实践](https://code.claude.com/docs/en/best-practices) — Anthropic官方推荐的工作流
- [Claude Code CLAUDE.md层级解析](https://www.promptcertifications.com/learn/posts/understanding-the-claude-md-hierarchy-user-project-and-directory-scopes-explained) — 三级作用域详解
- [Datacamp: Writing the Best CLAUDE.md](https://www.datacamp.com/tutorial/writing-the-best-claude-md) — CLAUDE.md写作指南
- [SFEIR Institute: Context Management Optimization](https://institute.sfeir.com/en/claude-code/claude-code-context-management/optimization/) — 上下文优化深度指南

## 参考来源

1. [Effective context engineering for AI agents — Anthropic Engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) — Anthropic官方上下文工程核心理论，提出"Context is a critical but finite resource"
2. [Best practices for Claude Code — Claude Code Docs](https://code.claude.com/docs/en/best-practices) — 官方最佳实践文档，涵盖环境配置到团队协作
3. [Claude Code Best Practices: 15 Tips from 6 Projects](https://aiorg.dev/blog/claude-code-best-practices) — 来自6个生产项目的实战经验，包含CLAUDE.md配置和对话模式
4. [Writing the Best CLAUDE.md: A Complete Guide — DataCamp](https://www.datacamp.com/tutorial/writing-the-best-claude-md) — 系统化的CLAUDE.md写作方法论
5. [Context Management Optimization Guide — SFEIR Institute](https://institute.sfeir.com/en/claude-code/claude-code-context-management/optimization/) — 上下文管理策略与Token优化技巧

---

**训练营适用性评估**：
- **适合类型**：中级开发者训练营（需有1个月以上Claude Code经验）
- **预计教学时长**：3-4小时（含实操练习）
- **推荐练习**：学员自带项目，按教程重构CLAUDE.md三级架构，并用分治策略完成一个Level 4任务
- **前置课程**：Claude Code零基础入门 + 基础操作熟练

*品牌信息：本文由Claude Code深度使用专家创作，基于Claude Code 2026年最新版本特性编写。*

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)