上下文不是越多越好：和 AI 协作时的"信息饮食"

一、一个反直觉的事实

刚开始用 AI 编程助手时，我有个朴素的直觉：喂得越多，答得越准。

于是我把整个文件贴进去、把相关目录全丢过去、把三份文档一起塞给它，心想"信息给足，总不会错"。

结果是相反的。它抓不住重点，东拉西扯；本该只改 A 文件，它却去动了 B；偶尔还会把某段早就废弃的旧约定，当成当前规则照做。

后来我才想明白：上下文窗口是一种稀缺资源，噪声会稀释信号。 给 AI 的信息不是"越多越保险"，而是像饮食——吃对、吃够，比吃撑重要得多。

二、上下文有三种成分

想清楚这一点，"怎么喂"就清楚了。我给到 AI 的信息，其实分三类：

• 必需：直接相关的代码、明确的约束、验收标准。这类要给足、给准。
• 噪声：无关的文件、大段日志、过期文档。这类给得越多，越干扰判断。
• 危险：过时的约定、自相矛盾的说明。这类比"不给"更糟——它会一本正经地按错误前提干活。

大多数人踩的坑，不是"给少了"，而是把噪声和危险信息当成了"保险"。

三、我组织上下文的几条规则

1. 先说"目标 + 约束 + 验收"，再给材料。
先讲"要做什么、不许做什么、怎么算做完"，再附代码。顺序反过来，AI 就会被材料牵着走，抓不住你的真实意图。

2. 精确指路，别整锅端。
指到文件、甚至函数一级，远比丢整个仓库有效。“改这个文件里的这个函数"和"看看这个项目”，得到的质量天差地别。

3. 让它自己去取，而不是你全搬给它。
与其把整个依赖链贴进去，不如让它按需检索——用完就"放下"。让 AI 主动找，比逼它通读一切，上下文利用效率更高。

4. 长会话要主动"压缩"。
聊到中途，早期那些试错、跑偏的过程会一直占着上下文。把已确认的结论收敛成一小段，用它替代冗长的历史，后面的对话会明显更稳。上下文里最该清理的，是过程的噪音，而不是结论。

5. 一次只谈一个目标。
把"顺手优化命名、加日志、修 bug"混在一段上下文里，它们会互相污染，最后哪件都没做干净。

四、两种失败，和中间那条线

上下文给得不合适，会走向两个极端：

• 太少：它只能靠猜——猜错方向、编造不存在的 API、自作主张。
• 太多：它抓不住重点，输出泛泛而谈，或者被无关内容带偏。

分寸在哪儿？我的经验是一句话：把不确定的地方说清楚，把确定但无关的地方拿掉。

"不确定"的部分（模糊的需求、隐含的约束）才需要你花笔墨；"确定但无关"的部分（跑得通的旧代码、已经废弃的设计），一个字节都是负担。

五、它和"知识资产"不是一回事

说到"喂给 AI 什么信息"，容易和我之前聊的两件事混起来，这里划清界限：

• 知识库 / 规则文件：是预先准备好的稳定上下文，属于长期资产，回答"有没有"。
• 上下文工程：是每次会话内的临场取舍，回答"这一刻该用哪一些"。

前者负责把沉淀铺好，后者负责在具体任务里挑对、裁剪。两者互补——但有了资产不等于会用资产，每次用什么、用多少，仍是一次独立的判断。

六、结语

和 AI 协作的质量，很大程度不取决于模型有多强，而取决于你喂给它的信息有多干净。

给它需要的，去掉它不需要的；把模糊的地方讲透，把无关的东西拿开——这比"多给一点当保险"要有效得多。说到底，会提问的人，从来不是话说得最多的人。