AI 编程的上下文构建
上下文有四层来源，优先级不同、腐化速度也不同：规则文件常驻、任务描述每次给、检索结果按需、对话历史最容易烂。整仓塞进去反而更差是 context rot；两条检索路线（索引检索 vs 代理式检索）是两个不同的评价函数；提示缓存要求静态在前动态在后。
也叫：上下文构建 · 规则文件 · AGENTS.md · CLAUDE.md · 代理式检索 · agentic search
二、上下文从哪来：四层来源，优先级不同，腐化速度也不同出自 T7-1
┌─ 第 1 层 系统提示 + 工具定义 全局共享，几乎不变 ← 缓存的地基 ├─ 第 2 层 规则文件（项目记忆） 项目内共享，周级变化 ├─ 第 3 层 会话取回的内容 本次任务相关，每次都变 ← 你真正能调控的 └─ 第 4 层 对话历史 单调增长，最脏
第 3 层是主战场。故障案例里的十二万 token 全在第 3 层；正确做法是把最关键的那句「V2 才是在跑的那个」上提到第 2 层写进规则文件，让它每次都在，而不是指望模型每次从代码里重新推断。
这里有一条容易被忽略的推论：规则文件是用来放「推不出来的事实」的，不是用来放「读一眼代码就知道的事实」的。官方给的检验方法很朴素：逐行问自己「删掉这行，模型会不会犯错？不会就删」。三家大厂给的长度上限数字不同（见下节表格），但都附了同一句警告：臃肿的规则文件会让模型忽略你真正的指令。
以上节选自T7-1 从「AI 帮我写」到「我带 AI 干」——工具形态、上下文预算与人的位置，读全文能看到前后语境。