Context vs Prompt Engineering 区别?

30 秒回答

1. 明确区分两者的核心定义：Prompt Engineering聚焦输入模板的优化，Context Engineering聚焦外部信息的筛选与组织
2. 阐述Context Engineering的三层架构（检索-重排序-压缩）
3. 说明两者协同关系：Context Engineering为Prompt Engineering提供高质量"原料"
4. 举例典型应用场景差异

回答与解析

答案要点

• 明确区分两者的核心定义：Prompt Engineering聚焦输入模板的优化，Context Engineering聚焦外部信息的筛选与组织
• 阐述Context Engineering的三层架构（检索-重排序-压缩）
• 说明两者协同关系：Context Engineering为Prompt Engineering提供高质量"原料"
• 举例典型应用场景差异

核心区别

Context Engineering 的三层方法

1. 检索层（Retrieval）

   • 多路召回：向量检索 + 关键词 + 知识图谱
   • 查询扩展：HyDE、子查询分解

2. 重排序层（Reranking）

   • 相关性打分：Cross-encoder精排
   • 多样性控制：MMR算法避免冗余

3. 压缩层（Compression）

   • 上下文压缩：LLMLingua、选择性上下文
   • 结构化组织：树状摘要、时间线梳理

协同关系

用户问题 → Context Engineering（造好"食材"）→ Prompt Engineering（做好"烹饪"）→ 模型输出

• CE是PE的基础：再精妙的提示词，喂给模型的上下文质量差，效果也受限
• PE反哺CE：通过PE分析模型失败案例，指导CE优化检索策略

应用场景差异

一句话总结

Prompt Engineering 是说话的艺术，Context Engineering 是选材的艺术；大模型应用从"调提示词"走向"建上下文系统"，是工程化成熟的标志。

口语版讲法(约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 示例，因为模型从上下文中已经学到了足够多的模式。但这会引发一个权衡，上下文质量是否真的能替代示例的引导作用？

所以整体来看，我更倾向于把 Prompt Engineering 看成是“最后一道工序”，而 Context Engineering 是“前面的供应链”。如果供应链不行，再好的工序也出不了好产品。反过来，如果供应链很强，提示词可以做得非常简洁。在工程化时，我会优先把精力花在上下文工程上，因为它的优化空间更大，收益也更稳定。

关键一句:当上下文工程足够好时，可以用 Zero-shot 替代 Few-shot，但需要权衡上下文质量是否能替代示例的引导作用。

面试官还可能这样问

1. 问法 1 · 场景切入

   你看我们做客服问答，用户问“我的订单什么时候到”，系统得先去查订单系统拿到物流信息。这时候你既要决定“怎么问”模型，又要决定“给什么”模型。那这两件事——提示工程和上下文工程——你觉得是一回事吗？

2. 问法 2 · 层层追问

   你做RAG的时候，一般怎么构造给模型的输入？……是先写提示词模板，还是先处理检索回来的文档？……如果检索结果质量差，提示词写得再好也没用，那这两者到底谁更重要，它们怎么配合？

3. 问法 3 · 直球架构

   请解释一下上下文工程和提示工程在大模型应用中的区别和联系。它们各自的目标、方法、应用场景是什么？上下文工程具体怎么做，比如检索、重排序、压缩这些步骤，和提示工程怎么协同？