从提示到上下文：为什么只说清楚远远不够
一个让人沮丧的场景
想象这个场景：你正在编写一个关于"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自我进化