上下文是怎么回事
上下文是这一次请求里模型能看到的全部内容。它有上限，而且并非看到就等于用上。
你会遇到的现象
- 聊到第三十轮，它开始忘记前面定好的规则
- 把整个项目丢给它之后，回答反而变含糊了
- 新开一个会话，昨天讲清楚的事要从头再讲一遍
它包含什么
| 组成 | 说明 |
|---|---|
| 系统提示与项目规则 | 工具自带的指令，加上你项目里的约束文件 |
| 历史对话 | 这一轮会话里说过的每一句，包括它自己的回复 |
| 读过的文件 | 它打开过的代码、文档。一个大文件能吃掉很大一块 |
| 工具输出 | 搜索结果、命令行输出、报错信息。这部分最容易失控 |
| 你最新说的话 | 本轮的指令 |
还有一条容易踩的：跨会话不会自动延续。今天的会话结束，昨天的判断就不在了，除非它被写进了项目里的文件。
长了会变差
直觉上给的信息越多越好，实际不是。上下文变长时，推理准确率会逐渐下滑，这个衰减是渐进的，不会突然崩掉，所以很难察觉。
- 中段最容易被忽略。模型对开头和结尾的注意力更高，塞在中间的关键约束经常不起作用。重要的规则要么放最前，要么在当下这条指令里重申。
- 窗口大不等于用得上。能装进一百万 token，不代表这一百万都被有效利用。塞满噪音之后，指令遵循和推理都会明显下降。
- 无关内容是污染。读了一堆用不上的文件、贴了一大段无关日志，这些不是「多点信息没坏处」，它们在挤占注意力。
- 成本和延迟也跟着涨。这一条对 AI 产品尤其现实——每一次调用都是真金白银。
四个应对动作
| 动作 | 做什么 | 具体手段 |
|---|---|---|
| 写出去 | 把结论存到上下文之外 | 规格文件、约束文件、进度记录。不让它反复推导已经定过的事 |
| 挑着给 | 只给这一步真正需要的 | 指名要改哪个文件，别让它自己翻遍整个仓库 |
| 压缩 | 长内容先摘要再进上下文 | 大段日志先提取关键行；长对话阶段性总结一次 |
| 隔离 | 不同任务分开跑 | 一个任务一个会话，别让上一件事的噪音污染下一件 |
还有一条跟代码组织有关：按功能分目录比按技术分层更适合 AI 协作。做登录相关的改动，前者只需要读 auth 目录，后者要从每一层各读几个文件才能拼出全貌。