上下文工程：提示词之后的新基本功

01熟悉的场景THE FAMILIAR SCENE

让 AI 干一个长活——写一份几十页的报告、重构一个小项目。开头它很聪明，越到后面越糊涂：忘了前面说好的约定，重复问已经答过的问题，引用一个根本不存在的文件。

直觉的反应是"模型不行了"，于是换个更强的模型。会好一点，然后在更晚的地方，以同样的方式再乱一次。

F-004 已经解释过一半：模型没有记忆，只有重读——每一步它"知道"的，只有此刻窗口里装着的东西。这份底稿讲另一半：既然窗口就那么大、还要花钱，那"让它看见什么"就不该是自然堆积的结果，而是一个要设计的东西。这件事现在有了名字，叫上下文工程。

提示词工程管的是"怎么说"：指令写得清不清楚、例子给得好不好。这依然重要，但它只是窗口里的一小块。

模型每一步实际看见的，是一整个窗口：你的指令、贴进去的资料、之前的对话历史、工具跑完返回的结果——全部排在一起，争夺同一块有限的地方。输出的质量，取决于这一整窗东西的质量，而不只是指令那一句。

所以把窗口当成工作台更准确：木匠开工前会收拾台面——用到的工具摆上来，不用的收走，上一件活的木屑扫掉。上下文工程就是每一步都做这件事：这一步需要什么，摆上；不需要什么，拿走。

而聊天窗口的默认行为恰恰相反：所有东西永远留在台面上，越堆越高。长对话变笨不是意外，是写在默认行为里的结局。

台面上的东西可以分四类，每类有自己的腐坏方式：

指令。要它干什么、守什么规矩。腐坏方式是被冲淡——几十轮对话之后，开头立的规矩淹没在中间的细节里，模型开始"忘记"人设和约定。

材料。这一步需要的资料——注意是"这一步需要的"，不是"所有的"。腐坏方式是放多了互相打架：两份口径不一的文档同时在台面上，模型多半不会举手报矛盾——它会挑一份信下去，你不知道是哪份。F-002 讲的检索，本质就是替这一类做筛选。

进度。做到哪了、还剩什么。腐坏方式是用全量历史冒充进度——历史里带着早期的错误和绕路，F-001 说过，一步的误判会成为下一步的前提，在循环里滚雪球。

回执。工具跑完返回的结果。腐坏方式是太长——一个命令输出几百行日志，重点两行，其余全在稀释台面上其他东西。

下次长任务变乱，先别怪模型：对着这四类问一遍，哪类腐坏了？

不需要任何框架，三个动作就是上下文工程的入门：

开新窗不是认输。长对话变笨时，把已经确定的结论自己整理成一段，开一个新会话，把这段贴进去继续——F-004 管这叫"换血"。旧窗口的几万字历史，浓缩成几百字的"目前为止"，是最朴素也最有效的一次台面清理。

给长任务写进度便签。开工时就让 AI 维护一份任务清单或小结，每完成一步更新一次。之后每一步给它看的是便签，不是全量历史——又便宜（F-004 的账），又不带早期错误。

材料按需给。一次给一章，不是整本书；问哪个模块，贴哪个模块的代码。贴之前先问自己：这一步真的用得到吗？用不到的材料不是中性的，它在占地方、在稀释、在制造打架的机会。

这份底稿站在三篇底稿的肩上：窗口为什么有限、钱花在哪，见 F-004 成本直觉；三种改变模型行为的手段里，"增强"那一档给参考书的那一半，本质就是上下文工程，见 F-005；替"材料"做筛选的流水线，见 F-002 RAG 部件清单。

再往深走一层是判断问题：材料从哪来、谁有权看、版本谁说了算——上下文的质量上限是知识系统的质量，见 N-002 为什么私有知识系统应该先于 RAG。

底稿负责把台面摆清楚；台面上的材料从哪来、可不可信，判断在笔记里。