地图:七组共 18 个概念

一张地铁线路图:先整体看清各条线路,再一站一站地坐过去。

这门课走过七组概念。第一组——窗口:模型到底知道什么。接着——从措辞一个 prompt 到组装 context 的转变。然后——窗口由什么构成,以及让它变差的三种力量:无关内容、预算和随时间腐烂。最后——实践:有意识地构建窗口,并衡量结果。

如何阅读每个概念

一本护照:每个人的栏目都一样,所以很容易比较。

下面每个概念都用同样的方式讲:它的英文名称(记住它——文档和文章都这么叫),一幅日常生活的画面,一张图,以及一张带有问题、思路、例子、代价和关联等栏目的卡片。这门课的核心思想:LLM 的质量由你放进窗口的东西决定,而不是巧妙的措辞。

Stateless Model——两次调用之间什么都不记得

一位才华横溢却彻底失忆的顾问——每次会面,你都得把每份文件重新递给他一遍,因为他对上次的事毫无记忆。

语言模型是无状态的(stateless)——这就是 Stateless Model 这个概念:它在两次请求之间什么都不保留。聊天机器人“记得”你的对话,不过是每次都把完整历史重新发了一遍。模型本身每次调用都从头开始,只知道此刻摆在面前的东西。

所以“模型知道什么?”从来不取决于模型——完全取决于你这一次选择放进去什么。

Context Window——它唯一的工作记忆

一个工人只能依据钉在他面前白板上的便签行事——把白板擦干净,就仿佛什么都没发生过。

Context window(上下文窗口)是模型在一次调用中看到的那块文本——你的指令、对话、各种数据、工具。它是模型全部的工作记忆,而且大小有限。如果某个事实、某条规则或某条过去的消息不在窗口里,模型就是不知道。

模型能推理的一切,都是依据窗口来推理的——这使窗口成为你真正要去设计的东西。

所以质量取决于你放进去什么

一位天才只依据你递给他的那一个文件夹作答——给他对的文件夹,答案就精彩;给他错的,他就自信地一无是处。

因为模型只依据窗口工作,它输出的质量大多在模型运行之前就已决定——取决于你组装了什么。同一个模型,给出精彩的答案还是糟糕的答案,完全取决于摆在它面前的是不是正确的 context。这重新定义了整份工作:你不是在从模型里哄出智能,而是在**筛选它能看到什么。**这种筛选就是 context engineering。

Prompt Engineering vs Context Engineering——措辞与组装

律师赢官司靠的不是巧妙的措辞,而是把恰好正确的文件、按正确的顺序、不带任何无关内容递给法官——案子在卷宗里,不在演讲里。

Prompt engineering 关心的是你怎么措辞指令。Context engineering 是更大的工作:每次调用时,把模型需要的全部信息——相关事实、历史、示例、工具——组装进窗口。

随着应用变大,措辞越来越不重要,组装越来越重要。大多数“AI 给了个糟糕答案”的时刻,并不是措辞不好,而是模型缺少从未给过它的 context。

Missing Context——大多数质量问题都是 context 问题

一个助手给出了错误答案,只因你忘了提那个改变一切的约束——他不蠢,只是不知情。

当某个 LLM 功能表现不佳时,本能反应是调整 prompt 措辞或怪罪模型。更常见的真正原因是 context 缺失或错误(missing context):相关文档没有被检索到,关键规则没有被包含,过时的历史把它搞糊涂了。

在改写任何措辞之前,先问问模型实际上面前有什么。修好 context 比修好措辞能解决多得多的 bug。

模型的好坏取决于它的输入

最好的厨师也只能用台面上的食材做菜——给他错的食材,手艺也救不了这道菜。

一个能力强但 context 糟糕的模型,会输给一个较弱但 context 出色的模型。这就是为什么 context engineering 而不是选模型,通常是最值得投入精力的地方:同一个模型的输出会随你喂给它的东西剧烈波动。想要更好的答案,不是靠更用力地要求,而是靠往窗口里放更好、更锋利、更相关的材料。输入就是杠杆。

System Prompt——长期行为与一次性请求

餐厅的长期政策——“我们是素食餐厅,十点打烊”——对比今晚的具体点单。前者框定一切;后者是所求之事。

System prompt 放的是适用于整个交互的长期指令:模型的角色、必须遵守的规则、语气、输出格式。用户消息则是具体的请求。

把你的人设、护栏和长期规则放进 system prompt,它们就能保持稳定,而用户的问题则千变万化。这就是模型在每次调用中是谁与它这一次被要求做什么之间的区别。

Few-shot Prompting——展示,而不只是讲述

给人展示三个做好的范例来教一种格式,比用语言描述它、指望对方想象得对,既更快也更清楚。

想得到你要的输出形态,最可靠的办法往往是在 context 里直接放几个输入与理想输出的示例。这就是 few-shot prompting 模式。模型对示例的模仿,远比对抽象描述的遵循来得好。

两三个锋利的示例,可以胜过一段话的指令,而且当模型差不多做对、却又不太对时,它们往往是最快的修复办法。

Context Assembly——用零件构建窗口

为一次会议收拾公文包:议程、两份相关报告、一张写着约束条件的便条——有意挑选的,而不是把整个文件柜都倒进去。

真正的 context window 每次调用都由若干部件组装而成:system prompt、相关历史、检索到的事实(RAG)、示例、可用的工具,最后是用户的请求。这就是 context assembly:每一次都有意识地决定哪些部件进来、哪些留在外面。

把窗口看作你用部件构建出来的东西,而不只是你敲出来的一段 prompt,这个思维转变会让其余一切豁然贯通。

Relevance over Completeness——更多的 context 不等于更好的 context

一页锋利的简报胜过 200 页的堆砌——读者能找到信号,而不是淹没其中,于是决定得更快更好。

把一切可能相关的东西“以防万一”都塞进窗口,很诱人。但更多并不更好——通常更糟。原则是 relevance over completeness(相关性胜过完整性):每个 token 都在争夺模型的注意力,无关的材料会稀释信号。

真正的功夫,是挑出少数重要的东西,而不是把所有可能重要的都放进去。

Context Dilution——噪声提高了答错的概率

把唯一相关的事实藏进一座大多无关的纸山里,连认真的读者也会开始引用错误的那一页——噪声本身造成了错误。

又长又被灌水的 context 不只是浪费空间;它在实实在在地拉低质量。这就是 context dilution:埋在无关材料之中,模型的注意力被摊得很薄,在长 context 中这会可测量地提高幻觉和出错的比率——它自信地用上了某个本不该是答案的东西。

“以防万一”添加的 context,可能恰恰就是造成失败的原因。更少、更锋利的 context,才是更可靠的 context。

Curation——为这次调用毫不留情地筛选

好编辑不加东西——他删,只把配得上留在这一页的句子交给你。

这门功夫是毫不留情的筛选:针对这一次具体的调用,只放模型真正需要的少数东西,其余一概留在外面。这意味着只检索最相关的片段,把历史裁剪到重要的部分,丢掉已经完成使命的 context。

Context Budget——窗口有限,每个 token 都要花钱

一只有重量上限、按公斤收费的行李箱——你装的是真正会用到的东西,而不是整个衣柜,因为有硬上限,也有价格。

Context window 有最大长度,而其中每个 token 都要花费延迟和金钱——更大的 context 在每一次调用中都更慢、更贵。所以 context 不是等着你去填满的免费空间;它是你要花的 context budget。

一个每次请求都塞满窗口的功能,规模一大就又慢又贵,甚至还没轮到质量受损。窗口是要分配的资源,而不是要填满的空洞。

Trim & Summarize——把窗口花在配得上位置的东西上

紧巴巴的旅行预算会逼你做出真正的取舍——你把钱花在对旅行重要的事上,其余的省掉,而这趟旅行因这份自律而更好。

把窗口当作预算,会改变你构建的方式:你裁剪(trim)对话历史,把旧的轮次总结(summarize)而不是原样带着走,并且只检索现在相关的东西,而不是你拥有的一切。每个 token 都应该配得上它的位置。

这与性能优化或缓存是同一种自律——有意识地把稀缺资源花在真正左右结果的事情上。

Long Context Windows——更大的窗口并没有终结这门自律

租一辆更大的卡车,并不意味着你该往里塞满垃圾——更大的容量是给更多有用东西的空间,而不是不再仔细打包的许可证。

模型不断推出更大的 context window(long context windows)——一百万 token,甚至更多——于是很容易以为预算问题就此消失。并没有。更大的窗口依然更贵,每个 token 也依然更慢,而且关键的是,更满的窗口依然会稀释注意力、招致错误。

更大的容量不是倾倒的许可;它只是你仍然必须精打细算去花的更多空间。筛选窗口这门自律,不会因为任何尺寸的增长而失效。

Context Rot——长 context 会累积过时且自相矛盾的状态

一长排人玩传话游戏——到最后,消息已悄悄变了样,而每个人都自信地重复着一个略有错误的版本。

在一段长对话或多步骤的 agent 任务中,窗口会被历史填满:更早的轮次、工具输出、做到一半的推理。久而久之,这堆东西变得杂乱——过时的事实挨着新鲜的事实,矛盾不断累积,最初的目标渐渐失焦。

业界把由此造成的质量衰退称为 context rot:随着模型自己积累的 context 越来越嘈杂,同一个模型会变得越来越不可靠。

Compaction——边走边压缩

好的记录员不会保留一场长会议的每一个字——他把它提炼成决定和未决问题,带走结论,而不是逐字稿。

解决办法是随着 context 增长而主动压缩它。这就是 compaction:把已完成的步骤总结成一份简短的滚动状态,而不是拖着完整的记录往前走;一旦提取出重要的内容,就丢掉工具输出;保留一份紧凑的工作总结,而不是原始历史。

模型带走的是结论,而不是产生结论的每一个字。长时间运行的 agent 就是这样保持连贯的——它们管理自己的 context,而不是任由它堆积。

Goal Re-anchoring——重新锚定目标

在漫长曲折的徒步中,你会定期核对地图和目的地——否则,你会一个看似合理的转弯接着一个,慢慢偏离本来要去的地方。

经过许多步骤,最初的目标会在此后发生的一切重压下被侵蚀。所以你要重新锚定它(re-anchoring):在每一步都把目标和关键约束重新写进窗口,让模型始终对准真正的目标,而不是随着对话漂移。

更大的窗口会让这更糟,而不是更好——它给漂移提供了更多累积的空间。让长任务保持在正轨上的,是主动管理,而不是原始容量。

Deliberate Assembly——有意识地构建窗口,而不是出于偶然

厨师是有意识地摆盘的——每个元素都有放在那里的理由——而不是把台面上有的东西一股脑刮到盘子里。

核心习惯是 deliberate assembly:把窗口当作你有意构建的东西。决定 system prompt 里放什么、历史保留或总结哪些、检索什么、展示哪些示例、暴露哪些工具。

许多 LLM 应用组装 context 是出于偶然——碰巧手边有什么就发什么。有意识地构建,并为每个部件说明理由,在很大程度上就是可靠功能与不稳定功能的分野。

Context Evals——像衡量代码那样衡量 context

你不会猜一个改动有没有帮助——你会去测试它。放进窗口的东西也是如此:一个答案变好了还是变差了,你应该知道是哪一种。

Context 的改动是真实的改动,所以要验证它们:当你调整放进窗口的东西——更多示例、不同的检索、裁剪过的历史——要用 evals 来检验效果,而不是只凭肉眼看一个输出。

没有度量的 context engineering 是凭感觉调优,一个“无害”的新增就是这样悄悄拉低质量的。把窗口的内容当作要测试的东西,用与 evals 课程相同的自律。

这一切如何连在一起

完整的地铁线路图:现在你能看到各条线在哪里交汇。

模型是无状态的 → 所以窗口决定一切 → 所以窗口就是你要设计的东西。窗口由部件(system prompt、示例、事实)组装而成。三种力量让它变差:无关内容、预算和随时间腐烂。每一种都有对应的实践:curation、trim and summarize、compaction 加 re-anchoring。而 evals 检验每一次改动是否真的有帮助。