# prompt engineering 已死。我从来没做过它。 整个行业花了两年时间，寻找对着模型念的魔法咒语。如今它正悄悄宣告 prompt engineering 已死，转而用 context engineering 和 harness engineering 取而代之。但问题在于：这些根本不是什么新把戏——它们就是工程，是真正搞系统的人一直在做的工作。为什么措辞从来不是重点，以及究竟是什么让一个 agent 能真正跑起来。 - **Author:** Fedor Chishchin - **Published:** 2026-06-03 - **Tags:** agents, methodology, ai-native - **Source:** https://fedorthinks.com/zh/blog/prompt-engineering-is-dead --- 差不多有两年时间，整个互联网都充斥着魔法咒语。"扮演一名资深工程师。" "深呼吸，一步一步把这道题想清楚。""答得更好我就给你 200 美元小费。" 人们像交换游戏秘籍一样交换这些咒语，仿佛模型是一个精灵，而正确的措辞就是 那句能解锁藏在它体内的好答案的暗号。 为此甚至诞生了一个专门的职位：_prompt engineer_。它的前提是：AI 时代的核心 技能就是遣词造句——找到那句魔法咒语。 那个时代正在结束，而搞清楚原因很值得，因为取代它的并不是一句更好的咒语。 而是人们终于意识到：根本就没有什么咒语。 ## 行业正在悄悄给这个词办葬礼 2025 年年中，Shopify 的 CEO Tobi Lütke [发了一条帖子](https://x.com/tobi/status/1935533422589399127)， 道出了很多人早已隐约感觉到的东西： > 比起 prompt engineering，我更喜欢 "context engineering" 这个说法。 > 它更准确地描述了核心技能：把任务所需的全部上下文提供给 LLM， > 让任务变得有可能被解决的那门艺术。 不到一周，Andrej Karpathy 就 [公开支持了它](https://simonwillison.net/2025/Jun/27/context-engineering/)， 并加上了那个让人一下子想通的比喻：LLM 就是 CPU，它的上下文窗口就是 RAM。 你的工作不是去念对那些词——而是在模型运行之前，把对的东西装进内存里。 到了 2026 年，这一点已经固化成了公认的核心技能。正如一份被广泛传播的实战指南 所说，**措辞只占问题的大约 10%。** 剩下的 90% 归 context engineering 管： 模型看到什么信息、以什么形式、在什么时刻——记忆、检索到的文档、工具输出、 状态，以及当窗口被填满时该*丢掉*什么。 这个重新定义是对的。但请注意它实际上是什么：这个领域审视了一番"寻找魔法咒语" 这件事，断定那从来就不是真正的工作，于是把这门学科按那个一直真正要紧的东西 重新命了名——对输入进行工程化。 ## 措辞从来不是重点 prompt engineering 注定要死，原因在这里：一个 prompt 把戏是绑定在某个特定模型、 某个特定日子上的。那句从某个模型里榨出更好答案的巧妙措辞，到了下一个模型上 就毫无用处——甚至会起反作用。你是在沙子上盖房子。每一次模型发布都会冲走你的 咒语，然后你又得出门去找新的。 一个*系统*不会这样腐烂。如果你的 agent 给出好答案的原因，是你喂给了它对的事实、 对的工具和一个清晰的任务，那么一个更好的模型会让它*变得更好*，而不是变得失灵。 你从来就不是依赖某句魔法咒语；你依赖的是好的输入。好的输入能挺过模型升级。 魔法咒语挺不过去。 这就是把戏和工程实践之间的全部区别。把戏是你偶然发现、然后藏着掖着的东西。 工程实践是你能够推理、能够测试、能够在各种变化中依赖的东西。prompting 是前者， 却假装成后者。 ## 究竟是什么让一个 agent 崩掉（不是措辞） 看一个真实的 agent 在生产环境里失败，你几乎从来看不到"prompt 写得不好"。 你看到的是某种远为乏味、远为结构性的东西。 你看到的是 **context rot（上下文腐化）**——Anthropic 的 [工程团队](https://www.anthropic.com/engineering/harness-design-long-running-apps) 描述过，当模型的上下文窗口被陈旧、嘈杂的历史填满时，它的推理能力会越来越差。 你看到 agent 在五十步之后跑偏，丢掉了原始任务的线索，用错误的结构去调用工具， 或者基于一个早已不再为真的状态去行动。一份对企业级 AI 失败案例的分析，把 [**其中 65% 归因于"harness 缺陷"**](https://atlan.com/know/what-is-harness-engineering/) ——上下文漂移、schema 错配、状态退化——既不是模型的问题，也不是 prompt 的问题。 那项工作里有一句话，我总是反复引用给别人听：**如果 agent 在五十步之后就跑偏了， 那一个百分点的 benchmark 提升毫无意义。** 没有任何 prompt 措辞能修好这个。 这不是措辞问题。这是系统问题——在一个漫长的任务里，agent 被允许看到什么、 持有什么、做什么、忘掉什么。 这就是行业现在所称的 **harness engineering** 那一层：模型周围的环境——它的工具、 它的记忆、它的约束、它的反馈回路，何时压缩上下文、何时把目标重新注入回去。 prompt 只是其中微不足道的一小块。harness 才是其余的全部。 ## 这一直就只是工程而已 把那套新词汇剥掉，看看 context engineering 和 harness engineering 实际上 要求你去做什么： - 决定系统获得**哪些输入**，来自可信来源，以干净的结构呈现。 - 随时间管理**状态**——保留什么、丢弃什么、在模型之外持久化什么。 - 定义**边界**——哪些工具、它们被允许做什么、契约是什么。 - 搭建**反馈回路**——检查、evals，以及在出现漂移时的恢复机制。 这不是什么新的 AI 学科。这就是*工程*。输入、状态、边界、反馈——无论中间那个 部件是一个函数、一个服务还是一个语言模型，这都是同一份活儿。模型在一点上很特别 （它是一个非确定性的猜测器，这正是你要给它 [做锚定（grounding）](/work/astrolinkers)的原因），但围绕在它*周围*的一切， 都是再寻常不过的系统工作。 所以当人们问我拿 prompt 做什么时，老实的答案是：尽量少做。我从来没有过一个 prompt-engineering 阶段。那份工作一直都是在搭建系统——模型无法覆盖的确定性来源、 边缘处带类型的契约、把任务写进 [一份 spec 而不是一个 prompt](/blog/specs-are-the-artifact)、 [用 evals 让我知道它有没有退化](/blog/evals-or-it-didnt-ship)。prompt 是其中 最无趣的部分，我也希望它一直保持无趣。你的结果越是依赖精确的措辞，它就越脆弱。 ## 为什么这是好消息 人们很容易把"prompt engineering 已死"读成又一次脚下的地面在晃——又一项技能被 淘汰，赶紧去学新东西。事实恰恰相反。prompt engineering 的死亡，是 AI 领域终于 承认：那个经久耐用的技能从来都不是一袋绑定特定模型的把戏。它一直都是工程—— 而工程不会被下一次发布冲走。你今天对输入、状态和边界所做的推理，等到底层的模型 变好一倍时，依然成立。 魔法咒语从来没有按人们期望的方式起过作用。而围绕模型的那个系统，一直都管用。 prompt engineering 之死，不是因为我们找到了更好的咒语——而是因为我们终于承认了： 从来就没有什么咒语，有的只是我们本就应该一直在做的那份工程。