前言

日常使用编程 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 清空对话历史，项目文件仍然在，只清掉对话噪音，比重开一个会话更高效。

总结

核心其实就是一句话，上下文应该活在代码和文档里，而不是活在对话历史里。