如何管理上下文
前言
日常使用编程 Agent 的时候,总会考虑到上下文窗口的大小,首先,不同厂商模型的上下文长度不一样,我日常使用 Claude Code(以下简称cc),搭配 GLM5.1、Deepseek-v4-pro,前者支持最大上下文窗口200k,后者能支持长达1M。
对其他领域不太了解,拿编程来说,当你上下文达到1M,前期任务对话的注意力已经被稀释了,200k的上下文超出后,在经过多次compact后,早期内容也会被截断,而且还会有幻觉累计的风险,长会话中如果某个错误理解没被纠正,后续会在错误基础上叠加;再者,一个会话只能做一件事,无法并行(当然,并不是说短会话就可以并行,还得看你的项目是否足够模块化,各层之间边界是否清晰),可见一直在一个会话中对话的性价比并不高。那是不是应该一个任务开一个会话呢,当然也不是,这种做法很容易想到的一点就是,重复喂上下文,每次都要重新解释项目背景、架构、约定...,效率极低,而且缺乏连贯性,模型不知道之前做了哪些决策,容易走回头路甚至错路。
可参考方案
核心思路是:用文件代替会话记忆,上下文存在于代码库本身,而不是对话历史里
维护好 CLAUDE.md
众所周知,cc有一个很核心的文件 —— CLAUDE.MD,你在项目根目录下进入cc,执行/init,大模型就会读取项目内容自动创建这个文件
如果你的项目已经有框架了,那么直接让大模型生成会比较省事,如果是新项目,则需要你手动编写好背景、架构、约束等
这个文件不仅是一个项目说明,更是一个项目记忆文件,cc每次启动都会读取它,建议 每完成一个阶段任务就更新这个文件,新会话一开始就有完整上下文,这一步也可以让大模型来帮你做,不过还是建议 review 一下
按"工作单元"切割会话,而不是按功能
不是"每个功能开一个会话",而是一个聚焦的任务开一个会话:
✅ 好的会话边界
- "实现订单创建的 API + service + 数据库 migration"
- "修复购物车计算逻辑的 3 个 bug"
- "重构用户模块,拆分成更小的 service"
❌ 不好的边界
- "帮我开发整个电商后台"(太大)
- "改一行代码"(太小,不值得切换)
第一个 prompt 规范好边界
新会话开头不要直接说"帮我写XXX",而是:
背景:我在开发电商项目(Next.js + PostgreSQL),CLAUDE.md 里有架构细节。
当前任务:实现订单状态流转逻辑(待付款→已付款→已发货→已完成)
相关文件:/app/api/orders/, /lib/services/orderService.ts
约束:状态流转需要记录操作日志,不能直接改 status 字段
利用 /clear 而不是开新窗口
当一个任务完成、要切换到另一个任务时,在同一个 Claude Code 实例里用 /clear 清空对话历史,项目文件仍然在,只清掉对话噪音,比重开一个会话更高效。
总结
核心其实就是一句话,上下文应该活在代码和文档里,而不是活在对话历史里。