聊到大模型很多人都会遇到一个让人头疼的场景刚开聊的时候模型还挺聪明聊到第三轮、第五轮它就开始前言不搭后语甚至把你前面交代过的重要条件忘得一干二净。又或者你明明把所有参考资料都贴进了对话框结果它还是对着错误的信息侃侃而谈。这十有八九不是模型变笨了而是你的上下文没有做好。上下文工程这个词听起来很专业但它本质上就是教你把话说清楚、把料备齐全的一套方法。它不是让你去写代码也不是让你去训练模型而是让你掌握跟大模型打交道的底层逻辑知道什么时候该说什么、先说什么后说什么、什么能放进上下文、什么必须省掉。这篇就围绕上下文工程展开讲清楚它到底解决什么问题、核心要素有哪些、实操怎么落地也会把常见坑位和排查思路一并整理出来希望能成为一份随时能翻出来的收藏级攻略。1. 为什么上下文工程是玩转大模型的第一步1.1 从一次失败的对话说起想象一个非常常见的场景你想让模型帮你写一份产品推广文案。你会怎么做大概率是直接发一句帮我写一份推广文案。模型确实会给你一份文案但大概率是那种放在哪个行业都能用、放到哪个产品上都行的通用模板。接下来你会补充说我们是一款面向年轻人的咖啡品牌主打冷萃工艺模型会重新输出一版加入了冷萃、年轻人这些词。然后你又想起要说价格偏高主打品质它又改一版。你再来一句不要用感叹号语气要克制它再改一轮。一轮又一轮地追加指令模型每次都能理解你最新的那条指令但它对整体目标、品牌调性、目标人群的把握是分散的、不稳定的。它只能基于当前这一轮对话加有限的记忆去猜测你的完整意图。这就是典型的上下文组织方式有问题——你在用对话轮次当上下文而不是用结构化信息当上下文。上下文工程解决的问题恰恰就在这里。它要求你在跟模型交流之前先把模型的工作背景准备好你是谁、要做什么、给谁看、有什么限制、参考什么资料、输出成什么样子。这些信息一次性、清晰地放进上下文里模型从一开始就站在正确的人设和任务框架内工作而不是靠你后续一遍遍打补丁。1.2 上下文工程和提示词工程到底有什么区别很多人会把上下文工程和提示词工程混为一谈其实它们有交集但不完全是一回事。提示词工程更关注单条指令怎么写比如怎么措辞、怎么加例子、怎么让模型一步步思考。它的颗粒度在一轮对话核心是让模型听懂你这一次提问。上下文工程则关注整段对话的全局信息布局颗粒度在一个会话。它要考虑的问题包括系统指令放在哪里、怎么写才能稳定约束模型行为参考资料以什么顺序、什么格式嵌入才能让模型准确调用示例放几个、放在什么位置才能让模型模仿输出格式多轮对话进行到一半时历史记录是保留原文还是压缩成摘要上下文窗口有限哪些信息优先级最高、哪些必须牺牲打个不恰当的比方提示词工程是教你怎么向一个临时员工派活上下文工程是教你怎么给一名正式员工做入职培训。前者解决这一单怎么干后者解决这个人在整个任职期间怎么一直干对。对于小白来说先搞懂上下文工程再回头去抠提示词技巧会顺很多。因为很多提示词技巧之所以失效不是措辞不对而是上下文环境没搭好。1.3 上下文好坏的差距有多大我用同一个模型、同样的任务做过对比测试任务很简单从一段产品介绍中提取三个关键卖点并按照指定格式输出。第一次我直接贴了一段产品介绍然后在后面加了一句提取三个关键卖点。结果模型提取出来的卖点确实有三个但格式是它自己临场发挥的有加粗、有列表符号、有总结语跟我要的1. 卖点名称一句话说明这种格式完全不沾边。第二次我先在上下文里交代了任务背景给出了一个输出示例明确说了严格参考示例格式不要额外解释然后才贴产品介绍。这一次模型输出的格式完全正确内容也没有跑偏。同一时刻、同一个模型只是上下文的组织方式不同输出质量差距就非常明显。这也是为什么我说上下文工程是玩转大模型的第一步——它不需要你懂技术原理只需要你掌握信息组织的方法就能立刻看到效果。2. 上下文的核心构件你的入职培训应该包含什么2.1 系统指令是人设与行为准则上下文工程里最重要的一块是系统指令。你可以把它理解为模型的岗位说明书。它定义了模型在整段对话中以什么身份出现、遵守哪些规则、优先完成什么目标。好的系统指令往往包含四个信息点角色定位你是谁。比如你是一名资深的中文编辑或你是一个帮助用户做决策的分析助手任务背景你现在要处理的是一批什么样的工作。行为规则对话过程中必须遵守的边界。比如只基于我提供的资料回答不要擅自补充外部信息如果信息不足明确告诉我缺什么输出偏好大方向的格式或语气要求。我见过很多人把系统指令写成一长串说教什么你是一个乐于助人的助手请始终礼貌、专业、准确之类这种话不是没用而是太笼统。真正起作用的系统指令是具体到见到什么情况做什么动作的那种。举例来说假设我要让模型帮我审校一篇文章我会把系统指令写成你是一名资深中文编辑。我会给你文章全文。你的任务是找出逻辑不通、事实性错误、语句冗长的段落。对每个问题按原文引用 - 问题类型 - 修改建议三段式输出。如果没有问题就直接回复无问题不要输出任何多余内容。对比请帮我审校下面的文章并给出修改意见前者在上下文层面就把人设、任务、规则、输出格式全部锁死了模型几乎不需要猜你要什么。2.2 用户指令是任务下达窗口用户指令是你每一轮真正要模型干的事也是上下文里最灵活的部分。它的作用不是重复系统指令而是把当前这一轮要做的事具体化。常见的问题是很多人把用户指令写得像聊天。比如那接下来你看看这个吧然后附一个文件。这种指令不是不行但对模型来说信息太少了。更好的做法是明确动作、明确对象、明确产出物。我自己的习惯格式是请对以下文档执行[具体操作]。要求[具体要求1]。[具体要求2]。文档内容如下--- [文档] ---这样模型能清楚地区分指令部分和材料部分不会把文档的内容也当成指令去执行。这里有个容易被忽略的点如果你把材料直接贴在指令前面模型可能会把材料末尾的某些句子误判为指令。用分隔符把指令和材料隔开能显著降低这种误判。2.3 参考资料要按可检索的标准嵌入当你需要模型基于外部资料回答问题时参考资料怎么放进上下文是一个非常讲究的环节。先说最经典的坑直接把一份两万字的行业报告粘贴进去然后问这份报告里提到了哪三个趋势模型确实能读但如果报告里相关内容分散在不同章节模型提取时容易遗漏、也会加入自己的联想。更稳妥的方式是提前把参考资料做裁剪。能切成段落就切成段落能提取要点就提取要点。如果你是在用支持文件上传的模型直接传文件当然方便但如果上下文窗口紧张或你希望模型聚焦手工整理参考资料仍然更可靠。整理资料时遵循一个原则让模型尽量少翻找直接给答案。换句话说与其把整份报告给模型让它自己找不如你先把报告里跟任务有关的部分摘出来再让模型基于摘录内容作答。前者考验模型的海量检索能力后者考验你的资料梳理能力而后者显然更可控。我还建议在参考资料的开头加一句简短的总览比如以下资料共三部分第一部分讲市场现状第二部分讲用户画像第三部分讲竞争格局。这个小动作能让模型更快建立资料的整体框架引用的时候很少跑偏。2.4 示例是输出格式的锚要让模型输出某种固定格式最有效的办法不是反复强调请按照XX格式输出而是直接给一个符合要求的示例。模型对示例的模仿能力远超对抽象描述的理解能力。这一点我反复验证过。当我要求模型以表格形式对比三款产品的优劣势时它给出的表格列名、行结构每次都略有不同。但当我给出一个示例明确写了表格的列是产品名、核心优势、主要劣势、适用人群、价格区间并填了一行示范数据后模型的输出结构立刻稳定了几乎不用后续调整。示例的数量一般是1到3个最合适。一个示例能让模型明白格式两个示例能让模型感知变化范围三个以上边际收益递减。如果示例太多反而会占用宝贵的上下文空间。这里有个细节值得注意示例的领域最好和真实任务保持一致。你想让模型写社交媒体的活动文案示例就放社交媒体文案而不是放一个新闻稿的示例。模型模仿的不仅是格式还有示例里的语气和用词习惯领域一致才能保证风格迁移到位。3. 实操过程从零构建一个高质量上下文3.1 动手前先想清楚这四个问题我在每一次认真的模型对话前都会先花几十秒在脑子里过四个问题。这四个问题想明白了上下文的结构基本就出来了。第一个问题这次对话的最终交付物是什么是一段文案、一份表格、一段代码、还是一个决策建议交付物不同上下文里需要给的参考信息和约束条件完全不同。第二个问题模型的角色应该是什么是执行者、还是顾问、还是对等讨论的伙伴角色决定你要用什么样的系统指令去框定它。第三个问题模型做这件事需要知道哪些背景信息品牌资料、用户画像、技术文档、公司制度哪些是必需的哪些是可选的这个判断很重要因为上下文窗口有限放太多无关信息反而会稀释重点。第四个问题模型的输出有什么绝对不能犯的错比如不能编造数据、不能用第一人称、不能超过多少字。这些红线应该明确写进上下文而不是等模型犯错之后再纠正。这四个问题想完你脑子里已经有了一个上下文的清单。接下来要做的事就是按清单把信息填进去。3.2 实操案例从零构建一个社交媒体文案生成的上下文我拿一个真实的使用场景走一遍全流程让模型生成某咖啡品牌的新品冷萃咖啡的社交媒体文案目标平台是小红书目标人群是25到35岁的城市职场女性。第一步写系统指令。我会这样写你是一名深耕生活方式领域的社交媒体文案策划。你熟悉小红书平台的表达风格懂得如何用标题抓眼球、用正文建立信任、用互动话术引导评论。你始终站在品牌方立场说话但表达方式要自然真实不能有广告腔。第二步写用户指令。用户指令要包含三件事任务内容、约束条件、参考资料。我会这样组织请为以下新品撰写一条小红书笔记文案。要求标题不超过20个字带1个emoji能引发好奇正文500字左右分成3到4个小段每段之间有自然过渡突出冷萃工艺、低酸感、高回甘三个卖点至少两个卖点用生活化场景体现结尾设置一个问题引导读者评论互动不要出现绝绝子yyds等过度泛滥的网络词以下是产品资料和品牌风格参考[此处粘贴产品资料包含冷萃工艺介绍、价格、规格、品牌视觉风格描述] ---第三步给一个输出示例。这一步很关键。我会提前写好或找一条满意的历史笔记作为示例放在用户指令之后、参考资料之前或之后看实际效果微调位置。示例的作用是告诉模型我要的小红书风格具体长什么样而不是它脑补的那种小红书风格。这一套流程走下来模型第一条输出就已经是可用的水平。偶尔有需要微调的地方也基本只改一两个句子不用大返工。3.3 上下文的长尾维护信息太多怎么办现实使用中最让人头疼的不是一开始的上下文构建而是对话过程中信息量不断累积之后上下文变得越来越长。模型有上下文窗口限制一旦超过窗口上限最前面的内容会被截断或丢失这时模型就开始失忆。解决思路有几个层次。第一个层次是精修输入。在对话开始之前尽量把参考资料压缩到必要范围。能用摘要就不用全文能用要点就不用长段落。第二个层次是滚动摘要。当对话进行到十几轮之后历史记录已经很长你可以手动对前面的对话做一个摘要把摘要作为新的上下文起始。比如前面的对话中我们已经确定了这次活动的目标人群是25到35岁的职场女性主推产品是冷萃咖啡价格定位在30元以上目前确定了三个核心卖点。下面我们继续讨论渠道投放策略。把摘要放在新一轮对话的上下文最前面模型就能在有限窗口内重新加载重要信息而不用回溯长长的历史记录。第三个层次是外部化记忆。如果你有比较重要的信息比如品牌调性、目标人群、长期不变的规则不要只依赖对话里的上下文而是把信息存在自己的笔记里每次对话开始时复制进上下文。记住模型的记忆只存在于上下文窗口内对话一结束那些信息对模型来说就不存在了。所以你不想反复交代的信息就要作为常驻上下文固定在每一轮对话的输入前部。3.4 参数调节温度、TopP和上下文配合着调很多人只知道调上下文忽略了生成参数的影响。其实上下文和参数是一对搭档必须配合使用。温度是控制模型输出随机性的参数数值越低输出越保守稳定数值越高输出越发散、有创造性。如果你构造的上下文非常完备、要求严格格式温度建议设置在0到0.4之间。这个区间里模型会非常听话按照上下文给定的框架执行。如果你做的是创意类任务比如写诗、起名、头脑风暴温度设在0.7到1.0之间更合适模型会更愿意跳出常规表达给出惊喜的选项。TopP是另一个控制随机性的参数它限制模型只从累积概率达到某个阈值的那部分词里做选择。实践中TopP和温度二选一调节就行不需要同时拉满保持一个参数固定、调另外一个会更可控。有一种常见误区上下文很完整、任务很明确结果用户把温度拉到1.0发现模型输出的内容虽然格式正确但语句开始飘甚至有重复演说的情况。这其实不是上下文的问题而是参数和任务类型不匹配。严谨型任务配低温创意型任务配高温这个匹配关系记牢了能少走不少弯路。4. 常见问题与排查技巧实录4.1 上下文明明很完整模型还是答非所问这是目前为止我遇到过的最高频问题没有之一。排查顺序基本固定你可以按下面这个清单逐项过一遍。第一检查是否出现了指令冲突。系统指令说你是一名专业的技术文档工程师回答要严谨用户指令却说帮我用轻松幽默的方式解释这个技术概念。两种指令打架模型往往不知所措输出结果就会在两种风格之间摇摆。解决办法很简单把指令统一成一个方向或者明确给出优先级优先满足用户指令中的风格要求。第二检查参考资料和指令之间是否有冲突。比如你贴的资料数据是2022年的指令要求基于最新市场情况分析模型就会很纠结。它既想忠于资料又想满足最新这个要求最后可能会编一个看起来合理的回答。解决方式是明确告知模型使用资料的哪一部分、忽略哪一部分并允许它在资料不足时明确回答资料中没有相关信息。第三检查是否放入了太多弱相关的信息。上下文工程有一个信号稀释问题强相关信息周围环绕着大量弱相关信息模型抓取重点的能力会下降。你可以把弱相关信息删掉或者把强相关信息放到上下文最前面和最末尾的位置这两个位置模型的注意力权重更高。4.2 模型在一轮长对话后失忆长对话失忆绝大多数情况不是模型能力问题而是上下文窗口被挤爆了。你可以做一件事来验证主动问模型你还记得我们对话刚开始时确定的核心目标吗。如果它支支吾吾说不上来基本就是前面的信息已经被截断了。排查方向有两个。一个是窗口溢出也就是对话内容已经超过模型最大支持长度。另一个是干扰淹没即前面的信息还在窗口里但被后面大量新内容稀释了模型提取不到。针对窗口溢出最直接的办法是把历史对话总结成摘要。不要指望模型自己记住你可以说请把我们从对话开始到现在确定的所有关键结论整理成一份摘要不要遗漏任何决策和数字。然后把这份摘要作为新对话的起点相当于把散落在历史中的信息重新装订了一遍。针对干扰淹没可以做一个信息重置动作。在需要模型集中处理某件事之前明确告诉它下面的内容请以刚才总结的核心目标为基准忽略后续讨论中与之相矛盾的表述。相当于帮模型划了一遍重点。4.3 模型输出格式飘来飘去格式不稳定是另一个高频坑尤其是表格类、列表类任务。你明确说了用表格输出模型第一次确实给你表格了但列名和列数跟你预期的不一样你让它改第二次它改了列名但行数又不对。这种情况大概率是上下文里的示例不够具体。我自己的经验是示例必须完整到可以照着抄的程度。不要给半截示例比如只给表头不给数据行。模型看到不完整的示例会倾向于自己补全结果就是它补全的方式和你的预期不同。另外示例的位置也很重要。一般情况下示例放在用户指令之后紧跟着的位置效果最好。不要放在参考资料之后因为模型处理完一大段参考资料后注意力会集中在资料内容上对示例的记忆会被弱化。如果用了示例还是不行的还有一个兜底方案让模型在输出之前先做一次格式确认。你可以说先输出你打算使用的表格结构确认无误后再填充内容。这一步能让格式错误在早期暴露而不是等模型已经写完全部内容才发现结构不对。4.4 模型在关键信息上自作主张地编造模型编造信息也就是常说的幻觉是一个需要认真对待的问题。上下文越模糊、越缺乏边界幻觉发生的概率就越高。一个屡试不爽的应对策略是在上下文中明确给模型加上信息边界声明。比如以下回答中凡是基于我提供的资料得出的结论都要标注引用来源如果资料中没有相关信息请直接说未在资料中找到相关内容不要猜测。加上这句话幻觉风险会立刻下降一个档次。还有个更进阶的做法把允许推测和禁止推测分开声明。比如你可以基于资料内容做合理的趋势推演但推演的部分必须用推测标注并且不能编造具体数字。这样既保持了模型的发挥空间又守住了事实性的底线。4.5 常见问题速查表症状常见原因优先排查动作答非所问、风格飘移指令冲突或参考资料混杂统一指令方向精简参考资料长对话失忆上下文窗口溢出或重点被稀释生成摘要、重设上下文起点输出格式不稳定示例不完整或示例位置不对补全示例、把示例移到指令后回答编造信息上下文缺少信息边界声明加入未找到请明说的约束抓错重点、忽略某个条件上下文信号被弱信息稀释把关键条件前置、加重强调输出重复啰嗦温度过高或上下文无约束降低温度、明确字数限制5. 进阶策略与日常习惯养成5.1 把上下文工程变成一种肌肉记忆学会上下文工程不难难的是每次对话都主动应用。我的建议是别去记什么高深框架就培养三个日常习惯。第一个习惯开口之前先憋五秒。无论多着急的提问先想清楚最终要什么产出。这个产出思维是所有上下文工程的起点。第二个习惯给命令配材料。你在模型面前不是一个空着手提问的人而是一个带着完整任务包的项目经理。每次提问前把背景资料、历史结论、约束条件都准备好形成指令加材料的组合。第三个习惯第一次对话就把格式定死。很多多轮返工都是因为第一轮没说清楚格式后面每次输出都有微调来回折腾。第一轮就把示例甩过去省掉后续所有格式纠偏的沟通成本。5.2 上下文模板化复制粘贴也是一种生产力当你用一套上下文方案解决了某一类任务之后不要满足于这次干得不错。把你写过的系统指令、用户指令、示例结构、参数配置整理成一个模板存进自己的知识库里。举一个实际例子。我整理过一套内容审校模板里面包含系统指令、用户指令框架、输出格式示例、温度建议每次拿到新的文章要审校直接套模板替换资料内容和任务对象五分钟内就能启动一次高质量审校。这类模板带来的收益是巨大的你不需要每次都从零思考上下文怎么搭只需要微调任务相关的部分。时间久了你会积累一批覆盖文案写作、数据分析、文档整理、代码编写等不同场景的模板库。这份模板库才是上下文工程真正给你留下来的资产。5.3 关注上下文窗口但别被参数绑架现在很多模型动不动就宣称支持百万级别的上下文窗口听起来好像上下文工程已经不必学了。事实并非如此。即使窗口再大模型对长文本中不同位置的注意力依然有差异信息太多依然会稀释重点。大窗口解决的是能不能放得下的问题上下文工程解决的是放进去之后模型能不能用好的问题这是两码事。我自己测试过把一个长文档完整丢给模型和把长文档提炼成要点之后丢给模型后者的回答准确率往往明显更高推理速度也更快。原因很简单模型的精力是有限的你帮它省掉无关内容它就能把更多脑力用在真正重要的信息上。所以在使用长上下文模型时我依然保持上下文精简的习惯。真正常态化使用的上下文长度可能只需要模型宣称窗口的十分之一都不到。不是刻意不占满窗口而是大多数任务根本不需要那么多信息。上下文工程的核心不是塞满而是精选。6. 写在最后的一点私人心得做上下文工程这段时间我最大的体会是它不考验技术考验的是换位思考能力。你要把自己想象成那个刚入职的实习生给它的入职培训材料做得足够清晰它就能把活干得足够漂亮。材料含糊、说明缺失、要求一变再变它自然手忙脚乱。换个角度看这也逼着我每次在提问前更认真地梳理自己的需求长期下来连带着我的工作习惯都变好了不少。再分享一个小习惯每次遇到一次特别成功的模型输出我都会回头翻一下当时的完整上下文看看是哪句话、哪个示例、哪个结构起到了决定性作用。多复盘几次你就慢慢摸清了你常用的那个模型的脾性。毕竟每个模型的预训练数据、指令遵循能力都不完全一样适合别人的上下文方案未必直接照搬就有效花点时间找到适合你手头模型的那套表达方式比收藏一百份网红模板都管用。 
长河君 · 2026/10/17 7:20:26 · 阅读 1.2k 上下文工程实战指南：构建高质量大模型对话的关键方法
聊到大模型很多人都会遇到一个让人头疼的场景刚开聊的时候模型还挺聪明聊到第三轮、第五轮它就开始前言不搭后语甚至把你前面交代过的重要条件忘得一干二净。又或者你明明把所有参考资料都贴进了对话框结果它还是对着错误的信息侃侃而谈。这十有八九不是模型变笨了而是你的上下文没有做好。上下文工程这个词听起来很专业但它本质上就是教你把话说清楚、把料备齐全的一套方法。它不是让你去写代码也不是让你去训练模型而是让你掌握跟大模型打交道的底层逻辑知道什么时候该说什么、先说什么后说什么、什么能放进上下文、什么必须省掉。这篇就围绕上下文工程展开讲清楚它到底解决什么问题、核心要素有哪些、实操怎么落地也会把常见坑位和排查思路一并整理出来希望能成为一份随时能翻出来的收藏级攻略。1. 为什么上下文工程是玩转大模型的第一步1.1 从一次失败的对话说起想象一个非常常见的场景你想让模型帮你写一份产品推广文案。你会怎么做大概率是直接发一句帮我写一份推广文案。模型确实会给你一份文案但大概率是那种放在哪个行业都能用、放到哪个产品上都行的通用模板。接下来你会补充说我们是一款面向年轻人的咖啡品牌主打冷萃工艺模型会重新输出一版加入了冷萃、年轻人这些词。然后你又想起要说价格偏高主打品质它又改一版。你再来一句不要用感叹号语气要克制它再改一轮。一轮又一轮地追加指令模型每次都能理解你最新的那条指令但它对整体目标、品牌调性、目标人群的把握是分散的、不稳定的。它只能基于当前这一轮对话加有限的记忆去猜测你的完整意图。这就是典型的上下文组织方式有问题——你在用对话轮次当上下文而不是用结构化信息当上下文。上下文工程解决的问题恰恰就在这里。它要求你在跟模型交流之前先把模型的工作背景准备好你是谁、要做什么、给谁看、有什么限制、参考什么资料、输出成什么样子。这些信息一次性、清晰地放进上下文里模型从一开始就站在正确的人设和任务框架内工作而不是靠你后续一遍遍打补丁。1.2 上下文工程和提示词工程到底有什么区别很多人会把上下文工程和提示词工程混为一谈其实它们有交集但不完全是一回事。提示词工程更关注单条指令怎么写比如怎么措辞、怎么加例子、怎么让模型一步步思考。它的颗粒度在一轮对话核心是让模型听懂你这一次提问。上下文工程则关注整段对话的全局信息布局颗粒度在一个会话。它要考虑的问题包括系统指令放在哪里、怎么写才能稳定约束模型行为参考资料以什么顺序、什么格式嵌入才能让模型准确调用示例放几个、放在什么位置才能让模型模仿输出格式多轮对话进行到一半时历史记录是保留原文还是压缩成摘要上下文窗口有限哪些信息优先级最高、哪些必须牺牲打个不恰当的比方提示词工程是教你怎么向一个临时员工派活上下文工程是教你怎么给一名正式员工做入职培训。前者解决这一单怎么干后者解决这个人在整个任职期间怎么一直干对。对于小白来说先搞懂上下文工程再回头去抠提示词技巧会顺很多。因为很多提示词技巧之所以失效不是措辞不对而是上下文环境没搭好。1.3 上下文好坏的差距有多大我用同一个模型、同样的任务做过对比测试任务很简单从一段产品介绍中提取三个关键卖点并按照指定格式输出。第一次我直接贴了一段产品介绍然后在后面加了一句提取三个关键卖点。结果模型提取出来的卖点确实有三个但格式是它自己临场发挥的有加粗、有列表符号、有总结语跟我要的1. 卖点名称一句话说明这种格式完全不沾边。第二次我先在上下文里交代了任务背景给出了一个输出示例明确说了严格参考示例格式不要额外解释然后才贴产品介绍。这一次模型输出的格式完全正确内容也没有跑偏。同一时刻、同一个模型只是上下文的组织方式不同输出质量差距就非常明显。这也是为什么我说上下文工程是玩转大模型的第一步——它不需要你懂技术原理只需要你掌握信息组织的方法就能立刻看到效果。2. 上下文的核心构件你的入职培训应该包含什么2.1 系统指令是人设与行为准则上下文工程里最重要的一块是系统指令。你可以把它理解为模型的岗位说明书。它定义了模型在整段对话中以什么身份出现、遵守哪些规则、优先完成什么目标。好的系统指令往往包含四个信息点角色定位你是谁。比如你是一名资深的中文编辑或你是一个帮助用户做决策的分析助手任务背景你现在要处理的是一批什么样的工作。行为规则对话过程中必须遵守的边界。比如只基于我提供的资料回答不要擅自补充外部信息如果信息不足明确告诉我缺什么输出偏好大方向的格式或语气要求。我见过很多人把系统指令写成一长串说教什么你是一个乐于助人的助手请始终礼貌、专业、准确之类这种话不是没用而是太笼统。真正起作用的系统指令是具体到见到什么情况做什么动作的那种。举例来说假设我要让模型帮我审校一篇文章我会把系统指令写成你是一名资深中文编辑。我会给你文章全文。你的任务是找出逻辑不通、事实性错误、语句冗长的段落。对每个问题按原文引用 - 问题类型 - 修改建议三段式输出。如果没有问题就直接回复无问题不要输出任何多余内容。对比请帮我审校下面的文章并给出修改意见前者在上下文层面就把人设、任务、规则、输出格式全部锁死了模型几乎不需要猜你要什么。2.2 用户指令是任务下达窗口用户指令是你每一轮真正要模型干的事也是上下文里最灵活的部分。它的作用不是重复系统指令而是把当前这一轮要做的事具体化。常见的问题是很多人把用户指令写得像聊天。比如那接下来你看看这个吧然后附一个文件。这种指令不是不行但对模型来说信息太少了。更好的做法是明确动作、明确对象、明确产出物。我自己的习惯格式是请对以下文档执行[具体操作]。要求[具体要求1]。[具体要求2]。文档内容如下--- [文档] ---这样模型能清楚地区分指令部分和材料部分不会把文档的内容也当成指令去执行。这里有个容易被忽略的点如果你把材料直接贴在指令前面模型可能会把材料末尾的某些句子误判为指令。用分隔符把指令和材料隔开能显著降低这种误判。2.3 参考资料要按可检索的标准嵌入当你需要模型基于外部资料回答问题时参考资料怎么放进上下文是一个非常讲究的环节。先说最经典的坑直接把一份两万字的行业报告粘贴进去然后问这份报告里提到了哪三个趋势模型确实能读但如果报告里相关内容分散在不同章节模型提取时容易遗漏、也会加入自己的联想。更稳妥的方式是提前把参考资料做裁剪。能切成段落就切成段落能提取要点就提取要点。如果你是在用支持文件上传的模型直接传文件当然方便但如果上下文窗口紧张或你希望模型聚焦手工整理参考资料仍然更可靠。整理资料时遵循一个原则让模型尽量少翻找直接给答案。换句话说与其把整份报告给模型让它自己找不如你先把报告里跟任务有关的部分摘出来再让模型基于摘录内容作答。前者考验模型的海量检索能力后者考验你的资料梳理能力而后者显然更可控。我还建议在参考资料的开头加一句简短的总览比如以下资料共三部分第一部分讲市场现状第二部分讲用户画像第三部分讲竞争格局。这个小动作能让模型更快建立资料的整体框架引用的时候很少跑偏。2.4 示例是输出格式的锚要让模型输出某种固定格式最有效的办法不是反复强调请按照XX格式输出而是直接给一个符合要求的示例。模型对示例的模仿能力远超对抽象描述的理解能力。这一点我反复验证过。当我要求模型以表格形式对比三款产品的优劣势时它给出的表格列名、行结构每次都略有不同。但当我给出一个示例明确写了表格的列是产品名、核心优势、主要劣势、适用人群、价格区间并填了一行示范数据后模型的输出结构立刻稳定了几乎不用后续调整。示例的数量一般是1到3个最合适。一个示例能让模型明白格式两个示例能让模型感知变化范围三个以上边际收益递减。如果示例太多反而会占用宝贵的上下文空间。这里有个细节值得注意示例的领域最好和真实任务保持一致。你想让模型写社交媒体的活动文案示例就放社交媒体文案而不是放一个新闻稿的示例。模型模仿的不仅是格式还有示例里的语气和用词习惯领域一致才能保证风格迁移到位。3. 实操过程从零构建一个高质量上下文3.1 动手前先想清楚这四个问题我在每一次认真的模型对话前都会先花几十秒在脑子里过四个问题。这四个问题想明白了上下文的结构基本就出来了。第一个问题这次对话的最终交付物是什么是一段文案、一份表格、一段代码、还是一个决策建议交付物不同上下文里需要给的参考信息和约束条件完全不同。第二个问题模型的角色应该是什么是执行者、还是顾问、还是对等讨论的伙伴角色决定你要用什么样的系统指令去框定它。第三个问题模型做这件事需要知道哪些背景信息品牌资料、用户画像、技术文档、公司制度哪些是必需的哪些是可选的这个判断很重要因为上下文窗口有限放太多无关信息反而会稀释重点。第四个问题模型的输出有什么绝对不能犯的错比如不能编造数据、不能用第一人称、不能超过多少字。这些红线应该明确写进上下文而不是等模型犯错之后再纠正。这四个问题想完你脑子里已经有了一个上下文的清单。接下来要做的事就是按清单把信息填进去。3.2 实操案例从零构建一个社交媒体文案生成的上下文我拿一个真实的使用场景走一遍全流程让模型生成某咖啡品牌的新品冷萃咖啡的社交媒体文案目标平台是小红书目标人群是25到35岁的城市职场女性。第一步写系统指令。我会这样写你是一名深耕生活方式领域的社交媒体文案策划。你熟悉小红书平台的表达风格懂得如何用标题抓眼球、用正文建立信任、用互动话术引导评论。你始终站在品牌方立场说话但表达方式要自然真实不能有广告腔。第二步写用户指令。用户指令要包含三件事任务内容、约束条件、参考资料。我会这样组织请为以下新品撰写一条小红书笔记文案。要求标题不超过20个字带1个emoji能引发好奇正文500字左右分成3到4个小段每段之间有自然过渡突出冷萃工艺、低酸感、高回甘三个卖点至少两个卖点用生活化场景体现结尾设置一个问题引导读者评论互动不要出现绝绝子yyds等过度泛滥的网络词以下是产品资料和品牌风格参考[此处粘贴产品资料包含冷萃工艺介绍、价格、规格、品牌视觉风格描述] ---第三步给一个输出示例。这一步很关键。我会提前写好或找一条满意的历史笔记作为示例放在用户指令之后、参考资料之前或之后看实际效果微调位置。示例的作用是告诉模型我要的小红书风格具体长什么样而不是它脑补的那种小红书风格。这一套流程走下来模型第一条输出就已经是可用的水平。偶尔有需要微调的地方也基本只改一两个句子不用大返工。3.3 上下文的长尾维护信息太多怎么办现实使用中最让人头疼的不是一开始的上下文构建而是对话过程中信息量不断累积之后上下文变得越来越长。模型有上下文窗口限制一旦超过窗口上限最前面的内容会被截断或丢失这时模型就开始失忆。解决思路有几个层次。第一个层次是精修输入。在对话开始之前尽量把参考资料压缩到必要范围。能用摘要就不用全文能用要点就不用长段落。第二个层次是滚动摘要。当对话进行到十几轮之后历史记录已经很长你可以手动对前面的对话做一个摘要把摘要作为新的上下文起始。比如前面的对话中我们已经确定了这次活动的目标人群是25到35岁的职场女性主推产品是冷萃咖啡价格定位在30元以上目前确定了三个核心卖点。下面我们继续讨论渠道投放策略。把摘要放在新一轮对话的上下文最前面模型就能在有限窗口内重新加载重要信息而不用回溯长长的历史记录。第三个层次是外部化记忆。如果你有比较重要的信息比如品牌调性、目标人群、长期不变的规则不要只依赖对话里的上下文而是把信息存在自己的笔记里每次对话开始时复制进上下文。记住模型的记忆只存在于上下文窗口内对话一结束那些信息对模型来说就不存在了。所以你不想反复交代的信息就要作为常驻上下文固定在每一轮对话的输入前部。3.4 参数调节温度、TopP和上下文配合着调很多人只知道调上下文忽略了生成参数的影响。其实上下文和参数是一对搭档必须配合使用。温度是控制模型输出随机性的参数数值越低输出越保守稳定数值越高输出越发散、有创造性。如果你构造的上下文非常完备、要求严格格式温度建议设置在0到0.4之间。这个区间里模型会非常听话按照上下文给定的框架执行。如果你做的是创意类任务比如写诗、起名、头脑风暴温度设在0.7到1.0之间更合适模型会更愿意跳出常规表达给出惊喜的选项。TopP是另一个控制随机性的参数它限制模型只从累积概率达到某个阈值的那部分词里做选择。实践中TopP和温度二选一调节就行不需要同时拉满保持一个参数固定、调另外一个会更可控。有一种常见误区上下文很完整、任务很明确结果用户把温度拉到1.0发现模型输出的内容虽然格式正确但语句开始飘甚至有重复演说的情况。这其实不是上下文的问题而是参数和任务类型不匹配。严谨型任务配低温创意型任务配高温这个匹配关系记牢了能少走不少弯路。4. 常见问题与排查技巧实录4.1 上下文明明很完整模型还是答非所问这是目前为止我遇到过的最高频问题没有之一。排查顺序基本固定你可以按下面这个清单逐项过一遍。第一检查是否出现了指令冲突。系统指令说你是一名专业的技术文档工程师回答要严谨用户指令却说帮我用轻松幽默的方式解释这个技术概念。两种指令打架模型往往不知所措输出结果就会在两种风格之间摇摆。解决办法很简单把指令统一成一个方向或者明确给出优先级优先满足用户指令中的风格要求。第二检查参考资料和指令之间是否有冲突。比如你贴的资料数据是2022年的指令要求基于最新市场情况分析模型就会很纠结。它既想忠于资料又想满足最新这个要求最后可能会编一个看起来合理的回答。解决方式是明确告知模型使用资料的哪一部分、忽略哪一部分并允许它在资料不足时明确回答资料中没有相关信息。第三检查是否放入了太多弱相关的信息。上下文工程有一个信号稀释问题强相关信息周围环绕着大量弱相关信息模型抓取重点的能力会下降。你可以把弱相关信息删掉或者把强相关信息放到上下文最前面和最末尾的位置这两个位置模型的注意力权重更高。4.2 模型在一轮长对话后失忆长对话失忆绝大多数情况不是模型能力问题而是上下文窗口被挤爆了。你可以做一件事来验证主动问模型你还记得我们对话刚开始时确定的核心目标吗。如果它支支吾吾说不上来基本就是前面的信息已经被截断了。排查方向有两个。一个是窗口溢出也就是对话内容已经超过模型最大支持长度。另一个是干扰淹没即前面的信息还在窗口里但被后面大量新内容稀释了模型提取不到。针对窗口溢出最直接的办法是把历史对话总结成摘要。不要指望模型自己记住你可以说请把我们从对话开始到现在确定的所有关键结论整理成一份摘要不要遗漏任何决策和数字。然后把这份摘要作为新对话的起点相当于把散落在历史中的信息重新装订了一遍。针对干扰淹没可以做一个信息重置动作。在需要模型集中处理某件事之前明确告诉它下面的内容请以刚才总结的核心目标为基准忽略后续讨论中与之相矛盾的表述。相当于帮模型划了一遍重点。4.3 模型输出格式飘来飘去格式不稳定是另一个高频坑尤其是表格类、列表类任务。你明确说了用表格输出模型第一次确实给你表格了但列名和列数跟你预期的不一样你让它改第二次它改了列名但行数又不对。这种情况大概率是上下文里的示例不够具体。我自己的经验是示例必须完整到可以照着抄的程度。不要给半截示例比如只给表头不给数据行。模型看到不完整的示例会倾向于自己补全结果就是它补全的方式和你的预期不同。另外示例的位置也很重要。一般情况下示例放在用户指令之后紧跟着的位置效果最好。不要放在参考资料之后因为模型处理完一大段参考资料后注意力会集中在资料内容上对示例的记忆会被弱化。如果用了示例还是不行的还有一个兜底方案让模型在输出之前先做一次格式确认。你可以说先输出你打算使用的表格结构确认无误后再填充内容。这一步能让格式错误在早期暴露而不是等模型已经写完全部内容才发现结构不对。4.4 模型在关键信息上自作主张地编造模型编造信息也就是常说的幻觉是一个需要认真对待的问题。上下文越模糊、越缺乏边界幻觉发生的概率就越高。一个屡试不爽的应对策略是在上下文中明确给模型加上信息边界声明。比如以下回答中凡是基于我提供的资料得出的结论都要标注引用来源如果资料中没有相关信息请直接说未在资料中找到相关内容不要猜测。加上这句话幻觉风险会立刻下降一个档次。还有个更进阶的做法把允许推测和禁止推测分开声明。比如你可以基于资料内容做合理的趋势推演但推演的部分必须用推测标注并且不能编造具体数字。这样既保持了模型的发挥空间又守住了事实性的底线。4.5 常见问题速查表症状常见原因优先排查动作答非所问、风格飘移指令冲突或参考资料混杂统一指令方向精简参考资料长对话失忆上下文窗口溢出或重点被稀释生成摘要、重设上下文起点输出格式不稳定示例不完整或示例位置不对补全示例、把示例移到指令后回答编造信息上下文缺少信息边界声明加入未找到请明说的约束抓错重点、忽略某个条件上下文信号被弱信息稀释把关键条件前置、加重强调输出重复啰嗦温度过高或上下文无约束降低温度、明确字数限制5. 进阶策略与日常习惯养成5.1 把上下文工程变成一种肌肉记忆学会上下文工程不难难的是每次对话都主动应用。我的建议是别去记什么高深框架就培养三个日常习惯。第一个习惯开口之前先憋五秒。无论多着急的提问先想清楚最终要什么产出。这个产出思维是所有上下文工程的起点。第二个习惯给命令配材料。你在模型面前不是一个空着手提问的人而是一个带着完整任务包的项目经理。每次提问前把背景资料、历史结论、约束条件都准备好形成指令加材料的组合。第三个习惯第一次对话就把格式定死。很多多轮返工都是因为第一轮没说清楚格式后面每次输出都有微调来回折腾。第一轮就把示例甩过去省掉后续所有格式纠偏的沟通成本。5.2 上下文模板化复制粘贴也是一种生产力当你用一套上下文方案解决了某一类任务之后不要满足于这次干得不错。把你写过的系统指令、用户指令、示例结构、参数配置整理成一个模板存进自己的知识库里。举一个实际例子。我整理过一套内容审校模板里面包含系统指令、用户指令框架、输出格式示例、温度建议每次拿到新的文章要审校直接套模板替换资料内容和任务对象五分钟内就能启动一次高质量审校。这类模板带来的收益是巨大的你不需要每次都从零思考上下文怎么搭只需要微调任务相关的部分。时间久了你会积累一批覆盖文案写作、数据分析、文档整理、代码编写等不同场景的模板库。这份模板库才是上下文工程真正给你留下来的资产。5.3 关注上下文窗口但别被参数绑架现在很多模型动不动就宣称支持百万级别的上下文窗口听起来好像上下文工程已经不必学了。事实并非如此。即使窗口再大模型对长文本中不同位置的注意力依然有差异信息太多依然会稀释重点。大窗口解决的是能不能放得下的问题上下文工程解决的是放进去之后模型能不能用好的问题这是两码事。我自己测试过把一个长文档完整丢给模型和把长文档提炼成要点之后丢给模型后者的回答准确率往往明显更高推理速度也更快。原因很简单模型的精力是有限的你帮它省掉无关内容它就能把更多脑力用在真正重要的信息上。所以在使用长上下文模型时我依然保持上下文精简的习惯。真正常态化使用的上下文长度可能只需要模型宣称窗口的十分之一都不到。不是刻意不占满窗口而是大多数任务根本不需要那么多信息。上下文工程的核心不是塞满而是精选。6. 写在最后的一点私人心得做上下文工程这段时间我最大的体会是它不考验技术考验的是换位思考能力。你要把自己想象成那个刚入职的实习生给它的入职培训材料做得足够清晰它就能把活干得足够漂亮。材料含糊、说明缺失、要求一变再变它自然手忙脚乱。换个角度看这也逼着我每次在提问前更认真地梳理自己的需求长期下来连带着我的工作习惯都变好了不少。再分享一个小习惯每次遇到一次特别成功的模型输出我都会回头翻一下当时的完整上下文看看是哪句话、哪个示例、哪个结构起到了决定性作用。多复盘几次你就慢慢摸清了你常用的那个模型的脾性。毕竟每个模型的预训练数据、指令遵循能力都不完全一样适合别人的上下文方案未必直接照搬就有效花点时间找到适合你手头模型的那套表达方式比收藏一百份网红模板都管用。