完整题目
请详细解释上下文工程(Context Engineering)与提示工程(Prompt Engineering)在大语言模型应用中的区别和联系，包括它们各自的目标、方法和应用场景。
本文目录
答案要点
- 明确区分两者的核心定义：Prompt Engineering聚焦输入模板的优化，Context Engineering聚焦外部信息的筛选与组织
- 阐述Context Engineering的三层架构（检索-重排序-压缩）
- 说明两者协同关系：Context Engineering为Prompt Engineering提供高质量"原料"
- 举例典型应用场景差异
核心区别
| 维度 | Prompt Engineering | Context Engineering |
|---|---|---|
| 目标 | 优化模型输入的表达方式 | 优化模型输入的信息质量 |
| 操作对象 | 提示模板、指令结构、示例格式 | 外部知识的选择、排序、压缩、组织 |
| 核心问题 | "怎么问" | "给什么" |
Context Engineering 的三层方法
-
检索层（Retrieval）
- 多路召回：向量检索 + 关键词 + 知识图谱
- 查询扩展：HyDE、子查询分解
-
重排序层（Reranking）
- 相关性打分：Cross-encoder精排
- 多样性控制：MMR算法避免冗余
-
压缩层（Compression）
- 上下文压缩：LLMLingua、选择性上下文
- 结构化组织：树状摘要、时间线梳理
协同关系
用户问题 → Context Engineering（造好"食材"）→ Prompt Engineering（做好"烹饪"）→ 模型输出- CE是PE的基础：再精妙的提示词，喂给模型的上下文质量差，效果也受限
- PE反哺CE：通过PE分析模型失败案例，指导CE优化检索策略
应用场景差异
| 场景 | 主导方法 | 原因 |
|---|---|---|
| 代码生成、创意写作 | Prompt Engineering | 依赖模型内化知识，需精确引导输出格式 |
| 客服问答、法律检索 | Context Engineering | 依赖外部实时/私有知识，需精准定位相关信息 |
| 复杂多跳推理 | 两者深度结合 | 既需要高质量上下文，也需要思维链提示 |
一句话总结
Prompt Engineering 是说话的艺术，Context Engineering 是选材的艺术；大模型应用从"调提示词"走向"建上下文系统"，是工程化成熟的标志。
换一种问法，检查是否真正理解
场景切入
你看我们做客服问答，用户问“我的订单什么时候到”，系统得先去查订单系统拿到物流信息。这时候你既要决定“怎么问”模型，又要决定“给什么”模型。那这两件事——提示工程和上下文工程——你觉得是一回事吗？
层层追问
你做RAG的时候，一般怎么构造给模型的输入？……是先写提示词模板，还是先处理检索回来的文档？……如果检索结果质量差，提示词写得再好也没用，那这两者到底谁更重要，它们怎么配合？
直球架构
请解释一下上下文工程和提示工程在大模型应用中的区别和联系。它们各自的目标、方法、应用场景是什么？上下文工程具体怎么做，比如检索、重排序、压缩这些步骤，和提示工程怎么协同？
练习口述回答 · 约4分钟
- 一句话定位：本质是‘怎么问’和‘给什么’的分工
- Prompt Engineering 和 Context Engineering 的边界划分
- Context Engineering 三层架构：检索-重排序-压缩
- 业务场景举例：客服退款场景中两者如何结合
- 落地风险与工程师姿态判断
这道题其实问的是，在大模型应用里，我们怎么把输入这件事拆成两个不同层面来优化。一个是怎么问，也就是提示工程；另一个是给什么，也就是上下文工程。两者目标不同，但在真实落地时，往往是混合着用的。
先明确一下边界。Prompt Engineering 解决的是表达问题，比如指令怎么写、示例怎么放、格式怎么约束，核心是让模型理解我们想要什么。而 Context Engineering 解决的是信息质量问题，尤其是当模型需要依赖外部知识时，比如客服场景下的退款政策、库存数据，怎么从一堆文档里选出最相关的片段，并且组织好，再喂给模型。说白了，Prompt Engineering 是说话的艺术，Context Engineering 是选材的艺术。
具体到上下文工程，我一般把它拆成三层。第一层是检索，这里不能只用一种方法，我会把 向量检索 和 [[BM25]] 这种关键词检索结合起来做，也就是 [[Hybrid Search]]，能覆盖语义相似和精确匹配两种需求。第二层是[[重排序]]，因为初步召回的结果往往有噪音，我会用 [[Cross-Encoder]] 做一次精排，把真正相关的文档提到前面，同时用 MMR 算法控制多样性，避免一堆相似内容挤占上下文窗口。第三层是压缩，因为大模型上下文窗口有限，不能把所有文档都塞进去，我会用 LLMLingua 或选择性上下文，把冗余信息去掉，只保留最核心的句子。
这里有个坑：很多人以为只要检索够好就行，但实际落地时，重排序和压缩往往才是决定最终效果的关键。如果不做重排，模型可能被不相关的噪音误导；如果不做压缩，窗口一满，模型会丢失关键信息。
举个例子，电商客服的退款场景。用户问“我买的手机降价了，能退差价吗？”这时候，Prompt Engineering 负责把问题转成标准指令，比如“请根据以下政策判断是否支持价保”。但真正能回答问题的，是上下文工程从知识库中检索到的价保政策文档。如果只靠关键词“降价”去搜，可能搜到一堆促销文章，但找不到具体的“7天价保”条款。所以我会先用混合检索召回，再用重排序把“7天价保”相关片段排到前面，最后压缩成一段话，加上提示词里的指令，模型才能给出准确答复。
再一个，落地时有个前提：上下文工程的效果，高度依赖知识库的质量和切分方式。文档如果没经过清洗，或者切分粒度过粗过细，检索召回率都会崩。常见失败场景是，文档里政策条款和客服话术混在一起，模型可能把话术当成政策。所以上线前我会特别关注文档的预处理，把结构化字段（比如政策ID、生效日期）单独提取出来，方便精确匹配。
说到这，其实还有一个有意思的延伸：当上下文工程做得足够好时，我们甚至可以用 [[Zero-shot]] 提示代替 [[Few-shot]] 示例，因为模型从上下文中已经学到了足够多的模式。但这会引发一个权衡，上下文质量是否真的能替代示例的引导作用？