提示工程到上下文工程的演变
刚接触大模型时，大家都在研究”怎么把提示词写好”。但随着应用变复杂，人们逐渐意识到：决定输出质量的，远不止那一句指令，而是模型在生成时”看到的一切”。这就引出了从”提示工程”到”上下文工程”的转变。
提示工程的基础技巧
提示工程（Prompt Engineering）研究的是如何措辞，让模型给出更好的回答。一些被反复验证有效的技巧包括：
- 明确角色与任务：告诉模型它是谁、要做什么、输出什么格式。
- 给出清晰约束：字数、语气、要避免什么，越具体越好。
- 分步引导：让模型”一步步想”，复杂问题先拆解再作答。
- 提供示例（few-shot）：与其干讲规则，不如给几个”输入—输出”的范例，模型会照着模仿。
few-shot 尤其值得一提：很多时候你说不清规则，但能举出例子。给模型两三个示范，它就能抓住你想要的模式。这是性价比很高的一招。
为什么从 prompt 转向 context
当应用从”问一句答一句”变成”基于大量资料、多轮对话、调用工具来完成任务”时，单纯打磨一句提示词就不够了。真正影响结果的，是塞进模型上下文窗口里的整体内容：
- 检索回来的文档片段对不对、全不全？
- 历史对话保留了哪些、压缩了哪些？
- 工具返回的结果如何组织后再交给模型？
- 系统指令、用户输入、外部资料之间的优先级如何安排？
这些都不再是”怎么写一句话”的问题，而是”如何系统性地组装模型的输入”。这就是上下文工程（Context Engineering）的范畴。
上下文由什么构成
可以把模型每次生成时的上下文，看成几类信息的拼装：
- 指令：系统提示词，定义身份、规则和边界。
- 检索：从知识库里取来的相关资料（RAG），提供时效性和依据。
- 记忆：对话历史、用户偏好、之前的中间结果，通常需要做压缩或摘要以省空间。
- 工具结果：函数调用返回的实时数据，需要清洗成模型易读的形式。
上下文工程，就是在有限的窗口预算内，决定”放什么、放多少、怎么排”，让模型恰好拿到完成任务所需的信息——既不缺，也不被无关内容淹没。
对开发者的启示
这个转变带来几条实际建议：
- 别只盯着 prompt 调措辞，要关注整条”信息供给链”：检索质量、记忆策略、工具输出格式。
- 上下文不是越多越好。塞太多无关内容会稀释注意力，反而降低质量，也增加成本。
- 把上下文构造当成可测试的工程：固定一批样例，调整组装策略后回归对比效果，而不是凭感觉改。
小结
提示工程教会我们如何与模型对话，而上下文工程把视角抬高了一层：管理模型看到的整体信息环境。随着应用越来越像”系统”而非”对话框”，谁能更好地组织上下文，谁就能更稳定地榨出模型的能力。
← 返回首页