★ FEATURED ARTICLE 很多人把大模型用不好第一反应就是这模型太笨但实际排查下来十有八九是上下文工程没做到位。所谓上下文工程就是指我们围绕LLM输入侧做的一系列设计、组织与管理工作决定给模型看什么、不看什么、以什么顺序看、以及看完一轮之后如何延续。它直接决定了模型能不能发挥出真正的潜能也是搭建一套理想AI工作环境的核心技能。这四大关键阶段——任务目标界定、上下文材料准备、提示词策略编排、多轮交互管理每一个都值得单独打磨。这篇文章我就用自己实际操作中的经验和踩坑记录把这四个阶段掰开揉碎讲清楚适合所有正在用LLM做应用、写自动化脚本、搭知识库助手的开发者参考。1. 上下文工程到底是什么从调包到调上下文很多朋友刚接触大模型时习惯把注意力放在选模型、调参数上认为换个更聪明的模型就万事大吉。可真到了实际项目里同一个模型别人能稳定输出高质量结果自己却经常得到答非所问、胡编乱造的内容。问题往往就出在上下文的构建上。1.1 为什么说上下文是LLM的真正工作台我们可以把LLM想象成一个能力很强但记忆极短、且特别容易受周围环境影响的临时工。它本身的知识储备很广但每次开工时眼前只有你递给它的那张工作台——也就是当前对话窗口里的全部内容。工作台上放了什么、怎么摆放、有没有干扰物直接决定了它能干出什么活儿。如果你把一堆杂乱无章的资料、一个含糊不清的目标、再加上几条互相矛盾的指令全丢上去那它当然只能给你一份乱七八糟的结果。上下文工程要做的就是把这个工作台收拾得井井有条让模型一上来就知道我是谁、要做什么、有哪些可用素材、答案应该长什么样。在很多真实项目中上下文工程带来的收益甚至比换模型还明显。我有一个做客服问答系统的项目最初用某款通用模型直接丢给用户问题让它回答效果一般经常答非所问或者漏掉关键信息。后来花了两周时间做上下文工程把企业知识库做了清洗和结构化、设计了带角色和示例的提示模板、给多轮对话加了记忆摘要。同样还是那个模型准确率直接提升了一大截用户反馈完全像换了个产品。这件事给我的触动很大模型能力是静态的上下文工程是动态的后者才是我们真正能发挥主动权的地方。1.2 四个阶段的整体视图我习惯把上下文工程拆成四个阶段分别对应一次完整交互从0到1、从1到N的完整链路。第一阶段是任务目标与边界界定。动手之前先想清楚这次调用想让模型完成什么输入是什么、输出是什么有哪些限制条件这个阶段的产出是一份任务说明书而不是直接写提示词。第二阶段是上下文材料的选择、清洗与结构化。模型不是数据库你不能把所有资料一股脑塞进去需要筛选出真正相关的信息并按照模型容易理解的格式组织好。第三阶段是提示词策略设计与角色编排。把目标和材料翻译成一段结构清晰、指令明确、带示例的提示词让模型知道每一步该怎么走。第四阶段是多轮交互中的上下文管理与迭代优化。现实中的AI工作环境很少只调一次接口往往是多轮对话、持续使用怎么维护对话历史、怎么避免上下文污染、怎么从错误中反推改进都属于这一阶段。这四个阶段不是一次性走完就结束的而是一个循环。每次看到Bad Case都需要回到前面某个阶段重新调整。下面我按顺序详细说。2. 第一阶段任务目标与上下文边界界定很多人的提示词写得差根源不是文笔不好而是在写之前根本没想清楚任务目标。你在上下文里塞进的第一句话往往就决定了模型的整个行为方向。如果连你自己都不知道要什么模型就更不可能知道。2.1 动手前先回答四个问题我在设计任何一次LLM调用前都会强制自己回答四个问题答不清楚就绝不动笔写提示词。第一个问题这个任务的核心输出是什么要求是一段文本、一个JSON、一份表格还是仅仅做一个判断输出形式需要一开始就锁定否则模型很容易自由发挥。第二个问题输入侧有哪些必要信息和可选信息比如做摘要任务必要信息是原文可选信息是目标长度、风格偏好、关注角度。第三个问题成功标准是什么怎么判断这一次输出是好的是包含所有关键点还是格式完全合法还是语气足够专业没有成功标准后面就没法迭代。第四个问题有哪些绝对不能触碰的边界比如不能编造数据、不能输出敏感内容、不能偏离某个固定口径、不能使用某种语言。这些边界要在进入正文前就写清楚。这一步看似简单却能把很多后续问题消灭在萌芽状态。我见过太多人上来就甩给模型一个帮我写个方案然后模型写出来一堆泛泛而谈的东西又反过来骂模型不行。其实只要在提问前补上一句我是某个行业的中型团队负责人需要一份针对新员工培训的3周方案包含目标、日程、考核方式控制在800字以内输出质量立刻就不一样了。2.2 上下文窗口预算Token从哪来、到哪去很多人忽略了一个关键资源上下文窗口是有限的。目前主流模型的上下文窗口从几万到几十万Token不等看着很大但实际可用空间会被很多隐性内容吃掉。指令、角色设定、示例、对话历史、检索到的参考文档、模型输出本身全都要占空间。我习惯在项目初期就做一次Token预算。假设模型窗口是32K我会把规划写成这样系统角色与全局指令1K用户任务描述0.5K少样本示例3个3K参考文档检索后20K历史对话摘要2K预留输出空间5K合计31.5K刚好卡在窗口之内。你会发现参考文档通常是最大的消耗者所以在第二阶段必须做信息筛选和压缩。如果预算超了优先砍参考文档其次砍示例最后砍角色指令。因为对大多数任务来说指令可以短但材料不能乱。这个预算表我会写进项目文档里每次改提示词都对照检查一遍避免不知不觉超限。模型一旦触发截断往往不是丢开头就是丢中间输出质量会断崖式下降这种问题极难排查。2.3 实操模板任务定义块基于第一阶段的思考我会在每次编写提示词时先写一个任务定义块放在上下文的最前面。它相当于给整个工作台定下基调。一个典型的模板长这样【任务目标】 针对用户提供的产品差评内容生成一段安抚回复。 【输入信息】 用户差评原文。 【输出要求】 1. 先表达歉意再给出具体解决方案 2. 不承认是产品质量问题但要体现负责任态度 3. 不超过120字。 【限制边界】 不得编造订单信息、不得承诺未经验证的赔偿、不得使用机械化的客服套话。这样一个任务定义块看起来很朴素但能让模型在阅读后续所有内容时都带着这个目标框架。我测试下来加了这一块的回复准确率、合规性都明显高于直接发挥式提问。这也说明第一阶段的工作不是可有可无的它是整个上下文工程的地基。3. 第二阶段上下文材料的选择、清洗与结构化目标定好之后就要往上下文里填充材料了。这一步最考验功力因为材料的好坏直接决定模型输出的事实基础。很多AI应用翻车不是因为提示词写得差而是因为喂进去的参考资料本身就是脏的、乱的、过时的。3.1 材料选择的相关性漏斗不要什么都往上下文里塞必须建立一个筛选漏斗。我自己的操作方法是四步过滤。第一步按任务目标圈定候选范围。比如做法律问答就只找相关的法规条文和司法解释而不是把整个法律库都搬进去。第二步按时间过滤。信息类任务必须优先选择最新材料过期的说明文档、旧版本政策条例很容易误导模型。第三步按权威性过滤。同一个知识点优先选官方文档、一手数据其次是质量较高的二手整理论坛灌水内容直接丢掉。第四步按信息密度过滤。同样讲一个概念一篇文章可能有一半是铺垫和废话只提取其中真正包含事实、数据、步骤的段落就行。这个漏斗看起来简单但大多数人会偷懒直接把几篇长文拼接进上下文结果模型被大量无关内容干扰反而忽略了关键信息。我做检索增强生成时对召回回来的文档还会做一次重排序只取与问题得分最高的前3到5段而不是把整篇文档都喂进去。这一步让我项目的幻觉率下降得非常明显。3.2 结构化组织从纯文本到语义块材料选好之后不能直接一大段怼进去要让模型好读。LLM对结构非常敏感语义块清晰的上下文比一大坨连续文本更容易被精确引用。我自己常用的做法是给材料加标签和分层。比如给模型提供产品资料时我不会写我们的产品叫智办系统是一款协同办公软件拥有任务管理、文档协作、审批流程等功能而是组织成【产品基本信息】 名称智办系统 类型协同办公软件 目标用户中小团队 【核心功能】 - 任务管理支持看板、列表、日历三种视图 - 文档协作多人实时编辑支持版本历史 - 审批流程可自定义审批节点和条件 【常见用户问题】 - 如何邀请成员进入团队设置... - 如何导出任务点击任务列表右上角...这样的结构模型在回答用户问题时能快速定位对应模块生成的答案也更接近从文档中找答案而不是自己凭空编。如果你在做一个知识库问答系统强烈建议把所有知识文档都统一成这种带标题的语义块格式前期多花点功夫清洗后期效果会好很多。3.3 长文本压缩摘要、检索和分块的经验现实中的资料往往很长一篇论文几万字、一本说明书几百页不可能全部塞进上下文。我总结出三种常用的压缩策略。第一种是抽象摘要。把整篇长文档先让模型或人工生成一段摘要再放进上下文。这个方案适合背景信息类材料但摘要会丢失细节不适合需要精确引用数据的场景。第二种是检索切片。把文档切成小块用向量检索或关键词检索找出最相关的几块只把这几块喂给模型。这是RAG最常见的形式适合开放域知识问答。第三种是分层结构。先放一个全局摘要作为目录级信息再把详细内容放在后面让模型按需查阅。这个方法在超长对话历史管理里非常有用后面我会细说。切片时要注意块的大小。我一般控制在每块300到500字太小会中断语义完整性太大会混入不相关内容。块之间用空行和标题隔开最后在提示词里明确告诉模型优先使用【参考文档】中的内容没有资料时如实说明不知道。这样模型就不会硬编了。4. 第三阶段提示词策略设计与角色/示例编排材料备好了接下来就是把目标和材料糅合成一段真正有效的提示词。这是很多人最感兴趣的部分但也是最容易被花哨技巧带偏的部分。我始终认为提示词的核心不是词藻而是结构、顺序和约束。4.1 指令、角色、示例的排布优先级一份完整的提示词通常包含角色设定、任务指令、上下文材料、示例、输出格式这几类组件。它们的排列顺序会影响模型的理解效果。我习惯遵循一个目标先行、角色辅助、材料跟上、示例兜底的顺序。先写任务目标让模型一进来就锁定方向。再写角色设定让它调用相应的知识背景和语气。接着给参考材料这是模型的事实依据。然后给少样本示例让模型模仿格式和推理风格。最后写输出约束和格式要求。比如错误示范是先给一大堆角色故事再给示例最后才轻描淡写一句帮我总结一下。这会让模型把更多注意力放在角色模仿而不是核心任务上。正确示范应该是你是一个数据分析助手。请根据下面的销售数据总结本季度各区域表现。 【销售数据】 ... 【输出要求】 以要点的形式输出每个区域包含完成率、同比增长、关键问题。这样模型扫一眼就知道该干什么不需要反复猜测。很多人为了调教模型喜欢写几百字的角色小传其实对大多数任务都是浪费。角色设定的作用只是锚定语气和知识范围三句话以内足够了。4.2 少样本示例的选取与数量控制少样本示例是提示词中威力最大的组件之一。一个精心设计的输入输出对往往比一百句抽象指令更能让模型理解你想要的答案。选示例时要注意三个原则相似性原则示例要尽量贴近真实场景差异性覆盖原则多个示例要覆盖不同边界情况而不是同一类重复反例原则有时需要放一个错误示范并标注为什么错这能有效抑制模型的某些不良倾向。数量上我一般控制在2到5个。少于2个模型往往学不会模式多于5个Token消耗大而且示例之间可能互相干扰。有一次我做邮件分类任务最初给了8个示例模型表现反而不稳定因为有些示例的分类边界重叠了。精简到3个典型示例后准确率还上升了一些。这件事让我不再迷信示例越多越好。示例本身也要保持一致性。如果示例的输出格式一会儿用列表、一会儿用段落模型就会困惑。最好把示例中的输入部分也按真实情况脱敏处理并让示例里的逻辑可解释而不是让模型单纯复制表面措辞。4.3 输出约束与格式锚点最后一个设计要点是输出约束。你希望模型输出什么格式就要在提示词里用格式锚点明确卡死。比如你希望它输出JSON就不要说请以JSON格式返回而是给出一个完整的JSON模板告诉它把字段填进去。模型对模板的遵循能力远高于对抽象指令的遵循能力。一个实用的做法是使用XML或Markdown标签把输出区域框出来。比如请将结果填入下面的JSON { summary: 这里写摘要, keywords: [关键词1, 关键词2], risk_level: high/mid/low }如果模型仍然不按格式输出可以用请只输出上述JSON结构不要包含任何解释来收紧。还有一个技巧是让模型先输出一个思考草稿再给出最终结果。这种两步法虽然增加了一些Token却能显著提升复杂任务的逻辑性。我在写推理类提示词时会在最后加上先梳理已知条件再逐步推导效果很不错。5. 第四阶段多轮交互中的上下文管理与迭代优化前面三个阶段解决的是单次调用怎么设计好。但真正搭建理想AI工作环境一定绕不开多轮交互——要么是用户和模型连续对话要么是Agent多次调用工具。这时候上下文管理就变成动态问题了。5.1 对话历史的取舍滑动窗口、记忆摘要多轮对话最基础的管理手段是滑动窗口只保留最近N轮对话作为上下文。这个方案简单粗暴但缺点是一旦关键信息被滑出去模型就失忆了。所以我会在此基础上叠加一个记忆摘要层。具体做法是每一轮或每几轮结束后让模型把当前对话产生的关键信息浓缩成摘要比如用户偏好、已经确认的事实、待办事项等。下次对话时把摘要信息和最近几轮窗口一起作为上下文喂进去。这样一来模型既保留了对长期信息的记忆又不需要把全部历史都塞进去。我做项目时通常会设定每5轮生成一次摘要并检查摘要是否遗漏核心决策否则后续会话会出现前后矛盾。摘要和原始对话在上下文里的排布也有讲究。摘要放在最前面因为它是对历史的高度概括原始最近对话放在后面因为模型对紧邻内容的注意力更强。这样安排下来即使窗口不大也能维持较长时间的连贯性。5.2 上下文污染与遗忘机制上下文污染是我在多轮交互中踩过最多坑的地方。所谓污染就是之前某条消息里包含的无关、错误或冲突信息影响到了后续所有轮次的输出。大模型不具备主动删除记忆的能力它只会把新信息和旧信息混合当新旧信息矛盾时输出就会崩坏。最常见的污染来源有三个一是用户中途改了需求但旧需求相关的示例和材料还在上下文里二是前一轮模型的错误输出被当作已知背景继续参与后续生成三是无关的闲聊话题夹在关键指令中间分散了模型注意力。我的解决办法是引入显式的遗忘机制。当检测到用户意图切换时主动重建上下文——清除掉旧的示例和对话记录只保留任务目标摘要和新任务的材料。另外可以在提示词中加一句请忽略前面对话中与本次指令冲突的内容以本次指令为准。这不能百分之百解决问题但对大多数场景很有效。还有一个土办法如果某一轮出现了明显污染不要继续对话直接开一个新会话把必要的摘要手动粘过去往往比试图纠正更省力。5.3 反馈闭环从Bad Case反推上下文缺陷上下文工程不可能一次到位必须建立反馈闭环。每次任务输出质量不达标时我都会把这个Bad Case单独拿出来反推是哪个阶段出了问题而不是简单换一个提示词再试。我有一套固定的排查路径先看任务目标是否明确再看参考材料是否相关、是否足够然后检查示例是否带来误导最后检查上下文是否被历史污染。如果模型输出太泛泛往往是一阶段目标界定不清晰如果模型编造了材料里没有的内容往往是二阶段材料筛选有遗漏如果模型格式不对往往是三阶段输出锚点不够硬如果模型前后矛盾多是四阶段对话管理出了问题。在项目里我会定期收集所有Bad Case给它们打上阶段标签统计哪一类问题占比最高。通常你会发现问题集中在一两个阶段那就集中精力优化那一块效率会高很多。我有一个同事一开始觉得模型不好用狂换模型后来我们帮他做了Bad Case分类发现八成问题出在第二阶段——喂进去的参考文档又旧又乱。把材料清洗和检索优化之后同一个模型的表现让人刮目相看。6. 常见问题与排查技巧实录最后整理一份我在实操中经常遇到的高频问题速查表以及两个典型的Debug案例希望能帮大家少走弯路。6.1 高频问题速查表问题现象可能原因排查方向输出内容太宽泛、不落地任务目标模糊缺少边界回到第一阶段补充具体输出要求和限制引用不存在的数据或事实参考材料缺失或不完整检查第二阶段材料覆盖率必要时加检索回答格式总是不对输出锚点不够明确在提示词中给出完整输出模板禁止多余解释多轮对话后开始胡言乱语上下文被污染或者历史过长使用记忆摘要滑动窗口及时重建会话加了示例反而更差示例数量过多或互相矛盾精简到2-3个高质量示例注意覆盖差异同样的提示词时好时坏参考文档顺序不稳定或引入无关内容固定文档排序规则重排检索结果清理干扰这张表我打印出来贴在工位上每次翻车就对照着查。多数情况下问题都能快速定位。6.2 两个典型Debug案例第一个案例是一个报表生成助手。用户要求模型根据销售数据生成周报但输出总是缺少环比和同比字段。我一开始以为是提示词指令不够清楚加了好几遍强调还是偶尔丢字段。后来反查Bad Case发现参考数据里根本没有上周和去年同期的数据模型自然没法算。问题出在第二阶段的信息准备而不是提示词。修正方案是把历史对照数据一起喂进去并在数据说明中标注字段含义和计算口径。改完之后丢字段的问题彻底消失。第二个案例是一个教育问答机器人。单轮问答效果不错但聊到第三四轮就开始乱。我检查发现用户在前几轮问的是A知识点之后切换到B知识点时对话历史里A的相关示例仍然占据上下文模型被旧内容干扰。解决方法是加了一个意图检测模块当识别到切换话题时清空前面的参考文档只保留一句简单历史摘要。同时在新指令开头加上忽略之前话题专注于当前问题。经过这样处理后续轮次的准确率明显稳定下来。这两个案例的共同点在于都不是靠换模型或堆提示词解决的而是回到上下文工程的具体阶段找到根因。这也再次说明精通上下文工程才是解锁LLM潜能的正确路径。最后分享一点个人体会做上下文工程心态上要像整理房间而不是表演魔术。每一次稳定的输出背后都是清晰的边界、干净的素材、合理的结构和及时的复盘。我自己刚开始时也追求各种复杂技巧后来发现把基础阶段做扎实效果反而最可靠。希望大家也能从这四个阶段入手一点点完善自己的AI工作环境让模型真正成为靠得住的搭档。
阅读完成 · 觉得有帮助？
