Claude Code 进阶技巧

解决复杂场景痛点 | 提升团队协作效率 | 掌握高级技巧

学习目标: 掌握 Claude Code 的高级技巧，解决日常开发中的复杂场景问题

适用对象: 已掌握基础技能，有 1-2 周实践经验的开发者

前置条件:

✅ 已学习快速上手教程
✅ 已使用实战指南完成 2-3 个场景
✅ 能熟练使用三段式工作流

📚 课程大纲

部分	内容	解决的核心问题
第一部分	复杂场景处理	如何拆分和组合复杂任务
第二部分	团队协作技巧	如何保持团队代码一致性
第三部分	上下文管理策略	如何高效管理对话上下文
第四部分	性能优化实践	如何识别和解决性能问题
第五部分	案例研究	实际项目中的应用经验

第一部分：复杂场景处理

1.1 流程组合技巧

什么是流程组合？

将多个基础流程组合使用，解决复杂的系统性任务。

适用场景

bash

单一流程无法完成的任务：
- 大型功能开发（涉及多个模块）
- 系统性重构（多层架构调整）
- 复杂的数据迁移

组合模式 1: 串行组合

场景: 开发新功能后需要性能优化

流程:

bash

阶段 1: 新功能开发流程（8-10 轮）
   ↓
阶段 2: 性能优化流程（4 轮）
   ↓
阶段 3: 生成文档

示例:

bash

# 阶段 1: 完成基本功能
使用《实战指南 - 工作流 1: 新功能开发》

（完成后）

# 阶段 2: 性能优化
/clear

继续性能优化，上一阶段已完成基本功能

【已完成】
- 订单批量导入功能
- Model/Service/API 三层实现

【当前问题】
- 导入 1000 条数据需要 30 秒

使用《实战指南 - 工作流 6: 性能优化》

（优化后）

# 阶段 3: 生成 API 文档
@api/v1/order_import.go
生成 OpenAPI 3.0 格式的 API 文档

关键要点:

✅ 阶段切换时使用 /clear
✅ 明确说明上一阶段的成果
✅ 每个阶段聚焦单一目标

组合模式 2: 并行组合

场景: 同时重构多个独立模块

流程:

bash

模块 A 重构  ──┐
模块 B 重构  ──┤─→ 集成测试
模块 C 重构  ──┘

示例:

bash

# 会话 1: 重构用户模块
/clear
使用《实战指南 - 工作流 2: 代码重构》
重构 user 模块

【记录设计要点到 DESIGN.md】

# 会话 2: 重构订单模块
/clear
使用《实战指南 - 工作流 2: 代码重构》
重构 order 模块

【记录设计要点到 DESIGN.md】

# 会话 3: 集成
/clear
@DESIGN.md 包含了两个模块的重构设计

现在需要：
1. 更新模块间的调用关系
2. 运行集成测试
3. 修复兼容性问题

关键要点:

✅ 使用文件（DESIGN.md）串联多个会话
✅ 模块独立重构，降低复杂度
✅ 最后统一集成和测试

1.2 长任务拆分策略

为什么要拆分？

问题: 单个会话对话轮数过多（> 50 轮）会导致：

上下文混乱
AI 理解偏差
Token 浪费

解决: 将长任务拆分为多个短会话

拆分原则

bash

1. 按模块拆分（Model → Service → API）
2. 按功能拆分（读 → 写 → 删）
3. 按阶段拆分（数据库 → 逻辑 → 接口）

实战案例

任务: 开发完整的功能管理系统

传统方式（❌ 不推荐）:

bash

一个会话完成所有功能，导致：
- 70+ 轮对话
- 上下文混乱
- 频繁纠错

拆分方式（✅ 推荐）:

bash

┌─────────────────────────────────────────┐
│ 会话 1: 数据库设计（4-6 轮）             │
│ 输出: DDL 脚本 + 设计文档                │
└─────────────────────────────────────────┘
              │
              ▼
┌─────────────────────────────────────────┐
│ 会话 2: Model 层实现（6-8 轮）          │
│ 输入: @DESIGN.md                        │
│ 输出: Model 层代码                       │
└─────────────────────────────────────────┘
              │
              ▼
┌─────────────────────────────────────────┐
│ 会话 3: Service 层实现（6-8 轮）        │
│ 输入: @DESIGN.md + Model 代码            │
│ 输出: Service 层代码                     │
└─────────────────────────────────────────┘
              │
              ▼
┌─────────────────────────────────────────┐
│ 会话 4: API 层实现（6-8 轮）            │
│ 输入: @DESIGN.md + Service 代码          │
│ 输出: API 层代码 + 文档                  │
└─────────────────────────────────────────┘

每个会话的模板:

bash

# 会话 1
/clear
设计功能管理系统的数据库

【需求】
（需求描述）

请完成数据库设计，并将设计要点记录到 DESIGN.md

# 会话 2
/clear
@DESIGN.md 包含了数据库设计

继续实现 Model 层

【要求】
- 遵循 CLAUDE.md 规范
- 每个表一个 Model 结构体

1.3 多模块协作

场景

修改涉及多个模块，需要保持一致性。

技巧 1: 使用设计文档串联

步骤:

bash

1. 第一次会话: 分析所有相关模块，输出设计文档
2. 后续会话: 引用设计文档，逐个修改模块

示例:

bash

# 会话 1: 整体设计
/clear

@api/v1/user.go @api/v1/order.go @service/user.go @service/order.go

分析：将用户会员逻辑从 user 模块独立为 membership 模块

【分析内容】
1. 哪些函数需要迁移
2. 模块间的新调用关系
3. 数据表变更

【输出】
请将设计方案记录到 REFACTOR_PLAN.md

# 会话 2: 实施
/clear
@REFACTOR_PLAN.md

按照重构计划，先完成 membership 模块的创建

技巧 2: 增量式修改

原则: 每次只修改一个模块，立即测试

bash

修改模块 A → 测试 → 提交
  ↓
修改模块 B → 测试 → 提交
  ↓
修改模块 C → 测试 → 提交

好处:

问题容易定位
可以随时回滚
降低风险

1.4 实战案例：复杂重构

任务

将混乱的订单模块重构为清晰的三层架构。

第 1 步: 全面分析

bash

/clear

@service/order.go
@service/payment.go
@service/benefit.go

这 3 个文件的逻辑混乱，需要重构为清晰的三层架构

【分析任务】
1. 当前的职责划分问题
2. 哪些逻辑应该在 Model 层
3. 哪些逻辑应该在 Service 层
4. 哪些逻辑应该在 API 层
5. 模块间的依赖关系

【输出】
请将分析结果和重构方案记录到 REFACTOR.md

不要写代码

第 2 步: 分模块重构

bash

# 会话 2: 重构 Model 层
/clear
@REFACTOR.md

按照重构方案，先完成 Model 层

【要求】
- 每个表一个文件
- 只包含数据库操作
- 使用结构体方法

每完成一个文件暂停

# 会话 3: 重构 Service 层
/clear
@REFACTOR.md

Model 层已完成，继续 Service 层

【要求】
- 业务逻辑集中在 Service
- 调用 Model 层方法
- 使用包级函数

# 会话 4: 重构 API 层
/clear
@REFACTOR.md

Service 层已完成，继续 API 层

【要求】
- 参数校验
- 响应组装
- 调用 Service 层

第 3 步: 集成测试

bash

/clear

重构已完成，现在进行集成测试

【测试要点】
1. 原有功能是否正常
2. 边界情况是否处理
3. 性能是否下降

请列出测试清单

第二部分：团队协作技巧

2.1 建立 CLAUDE.md 规范

为什么需要 CLAUDE.md？

问题: 团队成员各自用不同的提示词，导致：

代码风格不一致
AI 理解项目方式不同
协作效率低

解决: 建立统一的 CLAUDE.md 规范文档

CLAUDE.md 结构

bash

# 项目名称

## 项目概览
- 技术栈
- 目录结构
- 核心模块

## 代码规范
### 命名规范
- 文件命名: snake_case
- 结构体: PascalCase
- 函数: 导出用 PascalCase，私有用 camelCase

### 分层规范
- Model 层: 数据库操作，使用结构体方法
- Service 层: 业务逻辑，使用包级函数
- API 层: 参数校验 + 响应组装

### 错误处理
- 统一使用 pkg/errors
- Service 层返回业务错误
- API 层转换为 HTTP 状态码

## 常用命令
```bash
# 开发
npm run dev

# 构建
npm run build

特殊注意事项

所有数据库操作必须有事务
外部 API 调用要有超时控制
敏感信息不能记录日志

bash


---

#### 使用方式

**在每次会话开始时**:

```bash
@CLAUDE.md 请阅读项目规范

然后执行: {具体任务}

好处:

AI 理解项目上下文
生成的代码符合团队规范
减少后续调整

2.2 多人协作最佳实践

实践 1: 使用 Git 分支隔离

bash

# 每个人在自己的分支上使用 Claude Code
git checkout -b feature/user-payment

# 完成后合并
git checkout main
git merge feature/user-payment

好处:

避免冲突
便于代码审查
可以回滚

实践 2: 记录关键决策

在 CLAUDE.md 或 DESIGN.md 中记录：

bash

## 关键决策

### 2025-10-22: 计费方式设计
- **问题**: 需要支持多种计费方式
- **方案**: 采用策略模式
- **理由**: 便于扩展新计费方式
- **负责人**: 张三

好处:

其他成员了解背景
避免重复讨论
便于追溯

实践 3: 代码审查清单

bash

## Code Review 清单

在提交 PR 前，使用 Claude Code 检查：

- [ ] 代码符合 CLAUDE.md 规范
- [ ] 没有硬编码的配置
- [ ] 错误处理完善
- [ ] 添加了必要的注释
- [ ] 没有 TODO 遗留
- [ ] 测试覆盖关键逻辑

提示词:

bash

@api/v1/user.go @service/user.go

请检查以上代码是否符合 @CLAUDE.md 的规范

【检查项】
- 命名规范
- 分层规范
- 错误处理
- 注释完整性

输出检查报告，不要写代码

2.3 代码风格统一

学习参考风格

bash

读取 @user_benefit 模块的代码，分析其编码风格

【需要提取的规范】
- 文件命名规范
- 结构体命名
- 函数命名
- 注释风格
- 错误处理方式

整理后更新到 CLAUDE.md，后续所有代码都遵循此规范

应用风格

bash

采用方案 A，开始编码

【要求】
- 严格遵循 CLAUDE.md 中的规范
- 参考 user_benefit 模块的实现方式
- 特别注意错误处理要使用 pkg/errors

第三部分：上下文管理策略

3.1 何时清空上下文

应该清空的场景

bash

✅ 场景 1: 切换到完全不同的任务
   - 从订单模块切换到用户模块
   - 从开发切换到 Bug 修复

✅ 场景 2: 对话超过 50 轮
   - 上下文过长
   - AI 开始混淆

✅ 场景 3: AI 开始混淆上下文
   - 提到不存在的文件
   - 方案前后矛盾

✅ 场景 4: 完成一个完整流程后
   - 新功能开发完成
   - 重构完成

不应该清空的场景

bash

❌ 场景 1: 任务进行中
   - 会丢失重要上下文

❌ 场景 2: 仅仅换了个文件
   - 如果还是同一任务，不要清空

❌ 场景 3: 对结果不满意
   - 应该纠正，而非清空重来

3.2 清空后快速恢复

方法 1: 任务摘要恢复

bash

/clear

继续订单模块开发

【上次进度】
- 已完成: Model 层、Service 层
- 当前: 需要完成 API 层
- 关键决策: 采用方案 B（统一订单入口）
- 技术选型: 使用事务保证一致性

请先复述关键决策，然后继续 API 层开发

要点:

简明扼要说明进度
强调关键决策
明确下一步任务

方法 2: 文件恢复

bash

/clear

@WORKFLOW.md 记录了当前任务进度
@CLAUDE.md 记录了项目规范

继续当前任务

WORKFLOW.md 示例:

bash

# 当前任务

## 2025-10-22: 实现功能计费模块

### 进度
- [x] 需求分析
- [x] 方案设计（采用方案 B）
- [ ] 编码实施 (进行中)
  - [x] Model 层
  - [x] Service 层
  - [ ] API 层

### 关键决策
- 采用方案 B: 统一订单入口
- 使用事务保证次数扣减和订单创建的一致性
- 会员价 = 原价时不展示会员标签

### 待办
- [ ] 完成 API 层开发
- [ ] 补充 Service 层单元测试
- [ ] 生成 API 文档

3.3 长任务的上下文管理

策略 1: 分模块管理

bash

# 第 1 次会话: 完成 Model 层
/clear
开发 Function 模块的 Model 层
...
请将 Model 层的设计要点记录到 DESIGN.md

# 第 2 次会话: 完成 Service 层
/clear
@DESIGN.md 中有 Model 层的设计
继续开发 Service 层
...
请更新 DESIGN.md，补充 Service 层设计

# 第 3 次会话: 完成 API 层
/clear
@DESIGN.md 中有前两层的设计
继续开发 API 层

策略 2: 使用检查点

每完成一个阶段，创建检查点：

bash

# 完成 Service 层后
当前 Service 层已完成，请输出：
1. 已实现的功能清单
2. 关键设计决策
3. 下一步 API 层需要注意的事项

（将输出保存到 CHECKPOINT.md）

# 下次会话开始时
/clear
@CHECKPOINT.md

继续 API 层开发

3.4 避免上下文污染

问题

上下文中包含过多不相关信息：

bash

# 错误示例
/clear

【第 1-20 轮】讨论用户模块
【第 21-40 轮】讨论订单模块（上下文中仍有用户模块信息）
【第 41-60 轮】讨论支付模块（上下文中仍有前两个模块信息）

结果: AI 开始混淆三个模块

解决

方法 1: 及时清空

bash

# 用户模块完成后
/clear

# 开始订单模块
讨论订单模块需求

方法 2: 使用文件串联

bash

# 第 1 次会话
讨论用户模块
（将设计输出到 USER_DESIGN.md）

# 第 2 次会话
/clear
@USER_DESIGN.md

用户模块已完成，现在开始订单模块
（订单模块需要引用用户设计时，AI 会读取文件）

第四部分：性能优化实践

4.1 识别性能瓶颈

使用 AI 分析性能

bash

@service/order.go#L50-150

分析这段代码的性能瓶颈，不要写代码

【分析维度】
1. 是否存在 N+1 查询
2. 是否有不必要的数据库查询
3. 是否有循环中的重复计算
4. 是否可以使用缓存

4.2 优化 N+1 查询

场景

// ❌ N+1 查询
func GetOrders(userID int) []Order {
    orders := model.GetOrdersByUser(userID)  // 1 次查询
    for i, order := range orders {
        user := model.GetUserByID(order.UserID)  // N 次查询
        orders[i].UserName = user.Name
    }
    return orders
}

优化提示词

bash

@service/order.go#L50-80

这里存在 N+1 查询问题，优化为批量查询

【优化要求】
1. 收集所有 user_id
2. 批量查询 users 表
3. 在内存中组装数据

请给出优化方案，不要写代码

4.3 添加缓存

适用场景判断

bash

@service/function.go#L30-50

GetFunctionList 函数适合加缓存吗？

【判断标准】
- 读多写少？
- 数据一致性要求？
- 数据量大小？

请分析并给出建议，不要写代码

实施缓存

bash

为 GetFunctionList 添加 Redis 缓存

【缓存策略】
- key: function_list_{platform}
- 过期时间: 30 分钟
- 更新策略: 被动更新
- 穿透保护: 空结果缓存 5 分钟

请先说明实施步骤，不要写代码

4.4 异步处理

场景

订单创建后发送通知邮件，邮件服务慢导致接口响应慢。

优化提示词

bash

@service/order.go#L100-120

订单创建后发送邮件，改为异步

【方案要求】
1. 订单创建成功后，发送消息到队列
2. 异步 worker 从队列消费，发送邮件
3. 失败重试机制
4. 监控队列堆积

请给出完整方案，不要写代码

第五部分：案例研究

5.1 案例 1: 大型功能开发

背景

开发一个完整的会员权益系统，包括：

会员等级管理
权益配置
权益消费记录
统计报表

实施过程

阶段 1: 整体规划

bash

/clear

设计会员权益系统

【功能范围】
1. 会员等级管理（青铜/白银/黄金/钻石）
2. 权益配置（每个等级的权益）
3. 权益消费记录
4. 统计报表

【技术要求】
- 使用现有的三层架构
- 权益要可动态配置
- 支持权益过期

请给出：
1. 数据库设计
2. 模块划分
3. 实施计划（分几个会话完成）

将设计输出到 MEMBER_DESIGN.md

阶段 2-5: 分模块实施

bash

# 会话 2: Model 层
/clear
@MEMBER_DESIGN.md
实施 Model 层

# 会话 3: Service 层
/clear
@MEMBER_DESIGN.md
实施 Service 层

# 会话 4: API 层
/clear
@MEMBER_DESIGN.md
实施 API 层

# 会话 5: 统计报表
/clear
@MEMBER_DESIGN.md
实施统计报表功能

阶段 6: 集成测试

bash

/clear

会员权益系统开发完成

【测试要点】
1. 会员升级逻辑
2. 权益消费扣减
3. 权益过期处理
4. 统计数据准确性

请列出完整测试清单

关键收获

项目规模:

会话数: 6 个
代码量: 约 2000 行

关键成功因素:

✅ 详细的前期设计
✅ 分模块实施
✅ 使用文件串联会话
✅ 及时的测试验证

5.2 案例 2: 紧急 Bug 修复

背景

线上故障: 用户支付成功，但订单状态未更新

影响: 用户无法使用已购买的功能

要求: 紧急修复

实施过程

第 1 步: 快速定位

bash

/clear

紧急 Bug 需要快速定位

【问题描述】
用户支付成功，但订单状态未更新为"已支付"

【已知信息】
- 支付回调收到了
- 订单表中状态仍是"待支付"
- 用户无法使用功能

【相关代码】
@api/v1/payment_callback.go
@service/order.go

请快速分析可能的原因，不要写代码

【优先级】
1. 是否有事务问题？
2. 是否有异常未捕获？
3. 是否有并发问题？

第 2 步: 根因分析

bash

基于代码分析，我发现问题：

【问题】
支付回调中更新订单状态时抛出异常，但异常被吞掉了，
事务回滚导致状态未更新

【验证方式】
查看日志中是否有异常记录

请给出详细的问题说明

第 3 步: 快速修复

bash

采用最小修复方案

【修复内容】
1. 添加异常捕获和日志记录
2. 确保订单状态更新在事务中正确提交
3. 添加重试机制

开始修复

第 4 步: 验证和部署

bash

修复完成

【验证清单】
- [ ] 本地测试支付回调
- [ ] 测试环境验证
- [ ] 代码审查
- [ ] 准备回滚方案

输出验证步骤

关键收获

修复效果:

代码变更: 10 行
影响范围: 最小化

关键成功因素:

✅ 快速聚焦核心问题
✅ 最小化修复
✅ 完善的验证流程

5.3 案例 3: 系统性重构

背景

订单模块代码混乱，需要重构为清晰的三层架构。

当前问题:

API 层包含业务逻辑
Service 层包含数据库操作
没有统一的错误处理

实施过程

阶段 1: 全面分析

bash

/clear

@api/v1/order.go
@service/order.go
@service/payment.go

这 3 个文件职责混乱，需要重构

【分析任务】
1. 识别每个文件的职责问题
2. 梳理正确的分层架构
3. 制定重构计划
4. 评估风险点

请将分析结果输出到 REFACTOR.md

不要写代码

阶段 2-4: 分层重构

bash

# 会话 2: Model 层
/clear
@REFACTOR.md
重构 Model 层

【要求】
- 只包含数据库操作
- 使用结构体方法
- 每个表一个文件

# 会话 3: Service 层
/clear
@REFACTOR.md
重构 Service 层

【要求】
- 业务逻辑集中
- 调用 Model 层
- 统一错误处理

# 会话 4: API 层
/clear
@REFACTOR.md
重构 API 层

【要求】
- 参数校验
- 响应组装
- 调用 Service 层

阶段 5: 回归测试

bash

/clear

重构完成，进行回归测试

【测试范围】
- 所有订单相关接口
- 边界情况
- 性能对比

请列出完整测试清单

关键收获

重构成果:

代码变更: 1500 行
Bug 修复: 0（重构过程中未引入新 Bug）

关键成功因素:

✅ 详细的前期分析
✅ 分层逐步重构
✅ 完善的测试保障
✅ 保持向后兼容

🎓 学习总结

你已经掌握

✅ 复杂场景处理

流程组合（串行/并行）
长任务拆分策略
多模块协作技巧

✅ 团队协作

建立 CLAUDE.md 规范
多人协作最佳实践
代码风格统一

✅ 上下文管理

何时清空上下文
清空后快速恢复
避免上下文污染

✅ 性能优化

识别性能瓶颈
优化 N+1 查询
缓存和异步处理

✅ 实战经验

大型功能开发流程
紧急 Bug 修复技巧
系统性重构方法

下一步

实践建议

选择一个真实项目
- 使用学到的技巧
- 建立项目的 CLAUDE.md
- 记录最佳实践
分享给团队
- 组织内部培训
- 建立团队规范
- 持续优化流程
持续学习
- 探索更多场景
- 总结经验教训
- 贡献到团队知识库

参考资源

资源	用途
快速上手教程	复习基础知识
实战指南	查找具体场景
ClaudeCode.md	查询模板语法
README.md	文档导航

版本: v1.1 最后更新: 2025-10-23 适用: 有 1-2 周基础经验的开发者前置: 快速上手教程

Claude Code 进阶技巧 ​

📚 课程大纲 ​

第一部分：复杂场景处理 ​

1.1 流程组合技巧 ​

什么是流程组合？ ​

适用场景 ​

组合模式 1: 串行组合 ​

组合模式 2: 并行组合 ​

1.2 长任务拆分策略 ​

为什么要拆分？ ​

拆分原则 ​

实战案例 ​

1.3 多模块协作 ​

场景 ​

技巧 1: 使用设计文档串联 ​

技巧 2: 增量式修改 ​

1.4 实战案例：复杂重构 ​

任务 ​

第 1 步: 全面分析 ​

第 2 步: 分模块重构 ​

第 3 步: 集成测试 ​

第二部分：团队协作技巧 ​

2.1 建立 CLAUDE.md 规范 ​

为什么需要 CLAUDE.md？ ​

CLAUDE.md 结构 ​

特殊注意事项 ​

2.2 多人协作最佳实践 ​

实践 1: 使用 Git 分支隔离 ​

实践 2: 记录关键决策 ​

实践 3: 代码审查清单 ​

2.3 代码风格统一 ​

学习参考风格 ​

应用风格 ​

第三部分：上下文管理策略 ​

3.1 何时清空上下文 ​

应该清空的场景 ​

不应该清空的场景 ​

3.2 清空后快速恢复 ​

方法 1: 任务摘要恢复 ​

方法 2: 文件恢复 ​

3.3 长任务的上下文管理 ​

策略 1: 分模块管理 ​

策略 2: 使用检查点 ​

3.4 避免上下文污染 ​

问题 ​

解决 ​

第四部分：性能优化实践 ​

4.1 识别性能瓶颈 ​

使用 AI 分析性能 ​

4.2 优化 N+1 查询 ​

场景 ​

优化提示词 ​

4.3 添加缓存 ​

适用场景判断 ​

实施缓存 ​

4.4 异步处理 ​

场景 ​

优化提示词 ​

第五部分：案例研究 ​

5.1 案例 1: 大型功能开发 ​

背景 ​

实施过程 ​

关键收获 ​

5.2 案例 2: 紧急 Bug 修复 ​

背景 ​

实施过程 ​

关键收获 ​

5.3 案例 3: 系统性重构 ​

背景 ​

实施过程 ​

关键收获 ​

🎓 学习总结 ​

你已经掌握 ​

下一步 ​

实践建议 ​

参考资源 ​

Claude Code 进阶技巧

📚 课程大纲

第一部分：复杂场景处理

1.1 流程组合技巧

什么是流程组合？

适用场景

组合模式 1: 串行组合

组合模式 2: 并行组合

1.2 长任务拆分策略

为什么要拆分？

拆分原则

实战案例

1.3 多模块协作

场景

技巧 1: 使用设计文档串联

技巧 2: 增量式修改

1.4 实战案例：复杂重构

任务

第 1 步: 全面分析

第 2 步: 分模块重构

第 3 步: 集成测试

第二部分：团队协作技巧

2.1 建立 CLAUDE.md 规范

为什么需要 CLAUDE.md？

CLAUDE.md 结构

特殊注意事项

2.2 多人协作最佳实践

实践 1: 使用 Git 分支隔离

实践 2: 记录关键决策

实践 3: 代码审查清单

2.3 代码风格统一

学习参考风格

应用风格

第三部分：上下文管理策略

3.1 何时清空上下文

应该清空的场景

不应该清空的场景

3.2 清空后快速恢复

方法 1: 任务摘要恢复

方法 2: 文件恢复

3.3 长任务的上下文管理

策略 1: 分模块管理

策略 2: 使用检查点

3.4 避免上下文污染

问题

解决

第四部分：性能优化实践

4.1 识别性能瓶颈

使用 AI 分析性能

4.2 优化 N+1 查询

场景

优化提示词

4.3 添加缓存

适用场景判断

实施缓存

4.4 异步处理

场景

优化提示词

第五部分：案例研究

5.1 案例 1: 大型功能开发

背景

实施过程

关键收获

5.2 案例 2: 紧急 Bug 修复

背景

实施过程

关键收获

5.3 案例 3: 系统性重构

背景

实施过程

关键收获

🎓 学习总结

你已经掌握

下一步

实践建议

参考资源