会话连续性与战略压缩
在长期项目中，保持会话的连续性和有效管理上下文窗口是关键挑战。本指南介绍如何通过战略压缩技术维持高效的工作流程。
理解上下文窗口
上下文窗口的限制
Claude Code 的上下文窗口虽然很大，但仍有限制：
- 包含所有对话历史
- 包含读取的文件内容
- 包含命令执行结果
- 包含工具调用记录
当接近限制时，早期内容会被移除。
上下文窗口的影响
上下文窗口的大小影响：
- Claude 能记住多少信息
- 能同时处理多少文件
- 对话能持续多长时间
- 响应的准确性和相关性
会话连续性策略
识别会话边界
知道何时应该开始新会话：
应该继续当前会话：
- 任务相关且连续
- 需要之前的上下文
- 还在同一个功能模块
- 上下文窗口未满
应该开始新会话：
- 切换到完全不同的任务
- 上下文窗口接近限制
- 对话变得混乱
- 需要重新设定方向
会话转换技巧
平滑地从一个会话过渡到另一个：
旧会话结束前：
总结关键决策和发现：
1. 决定使用 JWT 认证
2. 令牌过期时间设为 1 小时
3. 使用 Redis 存储刷新令牌
4. 实现了基本的登录和注册功能
5. 待办：添加密码重置功能
新会话开始时：
继续用户认证功能的开发。
已完成：基本登录注册，JWT 认证
技术栈：Node.js, Express, JWT, Redis
现在任务：实现密码重置功能战略压缩技术
什么是战略压缩
战略压缩是指有选择地保留重要信息，丢弃不重要的细节，以优化上下文窗口的使用。
信息分层
将信息分为不同层次：
核心层（必须保留）：
- 项目架构和技术栈
- 关键设计决策
- 接口定义和约定
- 当前任务目标
支持层（按需保留）：
- 实现细节
- 代码片段
- 测试结果
- 调试信息
临时层（可以丢弃）：
- 探索性讨论
- 已解决的问题
- 过时的方案
- 冗余信息
主动压缩
在会话中主动压缩信息：
总结一下我们到目前为止的讨论：
核心决策：
- 使用 PostgreSQL 作为主数据库
- 使用 Redis 作为缓存层
- API 采用 RESTful 设计
- 认证使用 JWT
当前进度：
- 已完成：数据库设计、用户认证
- 进行中：订单管理功能
- 待办：支付集成、通知系统
技术约束：
- 响应时间 < 200ms
- 支持 1000 并发用户
- 99.9% 可用性
现在继续实现订单管理功能。渐进式细化
从高层次开始，逐步深入细节：
第一轮（高层次）：
设计订单管理系统的架构
第二轮（中层次）：
设计订单状态机和主要 API
第三轮（细节）：
实现创建订单的 API 端点文档化策略
外部文档
将重要信息记录到外部文档：
docs/
architecture.md # 架构设计
api-spec.md # API 规范
decisions/ # 设计决策
001-database.md
002-auth.md
progress.md # 进度跟踪在会话中引用文档：
根据 docs/decisions/002-auth.md 中的决策，
实现 JWT 认证代码注释
在代码中记录关键信息：
typescript
/**
* 用户认证服务
*
* 设计决策：
* - 使用 JWT 进行无状态认证
* - 访问令牌过期时间：1 小时
* - 刷新令牌存储在 Redis，过期时间：7 天
* - 密码使用 bcrypt 加密，salt rounds: 10
*/
export class AuthService {
// ...
}提交消息
使用详细的提交消息记录上下文：
feat(auth): implement JWT authentication
- Add JWT token generation and validation
- Implement refresh token mechanism using Redis
- Add password hashing with bcrypt
- Create authentication middleware
Technical decisions:
- Access token expires in 1 hour
- Refresh token expires in 7 days
- Using RS256 algorithm for JWT
Related: #123上下文恢复技术
快速恢复
快速恢复之前的工作状态：
继续昨天的工作。
项目：电商平台
模块：订单管理
上次进度：完成了创建订单 API
今天任务：实现订单查询和更新使用 Git 历史
利用 Git 历史恢复上下文：
查看最近 5 次提交，
了解最近的开发进展代码搜索
通过搜索快速定位相关代码：
搜索所有与订单相关的文件长期项目管理
项目知识库
建立项目知识库：
docs/
README.md # 项目概览
getting-started.md # 快速开始
architecture/ # 架构文档
api/ # API 文档
guides/ # 开发指南
decisions/ # 设计决策
troubleshooting.md # 故障排除定期总结
定期创建项目总结：
每周总结：
本周完成：
- 用户认证模块
- 订单创建功能
- 支付集成（进行中）
技术债务：
- 需要添加更多单元测试
- API 文档需要更新
- 性能优化待进行
下周计划：
- 完成支付集成
- 实现通知系统
- 性能测试和优化里程碑记录
记录重要的里程碑：
里程碑 1：MVP 完成（2024-01-15）
- 用户注册登录
- 商品浏览
- 购物车
- 订单创建
里程碑 2：支付集成（2024-02-01）
- Stripe 集成
- 订单支付
- 支付回调处理
里程碑 3：Beta 发布（2024-02-15）
- 性能优化
- 安全加固
- 用户测试智能上下文管理
优先级管理
根据重要性管理上下文：
高优先级（始终保留）：
- 当前任务的目标和要求
- 关键的技术约束
- 重要的设计决策
中优先级（按需保留）：
- 相关的代码实现
- 测试结果
- 性能数据
低优先级（可以丢弃）：
- 探索性的讨论
- 已解决的问题
- 临时的调试信息动态调整
根据任务动态调整上下文：
切换任务时：
暂时不需要认证模块的细节，
专注于支付集成的实现按需加载
只在需要时加载详细信息：
现在需要了解用户认证的实现细节，
请读取 src/auth/ 目录的相关文件会话模板
新功能开发模板
新功能：[功能名称]
背景：
- 项目：[项目名称]
- 技术栈：[列表]
- 相关模块：[列表]
需求：
- [需求 1]
- [需求 2]
技术约束：
- [约束 1]
- [约束 2]
参考：
- 类似功能：[文件路径]
- 设计文档：[文档路径]Bug 修复模板
Bug 修复：[Bug 描述]
环境：
- 项目：[项目名称]
- 分支：[分支名]
- 影响版本：[版本号]
问题：
- 现象：[描述]
- 重现步骤：[步骤]
- 错误日志：[日志]
相关代码：
- [文件路径]代码审查模板
代码审查：[PR 编号]
审查范围：
- 文件：[文件列表]
- 更改类型：[功能/修复/重构]
审查重点：
- 代码质量
- 安全性
- 性能
- 测试覆盖
项目上下文：
- 技术栈：[列表]
- 代码规范：[规范]压缩技巧
技巧 1：使用引用
用引用代替重复内容：
❌ 不好的方式：
[重复粘贴大段代码]
✅ 好的方式：
参考 src/auth/login.ts 中的实现技巧 2：总结讨论
定期总结讨论内容：
我们讨论了三种方案，
最终选择方案 B（使用 Redis 缓存），
原因是性能最好且实现简单。技巧 3：删除冗余
删除不再需要的信息：
之前讨论的方案 A 和 C 已经被否决，
现在专注于实现方案 B技巧 4：分层存储
将不同层次的信息分开存储：
高层设计 → docs/architecture.md
API 规范 → docs/api-spec.md
实现细节 → 代码注释
临时笔记 → 会话中最佳实践
主动管理
主动管理上下文，不要等到窗口满了：
我们已经讨论了很多内容，
让我总结一下关键点，
然后继续下一步保持焦点
保持会话的焦点：
这个讨论偏离了主题，
让我们回到原来的任务：
实现订单查询功能及时记录
及时记录重要信息：
这个决策很重要，
我会记录到 docs/decisions/定期清理
定期清理不需要的信息：
这些调试信息已经不需要了，
现在专注于实现新功能工具和技术
使用 Git
利用 Git 管理历史：
bash
# 查看最近的更改
git log --oneline -10
# 查看特定文件的历史
git log --follow src/auth/login.ts
# 查看某次提交的详情
git show abc123使用笔记工具
使用外部笔记工具：
- Notion
- Obsidian
- Markdown 文件
- Wiki 系统
使用项目管理工具
使用项目管理工具跟踪进度：
- GitHub Issues
- Jira
- Trello
- Linear
常见问题
问题 1：上下文丢失
解决：定期总结，使用外部文档
问题 2：信息过载
解决：分层管理，优先级排序
问题 3：难以恢复
解决：使用模板，记录关键信息
问题 4：重复讨论
解决：记录决策，引用文档
总结
有效的会话连续性和战略压缩需要：
- 主动管理上下文窗口
- 分层存储不同重要性的信息
- 使用外部文档记录关键内容
- 定期总结和压缩信息
- 保持会话的焦点和连续性
通过掌握这些技术，你可以在长期项目中保持高效的工作流程。