上下文工程又有新词了。AIGC不怎么赚钱，造词的速度还是非常非常快的。大家好，欢迎收听老范讲故事的YouTube频道。

提示词工程已经稍微有点过时了，现在的新词叫上下文工程。提示词工程长什么样，大家还记得吗？就是上来先说你是谁，谁先给大模型定一个位置。比如说你是一个资深翻译，你是个语文老师。然后呢，说我现在想要干一点什么事情了，给我出个题，给我做个翻译，再给他一个简单的例子，说你照这样给我把东西做出来。

光有提示词呢，肯定是不够的。除了刚才我们讲的完整的、结构化的提示词之外，你还是需要很多相关的上下文，才能够让大模型稳定的输出结果。那你说我们继续把提示词写长不就行了吗？我还见过那种直接写出几百字或者是上千字小作文的提示词。这个是不是可以继续往前走呢？不行了。因为你如果继续叫提示词工程呢，会容易引起误解。大家觉得只要不断的把提示词写长，就可以把这事解决掉。但其实除了提示词之外，还有非常非常多的上下文数据需要一起写进去，才能够让大模型稳定的输出我们所预期的、有价值的结果出来。

所以呢，就不能继续叫提示词工程了，一定要起个新词。而且呢，AI时代呢，起新词是非常重要的，因为可以吸引眼球。只有足够吸引眼球的东西，才有发展的前景。所以在这个时候，上下文工程就来了，一个新词诞生了。

这个造词的大师现在是谁呢？叫安德烈·卡帕西。这是一位造词专家，他呢是特斯拉跟OpenAI的AI科学家，已经离职了。现在呢主要的工作是投资人和顾问，他自己投一些项目，也帮助一些项目做顾问做孵化。这哥们呢在不停的造新词。2017年呢，他造的新词叫软件2.0。什么是软件2.0呢？把神经网络视作用数据而非代码编程的新规范。程序等于网络结构加训练数据加优化器，源代码缩到几百行，真正的逻辑写在权重里面。这是2017年提出来的，现在我们的大模型基本上就是长得这个模样。

到2023年呢，提出来叫LLMOS，大模型操作系统。把大语言模型比作新的CPU加操作系统，人类用自然语言编程，大语言模型负责调度、记忆和推理。2025年，氛围编程，也是他编发明的一个新词。彻底投降给AI，对着IDE聊天，粘贴报错，让模型自动改，人只管感受对不对。

现在上下文工程又来了。上下文工程呢叫context engineering，这个呢并不是卡帕西自己提出的。最早呢是2025年6月27号，一位开源作者叫Simon Wilkinson。

写了一个文章，提到了”Context Engineering”这个概念。在7月份呢，一帮人就出来说，这个实在是太棒了，要向这个方向发展，包括Longchain的一些博客。Longchain应该也算是AI Agent的一个开山项目吧，比较早期的一个项目。Shopify（加拿大最大的电商平台）的创始人也出来点赞，说一定要使用Context Engineer才可以让大模型稳定的输出结果。

在这个时候呢，卡帕西上去点了个赞。卡帕西说：”加一，我也赞同这件事情。”所以现在再去讲这个上下文工程的时候呢，都是说这是卡帕西点赞过的，或者说是卡帕西推崇的新的概念。因为他最有名，他最喜欢造词，所以现在都是把这个上下文工程这个事情跟卡帕西挂在一起。

AI时代，讲故事能力、吸引眼球的能力是非常非常重要的。所以我们看到一帮做机器人的公司，或者像OpenAI这样的公司，不停的给大家录视频，让普通的民众能够感受到这个东西好厉害。其实他也没搞明白这个大模型或者这些机器人到底能干嘛，只是觉得好炫酷。但这就够了。当大家都觉得这个东西很炫酷的时候，你就可以拿到融资，可以往前走。所以造新词还是很重要的。

那么上下文工程都包含什么东西呢？讲了半天在提示词工程基础上加什么了呢？上下文工程呢一共是6个模块：

第一个叫指令层（系统角色+少样例提示）。这个什么意思呢？原来我们写在系统提示词里的东西。我们跟大模型聊天的时候，是有两个提示词：一个叫系统提示词，一个叫用户提示词。系统提示词就是先规定大模型你是干嘛的，你是什么什么角色，现在要具体做什么什么事情。少样例是什么呢？叫Few-shot，就是你要给他提几个例子。你说我直接告诉你你是干嘛的，我不给你举例子行不行？这个事是不好的。最好呢是给他两个到八个之间的这种少量的样本。那你说我给他100个例子行不行？那个你基本上去微调模型去了。所以呢，叫少量样本。这个是写系统提示词的一个要求。所以呢，他的第一块（6个模块里的第一块）就是系统提示词。

第二块呢叫及时用户请求，也就是原来我们使用的用户提示词。

第三块是什么呢？叫对话历史和短期记忆。我们在聊天的时候，你不能说我每句都是新的吧，你还是要有一个对话历史的。

第四块叫长期记忆。长期记忆呢就是说，我们通过每一次聊天，把一些关键信息把它提取出来。因为现在甭管是OpenAI、Gemini，都在向长期记忆这一块发展。

我们说，你记得我是干嘛的吗？你记得这个原来我跟你说过什么事吗？他能想的起来要把用户偏好和先前的一些摘要放到这个上下文里边去。

第五个呢，是RAG检索到的文档、数据库条目以及实时API的一些结果，再加一些本地知识库，再加一些搜索结果呀，再加一些数据库里的信息。

第六块呢，叫工具与格式约束。什么意思呢？就是你要告诉他说：“我现在可以调哪些工具？”比如说我这有高德地图、有百度地图、有天气，或者一些其他的工具，你可以调用。调用的方式是什么样的？以及呢，输出什么样的一个结果？通常这种信息都不是按照正常的文本格式输出的。这种上下文工程要求的输出格式都是JSON格式，有哈西结构的一些文档。

整个的上下文工程包括这六个组成部分。它的工作方式是什么样的？我怎么能够让它用起来呢？分四步：

第一步呢，是写。写的时候呢，要把随时会用到但是当前窗口装不下，或者不该暴露给大语言模型的内容呢，持久化到窗口之外去，可读可写的一些外部存储上。有一些信息我认为你可能有用，但是呢现在我又不是马上就要给你，我要把它先存起来。

第二件事呢，叫选。选是什么呢？就是在庞杂的信息文档和工具描述里头，准确定义相关性，把最有用的多少条信息放到窗口里边去。在大模型里头，有一个东西叫上下文窗口。要把一时用不着的写在外面，随时可以调用；要把有用的选到窗口里头来。

第三步呢，叫压缩。在不丢关键信息的情况下，把即将写回窗口的内容做摘要和裁剪，满足TOKEN预算。什么意思呢？比如说做了RAG的选择了，或者做了搜索的结果返回了，这些信息是相对比较啰嗦的比较多。那怎么办呢？在这个时候你要先去做一次总结，然后把总结过的东西再扔给大模型。所以呢，在这要做压缩。

最后呢，第四步叫隔离。把彼此可能串味的信息拆分进独立的上下文窗口或者沙盒，减少干扰，并行提速。

我原来在这块翻过车，稍微给大家讲一嘴。我有一次呢，想去问大模型，说这个人跟谁谁一块创业去开咖啡馆了，他有什么其他的在咖啡馆里边管理或者创业的经验没有？大模型呢，就把一大堆的搜索结果拿进去去总结归纳去了。结果呢，他就说这个人在瑞幸干过高管，在星巴克干过高管。我一看，这挺好，赶快就去写演讲稿去了吗？但是最后去校验的时候发现不对。那是怎么回事呢？就是他在搜索了以后，把一大堆说星巴克跟这种咖啡馆之间是如何去比对的，瑞幸跟这些咖啡馆之间是如何差异，他们对瑞幸做了什么评价，瑞星对他们做了什么评价。

然后呢，再把我提问的这个人混到几个结果里边去了，就把一些信息上下文给混一块了。在这个里头就不要干这个事情。如果是说星巴克跟瑞幸对这个新的咖啡馆的形态有什么样的评价和比较，你单独的去让他干活。然后呢，你单独专门问，说这个人具体是做什么事情的，过去的履历是什么样的。这样的话，他等于是把上下文就分到不同的窗口里去了，他就不会说我给你搁一块，让你混成一锅粥以后再去给我输出了。这个也是很重要的。而且你分开了以后就可以并行处理嘛，可以快一点。这就是上下文工程6个部分和分四步走。

那么如何判定我们上下文工程是不是成功的呢？一旦有工程这俩字，就是你一定是可以去调优的，一定可以判断成不成功的。上下文工程的成功标准是同样的一个任务，用更低的成本、更少的幻觉、更快的响应速度把它完成掉，这就是成功的。你要不断的去调优，按这个方向调。失败是什么呢？叫垃圾进垃圾出。你把一大堆不应该给他的信息都扔进去了，然后一大堆垃圾的结果给你吐出来，这个就是失败了。

但是要注意，不是所有的大模型都能顶得住上下文工程的。你写了这么长的上下文扔进去，让他去干活，不是谁都行。那么什么样的大模型可以顶得住上下文工程的这种工作方式呢？它有三个要求：

第一个要求是你要长上下文。刚才咱们啰里八嗦说有6个部分，分几步去写，但是你把那6个部分写进去，这个总的TOKEN量是不会少的。所以呢，要求你至少是有128K的输入，你才可以去干活。所以像早期的Deepseek版本是64K输入的，干不了这事，放不下。

第二个是什么呢？就是原生工具调用的知识。有一些早期的模型是不支持原生工具调用的，包括比较新的像LLAMA4什么的，对原生工具调用的支持都不是很好。因为你要想让他把所有的事情做完，你就要让他可以去调用工具，调用搜索引擎、调用浏览器、调用刚才我们讲的比如天气预报、高德地图。你可以去调用这些东西，他才可以去干活。所以，你要支持原生工具调用。

第三个呢，就是要能够做稳定的Json结构输出。你不能说我要求你输出了以后，最后你输出的格式不完整、不正确，这个事也是没有办法做上下文工程的。因为呢，你这边做完上下文工程了以后，他可能不是最后一步，你下一步你还要再去用这些内容，需要去解析这个东西，才可以去说下一步再如何去使用。

现在我们所流行的这些大模型里头，谁行谁不行呢？咱们讲了三条标准。第一个，美国的御三家都是很好用的。

御三家就是GPT、Gemini、Claude。其他的一些呢，就稍微差一点。比如说像法国的Mistral，它的一些大的模型呢是可以使用的，但是完整格式输出的准确率不高。

咱们刚才讲的Gemini、Claude、GPT，完整Json格式输出的时候，也不能保证100%正确，但是呢可以保证到百分之九十几正确。Mistral呢，就是最后这一步的格式输出，有时候比如少个大括号，或者是多个引号什么这种事，他就有时候会出。或者说我少几项，比如说我应该要求是4个，结果他最后给你输出了3个，或者多输出了两个，有重复的。它的这块会稍微差一些。

马斯克的GROK3，推理模式下呢基本上可用。但是呢，有的时候会把推理的过程写到json文件里边去，所以并不是完全可用。或者说，还是有待提升吧。马斯克说这几天出GROK4，希望他能够把这个问题解决掉。

咱们自己的，比如Deepseek R1呢，早期的版本，就是1月份的那个版本呢，64K，这是没法跑，而且它对于工具的支持也不是很好。但是呢，到Deepseek R10528的时候呢，到128K了，够用吧，也不是特别够用。最好是256K或者是一兆以上的上下文，才会更好用一些。所以呢，它在这块呢稍微有些欠缺。然后到0528这个版本呢，它已经开始支持工具了，这块基本上可用。它的最大的问题还是上下文稍微不太够长。但是呢，DeepSeek R1输出的内容还是非常好的，输出的内容质量很高。它的Json的格式也是相对来说比较正确和完整的，就正确率很高。

千问3呢基本上是可以用的。千问3唯一的问题是什么？就是它输出的结果上，这是文字的东西呢，比Deepseek要单薄一些。另外一个现在国内比较好用的模型呢，是豆包1.6。推理过程比较长的时候，容易跑偏前头。比如推理五六步了以后，直接出结果，他有时候就直接出英文结果，这个就是稍微跑偏了一点点。

那你说我们现在有这么多模型：GPT4O、GPT4O Mini、Gemini 2.5 Pro、Gemini 2.5 Flash。这些版本之间，你去让它跑这个上下文工程，到底有什么区别呢？所有的这种大模型Pro版，或者是GPT4O这种完整版本，一定是效果最好的。但是呢，Flash版呢，它的速度会快一些，价格便宜一些。只是呢，你要给它复杂的上下文，或者要求它输出非常复杂上下文的时候呢，它有时候会丢东西，输出也不是很完整。

或者，你给他一个复杂上下文进来的时候，他也会有一部分就不考虑了。这个是会时有发生的。

如果你的工作相对来说比较简单，你输入的信息和输出的信息都没有那么复杂的话，可以尝试去使用 GPT-4o Mini 或者是 Gemini 2.5 Flash 这样的版本。

那么，上下文工程产出的结果到底是什么呢？其实很简单，就是 AI 应用可以稳定的输出能够解决特定问题的、有价值的 AI 应用。这就是上下文工程能干的活。

原来为什么很多 AI 应用下去不好使？因为每一次的输出非常不稳定，有时候灵，有时候不灵。那你在这种情况下就很麻烦，你不知道它哪次灵，哪次不灵。你输出的结果，你还得各种的校验，比如说容错呀什么的，这些东西都要去做。

再往下一步，比如其他的模型里去送的时候呢，你要在上一个结果输出的内容里头，再去挑选你真正需要的东西。这块就很麻烦。

现在的话，有了上下文工程之后，你可能没法要求说我输出的内容才华横溢，但是呢，基本上我是稳定的。我每一次都稳定的输出这样的一个东西。

那你说上下文工程是不是未来方向？是不是这个万能解药呢？赶快出个教材出去圈一圈钱去，或者说赶快去报个班我学一下。这个怎么说呢？下一批新名词还在路上。

在 AI 这个领域里头，日新月异，不停的有新名词出来。而且呢，模型及应用这件事呢，依然有效。

AI 应用当前的定位呢，还是比较尴尬。虽然有了上下文工程之后，很多的 AI 应用就可以去干活了，它真正有价值了，有稳定的输出了。但是上下文工程，只要带“工程”俩字，那就不是给普通人使了。

普通人就说我们看一看就行了。真的让你去写这种上下文工程，没有程序员的能力，基本上是搞不定的。

大模型最终呢，会通过自己的升级，让普通人可以通过闲聊的方式，实现上下文工程的稳定输出。这个最后是可以实现的。不是说你没有上下文工程的能力，你最后就解决不了。

但是现在的大模型还达不到这个能力。但是可能再过个一两年吧，这块应该是可以做到的。但是在这一两年里头，像我们这些程序员，就可以使用上下文工程做出一大堆的 AI 应用，把第一桶金挣回来。这就是上下文工程能够真正起的作用。

那么，上下文工程对于当前的行业有什么样的影响呢？落后的大模型服务商要抓紧升级了，方向已经确定了。

比如说扎克伯格，挖了这么多 OpenAI 的人，赶快干活，让你的 LLAMA 4 或者 LLAMA 4.5 吧，能够很好的在上下文工程里头干活。

比如说华为的盘古大模型，别光抄千问 2.5 了，把千问 3 抄一抄吧。

得把上下文工程跑通，否则的话，小粉红拿着你的这些模型也搭不出AI应用来。

还有就是像Deepseek，可能要进一步的拉长这个上下文。现在Gemini 2.5已经可以达到100万TOKEN，或者到200万TOKEN。LLAMA4其实TOKEN也很长，LLAMA4大概是可以到1,000万TOKEN，但是它对于原生的工具支持的确实要稍微差一些。这可能是未来一些大模型要去努力的方向。

第二个大批量的AI应用就会涌现出来了。一旦大家确定下来，上下文工程是未来做AI应用里的必经之路，这一块的话一定就会快速前进。而且这一次的AI应用做出来以后，它是真的能用的。原来很多人说：“我为什么做了半天最后不能用？”因为没有上下文工程，你的AI应用整个的输出过程是不可控的。或者你为了让它变得可控，让这整个的系统跑得非常慢、非常傻。

最终的结果是什么呢？就是英伟达的显卡又不够用了。为啥呢？新模型的训练需要英伟达，大量有用的AI应用的涌现需要英伟达，很多日常任务向AI应用的迁移需要英伟达，长上下文的吞吐还是需要英伟达。这可能就是现在上下文工程可以给我们带来的变化。

对于每一位听众来说，你说：“我是个程序员，我现在想去学点应用，赶快学起来，不学就落后了。”那你说：“我就是个普通人，你通过我今天讲这个故事，你也知道一下AI应用里头到底是咋干活的。如果产生的结果不对了，不是你所预期的结果了，可能是上面的6个部分和4步哪一步走错了。你稍微有一些逻辑，对于你去使用AI应用也会有很大帮助的。”

好，这个故事今天就讲到这里。感谢大家收听，请帮忙点赞、点小铃铛，参加DISCORD讨论群。也欢迎有兴趣、有能力的朋友加入我们的付费频道，再见！