Context Engineering 和 Prompt Engineering 有什么区别？

前两年大家聊大模型应用最常听到的是 Prompt Engineering。网上一堆文章教你怎么写提示词角色设定、分步骤思考、少样本示例、输出格式、禁止编造、语气约束。这些技巧当然有用。你让模型“简单讲一下”和“请用面向 Java 后端工程师的方式按问题背景、核心原理、代码示例、常见坑四段说明”效果肯定不一样。但做过真实 AI 应用的人会发现提示词写到一定程度以后收益会迅速变小。不是你不会写 prompt而是模型手里没有正确材料。用户问“这个告警为什么触发”你 prompt 写得再漂亮如果没有告警规则、指标数据、历史事件、设备拓扑、代码配置它只能猜。用户问“这段代码能不能改”你 prompt 再强调“不要乱改”如果没有相关调用链、测试结果、项目约定它还是只能靠语言模型的通用经验。这就是为什么现在越来越多人开始讲 Context Engineering。一句话说Prompt Engineering 是告诉模型怎么做Context Engineering 是决定模型拿着什么材料做。在简单聊天里prompt 很重要。在复杂应用里上下文往往更重要。Prompt 解决的是“指令问题”Prompt 的本质是指令。你告诉模型扮演什么角色、遵守什么规则、按什么格式输出、遇到不确定情况怎么办。比如你是一个资深 Java 工程师。 请审查下面代码里的并发问题。 输出格式 1. 风险点 2. 触发条件 3. 修复建议 不知道的地方不要编造。这就是典型 Prompt Engineering。它解决的是表达方式和行为边界。好的 prompt 能减少废话能让输出结构更稳定能让模型关注正确方向。尤其在单轮任务里prompt 的价值很明显。比如让模型写 SQL不加约束它可能直接给你一个能跑但慢的查询。你加上“表数据千万级优先考虑索引命中不允许全表扫描”它就会收敛很多。但 prompt 也有天花板。它不能凭空制造事实。你让模型“基于项目真实代码给建议”但你没给它项目代码它只能给通用建议。你让模型“参考公司内部规范”但规范不在上下文里它只能编一个像规范的东西。所以很多 AI 应用一开始看起来像 prompt 问题最后都会变成 context 问题。Context 解决的是“材料问题”Context 是模型这次推理能看到的全部材料。它包括用户问题、系统指令、历史对话、检索结果、文件内容、数据库返回、工具说明、运行日志、记忆信息等。Context Engineering 就是设计这一整套材料怎么进模型哪些信息该放进去哪些信息不该放信息太多时怎么筛顺序怎么排旧信息怎么压缩工具返回怎么总结哪些上下文可信哪些只是用户输入哪些内容可能带有 prompt injection 风险。这件事听起来不酷但非常工程。比如做一个代码助手用户让它修一个测试失败。你不能把整个仓库都塞给模型也不能只塞失败日志。比较合理的上下文可能是失败的测试输出相关测试文件被测函数最近 diff项目约定允许修改的文件范围可用工具列表上一步工具调用结果。这些东西比一句“你是资深工程师请修复 bug”重要得多。为什么只靠 Prompt 会越来越吃力第一个原因是任务变复杂了。早期很多 AI 使用场景是写文案、翻译、总结、改写。这些任务主要靠模型已有知识和语言能力。Prompt 写好一点效果就能上去。但现在 AI 应用越来越多是“连业务系统”查订单、读代码、跑测试、分析报表、操作后台、生成工单。这些任务依赖外部事实。外部事实不进上下文模型就没法可靠工作。第二个原因是上下文窗口虽然变大了但不是越大越好。很多人以为模型支持 100 万 token就可以把所有东西都塞进去。实际效果不一定好。上下文越大噪音也越大。模型可能被不相关信息带偏也可能漏掉关键片段。这和人看资料一样。你问我一个 bug让我看 3 个相关文件我能很快定位。你直接丢给我整个仓库压缩包我反而要先找入口。所以 Context Engineering 不是“塞更多”而是“塞对”。第三个原因是 Agent 需要连续上下文。普通问答只需要当前问题。Agent 要多步执行先查资料再调用工具再根据结果继续判断。每一步都产生新上下文。如果不管理几轮以后上下文会变成一锅粥。比如 Agent 第一步查到了错误日志第二步读了相关文件第三步又读了一个无关文件。到第四步时它到底该相信哪个结果哪个是最新的哪些已经过期哪些只是中间猜测这些都不是 prompt 能单独解决的。一个很典型的例子RAG 问答很多知识库问答项目一开始会这样做用户提问 - 向量检索 - 取前 5 段文档 - 拼到 prompt - 让模型回答。这就是最简单的 RAG。但上线以后会发现很多问题用户问的是流程问题检索出来的是概念介绍用户问的是最新制度检索出来的是旧版本几个文档互相冲突模型不知道该信谁文档片段太短缺上下文片段太长又塞进一堆无关内容。这时候你继续调 prompt效果有限。真正要改的是上下文工程文档切分方式要调整检索要加关键词和向量混合结果要按时间、权限、业务线过滤文档版本要进上下文冲突内容要标出来回答时要引用来源检索不到就让模型承认不知道。这些才是决定效果的东西。Context Engineering 不只是 RAG很多人一听上下文工程就以为是 RAG。其实 RAG 只是其中一部分。Context Engineering 覆盖的范围更大。第一类是检索上下文。比如知识库、数据库、搜索引擎、向量库把和问题有关的内容找出来。第二类是运行上下文。比如当前用户是谁、权限是什么、当前页面在哪、操作对象是什么、会话状态是什么。第三类是工具上下文。模型能用哪些工具每个工具做什么参数怎么填调用后返回什么。第四类是历史上下文。用户之前说过什么系统已经做过什么哪些判断被推翻了哪些结果仍然有效。第五类是约束上下文。比如不能修改哪些文件不能调用哪些接口哪些操作需要审批输出必须满足什么格式。做 Agent 的时候这些上下文都很重要。Prompt 和 Context 的关系Prompt 和 Context 不是二选一。更准确地说Prompt 是 Context 的一部分但不是全部。可以这么看Prompt 是说明书Context 是材料包模型是处理器工具是手脚Agent 循环是工作流。如果说明书写得很清楚但材料包错了结果还是错。如果材料包很完整但说明书没有约束输出也可能乱。一个好 AI 应用通常是两者配合系统 prompt 负责稳定行为比如“不确定就说不知道”“涉及删除必须请求确认”“回答要引用来源”。上下文工程负责提供事实比如相关文档、工具结果、用户权限、业务状态。真正的难点是上下文来源多了以后怎么组织它们。实际项目里怎么做 Context Engineering第一步不要一上来就设计复杂框架先列清楚模型完成任务需要哪些事实。比如做告警诊断助手你需要告警内容触发规则指标时间序列最近变更设备拓扑历史相似告警可执行操作当前用户权限。这个列表比 prompt 模板更重要。第二步给上下文分优先级。不是所有东西都同等重要。用户当前问题、关键日志、相关代码、工具返回结果优先级通常更高。历史对话、背景知识、候选文档要根据情况放。第三步控制上下文大小。长上下文不是垃圾桶。能用检索拿到 3 段关键内容就不要塞 30 段。能用摘要表达历史就不要把 20 轮对话原样放进去。第四步标注来源和可信度。同样一段文字来自系统配置、数据库、用户输入、网页搜索可信度不一样。尤其是 Agent 调工具时用户输入里可能包含“忽略之前所有指令”这种内容。上下文里不区分来源很容易出安全问题。第五步给关键步骤留可观察性。模型最后回答错了你要能回看当时给了哪些上下文检索命中了哪些文档工具返回了什么哪段内容影响了结论没有日志的上下文工程后期基本靠玄学调参。一个简单判断问题到底出在 Prompt 还是 Context如果模型知道事实但表达不稳定通常是 prompt 问题。比如它每次输出格式不一致、废话太多、语气不对、没有按步骤回答。这时调 prompt 有用。如果模型不知道事实或者事实拿错了通常是 context 问题。比如它引用旧文档、漏看关键日志、回答和业务数据对不上、把无关资料当依据。这时继续改“你要认真回答”没有意义。很多项目失败就是把 context 问题当 prompt 问题修。提示词越写越长效果还是飘。最后总结一下Prompt Engineering 没过时但它已经不是 AI 应用工程的全部。Prompt 解决“怎么要求模型工作”。Context 解决“模型基于什么工作”。越是接近真实业务、真实工具、真实数据Context Engineering 越关键。对开发者来说接下来更值得练的能力不是收集 100 条神奇提示词而是学会设计上下文流从哪里取信息怎么筛怎么排怎么压缩怎么防污染怎么让结果可追踪。AI 应用做得像不像产品很多时候不看 prompt 有多华丽而看上下文给得准不准。