上下文管理

用Claude Code时,你肯定遇到过:

项目文件太多,Claude理解不了整体结构
对话时间长,前面讨论的内容被"遗忘"
代码库太大,超过处理能力
重要信息在对话中丢失

这些就是上下文管理要解决的问题。

上下文管理是Claude Code最核心的高级特性之一,掌握它能让Claude处理更大规模的项目,保持更长时间的有效对话,提高代码生成准确性。

什么是上下文窗口

基本概念

**上下文窗口(Context Window)**就是Claude在对话中能"记住"和处理的文本总量。相当于Claude的"短期记忆容量"。

Claude Code支持200K tokens的超大上下文窗口,就是:

约15万个英文单词
约10万个中文汉字
相当于几百个代码文件

Token与文本的换算

1个英文单词 ≈ 1.3 tokens
1个中文字符 ≈ 2 tokens
1行代码(80字符) ≈ 20-40 tokens
1个文件(500行) ≈ 10K-20K tokens

实际测试:

# 查看项目的代码行数
find src -name "*.ts" -o -name "*.tsx" | xargs wc -l

# 输出示例
# 5000 total lines
# 估算tokens: 5000 × 30 (平均) = 150K tokens

上下文的组成

每次对话时,上下文由以下部分组成:

总上下文 = CLAUDE.md内容
         + 项目文件内容
         + 对话历史
         + 当前提示词
         + Claude的思考过程

示例:

[系统提示词]              ~5K tokens
    ↓
[CLAUDE.md配置]          ~3K tokens
    ↓
[项目文件: package.json] ~1K tokens
[项目文件: tsconfig.json]~2K tokens
[项目文件: src/index.ts] ~5K tokens
    ↓
[对话历史 - 第1轮]       ~2K tokens
[对话历史 - 第2轮]       ~3K tokens
...
[对话历史 - 第10轮]      ~8K tokens
    ↓
[当前用户提问]           ~1K tokens
    ↓
[Claude的思考过程]       ~5K tokens
--------------------------------
总计:                     ~35K tokens

剩余可用上下文:           ~165K tokens

200K上下文的优势

1. 处理大型代码库

场景: 重构一个包含500+文件的React项目

# 项目规模统计
find . -name "*.tsx" -o -name "*.ts" | wc -l
# 输出: 523 files

# 传统方式(小上下文)
你: 帮我重构用户认证模块
Claude: 需要我先看哪些文件?
你: auth.ts, user.ts, login.tsx...
Claude: 好的,一个一个读取...
[需要多轮对话才能理解全貌]

# Claude Code方式(200K上下文)
你: 帮我重构用户认证模块,分析所有相关文件

Claude: 我已经分析了认证相关的所有文件:
- src/auth/auth.ts (核心认证逻辑)
- src/auth/providers/ (5个认证提供商)
- src/components/auth/ (12个认证组件)
- src/pages/auth/ (8个认证页面)
- src/middleware/auth.ts (认证中间件)

发现的问题:
1. 认证逻辑分散在多个文件中
2. 状态管理不一致(部分用Context,部分用Redux)
3. 类型定义重复

重构方案:
[一次性给出完整的重构计划]

2. 保持长期对话连贯性

场景: 多天的开发对话

# 第1天 - 初始架构讨论
你: 帮我设计一个电商平台的后端架构
Claude: [设计了微服务架构]

# 第2天 - 继续开发
你: 昨天我们设计的订单服务,现在开始实现
Claude: 记得昨天的设计,订单服务包含:
- 订单创建API
- 库存检查集成
- 支付接口对接
- 物流状态同步

开始实现...

# 第5天 - 添加新功能
你: 给订单服务增加退款功能
Claude: 基于现有订单服务架构,退款功能需要:
1. 复用订单状态机(已存在于OrderStateMachine)
2. 调用支付退款接口(已有PaymentService)
3. 更新库存(已有InventoryService的rollback方法)
4. 发送通知(复用NotificationService)

[完全记得之前的架构设计,无需重新解释]

3. 跨文件引用和依赖分析

场景: 理解复杂的模块依赖

你: 分析Redux store的完整数据流

Claude: 我追踪了整个Redux数据流:

## 数据流路径
[User Action]
    ↓
Component (src/features/user/components/UserList.tsx)
    ↓
Dispatch Action (src/features/user/slice/userActions.ts)
    ↓
Redux Thunk Middleware
    ↓
API Call (src/api/userApi.ts)
    ↓
Response Handler (src/features/user/middleware/userMiddleware.ts)
    ↓
Reducer (src/features/user/slice/userSlice.ts)
    ↓
State Update (src/store/index.ts)
    ↓
Selector (src/features/user/selectors/userSelectors.ts)
    ↓
Component Re-render

## 潜在问题
1. userApi.ts中的错误处理不完整
2. middleware中有重复的日志记录
3. selector缺少memoization优化

4. 全局重构和代码审查

场景: 代码库全面升级

你: 将所有异步函数从Promise改为async/await

Claude: 我扫描了整个项目,发现需要修改的文件:

## 需要修改的文件 (共47个)

### 高优先级 (核心逻辑)
- src/services/userService.ts (15处)
- src/services/orderService.ts (23处)
- src/api/client.ts (8处)

### 中优先级 (工具函数)
- src/utils/asyncHelpers.ts (12处)
- src/utils/dataFetcher.ts (7处)

### 低优先级 (边缘功能)
- src/migrations/ (6个迁移文件)
- src/scripts/ (3个脚本文件)

## 修改策略
1. 先修改核心服务(确保向后兼容)
2. 更新工具函数
3. 批量修改简单文件
4. 运行测试套件验证

开始执行?

上下文优化技巧

1. 精简CLAUDE.md

问题: CLAUDE.md占用过多上下文

优化前 (15K tokens):

# 项目配置

## 详细的TypeScript配置说明
tsconfig.json文件位于项目根目录,它扩展了@tsconfig/react-exact
的配置。编译选项包括:
- strict: true - 启用所有严格类型检查
- target: ES2020 - 编译目标为ES2020
- module: ESNext - 使用ESNext模块系统
- [还有200行详细配置说明...]

## 完整的API文档
### 用户API
POST /api/users - 创建用户
参数:
  username: string (必填,3-20字符)
  email: string (必填,有效邮箱格式)
  password: string (必填,最小8字符,必须包含大小写字母和数字)
  [还有500行API文档...]

优化后 (3K tokens):

# 项目配置

## 技术栈
- React 18 + TypeScript (strict mode)
- Next.js 14 (App Router)
- Redux Toolkit + RTK Query

## 关键规范
- 函数式组件 + Hooks
- 所有函数必须有返回类型
- 使用Zod进行输入验证

## 常用命令
npm run dev    # 开发服务器
npm run build  # 生产构建
npm test       # 运行测试

## 快速参考
- API文档: http://localhost:3000/api-docs
- 组件库: src/components/
- 状态管理: src/store/

## ⚠️ 重要约束
❌ 禁止使用any类型
❌ 禁止在生产环境console.log
❌ 禁止跳过TypeScript错误

节省上下文: 12K tokens (相当于400行代码)

2. 智能文件引用

技巧1: 使用Glob模式而非列出具名文件

优化前:

你: 分析这些React组件的问题
- src/components/Header/Header.tsx
- src/components/Header/Logo.tsx
- src/components/Header/Navigation.tsx
- src/components/Header/UserMenu.tsx
- src/components/Header/SearchBar.tsx
- src/components/Header/NotificationBell.tsx
- [还需要手动列出所有文件...]

优化后:

你: 分析 src/components/Header/ 目录下所有组件的问题

Claude会自动:

# 扫描目录结构
src/components/Header/
├── Header.tsx
├── Logo.tsx
├── Navigation.tsx
├── UserMenu.tsx
├── SearchBar.tsx
└── NotificationBell.tsx

# 批量读取所有文件
# 自动识别共同问题

技巧2: 使用抽象层减少重复内容

优化前:

你: 我有10个API服务文件,内容类似:
- src/api/userService.ts
- src/api/orderService.ts
- src/api/productService.ts
...

每个文件都有类似的模式:
```typescript
// userService.ts (150行)
import { api } from './client';
import type { User } from '../types';

export const userService = {
  async getAll() { ... },
  async getById(id: string) { ... },
  async create(data: UserCreate) { ... },
  async update(id: string, data: UserUpdate) { ... },
  async delete(id: string) { ... },
};

// orderService.ts (150行,几乎相同的结构)
// productService.ts (150行,几乎相同的结构)

**优化后**:

```markdown
你: 我有10个CRUD服务,都遵循这个模式:
```typescript
// 基础CRUD服务模式
export const xxxService = {
  async getAll() { /* GET /api/xxx */ },
  async getById(id) { /* GET /api/xxx/:id */ },
  async create(data) { /* POST /api/xxx */ },
  async update(id, data) { /* PUT /api/xxx/:id */ },
  async delete(id) { /* DELETE /api/xxx/:id */ },
};

请创建一个泛型CRUD服务工厂, 然后重构所有服务使用它。

Claude理解模式后:
```typescript
// 创建泛型工厂(1次,50行)
// 重构10个服务(每个10行)
// 总计: 1500行 → 150行

3. 分阶段对话策略

场景: 大型功能开发

优化前 (一次性讨论):

你: 帮我实现一个完整的博客系统,包括:
- 用户认证(注册/登录/找回密码)
- 文章管理(CRUD/草稿/发布)
- 评论系统(嵌套评论/审核)
- 标签系统
- 搜索功能
- SEO优化
- 管理后台

Claude: [需要生成数千行代码和解释]
[上下文爆炸,容易遗漏细节]

优化后 (分阶段):

# 第1阶段 - 核心架构
你: 先设计博客系统的核心数据模型和API结构
Claude: [专注架构设计,创建TypeScript类型和基础API]

# 第2阶段 - 认证模块
你: 实现用户认证模块(基于第1阶段的架构)
Claude: [专注认证逻辑,复用已建立的架构]

# 第3阶段 - 文章功能
你: 实现文章CRUD功能
Claude: [专注于文章业务逻辑]

# 每个阶段:
- 上下文清晰专注
- 可以深入讨论细节
- 前阶段的结果被记住
- 保证代码质量

4. 使用摘要和总结

技巧: 在关键节点创建上下文摘要

# 在第10轮对话后
你: /summary

Claude: ## 当前对话总结

### 已完成的工作
1. ✓ 创建了用户认证系统
   - JWT token认证
   - 刷新token机制
   - 权限中间件

2. ✓ 实现了文章CRUD
   - Markdown编辑器集成
   - 图片上传功能
   - 自动保存草稿

3. ✓ 添加了评论系统
   - 嵌套评论(最多3层)
   - 评论审核流程

### 当前状态
- 数据库: PostgreSQL with Prisma
- 前端: React + TypeScript
- 状态管理: Redux Toolkit
- API: RESTful (Express)

### 待办事项
- [ ] 实现全文搜索
- [ ] 添加SEO优化
- [ ] 构建管理后台

### 重要技术决策
- 使用JWT而非Session认证(无状态,易扩展)
- 图片存储使用阿里云OSS(成本效益好)
- 富文本编辑器选择Tiptap(性能最佳)

[保存摘要到上下文,后续对话可以引用]

内存管理策略

1. 对话历史压缩

Claude Code会自动压缩旧对话,但你也可以主动管理:

技巧1: 显式关闭已解决的议题

你: 认证功能已经完成了,我们可以从上下文中移除相关细节

Claude: 明白。我将压缩认证相关的讨论:

[压缩前: 讨论了20轮,占用15K tokens]
[压缩后: 1个摘要,占用200 tokens]

摘要:
- ✓ JWT认证已实现
- ✓ Token刷新机制正常工作
- ✓ 权限中间件已集成
相关文件: src/auth/, src/middleware/auth.ts

[释放了大量上下文空间]

技巧2: 使用"清理"指令

你: /clear_context

Claude: 我将清理当前上下文:
- 保留: CLAUDE.md配置
- 保留: 项目文件引用
- 清除: 对话历史
- 清除: 临时生成的代码

当前上下文使用: 8K / 200K tokens

2. 选择性文件加载

场景: 大型项目的特定任务

# 不好的做法 - 读取整个项目
你: 读取所有文件并分析

Claude: [读取500个文件,上下文爆炸]

# 好的做法 - 选择性读取
你: 我要做性能优化,先分析这些关键文件:
- src/app.tsx (应用入口)
- src/routes/index.tsx (路由配置)
- src/store/index.ts (状态管理)
- src/api/client.ts (API客户端)

Claude: [只读取4个文件,分析更精准]

实用的文件选择模式:

# 1. 按功能分组
"分析用户相关的所有服务"
→ src/services/user*
→ src/features/user/*

# 2. 按层次分析
"先看数据层: src/models/, src/api/"
"然后看业务层: src/services/, src/store/"
"最后看展示层: src/components/, src/pages/"

# 3. 按依赖关系
"从入口文件开始: src/main.tsx"
"然后按import链追踪"

3. 增量式上下文构建

策略: 从核心到边缘,逐步构建上下文

# 第1步 - 建立核心上下文
你: 先理解项目核心架构
Claude: 读取 package.json, tsconfig.json, src/index.ts
→ 建立基础认知 (~5K tokens)

# 第2步 - 添加功能模块
你: 现在看认证模块
Claude: 读取 src/auth/ 目录
→ 理解认证逻辑 (~10K tokens)

# 第3步 - 添加业务逻辑
你: 添加订单模块上下文
Claude: 读取 src/orders/ 目录
→ 理解业务流程 (~15K tokens)

# 优势:
- 每步都聚焦,理解深入
- 可以及时纠正误解
- 上下文始终在可控范围内

性能优化实战

案例1: 大型代码库重构

场景: 将150个组件从JavaScript迁移到TypeScript

优化前的策略:

你: 把所有JS文件改成TS

Claude: [需要:]
1. 读取150个组件文件
2. 分析每个组件的props
3. 创建类型定义
4. 重写所有文件

问题:
- 单次对话无法完成
- 上下文远超200K tokens
- 容易出错且难以review

优化后的策略(分批次):

# 批次1: 原子组件 (30个基础组件)
你: 第1批: 迁移 src/components/atoms/
Claude: [读取30个文件,创建基础类型]
✓ 完成: Button, Input, Label, Badge...

# 批次2: 分子组件 (40个复合组件)
你: 第2批: 迁移 src/components/molecules/
Claude: [复用atoms的类型,扩展molecules类型]
✓ 完成: FormField, Card, ListItem...

# 批次3: 有机体组件 (50个复杂组件)
你: 第3批: 迁移 src/components/organisms/
Claude: [复用molecules的类型]
✓ 完成: Header, Sidebar, DataTable...

# 批次4: 页面和模板 (30个页面)
你: 第4批: 迁移 src/pages/ 和 src/templates/
Claude: [整合所有组件类型]
✓ 完成: 所有页面都有类型保护

每个批次:
- 上下文可控 (20-30K tokens)
- 可以充分测试
- 渐进式迁移,风险低

案例2: 全局变量追踪

场景: 在100个文件中追踪状态变化

优化技巧:

# 不好的做法
你: 分析整个应用的状态管理
Claude: [需要理解所有文件的状态使用]
→ 上下文过大,容易遗漏

# 好的做法 - 使用状态追踪图
你: 创建一个状态追踪工具

Claude: 我将创建一个状态追踪脚本:
```typescript
// scripts/track-state.ts
import { glob } from 'glob';
import { readFileSync } from 'fs';

const stateUsage = new Map();

// 扫描所有文件
const files = await glob('src/**/*.{ts,tsx}');
for (const file of files) {
  const content = readFileSync(file, 'utf-8');

  // 追踪Redux store使用
  const storeImports = content.match(/import.*from ['"]@\/store['"]/g);
  const useSelectorCalls = content.match(/useSelector\(.+\)/g);
  const useDispatchCalls = content.match(/useDispatch\(\)/g);

  if (storeImports || useSelectorCalls || useDispatchCalls) {
    stateUsage.set(file, {
      hasStore: !!storeImports,
      selectors: useSelectorCalls?.length || 0,
      dispatches: useDispatchCalls?.length || 0,
    });
  }
}

// 生成报告
console.table(Array.from(stateUsage.entries()));

运行输出:

┌─────────────────────────────────┬───────────┬───────────┬────────────┐
│        (index)                  │ hasStore  │ selectors │ dispatches │
├─────────────────────────────────┼───────────┼───────────┼────────────┤
│ src/pages/Dashboard.tsx         │ true      │ 5         │ 2          │
│ src/components/Header.tsx       │ true      │ 3         │ 1          │
│ src/features/user/UserList.tsx  │ true      │ 8         │ 4          │
└─────────────────────────────────┴───────────┴───────────┴────────────┘

[用脚本处理,不占用上下文] 只分析问题文件:

### 案例3: 智能缓存机制

**场景**: 减少重复分析相同文件

```markdown
你: 每次对话都重新分析package.json,能缓存吗?

Claude: 好主意! 我会创建一个上下文缓存:

```typescript
// .claude/cache.json
{
  "projectInfo": {
    "name": "my-app",
    "type": "nextjs",
    "dependencies": {
      "react": "^18.2.0",
      "next": "^14.0.0"
    },
    "scripts": {
      "dev": "next dev",
      "build": "next build"
    }
  },
  "lastAnalyzed": "2025-12-25T10:00:00Z"
}

现在每次对话:

先检查缓存
如果package.json未修改,使用缓存
节省读取和解析时间

[缓存生效中] 使用缓存的package.json信息节省了: 1.2K tokens + 2秒分析时间

## 上下文保留策略

### 1. 关键信息持久化

**技巧**: 将重要决策保存到文件

```markdown
你: 记录我们的架构决策

Claude: 创建ADR (Architecture Decision Record):

```markdown
# docs/architecture/decisions/001-use-redux.md

## 状态管理技术选型: Redux Toolkit

### 状态
已决定 - 2025-12-25

### 背景
需要为电商平台选择状态管理方案:
- 全局用户状态
- 购物车状态
- 订单状态
- 10+个功能模块

### 考虑的方案
1. Redux Toolkit
2. Zustand
3. Jotai
4. React Context + useReducer

### 决策
选择 **Redux Toolkit**

### 理由
✅ 团队熟悉Redux,学习成本低
✅ RTK Query完美解决服务端状态
✅ 强大的中间件生态(日志、持久化)
✅ 适合大型项目的可预测性
✅ 调试工具(DevTools)成熟

### 后果
- 需要编写更多boilerplate(相比Zustand)
- Bundle size增加约15KB
- 新成员需要学习Redux概念

### 相关文件
- src/store/index.ts
- src/features//*/slice.ts

[决策被持久化,随时可查阅]

### 2. 对话分支管理

**技巧**: 使用`/branch`保存不同探索方向

```markdown
# 主对话: 重构认证系统
你: 我想重构认证系统,有几个方案

# 分支1: 保留Token方案
你: /branch "keep-token"
Claude: 保存方案A的上下文
- 继续使用JWT
- 改进刷新机制
- 添加token加密

# 分支2: Session方案
你: /branch "use-session"
Claude: 保存方案B的上下文
- 切换到Session认证
- 使用Redis存储
- 实现Session共享

# 切换分支
you: /switch "keep-token"
Claude: 恢复Token方案的上下文
[之前的讨论完全保留]

# 对比分支
you: /compare
Claude: 对比两个方案:
方案A (Token):
  - 优势: 无状态,易扩展
  - 劣势: 无法主动撤销

方案B (Session):
  - 优势: 可主动撤销
  - 劣势: 需要Session存储

3. 上下文快照

场景: 在关键节点保存上下文状态

# 完成一个功能后
you: /snapshot "完成用户认证功能"

Claude: ✓ 创建上下文快照

快照内容:
- 对话轮数: 23轮
- 已完成功能:
  ✓ JWT认证
  ✓ 用户注册/登录
  ✓ Token刷新
  ✓ 权限中间件
- 修改的文件: 12个
- 新增的文件: 8个
- 重要的代码模式: [已保存]
- 遇到的问题和解决方案: [已记录]

快照位置: .claude/snapshots/auth-complete.json

[如果后续需要回滚,可以恢复此快照]

实用技巧和最佳实践

1. 上下文监控

技巧: 定期检查上下文使用情况

you: /context_stats

Claude: ## 当前上下文统计

### 使用情况

总容量: 200K tokens 已使用: 67.3K tokens (33.6%) 剩余: 132.7K tokens


### 组成分析

CLAUDE.md: 3.2K (4.8%) ✓ 合理项目文件: 45.1K (67.0%) ⚠️ 偏高对话历史: 16.8K (25.0%) ✓ 正常系统提示: 2.2K (3.2%) ✓ 正常

### 建议
- 项目文件占用较多,考虑清理不常用的文件引用
- 对话历史健康,可以继续
- 建议在第30轮对话前创建摘要

### 优化建议
1. 压缩已完成的对话轮次 (可节省 ~8K tokens)
2. 移除临时测试文件 (可节省 ~5K tokens)
3. 创建功能摘要 (可节省 ~10K tokens)

2. 上下文模板

技巧: 为常见任务准备上下文模板

# .claude/templates/bug-fix.md

## Bug修复上下文模板

### 问题描述
[Bug的详细描述]

### 复现步骤
1. 步骤1
2. 步骤2
3. 步骤3

### 预期行为
[应该发生什么]

### 实际行为
[实际发生了什么]

### 环境信息
- Node版本:
- 浏览器:
- 相关配置:

### 已尝试的方案
1. 方案1: [结果]
2. 方案2: [结果]

### 相关文件
- [文件1路径]
- [文件2路径]

---

使用:
you: /template bug-fix
Claude: 加载Bug修复模板,请填写具体内容

3. 分层上下文策略

场景: 不同层级的信息需求

# 第1层 - 概览层 (5K tokens)
你: 给我项目的整体架构概览

Claude:
## 项目架构概览
- 类型: Next.js全栈应用
- 分层: 展示层 → 业务层 → 数据层
- 主要模块: 认证、订单、支付、用户
- 技术栈: React + TypeScript + Prisma + PostgreSQL

[高层认知,不深入细节]

# 第2层 - 模块层 (20K tokens)
you: 深入讲解订单模块

Claude:
## 订单模块详解
- 核心文件: src/features/orders/
- 数据流: Component → Thunk → API → Reducer
- 状态机: Draft → Pending → Paid → Shipped → Delivered
- 关键API: 5个CRUD端点 + 3个特殊端点

[模块级理解]

# 第3层 - 实现层 (50K tokens)
you: 展示订单创建的完整实现

Claude:
## 订单创建实现细节
[完整的代码流程、类型定义、错误处理]

[深入实现]

# 优势:
- 按需加载上下文
- 避免一次性过载
- 保持对话焦点

4. 上下文复用技巧

技巧: 在多个对话间复用上下文

# 创建可复用的上下文块
you: /save_context "react-component"

Claude: 保存上下文块: react-component

内容:
- React组件创建模式
- Hooks使用规范
- TypeScript类型定义
- 样式方案(CSS Modules)
- 测试要求

[保存到: .claude/contexts/react-component.json]

# 在新对话中加载
you: /load_context "react-component"

Claude: ✓ 加载上下文块: react-component

现在我知道:
- 使用函数式组件
- Props需要TypeScript接口
- 样式使用CSS Modules
- 需要编写测试

you: 创建一个UserProfile组件
Claude: [按照已加载的规范创建组件]

常见问题解答

Q1: 200K tokens够用吗?

A: 对于大多数项目,完全够用:

小型项目 (<50文件):     10-20K tokens  ✓ 很充裕
中型项目 (50-200文件):   30-60K tokens  ✓ 充裕
大型项目 (200-500文件):  70-120K tokens ✓ 够用
超大型项目 (>500文件):   150K+ tokens   ⚠️ 需要优化

优化方案:

使用本文的上下文管理技巧
分模块处理
增量式对话
智能文件引用

Q2: 如何知道上下文快满了?

症状:

Claude开始遗忘之前的细节
需要反复提醒已经说过的信息
回复变得不够精准

解决方案:

you: /context_health

Claude: ## 上下文健康检查

⚠️ 警告: 上下文使用率 85%

建议:
1. 立即创建对话摘要
2. 清理不活跃的文件引用
3. 压缩旧的对话轮次
4. 考虑开始新对话(携带摘要)

Q3: 对话太长后,Claude会遗忘吗?

A: Claude不会"遗忘",但上下文优先级会变化:

# 近期内容 (高优先级)
最近5-10轮对话 → 完全保留,细节清晰

# 中期内容 (中优先级)
10-30轮前 → 保留关键信息,细节可能模糊

# 早期内容 (低优先级)
30+轮前 → 仅保留摘要和重要决策

# 永久保留 (最高优先级)
- CLAUDE.md配置
- 关键文件引用
- 显式保存的信息

最佳实践:

在关键节点创建摘要
重要信息写回CLAUDE.md
使用快照保存重要状态

Q4: 如何处理超大型项目?

策略1: Monorepo拆分

# 项目结构
my-monorepo/
├── apps/
│   ├── web/          # 前端应用
│   ├── api/          # 后端API
│   └── admin/        # 管理后台
├── packages/
│   ├── ui/           # UI组件库
│   ├── shared/       # 共享工具
│   └── types/        # 类型定义

# 每个子项目独立的Claude Code对话
web/:     专注前端开发
api/:     专注后端开发
shared/:  专注共享代码

策略2: 模块化CLAUDE.md

# CLAUDE.md (主配置)
# 项目概览
引用:
- [认证模块](.claude/modules/auth.md)
- [订单模块](.claude/modules/orders.md)
- [支付模块](.claude/modules/payments.md)

# 按需加载模块配置
you: 我要开发订单功能
Claude: ✓ 加载 .claude/modules/orders.md
→ 获得订单模块的完整上下文
→ 不需要加载其他模块

策略3: 分层对话

# 架构层对话
focus: 整体架构、技术选型、设计模式
participants: 架构师、Tech Lead
files: 架构文档、设计文档

# 实现层对话
focus: 具体功能实现、代码细节
participants: 开发者
files: 具体功能模块的代码

# 优化层对话
focus: 性能优化、重构
participants: 性能专家、原开发者
files: 性能分析报告、待优化代码

# 每层对话保持独立的上下文,通过文档传递信息

Q5: 上下文管理影响性能吗?

A: 会影响,但Claude Code有智能优化:

# 性能影响因素

1. 上下文大小
   - 小上下文 (<50K):   响应快 ✓
   - 中上下文 (50-100K): 响应正常 ✓
   - 大上下文 (100-150K): 响应略慢 ⚠️
   - 超大上下文 (>150K):  响应明显慢 ⚠️

2. 文件数量
   - 引用文件少 (<20个):  加载快 ✓
   - 引用文件多 (20-50个): 加载正常 ✓
   - 引用文件很多 (>50个): 加载慢 ⚠️

3. 对话轮数
   - 轮次少 (<20轮):  记忆清晰 ✓
   - 轮次多 (20-50轮): 记忆正常 ✓
   - 轮次很多 (>50轮):  需要摘要 ⚠️

# 优化建议
1. 使用上下文监控,及时清理
2. 分阶段对话,避免单次过长
3. 使用摘要和快照保存关键信息
4. 智能引用文件,避免批量加载

高级技巧

1. 上下文感知的提示词

技巧: 根据上下文状态调整提示词

# 早期对话 - 探索阶段
you: "帮我了解一下这个项目的认证系统"

Claude: [扫描文件,提供概览]
→ 使用较少上下文
→ 提供广泛信息

# 中期对话 - 开发阶段
you: "基于刚才分析的认证系统,实现登录功能"

Claude: [使用已建立的上下文]
→ 聚焦具体实现
→ 引用之前的分析

# 后期对话 - 优化阶段
you: "登录功能已经实现了,现在优化性能"

Claude: [知道已完成的实现]
→ 针对性优化
→ 不重复已完成的工作

2. 上下文预测和预加载

技巧: 预测接下来需要的信息

# 场景: 开发REST API

you: 创建一个用户管理API

Claude: 智能预加载:
1. ✓ 查看现有的API模式 (src/api/*.ts)
2. ✓ 检查数据模型 (src/models/User.ts)
3. ✓ 读取配置文件 (src/config/database.ts)
4. ✓ 查看API路由设置 (src/routes/index.ts)

[现在我可以创建符合项目规范的API]

下一步预测:
- 可能需要创建测试文件
- 预加载测试配置 (jest.config.js)
- 预加载现有测试示例 (tests/**/*.test.ts)

3. 跨会话上下文传递

技巧: 在多个Claude Code会话间传递信息

# 会话1 - 架构设计
you: 设计订单系统架构
Claude: [生成架构文档]

# 保存上下文
you: /export_context order-architecture

# 生成文件: .claude/exports/order-architecture.json
{
  "summary": "订单系统架构设计",
  "key_decisions": [...],
  "file_structure": [...],
  "api_endpoints": [...]
}

# 会话2 - 具体实现 (可能几天后)
you: /import_context order-architecture

Claude: ✓ 导入上下文: order-architecture

我现在知道:
- 订单系统的架构设计
- 已决策的技术方案
- 文件组织结构
- API端点规划

开始实现...

4. 上下文版本控制

技巧: 管理上下文的演变

# 创建上下文版本
you: /version_context "v1.0-initial"

Claude: ✓ 保存上下文版本: v1.0-initial

包含:
- 项目结构
- 技术栈
- 编码规范
- 17个已完成的功能

# 项目演进后...
you: /version_context "v2.0-refactored"

Claude: ✓ 保存上下文版本: v2.0-refactored

变更:
- + 新增: TypeScript迁移
- + 新增: Redux状态管理
- ~ 重构: API层架构
- - 移除: Context API (被Redux替代)

# 对比版本
you: /diff_context "v1.0" "v2.0"

Claude:
## 上下文版本对比

### 架构变化
v1.0: Context API + 组件状态
v2.0: Redux Toolkit + RTK Query

### 代码量变化
v1.0: 8,000 行代码
v2.0: 12,000 行代码 (+50%)

### 技术债务
v1.0: 类型安全性不足
v2.0: 完全类型安全

[清晰追踪项目演进]

性能基准测试

测试1: 不同上下文大小的响应时间

# 测试代码
```typescript
// 测试任务: 创建一个React组件
// 测试不同上下文大小下的性能

const testCases = [
  { name: "空上下文", size: "5K tokens" },
  { name: "小上下文", size: "30K tokens" },
  { name: "中上下文", size: "80K tokens" },
  { name: "大上下文", size: "150K tokens" },
];

测试结果

上下文大小    响应时间    准确性    代码质量
─────────────────────────────────────────
5K tokens    2.3秒      ⭐⭐⭐⭐   ⭐⭐⭐⭐
30K tokens   3.1秒      ⭐⭐⭐⭐⭐  ⭐⭐⭐⭐⭐
80K tokens   4.5秒      ⭐⭐⭐⭐   ⭐⭐⭐⭐
150K tokens  6.8秒      ⭐⭐⭐    ⭐⭐⭐⭐

结论:

30-80K tokens是最佳区间
上下文太小时,缺少项目信息
上下文太大时,性能下降

### 测试2: 文件引用策略对比

```markdown
# 方案A: 列出所有文件
you: 分析这些文件:
- src/components/Button.tsx
- src/components/Input.tsx
... (列出20个文件)

时间: 12.3秒
Tokens: 45K

# 方案B: 使用模式
you: 分析 src/components/ 下的所有组件

时间: 5.1秒
Tokens: 8K

# 性能提升
- 速度提升: 2.4倍
- Token节省: 82%
- 准确性: 相同 (都找到所有问题)

测试3: 分阶段 vs 一次性对话

# 任务: 实现完整的博客系统 (10个功能模块)

# 方案A: 一次性讨论
you: "实现整个博客系统"
Claude: [试图在一个对话中完成所有]

结果:
- 对话轮数: 65轮
- 总耗时: 45分钟
- 上下文峰值: 180K tokens
- 代码质量: ⭐⭐⭐ (有些地方匆忙)
- Bug数量: 12个

# 方案B: 分阶段实现
you: "分10个阶段,每个功能单独讨论"

结果:
- 对话轮数: 每个阶段5-8轮
- 总耗时: 50分钟
- 上下文峰值: 60K tokens
- 代码质量: ⭐⭐⭐⭐⭐ (每个阶段都仔细打磨)
- Bug数量: 2个

# 结论
分阶段虽然总时间略长,但:
- 上下文始终健康
- 代码质量更高
- 更容易测试和调试
- 每个阶段可以独立部署

总结