提示词工程正在消失：新岗位其实叫上下文工程

2023 年，“提示词工程师”一度被列为最热门的新兴职业。两年后，招聘网站上带这个 title 的岗位数量已经大幅萎缩。

表面解释是”模型变强了，不需要调提示词了”。这个解释不成立——如果模型真的变强到不需要调教，为什么企业落地 AI 的成本反而越来越高？

真正发生的事是：决定输出质量的主战场，从”怎么写这句话”转移到了”给模型看什么”。

一、措辞的红利在快速折旧

一个可以验证的观察：2023 年那些被广泛传播的”魔法提示词”——“你是一位世界顶级专家""这对我职业生涯至关重要""让我们一步步思考”——在今天的主流模型上带来的提升接近于零。部分研究显示，某些情绪化施压词甚至会轻微降低输出质量。

原因不难理解。早期模型对指令的格式极度敏感，一句”请以 JSON 格式输出”加不加”请”、放在开头还是结尾，效果能差百分之几十。厂商在训练阶段把这类不稳定点作为对齐目标逐一修复（指令遵循、格式遵循、长上下文利用），于是措辞层面的方差被压缩掉了。

当每个普通用户都能写出效果差不多的提示词时，提示词技巧就不再是竞争力。

二、剩下的方差在上下文里

那么今天同一个模型在不同团队手里，为什么效果还是天差地别？看下面这组对比：

维度	2023 年的写法	2026 年的写法
关注对象	句子	上下文窗口的完整内容
主要手段	角色扮演、语气、示例	检索策略、分块、工具设计、记忆写入规则
失败原因	指令不够清楚	关键信息没进上下文 / 进了错误信息
调试方式	改措辞再试	看 trace，定位是哪一步注入了脏数据
归属	个人技巧	系统工程

一个有代表性的例子：客服 Agent 答复错误，团队花了两天改系统提示，没解决。最后发现是知识库中同一政策存在三个版本（2024、2026 新旧并存），检索时按向量相似度随机命中旧版。这跟提示词一个字都没关系。

上下文工程的核心命题因此变成：在有限的窗口里，如何保证模型看到的是正确、够用、可信、且不互相冲突的信息。

三、上下文工程师实际在做什么

这个角色日常处理的是下面五类问题，每一类都有具体交付物：

1. 信息源治理。定义哪些知识可以进上下文、谁负责维护、如何标记版本和有效期。产出通常是知识库的内容规范，比如”同一政策只保留一个有效版本，历史版本标记为 archived 且不参与检索”。这一项往往是收益最大、最不被重视的。

2. 组装策略。写清楚一次请求的窗口如何分配：系统指令占多少、检索片段占多少、历史对话压缩到多少、留给输出的空间多少。一个实用的起点是把窗口预算显式写进配置，而不是让框架自动塞到满。

3. 压缩与摘要。长对话必然要压缩，而压缩是有损的。要决定压缩时保留什么：所有数字、所有承诺、所有待办、用户的明确偏好必须刚性保留；寒暄、重复确认可以丢。这份”保留清单”应该写进代码，而不是让模型自由发挥。

4. 工具接口设计。工具名、描述、参数schema 都是上下文的一部分。一个返回 8KB 原始 JSON 的工具，会挤掉真正有用的上下文。好的工具设计原则是：返回结构化、可裁剪、带 next-step 提示的窄结果。

5. 冲突处理。当检索内容和系统指令冲突时，谁赢？当两条记忆互相矛盾时，以哪条的时效为准？这些必须显式定义优先级，否则模型会自己猜，而它的猜测不稳定。

四、给从业者的三条迁移建议

从”调措辞”转向”查数据”。下次效果不好，先别改提示词，把这次请求的完整上下文打印出来读一遍。你会发现相当比例的问题肉眼可见：抓来的网页是一堆导航栏、检索片段被截断在半句话、历史记录里有个早就被推翻的错误结论。

把你的提示词改造成结构化的规范文档。不再是几段自然语言，而是分节的契约：角色与边界、可用信息、输出格式、异常处理、禁止事项。可版本化、可 diff、可回归测试的提示词才是工程资产。

学会读 trace。多步 Agent 的调试对象是整条调用链：每一步输入了什么、模型返回了什么、工具返回了什么。不会读 trace 的人，只能在一个黑箱里盲改措辞。

五、别把话说过头

提示词并没有完全没用。它在两个地方依然关键：一是边界定义，也就是明确告诉模型不能做什么（这类指令措辞稍松就会被绕过）；二是输出格式约束，尤其在需要程序化解析时。但它已经从一个高溢价的”技巧”降级为一项基础素养，和”会写 SQL”差不多。

真正稀缺的是另一件事：知道模型在什么情况下会出错，并且有能力在系统层面让它不出错。这件事很难被模型自己替代。