主题
上下文管理实战
模型每一次回答，只依据当前上下文窗口里的内容。上下文的质量决定回答的质量，上下文的体积决定成本。这一篇讲怎么在真实工作里管好它——这是《大语言模型是什么》第 3 节原理的直接应用。
1. 先建立一个心智模型
把上下文窗口想成一张固定尺寸的工作台：
- 你放上去的东西越多，单次成本越高（按 token 计费）。
- 工作台满了，最早的东西会被截断或压缩，模型就"看不见"了。
- 模型不会主动判断"哪个重要"——放什么、留什么、何时清理，完全是你的责任。
由此推出一条铁律：上下文不是越多越好，相关度才是第一标准。塞满无关文件，不仅费钱，还会稀释模型注意力，让关键信息更容易被忽略。
2. 一次会话的生命周期
健康的会话应该像这样推进：
一次会话的生命周期
- 1开场人负责设定角色 + 目标 + 关键约束
- 2中段人机协作围绕一个任务推进，小步确认
- 3收尾人负责总结成果，沉淀到文件或规则
- 4新任务 → 新会话人负责把必要背景带过去，不拖着旧对话
最常见的反模式是一个会话从早用到晚：话题横跨三个项目，历史里堆满已解决的报错和废弃方案。窗口一满，模型开始"忘事"、重复提问、自相矛盾——此时该做的不是硬撑，而是开新会话。
3. 实战技巧
3.1 项目规则文件：把"每次都要说的"固化下来
如果每个会话都要重复"我们用 TypeScript、测试用 Vitest、提交信息用中文"，把这些固化到项目根目录的规则文件里（Claude Code 的 CLAUDE.md、Codex 的 AGENTS.md）。客户端会自动把它们注入上下文，一次编写、处处生效。
规则文件写什么：
- 技术栈与目录结构的一句话说明；
- 编码规范和命名约定；
- 常用命令（如何构建、如何跑测试）；
- 明确禁止的事项（"不要改动 migrations 目录"）。
不要写成万字长文——规则文件每次会话都会进入上下文，本身也有 token 成本，保持一屏以内最好。
3.2 按需提供文件，而不是整目录
让模型看"相关的"文件：
text
差：这是我们整个项目的压缩包，帮我改个按钮样式
好：按钮在 src/components/Button.vue，样式规范在 docs/style.md，改成圆角 8px终端 Agent 会自己读文件，你只需在指令里点出文件路径；聊天工具则直接粘贴相关片段。判断标准很简单：这段信息不提供，模型会猜错吗？会，就提供；不会，就不提供。
3.3 长会话主动"做减法"
会话变长时的三个减法动作：
- 压缩历史。Claude Code 提供
/compact等压缩指令，把长历史浓缩成摘要后继续；其他客户端找类似功能或手动操作。 - 总结再开新会话。让模型输出当前进展的三行总结（已完成、进行中、下一步），粘进新会话作为开场，比拖着全部历史便宜且干净。
- 大输出落盘。让模型把长方案、长清单写到文件里，后续引用文件而不是让它们留在对话历史里。
3.4 大任务的拆分节奏
长任务主动分段，每段一个明确的里程碑：
text
第 1 段：分析现状，输出方案文档（不写代码）
第 2 段：按方案实现核心模块
第 3 段：补测试并修复
每段之间：人工确认 + 必要时新开会话拆分的额外收益：每段开始时上下文干净、目标单一，模型的执行质量和你的审查效率都更高。这正是《第一个 AI 编程项目》"小步实现"方法论的上下文版本。
4. 症状对照表
| 症状 | 根因 | 处理 |
|---|---|---|
| 长会话后期开始"忘事" | 早期内容被截断出窗口 | 压缩历史或总结后新开会话 |
| 回答越来越贵 | 历史滚雪球，每轮都带着全部包袱 | 主动做减法，见 3.3 |
| 模型忽略你的约束 | 约束在很早之前说过，早已不在窗口 | 关键约束写进规则文件或每次重申 |
| 回答泛泛、像没读过项目 | 缺少项目上下文 | 补规则文件，指令中点明相关文件 |
| 同样的解释反复出现 | 在错误的信息基础上追问 | 停止追问，纠正上下文再继续 |
5. 检查清单
- 新任务是否开了新会话，而不是续用前一次任务的长对话？
- 项目规则文件是否存在、是否保持在一屏以内？
- 发送前是否问过自己："这段信息删掉模型会猜错吗？"
- 长会话是否在关键节点压缩或总结过？
- 大段产出是否落盘为文件，而不是留在对话里？
把上下文管好，同一批工具、同一个模型，产出质量和成本都会有肉眼可见的改善。相关的省钱视角见《效率与省钱技巧》，Agent 视角的系统论述见《上下文工程与记忆》。