Everything You Need to Know About Context Engineering in 40 Minutes | Ravi Mehta

别再只盯着提示词了，真正决定AI产品好坏的是上下文工程——系统性地设计模型看到的所有信息，这才是从“能用”到“好用”的分水岭。

这期内容适合所有正在或即将构建AI产品的工程师、产品经理和技术负责人。它值得花时间看，因为大多数团队把精力浪费在调提示词上，却忽略了决定模型输出质量的真正关键——上下文。最值得注意的洞见是：上下文工程不是玄学，而是一套可复用的工程方法论，它把“模型看到什么”这件事从艺术变成了可设计、可测试、可迭代的系统。

Ravi Mehta 把“上下文工程”定义为一种系统性的工程实践，核心是设计AI模型在生成回答之前所看到的一切信息，而不仅仅是提示词本身。他把上下文拆解成一个完整的堆栈：系统指令、用户状态、对话历史、检索知识、工具输出、示例、数据结构和记忆。然后，他详细展示了产品团队应该如何决定哪些信息该放进上下文、哪些该排除，以及如何动态组装、预算Token、评估效果。整期内容的核心是：更好的AI产品，来自于用过去设计数据模型、API和用户体验流程的严谨态度，来设计整个上下文管道。

1. 上下文工程比提示工程更重要。提示词只是上下文的一部分，真正决定模型行为的是它看到的全部信息——包括历史对话、用户状态、检索结果等。团队应该把更多精力放在设计“模型看到什么”上，而不是反复调提示词。
2. 上下文不是越多越好。把尽可能多的信息塞进上下文是常见错误。过多的无关信息会稀释注意力、浪费Token、增加延迟，甚至导致模型“迷失”在噪声中。好的上下文设计是“够用就好”，而不是“越多越好”。
3. 上下文需要动态组装。不同场景、不同用户、不同时间点，模型需要看到的信息是不同的。上下文不应该是一个静态模板，而应该根据当前请求动态构建，比如只加载最近3轮对话、只检索与当前问题最相关的5条知识。
4. 记忆管理是上下文工程的核心挑战。长期记忆（如用户偏好、历史行为）如果直接塞进上下文，会迅速耗尽Token预算。正确的做法是：对记忆进行摘要、分层存储（短期/长期）、按需加载，并且定期清理过时或冲突的记忆。
5. 检索质量决定上下文质量。如果RAG（检索增强生成）的检索结果不准确，上下文就会充满噪声。团队需要投入精力优化检索策略（如混合搜索、重排序），而不是只关注模型本身。
6. 结构化输出是上下文工程的一部分。通过定义输出格式（如JSON Schema），可以显著提升模型输出的可靠性和可解析性。这相当于给模型一个“答题模板”，减少自由发挥带来的不确定性。
7. 上下文工程需要评估循环。不能凭感觉判断上下文设计的好坏。团队应该建立评估指标（如回答准确率、Token浪费率、用户满意度），通过A/B测试和迭代来优化上下文策略。

上下文不是提示词的附属品，它是AI产品的数据模型——设计它的严谨程度，决定了产品能力的上限。

这对AI从业者最直接的启发是：把上下文当成产品的基础设施来设计，而不是事后补救。

具体来说，可以立刻做三件事：

1. 建立上下文清单。列出你的AI产品中，模型每次调用能看到的所有信息源（系统指令、用户资料、历史记录、检索结果等），然后逐一评估：这个信息源是必须的吗？它占用了多少Token？它会不会引入噪声？
2. 设计上下文预算。给每个信息源分配Token上限，比如系统指令占500 Token、用户状态占200 Token、历史摘要占1000 Token。超出预算的部分必须压缩或丢弃。这能倒逼团队做更精细的设计。
3. 引入上下文测试。在开发流程中加入“上下文质量测试”，比如：当检索结果不准确时，模型是否会忽略它？当记忆过时时，模型是否会纠正？当Token预算不足时，模型是否会优先使用最重要的信息？

对于正在做AI Agent或复杂对话系统的团队，上下文工程是比模型选型更紧迫的工程问题。一个中等水平的模型配上精心设计的上下文，往往比一个顶尖模型配上混乱的上下文表现更好。