提示词工程、上下文工程，到底在"工程"什么？

柏林ACS · 2026-08-06 · 读完约需 6 分钟

这两年，AI 圈起伏最大的概念要数 Prompt Engineering。

两年前它最火：培训班爆满，技巧文章刷屏，"提示词工程师"成了真实岗位。两年后风向反转："Prompt Engineering 已死"——模型都听得懂人话了，还要技巧干什么？背模板的人开始迷茫：那些年攒下的"秘籍"，是资产还是废纸？

新口号紧接着就位："Prompt 已死，Context 为王。"上下文工程成了新显学。可追问一句"它具体在工程化什么"，答案五花八门：有人说是 RAG，有人说是写更长的系统提示词，有人说是管理对话历史，还有人说就是把资料都塞进上下文窗口。

两边的共同问题是：从未说清工程对象是什么。一件事没被准确定义，"它死了"和"它还活着"这两句话，其实都没有确切的含义。

先给 Prompt 一个定义：Prompt 是一次性的搜索控制。"一次性"说的是作用范围：发出即生效，搜完即失效，不积累、不沉淀；"搜索控制"说的是本质：一条 Prompt 是在调整这一次搜索的控制参数。

这个定义把整个领域重新组织了。过去你收藏的所有技巧不再需要逐条背诵，只需要逐条归位——归到四层结构的参数上（第 03-07 篇的内容）：角色设定、背景介绍，调的是初始化；说明真实意图、给出评价标准，调的是目标；扮演反方、头脑风暴、限定预算，调的是空间；先计划后执行、边做边查证，调的是运行。层只有四层，参数也就集中在这些位置，缺什么调什么——这已经覆盖了提示词工程最关键的一层。

看一个完整的归位过程。一位运营经理最初的 Prompt 是："帮我分析一下我们产品的用户流失问题，要深入、全面、专业。"拿四层自检过一遍：初始化为零，产品是什么 AI 一概不知；目标为零，"深入、全面、专业"等于把尺子交回默认值；空间只有一个模糊方向；运行没有设计。逐层补齐之后，它变成了这样："我们是一款帮助小团队管理客户的 SaaS，客单价低，用户自助开通。目标是下个季度把次月留存提升 5 个百分点；评价分析优劣的标准是，能否指向这个月就能执行的动作。请从三个方向分别分析：新用户没找到核心价值、老用户的需求消失、被竞品挖走。先列出每个方向的可能原因，再深入分析权重最高的一个，最后给出这个月应该做的三件事。"同一个任务，同一款模型，差别只是每个参数各就各位。

那哪些技巧真的死了？弥补模型缺陷的那些：哄它仔细算数的咒语、防止它忘记指令的复读。模型变强，这些补丁被一一撕掉。但操作搜索结构的技巧不会死：搜索总需要初始状态、评价标准、空间参数，而这些参数不会自己出现，只能由人给定。模型越强，同一组参数通常能被执行得更充分。Prompt 仍然在起作用，只是它不再主要承担弥补模型缺陷的任务。

再说 Context Engineering。注意一条边界：一条 Prompt 用一次，是控制；可当同一段内容被团队反复粘贴——每次评审都带着同样的背景卡——它在事实上已经成了配置，只是还穿着 Prompt 的外衣，靠每个人记得复制粘贴来维持。反复使用的 Prompt，应该固化下来。Context（上下文）就是搜索配置在一次搜索中的具体表达；上下文工程，就是把产品定位、设计原则、历史决策这些控制参数持续建设成配置库，再按每次任务裁剪出切片的工程。

同样是"做上下文工程"，有的团队做出了复利，有的团队做出了仓库。做仓库的，工程对象是"资料"：收录、整理、堆砌，成绩按"积累了多少文档"算。做复利的，工程对象是"配置"：提炼规则、按任务裁剪、定期清理，成绩按"每一次搜索的初始状态是否在变好"算。前者的资料越堆越多，搜索的起点却从未移动。

所以两个"工程"的分野，最后落在同一个判断标准上：每一次搜索的初始状态，有没有在变好？ Prompt 管一次，上下文工程管每一次——同一组参数，两种时间尺度。

判断两个工程做得对不对，标准都是那句：每一次搜索的初始状态，有没有在变好。团队里那段每次评审都要手动粘贴的背景卡，就是第一个该固化的东西。完整的论证在《AI认知搜索理论》第十一、十二章。下一篇文章，我们用一条翻车的自动化链条来检验这句话。