「提示词工程」这个词流行了两年，它带来一个副作用：让人以为效果的瓶颈在于怎么说话。
实际经验恰恰相反。在多数生产系统里，反复打磨措辞的收益很快见顶，而重新审视「模型看到了什么」往往能带来数量级的改善。
一个常见的困境
假设你做了一个客服助手，效果不稳定。你开始改提示词：
第一版：加上了「你是专业的客服」→ 好了一点。 第二版：加上了「回答要简洁」→ 好了一点。 第三版：加了三个示例 → 明显变好。 第四版：再加上「注意语气友善」→ 没变化，甚至变差。
到第四版你就遇到了天花板。原因不是措辞不够好，而是你能提供的判断标准已经用完了。剩下的不确定性来自别处：
- 它有时拿到的是过期的政策文档。
- 它有时拿到三份互相矛盾的说明。
- 它有时拿到了无关的 FAQ，然后认真地为无关内容找解释。
这些问题都改不了——只用改提示词的话。
两个词的区别
提示词工程关心的是：怎么说。指令怎么写、示例怎么给、格式怎么约束。
上下文工程关心的是：给它看什么。系统提示、任务说明、检索到的资料、历史对话、工具返回结果，以及它们的组织、排序与压缩方式。
前者是后者的一部分。把两者混为一谈，会让人把大量时间花在收益最小的那个维度上。
为什么上下文是更大的杠杆
第一，模型没有记忆，也没有主动获取信息的能力。
它每一刻的表现完全由当前上下文决定。这意味着你控制上下文，就等于控制它的认知边界。
第二，无关内容不是中性的。
这一点常被误解。多数人以为多给点信息没坏处，模型会自己挑。实际上，无关内容会主动降低准确率——模型会认真地为噪声寻找解释，甚至被噪声带偏。
在检索增强的场景里，把召回数量从 20 条降到 5 条，效果常常反而提升。
第三，上下文直接决定成本。
每次请求都要重发全部历史，费用按总 token 计算。多轮对话的成本是二次增长的。上下文设计不只是质量问题，也是商业模式问题。
第四，换模型提升 5%，清理上下文可能提升 50%。
这是最实际的论据。模型能力在快速趋同，而上下文质量的差异完全取决于你的工程水平。
四个具体动作
选择：只放与当前任务真正相关的信息。宁可少给，不要多给。
压缩：把长文档摘要成要点，把历史对话折叠成结论。原则是——保留决策，丢弃过程。
排序：重要信息放在开头或结尾。中间位置最容易被忽略，这是长上下文里的稳定现象。
隔离：把不可信内容（网页、用户上传的文件、第三方 API 的返回）明确标注为「数据」，永远不当作指令执行。这不只是质量问题，也是安全底线——提示注入正是从这里进来的。
一个诊断方法
如果你的系统效果不稳定，先不要改提示词，做这件事：
把每次请求的完整输入打印出来，人读一遍。
你会惊讶地发现多少明显不该出现的内容正躺在上下文里：三个月前的对话、格式错乱的表格、上次失败重试的残留、同一份文档的三个版本。
多数时候，删掉它们比优化任何措辞都有效。
结论
提示词工程是入门技能，上下文工程是核心能力。
模型会继续变强，提示词的技巧会继续贬值——因为更强的模型对模糊指令更宽容。但信息供给的质量没有上限：你的检索有多准、压缩有多克制、隔离有多严格，这些永远不会被模型能力自动解决。
把时间花在这里，收益更持久。