Context vs Prompt Engineering：从小炒菜谱到中央厨房

可视化演示

展示上下文工程与提示工程核心区别、Token窗口预算分配、动态上下文组装流程、从Prompt到Context演进路径，步进式深入理解LLM上下文管理工程方法论。

概念界定：菜谱与大厨

老王的小炒店里，墙上贴着一张张手写菜谱：“宫保鸡丁，鸡丁先腌十分钟，大火翻炒，最后放花生米。”每来一桌客人点这道菜，老王都要看一眼菜谱，然后凭经验动手。这里的“菜谱”就是 Prompt：一段写给模型看的指令文本，告诉它做什么、怎么做。Prompt Engineering 就是研究“怎么写好这张菜谱”的学问——措辞怎么排、示例给几个、格式怎么约束，让模型一次就听懂。

而老王的连锁店开起来后，他发现仅仅优化菜谱远远不够。一道菜要好吃，取决于食材新不新鲜（背景知识）、灶台火候稳不稳定（模型能力）、客人的口味偏好（用户画像）、以及上一位客人点过什么（对话历史）。把这些要素统一管理起来的整套体系，就是 Context。Context Engineering 研究的是“如何设计和维护整套出餐系统”，而不仅仅是在灶台前喊一句漂亮的吆喝。

在技术层面，一个完整的 Context 通常由四类信息构成：指令（Instruction）告诉模型角色和任务，背景资料（Background）来自知识库检索，对话历史（History）保留多轮交互的记忆，用户画像（Profile）描述用户偏好与身份。Prompt 只是 Context 中的“指令”这一个子集，而 Context 是装着所有食材的整个备菜台。理解了这一点，你就明白了为什么两个概念的工程边界完全不同：一个在“文本优化”层面发力，一个在“系统构建”层面发力。

所以，当你再听到"Prompt Engineering"时，请把它想成老王那手精致的颠勺功夫；而 Context Engineering，是围绕这手功夫建起来的整套中央厨房。菜谱再精彩，也只是厨房的一部分。

核心坐标：静态口令 vs 动态系统

老王的小炒店，服务员在门口喊一嗓子“一份宫保鸡丁！”，老王就照菜谱炒一份。这句吆喝是固定的、独立的：这桌客人是谁、之前聊过什么，老王并不关心。这就是 Prompt 的典型特征——静态的、单点的一次性指令。它不会主动查阅资料，不会翻看历史，每一句命令都像一张崭新的便签纸。

中央厨房则完全不同。一份宫保鸡丁要出餐，系统会自动做三件事：查一下这位顾客的会员档案（画像），去冷库里取今天早上分装好的鸡丁（检索背景资料），再看一眼他上一单点的什么避免重复（历史记录）。所有这些动态汇入一条生产线，才最终形成“炒这道菜”的完整指令。这就是 Context——组装出来的动态系统，它随着每一次请求、每一个用户、每一段历史而实时变化。

从工程视角看，两者的坐标差异体现在三个维度。静止与流动：Prompt 是一条固定文本，Context 是随请求变化的动态集合；手工与自动：Prompt 依赖人逐次手写，Context 由系统自动组装；局部与全局：Prompt 只看当下的一次问答，Context 横跨知识库、记忆与业务系统。用集合论的语言说，静态的 Prompt 是整个动态 Context 的一个子集。这个包含关系，是理解两者关系的最小必要知识。

所以，别再纠结“Prompt 和 Context 谁更好”。它们压根不在一个维度上：一个是一句吆喝，一个是运转整个后厨的系统。理解了“包含”而非“取代”，你就握住了这两者的正确坐标系。

价值版图：手艺人与架构师

老王最自豪的，是他那口锅气。同样一盘青菜，他颠两下就比徒弟炒的香——这是手艺，来自千百次重复得来的肌肉记忆。Prompt Engineering 的价值也在于此：通过精心优化指令的措辞、示例、逻辑，让模型输出更准确。这套手艺在任何 LLM 应用中都不会过时，它决定了你看似不起眼的文本能否激发出模型真正的能力。

但手艺有上限。老王一天最多炒两百道菜，他徒弟照着菜谱炒，味道就是差一截——为什么？因为菜谱只能传递“放盐少许”，传不了“油温七成热”这种隐性经验。同样，提示词技巧只能优化模型“听懂”的概率，却控制不了背景知识够不够、历史记忆全不全、检索结果准不准。真正的杠杆在于上下文治理：把知识、记忆、规则当作系统资产来经营，而不是每次临时抱佛脚。

这就引出 Context Engineering 的价值定位：Prompt Engineering 优化“单点指令的有效性”，Context Engineering 治理“整个信息供应链的质量”。在应用中，两者共同决定输出上限。一个形象的公式是：输出质量 = 模型能力 × 上下文质量。模型再强，上下文是一团乱麻，回答照样跑偏；反之，上下文组织得越清晰，小模型也能发挥出超出预期的水平。

换句话说，提示词高手打磨的是“一句漂亮的吆喝”，Context 工程师经营的是“整条供应链的质量”。前者是手艺人的匠心，后者是架构师的格局。AI 应用要规模化，缺不了后者。

上下文管理：备菜间的功夫

中央厨房的备菜间，是整个连锁店的心脏。每天凌晨，采购员把蔬菜按类分装进保鲜盒，标上日期，放进不同温区的冷柜：叶菜类 2℃、肉类-18℃、干货常温。这样出餐时，厨师随手就能拿到需要的食材。上下文管理就是这个备菜间——在请求到来之前，先把知识准备好、组织好、编排好，而不是等到用户提问时才手忙脚乱找资料。

管理上下文首先要面对一个硬约束：上下文窗口是有限的，就像保鲜柜的容量有限。模型一次只能读取有限数量的 Token。塞太多无关内容，有效信息会被稀释，甚至直接溢出窗口，导致关键指令被“挤”出视野。因此 Context Engineering 的第一课不是“塞什么”，而是“不塞什么”——学会做减法，比学会做加法更重要。

上下文管理包含三个核心动作。窗口规划：评估任务需要多少 Token，给知识库、历史、指令分配预算；内容组织：将长文档分块（Chunking）、摘要（Summarization）、加标签（Tagging），方便检索；检索注入：按用户问题从知识库选出最相关的片段注入上下文。衡量管理好坏的关键指标是窗口利用率——它直接反映你的“保鲜柜”里装的是今天要用的食材，还是囤积过期的冻货。

老王的经验告诉我们：好厨师不靠食材堆砌，靠的是备菜间井井有条。Prompt 工程让你喊得出好口令，而上下文管理决定你有没有好料可喊、窗口装不装得下。

动态组装：自动配餐流水线

中央厨房最神奇的环节在出餐高峰。顾客扫码下单的瞬间，系统同时做三件事：从数字档案里调出这位常客的口味（他不吃香菜）、从冷库挑出对应食材（今天推荐的鸡腿肉）、翻出他上回的评价（嫌上次太咸）。三路信息汇聚到一条流水线上，自动拼成一份完整的加工单，交到灶台。这就是动态上下文组装——不是人肉复制粘贴，而是系统自动配餐。

在 LLM 应用中，这三路信息分别对应：用户画像（Profile）、知识检索（Retrieve）、对话历史（Memory）。组装器（Assembler）按业务策略把它们与系统指令拼接成最终 Prompt。拼什么、按什么顺序拼、各占多少比例，这些决策就是 Context Engineering 的核心技术。同样的模型，用不同的组装策略，效果可以天差地别。

一个典型的动态组装流程可以概括为：先根据用户问题 q 从知识库检索 Top-K 相关片段；再读取用户 u 的画像和最近 n 轮对话历史；最后按“系统指令 → 画像 → 历史 → 检索片段 → 当前问题”的顺序组装成完整的上下文。检索增强（RAG）、路由分发（Routing）、对话编排（Orchestration）是三个最常用的实现手段。它们让上下文不再是“写死的纸”，而是“活着的流水线”。

如果说 Prompt Engineering 关心的是“这句话怎么写”，Context Engineering 关心的则是“这句话怎么来”。流水线一转，上下文自己备齐了——这正是老王从单店迈向连锁的关键一跃。

演进路线：从掌勺到建厨房

老王把小炒店开成连锁店，不是某一天突然学会的。他先把手写菜谱打印成标准手册（模板化），再请人把食材提前切好分装（半成品化），然后引入冷库和排菜系统（体系化），最后才建成中央厨房（工程化）。这条路，恰好就是 Prompt Engineering 向 Context Engineering 演进的真实轨迹。没有前面的铺垫，中央厨房不过是空中楼阁。

从技术演进看，AI 应用开发正沿着同样的阶梯攀爬。第一级：纯手写提示词，每次调用现场发挥，适合 Demo 和简单问答；第二级：提示词模板化，把固定部分抽离复用，如 LangChain 的 PromptTemplate；第三级：引入检索与记忆，让上下文按需变化；第四级：完整的上下文工程平台，把知识、记忆、评估、监控作为系统能力统一治理。每一级都在解决上一级的瓶颈。

这场演进的本质，是范式的转变——从“面向单次对话的文本优化”转向“面向业务场景的信息系统工程”。提示词不会消失，它被吸收为 Context 系统中的一个模块。这就像大厨的手艺没有被机器取代，而是被转化成了流程、SOP 和品控标准。理解这条演进路径，能帮你判断：你的应用现在处在哪一级，下一步该升级什么，而不是盲目追新概念。

所以，别把“从 Prompt 到 Context”理解成一场革命——它是一次自然进化。老王没有丢掉颠勺的手艺，而是把它放进了更大的系统。你也不用推翻已有的提示词经验，而是把它升级为工程体系的一部分。

实践落地：厨房的仪表盘

连锁店总部的大屏上，跳动着几个关键数字：今日出餐合格率 98.7%、食材损耗率 3.2%、平均出餐时间 4 分 15 秒。老王不用再去每个分店亲自炒菜，他只要盯着这面仪表盘，就能知道整个体系健不健康。Context Engineering 的落地，同样需要这样一面仪表盘——用数据代替感觉，用指标代替猜测。

很多团队的 Context 系统上线后效果不错，但过了两周，发现回答质量时好时坏。为什么？因为没有评估和监控。上下文组装是动态的：知识库更新了、用户分布变化了、检索质量波动了，任何一环出问题都会反映到最终效果上。如果只有上线时的“一次性评测”，系统就会悄悄劣化，而你浑然不知。

落地一套 Context 工程，至少需要三块基础设施。工具链：LangChain、LlamaIndex 等编排框架，提供检索、组装、调用的标准组件；评估体系：用“黄金问答集”定期回归测试，核心指标包括任务准确率、上下文命中率、Token 成本与响应延迟；监控运维：记录每次请求的上下文组装明细、检索命中的文档、模型输出，出现 badcase 可以回放归因。这三块构成一个持续优化的闭环，让系统越跑越稳。

老王的连锁店靠数据管理，而不是靠他挨个灶台喊话。Context Engineering 的落地同样如此：用仪表盘代替直觉，用指标代替感觉。当你建立起质量、成本、延迟三位一体的监控体系，你的 AI 应用才真正从“作品”变成了“产品”。

AI 应用场景

Python 演示

# context_vs_prompt.py"""Prompt vs Context Engineering 最小对比演示""" KNOWLEDGE_BASE = {    "退款": "退款政策: 7天无理由, 需保留原包装",    "物流": "物流政策: 默认发货后3天送达",    "发票": "发票政策: 支持电子发票, 24小时发放",}  def fake_model(context):    """模拟LLM: 根据上下文中是否含知识做出不同回答"""    docs = [line.replace("【知识】", "") for line in context.split("\n")            if "【知识】" in line]    if docs:        return "[模型] 结合检索知识回答: " + "；".join(docs)    return "[模型] 抱歉, 我缺少相关知识, 无法准确回答。"  class PromptHandCraft:    """方式一: Prompt工程, 每次手工拼提示词"""     def ask(self, question):        prompt = "你是AI助手, 请回答用户问题: " + question        return fake_model(prompt)  class ContextAssembler:    """方式二: Context工程, 动态组装上下文"""     def __init__(self):        self.knowledge_base = KNOWLEDGE_BASE        self.history_map = {}        self.profile_map = {"user_001": "金牌会员, 偏好简洁回答"}     def retrieve(self, query):        # 简单的关键词召回, 模拟向量检索        hits = []        for key, doc in self.knowledge_base.items():            if key in query:                hits.append("【知识】" + doc)        return hits     def load_profile(self, user_id):        return self.profile_map.get(user_id, "普通用户")     def load_history(self, user_id):        return self.history_map.get(user_id, [])     def assemble(self, user_id, question):        parts = ["【画像】" + self.load_profile(user_id)]        parts += self.retrieve(question)        history = self.load_history(user_id)        if history:            parts.append("【历史】" + "；".join(history))        parts.append("【问题】" + question)        return "\n".join(parts)     def ask(self, user_id, question):        context = self.assemble(user_id, question)        self.history_map.setdefault(user_id, []).append(question)        return fake_model(context)  def main():    print("===== 方式一: Prompt 手工拼 =====")    worker = PromptHandCraft()    print(worker.ask("退款怎么操作? "))     print("\n===== 方式二: Context 动态组装 =====")    engine = ContextAssembler()    print(engine.ask("user_001", "退款怎么操作? "))    print(engine.ask("user_001", "那发票呢? "))  if __name__ == "__main__":    main()

1. KNOWLEDGE_BASE = {模拟企业知识库，像中央厨房的食材冷库。
2. def fake_model(context):模拟 LLM：有检索知识就给出具体回答，否则只能道歉。说明“上下文里有什么，输出就有什么”。
3. class PromptHandCraft:传统 Prompt 模式：只拼一句话就提问，不查库、不记历史。
4. def retrieve(self, query):最简版“按需取料”，真实系统会换成向量相似度检索。
5. if key in query:关键词命中即视为相关，这是检索的朴素雏形。
6. def assemble(self, user_id, question):核心组装逻辑：画像、知识、历史、问题按顺序拼成一个完整上下文。
7. self.history_map.setdefault(user_id, []).append(question)把提问写入历史，让多轮对话“不失忆”。

常见误区

面试题