从提示工程到上下文工程：大模型应用开发新范式

1. 从提示工程到上下文工程的演进

在AI开发领域，我们正经历着一次重要的范式转变。早期开发者最关注的是如何编写有效的提示词（Prompt Engineering），但随着大模型应用场景的复杂化，单纯优化提示词已经无法满足需求。这就好比在图书馆里，我们不仅需要知道如何向图书管理员提问（提示工程），更需要懂得如何管理整个图书馆的藏书系统（上下文工程）。

1.1 为什么上下文如此重要

想象一下这样的场景：你让AI助手帮你重构一个大型代码库。开始时它表现得很好，但进行到第三步时突然"失忆"了——要么忘记之前的修改，要么把完全不相关的代码混在一起。这不是模型变笨了，而是上下文管理出了问题。

在多轮交互的复杂任务中，上下文就像AI的工作记忆区。每次交互都会产生三类关键信息：

• 工具调用参数（调用什么工具、传递什么参数）
• 工具返回结果（代码片段、错误日志等）
• 模型的中间推理过程

这些信息会不断累积。根据Anthropic的数据，Claude Code处理复杂任务时平均要进行50次工具调用，这意味着上下文可能膨胀到数万token。

1.2 上下文窗口的挑战

你可能会问：现在模型的上下文窗口不是已经扩展到百万token了吗？问题在于，随着上下文变长，模型性能会显著下降。这不是容量问题，而是注意力稀释效应——关键信息被大量噪声淹没。

这种现象在"needle in a haystack"基准测试中得到验证：随着token数量增加，模型召回关键细节的准确率持续下降，研究人员称之为上下文衰减（context rot）。大模型就像人一样，能同时处理的信息量是有限的，每个新token都在消耗这个有限的注意力预算。

2. 提示工程与上下文工程的区别

2.1 关注点的根本差异

提示工程和上下文工程不是替代关系，而是互补演进。提示工程关注"如何表达"——怎样组织语言、设计指令、使用few-shot示例。它的核心问题是："用什么词能让模型理解我的意图？"

上下文工程则关注"提供什么信息"——系统指令、工具定义、外部数据、消息历史等。它的核心问题是："什么样的信息环境最能引导模型产生期望行为？"

2.2 工作模式的对比

这两者的差异体现在多个维度：

| 维度 | 提示工程