从一次“失忆”说起
昨晚让智能体改一个鉴权中间件，前两分钟它还知道 src/middlewares/auth.ts 里有一份待办的白名单逻辑，第三分钟它若无其事地重写了一份。这是上下文被截断后的典型表现：不是忘了，而是压根没看到。
编码智能体的窗口看起来很大，真正可用的部分被系统提示、工具定义、历史工具返回值切得七零八落。
| 组成 | 占用量级 | 可控性 |
|---|---|---|
| 系统提示与工具定义 | 10K-20K | 低 |
| 检索到的代码片段 | 5K-60K | 高 |
| 命令输出（构建/测试日志） | 波动极大 | 高 |
| 历史对话轮次 | 随时间线性增长 | 中 |
四条规矩
一、日志先裁剪再入窗。 构建失败时把整段 webpack 输出丢给模型是最常见的浪费。我收敛成一条命令：
npm run build 2>&1 | grep -E "error|Error" -A 3 | tail -40
一次调用从 30K token 降到 400，剩下的全是错误本身。
二、每个任务开新会话。 接着上一个任务的会话开新需求，是上下文污染的主要来源。上文的目录结构、上文的命名习惯都会渗进这次的判断。
三、把稳定约定沉到文件里。 与其在对话里反复强调“我们用 pnpm、组件放 packages/ui”，不如固化成仓库内的约定文件，让工具自己去读。对话里的说明会丢，文件不会。
四、限制单次检索的文件数。 让它“看看整个模块”，它会读 40 个文件；让它“读 auth 中间件和它的两个调用点”，它读 3 个。前者烧完窗口，后者解决问题。
一点体会
模型能力涨得很快，但工程瓶颈早就从“能不能写对”移到了“记不记得住”。同一个模型，喂进去的上下文质量差别能到两倍以上，这不是玄学，是 token 预算的分配问题。
上下文管理本质上就是把大模型当成一台带宽有限、内存昂贵的分布式系统来调度：能压缩的别传输，能缓存的别重算，能落盘的别留在内存里。
