直接分享点实在的。上下文工程这词这两年被提得越来越多很多人把它和提示词工程混在一起其实两者压根不是一回事。如果说提示词工程是教你怎么跟AI说第一句话那上下文工程就是教你怎么管理AI在这一整段对话里看过的所有信息。我刚接触大模型开发那会儿最头疼的就是AI聊着聊着就跑偏前面说过的事后面全忘了后来系统研究了一段时间上下文工程才彻底搞明白问题出在哪今天把这些经验整理出来希望对你有用。1. 上下文工程到底在解决什么问题1.1 一个例子先说清楚为什么AI经常“答非所问”想象一下你有个新来的实习生你给他布置任务只说了一句“帮我写个方案”他大概率写出一堆泛泛而谈的东西因为他不了解你的项目背景、目标用户、预算限制、公司风格。大模型也一样它见过海量公开文本每次对话都是冷启动你如果不把该交代的东西交代清楚它就按训练数据里的“平均情况”来应对你。我有个朋友让AI帮他改写一封商务邮件结果AI直接把语气写得跟客服机器人一样满屏“您好、亲”。问题出在哪他没告诉AI这是给长期合作的老客户写的、双方已经很熟了、不用过分客套。这其实就是上下文没搭建好。上下文工程的核心任务就是把“该交代的信息”在合适的位置、用合适的形式交给AI让它从一次冷启动的通用生成变成贴合你这个具体场景的定向生成。1.2 上下文工程 vs 提示词工程别搞混很多人觉得上下文工程是提示词工程的高级版这个理解不太准确。提示词工程关注的是单次请求如何编写得更清晰、更具体比如用“请用三步法分析”这种结构化的指令而上下文工程关注的是整个会话中哪些信息应该长期存在、哪些临时出现、哪些该被丢弃以及这些信息如何影响AI的每一次回复。我用个类比来解释提示词工程像是给厨师写一张点菜单告诉他今天要做什么菜、口味偏咸还是偏淡上下文工程则像是给厨师一份完整的后厨工作手册里面写了餐厅的定位、常客的口味偏好、今天采购到了哪些食材、哪些菜已经卖完了。做AI产品的人应该深有体会单次提示词写得再好对话一长AI还是会出问题因为上下文管理没跟上。反之上下文搭得好有时候哪怕提示词写得简单点AI的表现也会稳定得多。1.3 大模型的“记忆”到底长什么样理解上下文工程首先要搞清楚大模型是怎么“记东西”的。技术上说它在每次回复前会把自己能看到的全部文本——系统指令、历史聊天记录、你新输入的问题、可能需要的外部资料——打包成一个序列这个序列里所有内容都会被模型一起处理限制就是这个序列有最大长度也就是“上下文窗口”。这个窗口不是无限大的有的模型是几万字符有的是十几万字符但再大也有上限。你以为AI记得你说过的话其实是它把你说过的话都堆在这个窗口里重新读了一遍。这个特性决定了上下文工程的几个核心约束窗口有限你得挑最有价值的内容往里放。塞太满模型会“走神”反而抓不住重点。所有内容平等地被模型看到你没法手动标“这句话更重要”只能靠位置和措辞来引导注意力。理解了这一点后面很多操作你就能自己推导出答案了。2. 上下文工程的四个核心模块2.1 系统指令给AI定人设和边界系统指令是上下文里最顶层的那段话相当于这个会话的“宪法”。它不需要每轮重复但从第一轮开始就一直在模型“脑”里影响每一轮输出。系统指令建议包含四类信息信息类型要写什么举例角色定位AI在这个对话里是谁“你是拥有十年经验的产品经理”任务边界哪些做、哪些不做“只讨论产品方案不做代码实现”行为规则回复的风格、格式、禁忌“每次回答先给结论再用三点展开”输出标准最终交付物的规格“输出markdown格式包含背景、方案、风险”我踩过的坑是系统指令写得又长又空全是“你是一个优秀的AI助手请帮助用户解决各种问题”这种废话。真正的系统指令应该是约束越多越具体越能限制输出。比如我自己写文案的时候系统指令里会写“禁止使用感叹号禁止使用“赋能”这类词每段不超过50字”效果立竿见影。2.2 背景材料让AI有据可依第二个模块是背景材料也就是你希望AI在对话题里默认具备的知识。比如你在做一个法律问答机器人系统指令下面是隐私政策、产品说明文档、常见问题清单这些都是背景材料。背景材料有几个放置策略。第一相关内容放在历史对话前面替代一部分你们来回聊天的内容节省空间。第二把高频信息前置把低频信息后置因为模型对开头和结尾的内容记忆更深。第三背景材料本身要控制篇幅尽量精炼成摘要而不是整篇文档塞进去。我习惯每周维护一个背景文档每次做任务前从里面挑出跟当前任务相关的段落塞进去而不是一把梭全扔给模型效果和成本都更可控。2.3 示例示范用例子框住输出风格给AI看两三个高质量例子比反复叮嘱它“写得好一点”有用得多。如果你想让AI写某种风格的产品文案与其写一百遍“请写得专业一点”不如直接给它两个你认可的范文让它照着这个调性来写。示例在上下文中起到的作用是“潜规则”级别的。模型不只是模仿你的例子它还会从例子里反向推断你的审美偏好、篇幅习惯、甚至语气习惯。所以我给示例的时候刻意选了风格差异比较大的几个这样模型更容易抓住“共同点”而不是被某一个例子带偏。一个实用技巧示例不只是给输出格式最好也包含输入输出的配对。也就是说你给它看“用户问了什么模型应该答什么”这样模型能学到对应关系而不仅仅是格式。2.4 对话历史的取舍不是越长越好很多人有个误区觉得把全部历史对话都保留下来AI就更懂你。事实是对话超过一定长度后早期信息对模型的影响会衰减而这个衰减过程无论是处理速度还是费用都在增加。大部分情况下你不需要保留所有轮次。我实际用的是三条规则用户最新诉求之前的内容只保留总结不保留原文。最新几轮完整保留因为模型对尾部内容最敏感。涉及确定状态的信息比如用户已经确认过的偏好额外提取出来放到上下文开头。这个“总结近期完整关键信息前置”的组合几乎可以解决90%的上下文膨胀问题。3. 实操三种常见场景下的上下文搭建方案3.1 场景一让AI稳定帮你写公众号文章这个场景里我的上下文结构长这样系统指令你是一名资深自媒体编辑擅长写通俗易懂、观点鲜明的文章。文章结构包含“问题引入—分析原因—给方案—总结思考”每段不超过200字禁止使用“赋能、抓手”等空词。背景材料这个公众号的读者画像——互联网从业者25-35岁对效率工具敏感喜欢干货讨厌营销味。对话历史上一轮我们确定了选题“为什么你总在加班”。当前输入根据以上信息写一篇1200字的初稿包含至少3个案例。这套结构搭完之后AI输出稳定多了不再每篇都像那种堆砌形容词的“营销爆款文”。关键是背景材料里写的读者画像起了作用AI自动调整了例子选择的风格。3.2 场景二用它解释和排查代码报错开发场景跟写作场景不太一样代码问题的上下文更偏碎片化而且更新频率很快。我处理报错时上下文结构是这样的系统指令你是资深后端工程师回答时先复述你理解的报错场景再给出排查步骤最后给出修复建议并说明每步的原因。背景材料项目技术栈清单、框架版本、当前分支的近期改动文件列表。对话历史过去三次报错与解决方案的摘要。当前输入粘贴完整报错堆栈信息和相关代码片段。有人可能会想直接把报错信息扔进去不就行了为什么还要背景材料因为很多报错产生的原因是版本不匹配、依赖冲突这类上下文信息。把技术栈和版本号提前放好AI的排查方向会准很多至少不会动不动就让你重装依赖。3.3 场景三把AI当数据分析助手用这个场景是信息密度最高的因为数据本身的上下文就很大。我一般会分两步走第一步先把原始数据的关键指标摘要给AI看让它判断大概情况第二步把需要详细分析的行数据或模块切片补齐。摘要放在前面相当于先让AI建立一个整体框架再给它细节它就容易抓住重点。反过来你一上来把一万行CSV全塞进去它反而会迷失在细节里给你输出一些毫无关联的观察。如果你遇到的是那种上下文窗口特别大的模型觉得塞全量数据也没问题我也建议至少先做一次字段说明的梳理——把每一列的含义、单位、口径写清楚放在数据前面这会直接影响分析质量。4. 常见问题与排查技巧实录4.1 问题一AI聊着聊着就“失忆”了症状是前面说过自己是某公司的HR过二十轮后又开始回答不知道你是什么行业了。原因一般是两个一是历史过长早期信息衰减得厉害二是你中途输入了太多无关的闲聊内容把关键信息“挤”出去了。排查建议优先检查系统指令里是不是有角色设定如果没有先补上。检查对话历史是否已经很长需要用摘要替换前段内容。如果是产品类场景考虑把“用户关键属性”单独提取出来放上下文开头每次动态更新。4.2 问题二上下文越长回答越敷衍这其实是所有大模型都存在的现象跟上下文窗口大小无关。窗口大只是能放更多数据不代表放进去的数据都有效。内容太多了之后模型很难把握哪些对你更重要回答就趋于平淡。我的处理方式是做信息分级把直接影响本次回答的内容当前任务、引用材料放尾部把影响全局的内容角色、边界、偏好放头部把相关性不高的“背景知识”能省就省。如果背景知识确实有用就压缩成要点摘要别让原文整段堆进去。4.3 问题三AI在输出里编造了背景材料中没有的内容这种问题出现大多是你没有给AI显式的“未知信号”。比如你问它某个数据它没有就开始编。对抗这个问题的办法是在系统指令里明确写一条规则“如果材料中不存在的信息明确回答信息不足不要推测。”这招实测特别管用。你只要给了它这个出口它就不会硬撑编造了。另外如果背景材料的来源很多且格式杂乱可以在每段材料前都加上“材料来源”标记它更容易辨别哪些是事实哪些是推测。我把这些方法稳定用起来之后最大的感受是上下文工程不是让你做一个无所不能的大容器反而是让你做一个精明的筛选器。我自己现在写各种提示词模板都遵循同一个习惯先问清楚这个任务需要哪些背景、要用什么标准输出、哪些案例可以当参考再组织上下文。这个习惯相当于固定下来之后设计一次新的人机交互流程时效率会高很多。如果有机会下一篇我可以展开讲讲最近遇到的一个复杂项目——怎么用检索增强给背景材料做动态筛选那种场景才真正把上下文工程玩出了花。