Prompt格局小了,上下文工程称王!Shopify CEO提上下文工程,大神Karpathy一众创业者狂喊+1,网友:都是巫术 原创

发布于 2025-7-2 14:14
浏览
0收藏

编辑 | 云昭

Prompt工程又“失效”了?!

之前是各种白领对它“喊打喊杀”,担心它取代自己的工作,后来的口风就变成了“大模型强大到不再需要Prompt工程了”,现在圈里又有谷歌的大佬抛出了神断言,让评论区炸锅的那种。

今天一早,小编刷到一篇洗脑神文,差点以为这是新一轮的AI黑话洗脑包上线了。文章直呼:

“Prompt工程”格局小了,更大格局的“Context工程”才是大模型的王道。

不过细读下来,小编并没有作者其实是醉翁之意不在酒,更多还是再说构建智能体时,上下文工程的重要性——

我们发现,决定智能体成败的关键在于你赋予它的上下文的质量。大多数智能体失败不再是模型失败,而是上下文失败。

所谓“上下文工程”,它不是一句提示词,它是一个系统工程。

一次廉价演示和一次神奇 AI 体验之间的差距,全在于——上下文的质量

Prompt不香了?Context Engineering又是哪个工程师发明的新名词?

评论区一众大厂和创业者都在喊“+1”。(后来小编搜了一下:新名词的是Shopify CEO Tobi Lutke提出的,前OpenAI大神Karpathy也X转帖了。)

这篇文章的作者也大有来头,Google DeepMind的高级AI关系工程师Philipp Schmid。据悉,Schmid正在组建DeepMind的首个AI开发者关系团队,这个团队主要KPI就是输出!而且输出的是DeepMind的前沿AI研究成果!小编果断关注了一波。

话不多说,直接上干货。

1.大模型的新技能不是Prompt

原文标题为《The New Skill in AI is Not Prompting, It's Context Engineering》,大体主张是:

与其再去研究“怎么写提示词(prompt)”,真正应该关注的,是如何为 AI 组织一个完整、合适、动态的上下文(context),这才是 Agent 成败的关键。

可以说再一次把“Prompt”与“Contex”的引战放到了明面上。当然从评论区的效果上看,事实也的确如此。

相信大家都有这样的“皱眉头”经历:

费劲写了一段“完美Prompt”,希望AI给出精准回答。(ps:想一想,你有没有写过这样一个提示“做好这件事,奖励你1万块!”)但结果,AI模型却就总是给出一个非常机械的、“缺少灵魂”的输出。

对此,作者指出:为什么上下文比提示词更重要了?

随着 AI Agent(智能体)的崛起,我们输入模型的“有限工作记忆”里到底装了什么,变得比以往任何时候都更关键。(即:大模型就像一台超强的语言引擎,但它的“记忆”有限,单靠一段话很难覆盖复杂的业务需求和多维信息。结果就是,AI“答非所问”,或者机械死板,差强人意。)

现在,决定一个 Agent 成败的核心因素,不再是调用哪个大模型、写了多花哨的提示词,而是——你给它的上下文质量够不够好。

2.Karpathy等许多大佬也认同“上下文工程”

其实很多圈内大神都赞同“上下文工程”而非“提示工程”。

前OpenAI、特斯拉的大神上个月就公开表示+1支持。

@karpathy

+1 支持“上下文工程(Context Engineering)”而非“提示工程(Prompt Engineering)”。

Karpathy 认为,人们通常把“prompt”理解为日常使用LLM时输入的一小段任务描述。而不同的是,在真正面向工业级应用的 LLM 系统中,上下文工程是一门微妙而复杂的“填充上下文窗口”的艺术与科学

Prompt格局小了,上下文工程称王!Shopify CEO提上下文工程,大神Karpathy一众创业者狂喊+1,网友:都是巫术-AI.x社区图片

大神还进一步解释了为什么既是科学又是艺术?

为什么说是科学?因为做好这件事涉及:任务说明与解释、Few-shot 示例、RAG 检索、相关数据(可能是多模态的)、工具、状态、历史记录、信息压缩等。信息太少或格式不对,LLM 就拿不到做出好回应的材料;信息太多或不相关,则会推高成本,反而拉低性能。

为什么说是艺术?因为你需要依靠对“模型心理”的直觉来构建合理的输入。

除了上下文工程之外,Karpathy认为大模型还有很多问题需要解决,比如:

  • 正确地拆解问题形成控制流程
  • 恰当地打包上下文窗口
  • 调度不同类型和能力的模型
  • 搭建生成与验证的 UI/UX 流程
  • 还有更多:安全机制、性能评估、并行处理、预取缓存……

所以,Context Engineering 只是构建一个完整 LLM 应用所需的厚重软件层中的一小部分而已。

Karpathy指出,“ChatGPT 套壳器”这个说法已经过时,甚至是完全错误的。

而Karpathy点赞的这则帖子正是另一位大佬——

白天当CEO、夜间当黑客的“通才”,Shopify 的掌门人Tobi,在X上,他发表了自己的看法:

我真的很喜欢“上下文工程”这个术语,而并非“提示工程”。

原因是,它更好地描述了核心技能:为大模型提供充分的上下文背景,使得 LLM 有可能合理地解决任务,这是一门艺术。

Prompt格局小了,上下文工程称王!Shopify CEO提上下文工程,大神Karpathy一众创业者狂喊+1,网友:都是巫术-AI.x社区图片

此外,许多评论者也分享了自己在实际应用中的见解:

完全同意。现在你几乎很难再靠那种“如果你答对我就给你 100 美元”之类的小聪明来提升模型性能了——本来就应该如此。

真正的优势在于:你是否能精心构建上下文,帮模型最大程度减少“战争迷雾”。它正在趋近于人类式的信息需求。

Prompt格局小了,上下文工程称王!Shopify CEO提上下文工程,大神Karpathy一众创业者狂喊+1,网友:都是巫术-AI.x社区图片

3.上下文没那么简单,包含7部分

要理解“上下文工程”,我们得先重新定义“上下文”这个词。

不是你发给 LLM 的一句话。作者指出:

你可以把它想象成模型在生成回答之前,所能看到的一切信息

作者将上下文的构成分成了 7 部分:

  • 系统指令 / 初始提示(System Prompt):在对话开始时,预先定义模型行为的一组说明,可包含示例、规则等。
  • 用户提示(User Prompt):用户当下发出的任务或问题。
  • 短期记忆 / 对话历史(State / History):当前对话中的来龙去脉,包括之前的提问与回应。
  • 长期记忆(Long-Term Memory):模型跨会话记住的持久信息,例如用户偏好、项目摘要、背景知识等。
  • 检索信息(RAG):来自外部文档、数据库或 API 的实时信息,用于增强模型回答。
  • 可用工具(Available Tools):模型可调用的函数或工具列表,如 ​​check_inventory​​​、​​send_email​​。
  • 结构化输出格式(Structured Output):定义模型回答的格式,比如 JSON 模板或结构体。

Prompt格局小了,上下文工程称王!Shopify CEO提上下文工程,大神Karpathy一众创业者狂喊+1,网友:都是巫术-AI.x社区图片

好的上下文 ≠ 靠 LLM 猜,而是靠系统主动“喂”进去该知道的一切。 

4.从“廉价Demo”到“神奇AI”的关键

真正打造出一个可靠、有用的 AI Agent,核心不在于代码多复杂,也不在于使用了什么花哨的框架,而在于你给它什么上下文

想象这个简单例子:

有人发来一封邮件:Hey, just checking if you’re around for a quick sync tomorrow.(嘿,想问问你明天能不能快速聊一下。)

对于一个 Agent 而言,它能看到的上下文只有用户刚发来的这句话,于是它冷冰冰地回应:

Thank you for your message. Tomorrow works for me. May I ask what time you had in mind?(谢谢你的信息,明天对我来说可以。你想定几点呢?)

逻辑没错,但像极了“机器人在敷衍人类”,没错这水平也就是个廉价的Demo。


但,如果有了足够丰富的上下文,比如我们把日程表、对方的邮件来往记录、联系人信息、自动回复邮件等工具都喂给它——

我们就可以见证奇迹:神奇 AI(Magical Agent)诞生了!它的回应就像一个会来事儿的真人:

上下文包含:

  • 你的日程表(显示你明天全天爆满)
  • 你和对方以往的邮件记录(判断用语是否需要随意一些)
  • 联系人信息(识别出对方是关键合作伙伴)
  • 可用工具(比如发出邀请、自动回复邮件)

最终生成的回应是:

Hey Jim! Tomorrow’s packed on my end, back-to-back all day. Thursday AM free if that works for you? Sent an invite, lmk if it works.(嘿 Jim!我明天全天都排满了。周四上午有空,合适吗?我已经发了个邀请,看看是否合适。)

神奇不是因为用了更聪明的模型,而是因为上下文到位了。所以,Agent 的失败,更多是上下文失败,而不是模型失败。

5.从提示工程转向上下文工程,有何不同?

现在,我们可以回答两者到底有什么不同了。

如果说提示词工程是想写出“一句话打动模型”,那么上下文工程是一门系统工程学科。

首先,来看定义(更接地气地讲):

上下文工程(Context Engineering)是设计和构建动态系统的一门学问,目标是在正确的时间、以正确的格式,向大模型提供完成任务所需的一切信息和工具。

它的核心特征有 4 个:

  • 系统,而不是字符串:不是静态的模板,而是在调用 LLM 之前动态生成的结果。
  • 动态、按需生成:对一个请求来说,也许上下文是日程表;另一个请求可能需要最近的网页搜索或邮件往来。
  • 信息与工具,刚刚好地送达:避免垃圾进垃圾出(Garbage In, Garbage Out),只提供任务真正需要的信息与能力。
  • 格式也很关键:与其丢一堆生肉数据,不如给出提炼后的摘要;工具调用格式清晰,胜过模糊提示。

即,作者提出,只有为 LLM 提供恰当且动态组合的信息、工具和指令,才能让 AI 真正理解并高效完成复杂任务。所以,要构建强大、稳定的 AI Agent,不再是靠“提示词魔法”或“换个大模型”,而是靠“上下文工程”:

在正确的时间,把正确的信息与工具,以正确的格式,放进模型的脑子里。

而这是一项跨学科挑战,既需要理解业务场景,也需要明确目标输出,更需要设计清晰的信息结构,让语言模型真正完成任务

6.网友热议:造新词儿?

对于上下文工程,一位谷歌的同事(巧了,也叫菲利普,也是作者团队的人员,Google DeepMind AI 开发者关系负责人),开始在 Karpathy 的评论区下面调侃:上下文工程是新的“氛围编程”!

Prompt格局小了,上下文工程称王!Shopify CEO提上下文工程,大神Karpathy一众创业者狂喊+1,网友:都是巫术-AI.x社区图片

Karpathy 回应:哈哈,我不是想造个新词什么的。

哈哈我不是在发明新词,只是觉得人们对“prompt”的理解太过简单化,低估了其复杂性。

“你提示 LLM 回答“天空为什么是蓝色”,那是 prompt。但真正的 AI 应用不是一句话提示,而是精心构建一整个上下文环境,让 LLM 去完成定制化任务。”

Prompt格局小了,上下文工程称王!Shopify CEO提上下文工程,大神Karpathy一众创业者狂喊+1,网友:都是巫术-AI.x社区图片

此外,相关评论还探讨了“context rot”、动态信息检索、如何进行有效评估以及 AI 项目的落地技巧。 

Prompt格局小了,上下文工程称王!Shopify CEO提上下文工程,大神Karpathy一众创业者狂喊+1,网友:都是巫术-AI.x社区图片


当然,更多在做Agent产品开发的人表示深度认可:上下文才是真正的杠杆!

@0xCapx(Agent 应用创业公司)

当 Agent 来运营一家企业时,上下文就不再是“锦上添花”,而是“系统架构”本身。

@The_Utility_Co(Web3自动化创业团队)

100% 认同。Prompt 只是“你好”,Context 是你的人生故事、Spotify 歌单、甚至银行账户信息。

当我们将 LLM 接入 Web3 自动化系统时,大部分工作其实都在策划好传感器数据、DAO 信号、链上信息的上下文输入,这样模型才能“真正做事”,而不是只会“聊天”。

真正的杠杆在于上下文工程。

7.老瓶装新酒?技术本质都是黑盒巫术

不过,也有人为,prompt 和 context 有点强分彼此,区别不大,只是表达不同。(言外之意,老瓶装新酒,为了造 buzz。)

所谓“context engineering”只是把 prompt 拆成多个来源组合而已,本质还是 prompt engineering。

多位评论者指出:“prompt” 和 “context” 在技术上本质是一回事,都是输入模型的 Token 序列。

模型并不区分你是通过“用户输入”还是“上下文历史”送进来的内容。

一位开发者更是总结得很直白:“你完全可以把 context 整个打包成 prompt 发进去,对模型没区别。”

还有网友强调:“magic”背后依然离不开编程和理解模型原理,也有人批评上下文工程很容易变成一种“玄学”炒作。

简单的理解,不管叫 prompt 还是 context,都是黑盒巫术本质还是“try and see”。

还有网友调侃:LLM 是非确定性机器,结果不稳定、重复性不强,所谓“工程”不过是“调参的艺术”。

Prompt格局小了,上下文工程称王!Shopify CEO提上下文工程,大神Karpathy一众创业者狂喊+1,网友:都是巫术-AI.x社区图片

8.写在最后:Prompt 淡出或是必然

在小编看来,提词工程的淡出(产品化),上下文工程兴起,已经是一种趋势。

首先,产品侧来看,随着 RAG、Agent、AutoChain 等机制普及,开发者越来越依赖工具自动构建 prompt,而不是手写 prompt。

“好 prompt” 越来越像产品的功能,而非用户的技能。

其次,模型侧来分析。模型 token window 增大,但 context 变长后“腐烂”(context rot)问题日渐凸显。

Prompt格局小了,上下文工程称王!Shopify CEO提上下文工程,大神Karpathy一众创业者狂喊+1,网友:都是巫术-AI.x社区图片

对于我们而言,如何管理、组织、剪裁 context 成为下一步挑战。

正如一位Hackernews的网友 Drew Breunig 所提到了一些关键技术:Context Quarantine、Tool Loadout、Summarization 等。

当然,不管是提示词工程,还是上下文工程,小编认为——哪个都不是万能的!

“即使你有 memory bank,有 plugin,最终还是得人类自己写代码。”

参考链接:

​https://x.com/tobi/status/1935533422589399127​

​https://x.com/karpathy/status/1937909397180796982​

本文转载自​​51CTO技术栈​​,作者:云昭

©著作权归作者所有,如需转载,请注明出处,否则将追究法律责任
收藏
回复
举报
回复
相关推荐