从提示到上下文：为什么只说清楚远远不够
问题描述
考虑这样一个提示词：主题是"Python MySQL连接最新最佳实践"，包含精心设计的角色设定（“你是一位有10年经验的Python数据库专家”）、明确的指令（“只提供2024年的最佳实践，不要过时的方法”）和具体的格式要求（“列出主要方法、优缺点、代码示例、安全注意事项”）。
提示词本身设计得当，但 GPT 仍可能自信地给出 2018 年已弃用、存在安全漏洞的代码。原因在于：模型不知道 2024 年的最佳实践，因为它的训练数据截止时间不包含这些新信息。问题不在提示词，而在模型的知识。
问题出在哪？
传统的 Prompt Engineering 只能控制"你如何说"，但无法控制"模型知道什么"。模型无法访问：
- 训练时间之后发布的文档
- 你私有的公司文档
- 实时数据
- 它没有训练过的专业领域知识
无论提示词多么精妙，都无法弥补知识鸿沟——正如给一位从未学过现代医学的医生看最新期刊，他只能依据过时的知识来解读。
解决思路的萌芽：RAG
2020年，Lewis 等人在 NeurIPS 上提出了检索增强生成（Retrieval-Augmented Generation，RAG）的概念。这个想法很直观：不要仅仅依赖模型的内部知识，而是从外部知识库中检索相关文档，并将它们注入到模型的上下文窗口中。
模型现在可以在回答之前"阅读"最新的文档。
举个例子，当用户问"Python MySQL连接最新最佳实践"时，系统会：
- 从最新的技术博客、官方文档、Stack Overflow 中检索相关内容
- 将这些内容添加到上下文中
- 让模型基于这些最新信息回答问题
这样，模型就拥有了它训练时没有的知识。
从 RAG 到上下文工程
RAG 只是开始。2025年9月，Anthropic 在他们的工程博客上正式提出了"上下文工程"（Context Engineering）。2025年6月25日，Andrej Karpathy 也对此表示认可：“上下文工程是一门精妙的艺术和科学，即用恰到好处的信息填充上下文窗口，让模型能够采取下一步。”
这比单纯的 RAG 更广泛——它包括：
- 知识层（系统提示词、工具定义）
- 记忆层（对话历史、长期记忆）
- 检索层（RAG、向量搜索、知识图谱）
- 生成层（输出约束、思维链指导）
上下文工程涵盖的范围比文档检索更广，它面向的是整个信息环境的设计。
核心认知转变
核心转变在于：从"优化你所说的"转向"优化模型所知道的"。
- Prompt Engineering = 优化指令（静态的）
- Context Engineering = 优化信息环境（动态的）
这就像从优化食谱（如何烹饪）到优化整个厨房环境（食材、工具、流程）的转变。
预告
下一篇将展开上下文工程的四个支柱、RAG 的具体实现，以及如何构建第一个知识库问答机器人。
本文是"AI 工程范式演进"系列的第3部分。系列结构如下：
- AI工程范式的四个发展阶段
- 不同阶段的实践建议
- 从提示到上下文：为什么只说清楚远远不够 ← 当前文章
- 上下文工程的四个支柱
- 工具工程的本质与陷阱
- 循环工程：让AI自我进化