把 200K 上下文跑满之后，我给编码智能体立了四条规矩

从一次"失忆"说起

昨晚让智能体改一个鉴权中间件，前两分钟它还知道 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 预算的分配问题。

上下文管理本质上就是把大模型当成一台带宽有限、内存昂贵的分布式系统来调度：能压缩的别传输，能缓存的别重算，能落盘的别留在内存里。