prompt engineering 已死。我从来没做过它。

差不多有两年时间，整个互联网都充斥着魔法咒语。"扮演一名资深工程师。" "深呼吸，一步一步把这道题想清楚。""答得更好我就给你 200 美元小费。" 人们像交换游戏秘籍一样交换这些咒语，仿佛模型是一个精灵，而正确的措辞就是 那句能解锁藏在它体内的好答案的暗号。

为此甚至诞生了一个专门的职位：prompt engineer。它的前提是：AI 时代的核心 技能就是遣词造句——找到那句魔法咒语。

那个时代正在结束，而搞清楚原因很值得，因为取代它的并不是一句更好的咒语。 而是人们终于意识到：根本就没有什么咒语。

行业正在悄悄给这个词办葬礼

2025 年年中，Shopify 的 CEO Tobi Lütke 发了一条帖子， 道出了很多人早已隐约感觉到的东西：

比起 prompt engineering，我更喜欢 "context engineering" 这个说法。 它更准确地描述了核心技能：把任务所需的全部上下文提供给 LLM， 让任务变得有可能被解决的那门艺术。

不到一周，Andrej Karpathy 就 公开支持了它， 并加上了那个让人一下子想通的比喻：LLM 就是 CPU，它的上下文窗口就是 RAM。 你的工作不是去念对那些词——而是在模型运行之前，把对的东西装进内存里。

到了 2026 年，这一点已经固化成了公认的核心技能。正如一份被广泛传播的实战指南 所说，措辞只占问题的大约 10%。 剩下的 90% 归 context engineering 管： 模型看到什么信息、以什么形式、在什么时刻——记忆、检索到的文档、工具输出、 状态，以及当窗口被填满时该丢掉什么。

这个重新定义是对的。但请注意它实际上是什么：这个领域审视了一番"寻找魔法咒语" 这件事，断定那从来就不是真正的工作，于是把这门学科按那个一直真正要紧的东西 重新命了名——对输入进行工程化。

措辞从来不是重点

prompt engineering 注定要死，原因在这里：一个 prompt 把戏是绑定在某个特定模型、 某个特定日子上的。那句从某个模型里榨出更好答案的巧妙措辞，到了下一个模型上 就毫无用处——甚至会起反作用。你是在沙子上盖房子。每一次模型发布都会冲走你的 咒语，然后你又得出门去找新的。

一个系统不会这样腐烂。如果你的 agent 给出好答案的原因，是你喂给了它对的事实、 对的工具和一个清晰的任务，那么一个更好的模型会让它变得更好，而不是变得失灵。 你从来就不是依赖某句魔法咒语；你依赖的是好的输入。好的输入能挺过模型升级。 魔法咒语挺不过去。

这就是把戏和工程实践之间的全部区别。把戏是你偶然发现、然后藏着掖着的东西。 工程实践是你能够推理、能够测试、能够在各种变化中依赖的东西。prompting 是前者， 却假装成后者。

究竟是什么让一个 agent 崩掉（不是措辞）

看一个真实的 agent 在生产环境里失败，你几乎从来看不到"prompt 写得不好"。 你看到的是某种远为乏味、远为结构性的东西。

你看到的是 context rot（上下文腐化）——Anthropic 的 工程团队 描述过，当模型的上下文窗口被陈旧、嘈杂的历史填满时，它的推理能力会越来越差。 你看到 agent 在五十步之后跑偏，丢掉了原始任务的线索，用错误的结构去调用工具， 或者基于一个早已不再为真的状态去行动。一份对企业级 AI 失败案例的分析，把 其中 65% 归因于"harness 缺陷" ——上下文漂移、schema 错配、状态退化——既不是模型的问题，也不是 prompt 的问题。

那项工作里有一句话，我总是反复引用给别人听：如果 agent 在五十步之后就跑偏了， 那一个百分点的 benchmark 提升毫无意义。 没有任何 prompt 措辞能修好这个。 这不是措辞问题。这是系统问题——在一个漫长的任务里，agent 被允许看到什么、 持有什么、做什么、忘掉什么。

这就是行业现在所称的 harness engineering 那一层：模型周围的环境——它的工具、 它的记忆、它的约束、它的反馈回路，何时压缩上下文、何时把目标重新注入回去。 prompt 只是其中微不足道的一小块。harness 才是其余的全部。

这一直就只是工程而已

把那套新词汇剥掉，看看 context engineering 和 harness engineering 实际上 要求你去做什么：

• 决定系统获得哪些输入，来自可信来源，以干净的结构呈现。
• 随时间管理状态——保留什么、丢弃什么、在模型之外持久化什么。
• 定义边界——哪些工具、它们被允许做什么、契约是什么。
• 搭建反馈回路——检查、evals，以及在出现漂移时的恢复机制。

这不是什么新的 AI 学科。这就是工程。输入、状态、边界、反馈——无论中间那个 部件是一个函数、一个服务还是一个语言模型，这都是同一份活儿。模型在一点上很特别 （它是一个非确定性的猜测器，这正是你要给它 做锚定（grounding）的原因），但围绕在它周围的一切， 都是再寻常不过的系统工作。

所以当人们问我拿 prompt 做什么时，老实的答案是：尽量少做。我从来没有过一个 prompt-engineering 阶段。那份工作一直都是在搭建系统——模型无法覆盖的确定性来源、 边缘处带类型的契约、把任务写进 一份 spec 而不是一个 prompt、 用 evals 让我知道它有没有退化。prompt 是其中 最无趣的部分，我也希望它一直保持无趣。你的结果越是依赖精确的措辞，它就越脆弱。

为什么这是好消息

人们很容易把"prompt engineering 已死"读成又一次脚下的地面在晃——又一项技能被 淘汰，赶紧去学新东西。事实恰恰相反。prompt engineering 的死亡，是 AI 领域终于 承认：那个经久耐用的技能从来都不是一袋绑定特定模型的把戏。它一直都是工程—— 而工程不会被下一次发布冲走。你今天对输入、状态和边界所做的推理，等到底层的模型 变好一倍时，依然成立。

魔法咒语从来没有按人们期望的方式起过作用。而围绕模型的那个系统，一直都管用。 prompt engineering 之死，不是因为我们找到了更好的咒语——而是因为我们终于承认了： 从来就没有什么咒语，有的只是我们本就应该一直在做的那份工程。