指出 Prompt 工程有限,AI 系统真正需要的是上下文工程——控制模型何时看见什么、知道什么、能做什么,包含对话历史、文档检索、工具输出、业务规则等完整工作环境。
可信赖的 AI 系统,靠的是控制模型看到什么、何时看到、以及接下来能做什么。
大多数人都试图通过把 Prompt 写得更长来提升 AI 效果。
这招管用——直到某一天不管用。
即便 Prompt 写得再漂亮,模型仍可能给出很弱的回答,因为 Prompt 只是模型实际所见的其中一部分。更大的系统还包含对话历史、示例、检索到的文档、工具输出、记忆、业务规则,以及任务的当前状态。
这整套工作环境,就是上下文(Context)。
而学会设计它,正在变得比再学一堆 Prompt 技巧更重要。
Prompt 工程问的是:"我该说什么?"
上下文工程问的是一个更根本的问题:
"AI 现在应该知道什么?"
想象一下,你对 AI 助手说:
"回复这位客户,帮他们预约一个时间。"
这条指令很清晰,但仅凭它还不足以可靠地执行。
助手可能还需要:
这些细节没有让原句变得更优雅。
它们让系统变得更强大。
这就是差别所在。
一个常见误区是把 AI 的上下文窗口当成储物柜:只要觉得某条信息可能有用,就往里塞。
但无关信息会与相关信息竞争。
如果你把一本 70 页的说明书塞进每次请求,模型确实有了更多数据——但也有了更多需要筛选的噪音。
更好的做法通常是:只提供当前决策所需的最少信息量,等任务真正需要时再获取更多。
不要把"你知道的全部"都给 AI,而是给"下一步有用的那部分"。
这一点对 Agent 尤为重要,因为 Agent 会在多个动作之间运作。
它们可能搜索、调用工具、读取结果、更新状态、做下一个决策、然后继续。
在第一步有用的上下文,到第六步可能已经无关紧要了。
因此,可信赖的系统需要能够随任务变化的上下文。
这里有一个适用于几乎所有 AI 工作流的实用结构。
"调研这家公司。"
"判断这家公司是否符合我们的理想客户画像,并返回支撑决策(是否联系它)的必要证据。"
第二个版本给了模型一个需要优化的决策目标。
提供做出该决策所需的信息——而避免无关材料。
对于潜在客户调研,可能需要:公司网站、地点、服务、决策者数据,以及之前的 CRM 状态。
对于客服场景,可能需要:当前的工单、账户状态、产品文档,以及最近的交互记录。
上下文应该跟随任务。
一个能访问邮件日历 CRM 和网络搜索的助手,与一个只能生成文字的聊天机器人,是完全不同的存在。
好的工具上下文包括:
这能防止模型把所有问题都当成写作练习来处理。
AI 不应该反复重新发现相同的事实、不应该两次联系同一个人、不应该忘记客户已经拒绝过。
有用的记忆不是"记住所有事"。
有用的记忆是结构化的状态:
这让下一轮对话更小、更清晰。
系统应该知道如何判断自己是否成功了。
"在日历返回确认的预约 ID 之前,不要标记任务完成。"
"如果两个独立来源无法验证该声明,标记为未验证,而不是猜测。"
"发送外部消息之前停下来请求审批。"
没有验证,AI 可能产生听起来完整、但实际未完成任务的结果。
假设你希望 AI 为一个新的 AI 功能创建一条社交帖子。
"创建一条关于这次更新的 LinkedIn 帖子,要吸引人。"
这可能产生不错的文案。
一个经过上下文工程设计的版本,还会提供:
Prompt 本身可能依然很短。
上下文承担了真正的工作。
一个 Agent 有价值,不是因为它的系统 Prompt 最长。
它的价值在于:能反复获取正确的信息、使用正确的工具、观察结果、更新状态、选择下一个动作。
这就是为什么复杂的 AI 系统往往从检索、记忆、工具、检查点和评估中受益——而不只是更多的指令。
还有另一个重要的教训:
不是每个任务都需要 Agent。
如果一个 Prompt 能可靠地解决问题,就用一个 Prompt。
如果一个可预测的步骤序列能解决问题,就用工作流。
只有当路径本身需要根据一路上发生的情况来调整时,才使用 Agent。
复杂性应该靠实力挣得它的位置。
在花十分钟重写 Prompt 之前,先问自己:
"模型当前的上下文里缺少什么信息?"
然后检查五件事:
如果这五点都对,一个出人意料地简单的 Prompt 可以表现得极其出色。
如果这五点错了,一个看起来很厉害的 Prompt 仍然可能失败。
Prompt 工程不会消失。
清晰的指令依然重要。
但下一层是更广阔的。
真正的技能是围绕模型设计环境:什么进入、什么排除在外、什么可以检索、什么被记住、有哪些工具可用、以及如何检查成功。
Prompt 告诉 AI 你想要什么。
上下文给它一个真正做好的公平机会。
这才是更多 AI 用户应该学会填补的差距。
问题:最近提升你 AI 效果最多的是什么——重写 Prompt、添加更好的上下文、还是给 AI 更好的工具?