说到与大型语言模型互动，许多人仍停留在“编写提示词”的阶段，绞尽脑汁地想着如何把一句话问得更巧妙。但从单句优化，到构建一套完整的信息架构，这中间其实是一道鲜明的分水岭。今天这篇，就来聊聊这个进阶话题：从“提示词工程”走向“上下文工程”，以及如何系统性地提升AI输出的质量。
核心内容
这篇指南将覆盖三个关键层次：
1. 提示词工程与上下文工程的本质差异——这不仅是术语的更新，更是思维方式的根本转变。
2. 提升AI输出质量的8个实用技巧——都是可以直接上手操作的干货。
3. 工业级大语言模型应用的系统化方法论——看完就知道一个靠谱的AI系统背后，到底需要哪些组件。
一句话核心摘要：“上下文工程”指的是为AI提供成功完成任务所需的所有信息和工具——而不仅仅是一句精心设计的提示词。它是“提示词工程”的演进，体现了一种更宏大、更系统化的方法。
上下文工程技巧：8条拿来就用的建议
想从AI那里获得最佳结果，你得像给新同事交代任务一样，把背景、规则和示例都讲清楚。输出的质量，直接取决于你输入的质量。
那么，具体该怎么做？
- • 力求精确： 模糊的请求只能换来模糊的答案。“写个方案”和“写一份针对初创公司的、500字左右的市场分析方案”，结果天差地别。
- • 提供相关代码： 需要帮忙Debug？把相关的文件、文件夹或代码片段直接丢进去，别让它去猜你那五百行代码里哪段出了毛病。
- • 附上设计文档： 写代码前，把相关的设计文档章节贴进去，让它理解宏观背景，而不是自顾自地写。
- • 分享完整的错误日志： 调试时，别只给一句“它报错了”。完整的错误信息和堆栈跟踪是AI解决问题的关键线索。
- • 展示数据库结构图： 涉及到数据库操作时，一张结构截图能帮它生成更精准、不出错的数据交互代码。
- • 利用PR反馈： Pull Request里的评审意见是富含上下文的绝佳素材，直接拿给AI看，它能更懂你的需求。
- • 给出示例： 榜样的力量是无穷的。直接展示一个你期望的输出样例，比你说一百句“我要那种风格”都管用。
- • 明确你的限制： 必须用哪个库？不能用什么模式？说清楚所有条条框框，它才不会跑偏。
从“提示词工程”到“上下文工程”：一次思维的进化
提示词工程关注的是“怎么问”，而上下文工程关注的是如何构建一个完整的信息环境，让AI能可靠地解决问题。
“提示词工程”这个词火过一阵，核心技巧就是通过遣词造句来获得更好输出。它教会我们用巧妙的“一句话”进行“散文式编程”。但在圈子外，很多人觉得这就是在聊天框里输入花哨的请求。坦白说，这个词从未能真正传达出有效使用大语言模型所需要的复杂性和系统性。
随着应用的深入，仅关注单个提示词的局限性越来越明显。用一句俏皮话来总结就是：提示词工程的探索，其实是在为上下文工程的腾飞铺路。换句话说，一句机智的提示词或许能在演示中惊艳全场，但要构建一个可靠的、工业级的大语言模型系统，则需要更全面的方法论。
正是这种认识，让行业逐渐凝聚在“上下文工程”这个词上。它更准确地描述了从AI获得卓越成果的这门手艺。上下文工程意味着构建大语言模型所能看到的整个上下文窗口——不只是一条简短指令，还包括完成任务所需的所有背景信息、示例和指南。
这个短语在2025年中得到广泛推广，Shopify的CEO Tobi Lütke和AI领域的领军人物Andrej Karpathy都是其积极倡导者。
Tobi写道：“相比提示词工程，我真的更喜欢‘上下文工程’这个词。它更好地描述了核心技能：为任务提供所有上下文，使其能被大语言模型合情理地解决的艺术。” Karpathy对此表示强烈赞同，并指出，在每一个严肃的大语言模型应用中，上下文工程都是一门精巧的艺术和科学，需要在每一步为上下文窗口填充恰到好处的信息。
现实世界中的大语言模型应用，并非靠运气或一次性的提示词成功，而是通过围绕模型的查询精心组装上下文来实现的。
术语的变化反映了方法的演进。如果说提示词工程是想出一句神奇的咒语，那么上下文工程就是为AI编写完整的剧本。这是一种结构性的转变：提示词工程在你精心制作好一个提示词后就结束了，而上下文工程则始于设计整个系统，以便有组织地引入记忆、知识、工具和数据。
正如Karpathy解释的那样，要做好这一点，涉及到方方面面：从清晰的任务指令和解释，到提供少样本示例、检索到的事实（RAG）、可能的多模态数据、相关工具、状态历史，以及将所有这些小心翼翼地压缩到一个有限的窗口中。上下文太少（或类型不对），模型缺乏信息，无法达到最佳性能；无关的上下文太多，则浪费计算资源，甚至降低性能。 找到那个最佳平衡点，确实并非易事。难怪Karpathy称之为一门科学，也是一门艺术。
“上下文工程”这个词之所以流行，就是因为它直观地捕捉到了我们在构建大语言模型解决方案时实际在做的事情。“提示词”听起来像是一个简短的查询，而“上下文”则意味着我们为AI准备的更丰富的信息状态。
撇开语义不谈，为什么这个转变如此重要？因为它标志着AI开发心态的成熟。生产环境中的生成式AI不像念一句魔法咒语，而更像是为AI设计一个完整的工程环境。一次性的提示词或许能做出炫酷的演示，但对于稳健的解决方案，你需要控制模型在每个步骤“知道”什么和“看到”什么。这通常意味着检索相关文档、总结历史记录、注入结构化数据或提供工具。结果就是，我们不再将提示词视为一次性指令，而是开始从上下文管道的角度思考：所有那些为AI成功铺路的信息和交互片段。
图解：多个信息源被组合到大语言模型的上下文窗口中。上下文工程师的目标就是用正确的信息、正确的格式填充该窗口，以便模型能有效地完成任务。
为了说明这一点，来看看视角的差异。提示词工程常常是一场文字游戏，而上下文工程感觉更像是传统的工程学：这个系统需要哪些输入？我如何获取这些输入并提供给系统？以什么格式？在什么时间？我们从从单个提示词中榨取性能，转向设计由大语言模型驱动的系统。
上下文工程究竟是什么？
一句话定义：上下文工程意味着在运行时，动态地为AI提供成功所需的一切——指令、数据、示例、工具和历史记录——所有这些都被打包到模型的输入上下文中。
一个很有用的心智模型（由Andrej Karpathy等人提出），是将大语言模型看作一个CPU，将其上下文窗口看作RAM或工作内存。作为工程师，你的工作就类似于一个操作系统：将恰到好处的代码和数据加载到那个工作内存中，以完成任务。在实践中，这些上下文来自许多来源：用户的查询、系统指令、从数据库或文档中检索到的知识、其他工具的输出，以及先前交互的摘要。
具体来说，它涉及以下几个方面：
- • 它是一个系统，而非一次性提示词。 在一个精心设计的系统中，大语言模型最终看到的提示词由几个部分动态编织而成：开发者编写的角色指令、最新的用户查询、动态获取的相关数据，以及期望输出格式的示例。例如，一个编程助手AI收到查询“如何修复这个身份验证bug？”，系统会自动搜索代码库，检索相关文件片段，然后构建一个包含角色设定、代码片段、错误日志等信息的复杂提示词。上下文工程的核心工作，就是决定引入哪些部分，以及如何将它们连接起来。
- • 它是动态的，因地制宜。 与单个硬编码的提示词不同，上下文的组装是根据每个请求进行的。系统会根据查询或对话状态包含不同的信息。多轮对话中，可能会包含摘要而非完整记录来节省空间；如果用户引用了某个文档，系统就会去检索并包含相关摘录。这种动态性至关重要，它让AI的行为变得像程序一样，能响应输入的状态变化。
- • 它融合多种类型的内容。 一个稳健的大语言模型应用通常需要三种上下文的融合：指令性上下文（我们提供的提示词或指导）、知识性上下文（我们从外部来源检索到的领域事实）、以及工具性上下文（模型通过调用工具或API获得的结果）。上下文工程就是管理所有这些信息流并将它们连贯地合并起来的学科。
- • 格式与清晰度至关重要。 不仅是包含什么，还有如何呈现它。如果你扔给它一堆非结构化的文本，模型可能会困惑。有效的上下文工程通常涉及创造性的信息设计——总结长文本、使用项目符号、明确标注数据来源、格式化错误日志等，让输入对大语言模型来说尽可能易于消化。
最重要的是，上下文工程是为了给AI的成功创造条件。
请记住，大语言模型功能强大但并非通灵。它只能根据其输入内容加上其训练期间学到的知识来作答。如果它失败或产生幻觉，根本原因往往是我们没有给它正确的上下文，或者我们给了它结构混乱的上下文。反之，如果你确实提供了所有相关信息和清晰的指导，模型的性能会显著提高。
提供高质量上下文的实用技巧
那么，如何确保我们正在给AI它所需要的一切？以下是一些在构建AI编程助手和其他大语言模型应用时发现的有用技巧：
- • 包含相关的源代码和数据。 让AI处理代码？给它看实际的代码。让AI回答问题？给它提供相关的论据或文档（通过检索）。低质量的上下文保证了低质量的输出，模型无法回答它没有被告知的事情。
- • 指令要精确。 清晰说明你想要什么。如果答案需要特定格式（JSON、特定风格等），务必说明。如果AI在编写代码，指定约束条件，如使用或避免哪些库。请求中的模糊性会导致答案漫无边际。
- • 提供期望输出的示例。 少样本示例非常强大。想要以特定风格记录函数？在提示词中展示一两个正确的例子。对输出进行建模，有助于大语言模型准确理解你想要什么。
- • 利用外部知识。 如果任务需要超出模型训练范围的领域知识（例如，公司特定的细节、API规范），检索这些信息并将其放入上下文中。当大语言模型能够引用所提供文本中的事实，而不是从记忆中回忆时，它们的准确性会高得多。
- • 在调试时包含错误信息和日志。 要求AI修复bug？给它看完整的错误跟踪或日志片段，这些通常包含了解决问题的关键线索。
- • （聪明地）维护对话历史。 在聊天场景中，反馈对话至今的重要部分。通常你不需要完整的历史记录——一个关键点或决策的简明摘要就足够了，既能提供上下文，又能节省token空间。
- • 不要回避元数据和结构。 有时告诉模型为什么你给它一段上下文会有所帮助。使用标签头，比如“这里是相关的数据库结构图：”，能让模型更好地解析多部分提示词。
记住黄金法则：大语言模型功能强大，但它们不会读心术。 输出的质量与你提供的上下文的质量和相关性成正比。上下文太少，AI就得靠猜；上下文太多或太杂，又会分散注意力。上下文工程师的工作，就是精确地为模型提供它所需要的，而不是它不需要的。
回应质疑者
值得直面的批评是，不少经验丰富的开发者认为“上下文工程”不过是换了层皮的提示词工程。这种担忧不无道理。
传统的提示词工程专注于你给大语言模型的指令。而上下文工程则涵盖了整个信息生态系统：动态数据检索、内存管理、工具编排，以及跨多轮交互的状态维护。当前许多AI工作确实缺乏我们期望于工程学科的那种严谨性。有太多的试错，太少的衡量，以及不充分的系统化方法论。说实话，即使有完美的上下文工程，大语言模型仍然会产生幻觉，犯逻辑错误。上下文工程并非万能灵药——它是在当前约束下的损害控制与优化。
有效上下文的艺术与科学
出色的上下文工程能够达成一种平衡——包含模型真正需要的一切，但避免可能分散其注意力（并增加成本）的无关或过多的细节。
正如Karpathy所描述的，上下文工程是科学与艺术的精妙结合。
“科学”部分涉及遵循某些原则和技术来系统地提高性能。例如，在代码生成中包含相关代码和错误信息是常识；在问答中检索支持性文档是合乎逻辑的。成熟的方法如少样本提示、检索增强生成（RAG）和思维链提示，通过研究和试验证明了其有效性。尊重模型的约束也是门科学——每个模型都有上下文长度限制，过度填充窗口不仅会增加延迟和成本，如果重要部分被噪音淹没，还可能降低质量。
Karpathy总结得很好：“上下文太少或形式不对，大语言模型就没有获得最佳性能的正确环境。太多或太无关，大语言模型的成本可能会上升，性能可能会下降。”
科学在于选择、修剪和优化格式化上下文的技术。例如，使用嵌入来找到最相关的文档（避免插入不相关文本），或者将长历史压缩成摘要。研究人员甚至对长上下文的失败模式进行了分类——比如上下文投毒（前期幻觉导致后续错误）或上下文干扰（过多无关细节导致模型失焦）。
然后是“艺术”的一面——源于经验的直觉和创造力。
这关乎于理解大语言模型的怪癖和微妙行为。一个经验丰富的上下文工程师会对如何为特定模型组织提示词形成一种感觉。例如，你可能发现某个模型在列出解决方案步骤后再深入细节时表现更好，所以你在提示词中加入“让我们一步一步地思考……”。或者你注意到模型经常误解某个特定术语，所以你在上下文中预先澄清它。这些灵感通常来自观察和迭代。这就是提示词制作仍然重要的地方，但现在它服务于更大的上下文系统。
让我们探讨一些上下文工程师常用的策略和模式：
- • 检索相关知识： 最强大的技术之一。如果模型需要其训练记忆中不存在的领域特定数据，让你的系统获取这些信息并将其包含进来。设计好的搜索查询或嵌入空间以获取正确的片段，并清晰地格式化插入的文本（带有引文或引号），让模型知道要使用它。
- • 少样本示例和角色指令： 这是经典技巧。希望模型以特定风格输出？给它看例子。设置一个系统角色或人设可以引导语气和行为。这些技巧之所以是基本功，是因为它们有效。在上下文工程的思维模式下，提示词的措辞和示例只是上下文的一部分，但仍然至关重要。
- • 管理状态和记忆： 许多应用涉及多轮交互。常见技术是摘要压缩——每几次交互后，对其进行总结，使用该摘要继续。另一种策略是将重要事实写入外部存储，然后在需要时检索。这里的关键在于弄清楚保留什么、何时总结，以及如何在正确的时机重新呈现过去的信息。
- • 工具使用和环境上下文： 现代AI智能体可以使用工具，每个工具的输出都成为新的上下文。上下文工程意味着指导模型何时以及如何使用工具，然后将结果反馈回来。关键在于，你作为工程师，编排了模型与外部世界之间的这种对话。
- • 信息格式化和打包： 你通常拥有的信息比能容纳的要多。所以要学会压缩或格式化它。例如，与其丢给它一个庞大的JSON，不如提取关键字段并清晰呈现。简而言之，像用户体验设计师一样思考，但你的“用户”是大语言模型——为它的消费设计提示词。
这些技术的影响是巨大的。当你看到一个令人印象深刻的大语言模型演示解决复杂任务时，可以确信，幕后不仅仅是一个聪明的提示词，而是一个上下文组装的管道在支持它。
例如，一个AI结对程序员可能会实现这样的工作流程：
- 搜索相关代码
- 将代码片段与用户请求一起打包
- 如果模型提出修复方案，在后台运行测试
- 测试失败？将失败输出反馈给模型，让其改进方案
- 循环直到测试通过。
每一步都有精心设计的上下文，与“只提示大语言模型修复我的bug”的策略相去甚远。
上下文腐烂的挑战
随着我们越来越擅长组装丰富的上下文，一个新问题出现了：随着时间的推移，上下文实际上会自我毒化。这种现象被恰当地称为“上下文腐烂”，它描述了随着对话变长，上下文质量因积累了干扰、死胡同和低质量信息而下降的过程。
为什么会发生这种情况？上下文窗口是模型的工作内存。当这个内存被失败的尝试、矛盾的信息或离题的讨论弄得乱七八糟时，就像试图在一张堆满旧草稿和无关文件的桌子上工作。模型很难辨别什么是当前相关的，什么是历史噪音。对话中早期的错误可能会累积，形成一个反馈循环。
这在迭代性工作流程中尤其成问题，比如调试、代码重构或研究项目。每一次失败的尝试都会在上下文中留下痕迹，干扰后续的推理。
管理上下文腐烂的实用策略包括：
- • 上下文修剪与刷新： 定期对实例进行总结，然后用新的上下文启动一个新实例，并输入前一个实例的摘要。这相当于为上下文做垃圾回收。
- • 结构化的上下文边界： 使用清晰的标记来分隔不同的工作阶段，例如，明确将某些部分标记为“先前尝试（仅供参考）”与“当前工作上下文”。
- • 渐进式上下文精炼： 在取得重大进展后，有意识地从头开始重建上下文，只提取关键决策、成功方法和当前状态。
- • 检查点摘要： 定期让模型总结已完成的工作和当前状态，并在开始新会话时以此作为新上下文的种子。
- • 上下文分窗： 将非常长的任务分解为具有自然边界的阶段，每个阶段都以一个干净的开始，只带有前一阶段的基本延续信息。
这个挑战也凸显了为什么“把所有东西都扔进上下文”不是一个可行的长期策略。就像好的软件架构一样，好的上下文工程需要有意识的信息管理——不仅要决定包含什么，还要决定何时排除、总结或刷新。
上下文工程在大语言模型应用全局中的位置
上下文工程至关重要，但它只是构建完整大语言模型应用所需更大技术栈中的一个组件——与控制流、模型编排、工具集成和护栏等并存。
用Karpathy的话来说，上下文工程是“一个正在兴起的、非同小可的厚重软件层中的一小部分”。一个生产级的大语言模型系统通常需要处理许多提示之外的问题：
- • 问题分解和控制流： 稳健的系统不是将用户查询视为一个单一的庞大提示词，而是将问题分解为子任务或多步工作流。设计这个流程是一个经典的编程任务。
- • 模型选择和路由： 为不同的工作使用不同的AI模型，系统需要逻辑来将请求路由到适当的模型，每个模型可能有不同的上下文长度限制。
- • 工具集成和外部操作： 管理AI可以执行的操作（如调用API、运行代码），包括提供工具列表和使用说明，并执行工具调用。这通常需要一个提示-执行-整合-再提示的循环。
- • 用户交互和用户体验流程： 需要将用户的反馈（如“选项2不错，但再短一点”）带入下一轮的提示词中。
- • 护栏和安全： 内容过滤器、权限检查、输出验证等，这些通常会在上下文中添加额外的指令。
- • 评估和监控： 记录每个请求和响应，分析失败和异常值，并据此改进提示词和上下文策略。
我们现在谈论的是一种新型的应用架构。在这种架构中，核心逻辑涉及管理信息（上下文）并通过一系列AI交互来适应它。Karpathy列出的控制流、模型调度、内存管理、工具使用、验证步骤等元素，共同构成了他戏称为“一个正在兴起的厚重软件层”。当我们构建这些系统时，本质上是在编写元程序：编排另一个“程序”（AI的输出）来解决任务的程序。
对于软件工程师来说，这既令人兴奋又充满挑战。在这种背景下，上下文工程位于系统的核心：如果你不能在正确的时间将正确的信息输入模型，其他任何东西都救不了你的应用。
结论是，我们正在从提示词设计转向系统设计。上下文工程是该系统设计的核心部分，但它与许多其他组件并存。
结论
核心要点： 通过掌握完整上下文的组装（并将其与扎实的测试相结合），我们可以最大化从AI模型获得最佳输出的机会。
对于经验丰富的工程师来说，这种范式的核心在很多方面都很熟悉——它关乎于良好的软件实践，只是应用在一个新的领域：
- • 我们一直知道垃圾进，垃圾出。现在这个原则体现为“坏上下文进，坏答案出”。
- • 我们在代码中重视模块化和抽象。现在我们将任务抽象到高层次，构建AI+工具的模块化管道。
- • 我们在传统开发中实践测试和迭代。现在我们将同样的严谨性应用于AI行为，编写评估并改进提示词。
在拥抱上下文工程时，你实际上是在说：我为AI的行为负责。它不是一个神秘的预言家，而是我需要用正确的数据和规则来配置和驱动的一个组件。
这种心态的转变是赋能的。它意味着我们不必将AI视为不可预测的魔法——我们可以用扎实的工程技术（加上一点创造性的提示词艺术）来驯服它。
那么，如何在实际工作中采纳这种以上下文为中心的方法？
- • 投资于数据和知识管道。 构建文档的向量搜索索引，设置数据库查询。知识源是开发中的一等公民。
- • 开发提示词模板和库。 创建结构化的模板，保存在版本控制中，并与团队共享迭代。
- • 使用能给你控制权的工具和框架。 选择能让你深入了解并调整事物的框架。
- • 监控和检测一切。 记录输入和输出，使用可观察性工具来追踪每个请求的上下文是如何构建的。
- • 让用户参与其中。 设计用户体验，让AI能提出澄清问题，用户能提供额外细节来完善上下文。
- • 培训你的团队（和你自己）。 使上下文工程成为一个共享的纪律，在代码审查中也审查提示词和上下文逻辑。
随着我们前进，上下文工程将成为第二天性——就像今天编写API调用或SQL查询一样。几年后，“你把上下文设置好了吗？”将成为和“你处理好那个API响应了吗？”一样常见的代码审查问题。
在拥抱这一新范式时，我们并非抛弃旧的工程原则——我们是以新的方式重新应用它们。AI并没有让这些技能过时，它放大了它们在指导AI中的重要性。软件工程师的角色正在演变，我们正在成为AI的导演和编辑，而上下文工程就是我们有效指导AI的技术。
开始从你提供给模型的信息的角度思考，而不仅仅是你问什么问题。 去实验它，迭代它，并分享你的发现。那些懂得如何喂养AI的人，将永远拥有优势。