📄 一句话概括
上下文不是仓库，是工作台——只放今天要用的；喂 30 个文件多付的 8100 行成本，换来的是一堆用不上的背景。
📝 本节和前面几节的关系
上一节讲把话说明白，这一节讲喂什么：很多人在【喂得越多越保险】上吃过亏。
一、一个很常见的直觉，以及它为什么错
直觉是【多给点背景，它理解得更好】。实际上背景一旦过量，注意力就被摊薄了。 一个文件平均三百行——喂三十个，就是九千行的东西挤在你的要求旁边。 你真正要用的可能只有其中两个文件。
二、两种喂法的信噪比
倒一堆：十个项目的说明喂进去，它要自己筛掉其中九个——它筛不一定对。 喂一份摘要：当前项目的三页要点，它几乎不用筛。 差别不在给不给背景，在背景里有多少是要紧的。
三、怎么瘦
先自己筛一遍：哪些文件是这次真正要碰的？只给这些。 再摘出一段：相关的那个函数、那个字段，不用给整个文件。 其余的让它自己去找——第 1.6 节说过，它会搜索、会读，你只要告诉它方向。
四、一个反直觉的结论
上下文瘦身不只省钱，还提高质量。 因为它少了一样东西要去分辨——这往往就是它跑偏的源头。 所以每次喂之前问一句：这份东西，它今天真的用得上吗？用不上就别喂。
五、动手 Demo：上下文工程——多给不等于好使
下面把两种喂法并排，再算一遍喂文件的行数代价。
TH([u"喂法", u"喂了什么", u"它要自己筛掉", u"信噪比"], [12, 28, 26, 10])
T([u"倒一堆", u"十个无关项目的说明", u"其中九个", u"约 1 成"], [12, 28, 26, 10])
T([u"喂一份摘要", u"当前项目的三页要点", u"几乎不用", u"很高"], [12, 28, 26, 10])
实跑输出：
--------------------------------------------------------------------
上下文工程——多给不等于好使
--------------------------------------------------------------------
给它一堆资料很容易，给对资料很难。看两组资料的区别：
喂法 喂了什么 它要自己筛掉 信噪比
---------------------------------------------------------------
倒一堆 十个无关项目的说明 其中九个 约 1 成
喂一份摘要 当前项目的三页要点 几乎不用 很高
再算一笔：假设一个文件平均 300 行——
喂 3 个文件 = 900 行
喂 30 个文件 = 9000 行
喂 30 个文件，多付的是 **8100 行**的成本，换来的是一堆它用不上的背景。
结论一句话：**上下文不是仓库，是工作台——只放今天要用的。**
那个行数对比才是关键：喂三十个文件多付的 8100 行，换来的却是一堆用不上的背景。 所以上下文不是仓库，是工作台——只放今天要用的。
30 秒实验
- 数一数你上一个任务喂了几个文件，其中几个是真相关的。
- 试着把背景砍掉一半再喂一次——看结果变好还是变差。
常见误区
- 把整个项目一股脑喂进去。你分不清哪些重要，它更分不清。
- 以为少给背景会出错。它会自己搜索——第 1.6 节讲过，给方向比给全文更省。
自测三问（点开对答案）
1. 为什么多喂背景不一定更好？ —— 背景一旦过量注意力就被摊薄，而且它筛得不一定对。 2. 上下文瘦身的三步是什么？ —— 自己筛出真正要碰的文件、摘出相关那一段、其余让它自己去找。 3. 瘦身的额外好处是什么？ —— 提高质量——少一样要去分辨的东西，就少一个跑偏的源头。- ☐ 下一节（6.3 让Claude Code采访你）