一、先算一笔账：一个会话读了多少东西

一次典型会话会读：入口文件、核心模块、配置文件、测试文件，再加上搜索命中的片段。 本节的演示里，这些加起来六千五百多行。这只是【读】的部分。 再往后它写、改、验证，还要继续加。

二、为什么越往后越慢越贵

因为后面每句话都要带着前面读过的这些。 于是同一个任务，开头问一次和第五个任务再问一次，价钱差着好几倍。 这不是它笨，是上下文窗口就那么大，只能靠取舍。

三、对策只有两条，都很朴素

一、做完一件事就收尾，别把三件事挤在一个会话里。新开一个会话，账就归零了。 二、下一件事开工前，先给它一份简短总结——这次改了什么、现在什么状态、要注意什么。省掉的是它重新读一遍。 第二条是重点：总结是你写给它的地图，写一次，后面几轮都在用。

四、一个判断标准

当你发现它在重复问同一件事，或者忘了你早先说过的话——就是该收尾的时候了。 这两条信号几乎总是提前出现，比你感觉到的要早。

五、动手 Demo：上下文别变垃圾场——算一笔账

下面统计一次典型会话读了多少行。

reads = [(u"读入口文件", 1, 120), (u"读核心模块", 6, 3800),
         (u"读配置文件", 3, 260), (u"读测试文件", 4, 900),
         (u"搜索命中片段", 10, 1500)]
total = sum(ln for _, _, ln in reads)

实跑输出：

--------------------------------------------------------------------
上下文别变垃圾场——算一笔账
--------------------------------------------------------------------

会话越长，读过的文件越多。下面算一次典型的会话开销：

  动作             次数     累计行数
  -----------------------------------
  读入口文件       1        120
  读核心模块       6        3800
  读配置文件       3        260
  读测试文件       4        900
  搜索命中片段     10       1500

一个会话读下来 6580 行。

接着做第三件事（比如加一个新功能）时，它**还得带着前面这些**，越往后越慢越贵。
对策只有两条：
    一、做完一件事就收尾，别把三件事挤在一个会话里
    二、下一件事开工前，先给它一份简短总结，省掉重新读一遍

输出里最该记的是那个总数：六千五百多行，而且这还只是【读】。 对策那两行是全部答案：做完一件事就收尾；下一件事先给总结。总结是你写给它的地图。

30 秒实验

1. 翻一下你今天开的会话，有几个是超过三件事挤在一起的？
2. 养成习惯：每做完一件事就新开会话，并写三句话的总结交接。

常见误区

1. 在一个会话里连做三件事。后面每句话都在替前面的历史付钱。
2. 以为收尾就是关掉窗口。真正的收尾是留一份总结——关掉而不总结，下一个会话还是从零读。

• ☐ 下一节（4.8 6个常见误区）

相关笔记

• 🐳 DeepSeek Harness技术架构原理 · 索引 — 上下文窗口与成本的实际算法
• 🧡 Claude Code橙皮书 · 索引