同一个大模型为什么有人几句话就让它交出漂亮结果有人写了一大段还是被它一本正经地胡说八道差别基本不在模型本身而在上下文工程。简单说上下文就是你发给大模型的全部信息——你说了什么、给了哪些背景、提了什么要求甚至你提问之前模型的回复也算。模型不是搜索引擎搜索引擎是去数据库里找现成答案大模型是根据你给的上下文现场造句。你没给它足够的约束和条件它就自由发挥你给了清晰的角色、任务、约束和范例它就像换了个人一样靠谱。这篇攻略就是给刚接触大模型的小白准备的。我会先从原理讲清楚为什么上下文这么重要然后给出一套可以直接套用的上下文模板再用三组实测对比让你直观看到差距最后把常见的坑和进阶玩法一次讲透。不管你是拿它写文案、整代码、做总结还是规划日程看完这篇都能少走很多弯路。1. 为什么同一款大模型别人一写就灵你一问就跑偏1.1 模型的记忆力和人类的短期记忆是两回事我们习惯用人类的思维方式去揣测AI这是第一个误区。你给同事布置任务说一次他就记住了第二天还能想起来大模型不是这样。它的工作方式更像一个只看当前屏幕的临时工你发过去的这段对话里写了什么它就以什么为依据对话框关掉它什么都不记得。每次新对话它都是失忆状态。这带来一个非常实用的小诀窍每次重要的任务都要在对话里重新、完整地交代背景。别指望它记得上一轮你提过的需求哪怕就在同一个会话里一旦聊了太久前面的信息在注意力中被摊薄了它也可能记不住关键内容。把所有重要信息放在离输出最近的位置永远是第一原则。1.2 上下文工程说白了就是工作交接我经常用一个比喻解释上下文工程——大模型就是一位能力很强但完全不了解你业务的新员工。这位员工智商在线、知识面广但他不知道你公司的规矩、不知道你要的风格、不知道你手头的项目背景。你能不能让这位新员工一次就把活儿干好完全取决于你的交接说明写得多清楚。上下文工程就是这套交接说明的方法论。它包含三件事第一喂给模型哪些背景信息第二以什么结构组织这些信息第三怎么让模型始终围绕着目标输出而不是越聊越偏。对小白来说不需要一开始就学复杂的向量检索、知识库这些高阶玩法先把每一次对话的交接说明写清楚你已经超过了90%的普通用户。2. 上下文工程的底层逻辑模型不是搜索引擎而是接话大师2.1 大模型的本质是概率预测想玩好上下文工程绕不开一个问题大模型到底是怎么工作的抛开学界那些复杂术语你可以把它理解成一个超级强大的接话大师。它做的事情其实只有一个根据你前面给的文字预测下一个最应该出现的文字是什么。你给它今天天气真它接着写好的概率就特别高你给它11它写2的概率也特别高。这个过程完全依赖上下文。你给的上下文越明确它的预测范围就越窄命中你心里的答案就越容易。反过来如果你只丢给它一句总结一下它的预测空间大到没边——它可以总结任何东西所以就会给出最安全、最空洞的废话。这也解释了为什么同样一个模型有的人觉得好聪明有的人觉得蠢得要死区别其实在喂给它的上下文质量。2.2 设计上下文的四个关键要素既然上下文决定了输出质量那什么是好上下文我拆解过不少高质量提示词发现它们基本都包含四个要素角色、任务、约束、范例。把这四个字母记成角任约例也行写提示词的时候挨个过一遍基本不会漏。要素作用小白最容易犯的错角色告诉模型用谁的视角、什么风格说话不设角色模型默认用百科全书中性腔说话任务明确要做什么事、交付什么结果只说帮我看看这种模糊动词约束限定范围、字数、格式、禁忌完全不提模型自由发挥范例给出一个期望答案的样子只说不想要什么不说想要什么我特别想强调角色这一条。很多人觉得给模型安排角色是玄学其实背后有道理大模型的训练数据里有海量的医生写病历老师批作业编辑审稿件这类文本当你让它扮演某个角色等于在它海量的输出风格库里按下了一个筛选开关输出的语气、结构和用词都会向那个角色靠拢。你可以试试同一个任务分别让它作为朋友回答和作为行业专家回答出来的内容跨度会非常大。2.3 清楚和模糊的差距比你想的大得多有朋友跟我说我明明问得很清楚了它还是答非所问。我把他的对话拿来一看发现他说的清楚是自我感觉良好。比如他问这个方案哪里有问题——这句话在人类之间没问题因为双方共享大量背景但对模型来说它不知道这个方案是什么、评估标准是什么、关注维度是什么。它在信息不足的时候只能猜一猜就容易偏。我建议你把每一次提问都想象成发给一个从没见过这个项目的实习生。你得多说几句这个方案是干什么的、你希望从哪几个角度评估、输出形式是列表还是段落、大概多少字。听起来麻烦但实际上只多花三十秒。这三十秒通常能让输出的可用性翻一倍以上。3. 小白第一套上下文模板从随便问问到稳定交付3.1 四步写出高质感上下文下面这套写法我用了很久也教给过很多刚入门的朋友。它不复杂但每一步都有明确目的。按顺序填空就行。第一步定义角色和语气。比如你是一名有十年经验的电商活动策划。目的不是玩角色扮演而是提前锁定输出的语气、词汇和判断标准。第二步交代任务和背景。把你要做的事情讲清楚包括前因后果。比如我负责一个化妆品的年中促销活动目标是把客单价从150元提升到220元目前预算有限不能做大规模投流。背景越具体模型的建议就越贴合你的实际情况。第三步写清约束条件。包括字数、格式、结构、必须包含的元素和绝对不能出现的内容。比如请给出五个方案每个方案控制在100字以内按成本从低到高排序不要提线下活动因为我没有人手执行。第四步给一个范例。范例是四要素里最容易被忽略但最有效的一个。你不需要给完整的样例给一个片段、一个开头甚至一个结构骨架都行。模型会照着这个模式模仿比你用十句话描述我想要什么风格都管用。3.2 一套可以直接复制的完整模板为了让你直观感受我写一个完整的上下文示例这个例子是请模型帮忙优化店铺简介你可以直接替换成自己的场景角色你是一名擅长写消费品牌文案的资深编辑文字风格简洁、有温度、不堆砌形容词。 任务帮我优化下面这段店铺简介。这家店主要卖手工皮具目标客户是25到40岁、注重品质的城市上班族。当前简介写得太平淡我希望它能让读者感受到手工制品的温度和细节感。 原文 本店经营手工皮具多年产品全部真皮制作工艺精良欢迎选购。 要求 1. 输出三个不同方向的版本一个强调工艺细节一个强调使用场景一个强调情感联结 2. 每个版本控制在80字以内 3. 不要用匠心品质保障这类烂大街的词 4. 语气自然像店主本人在说话不要像广告。 范例仅供参考的结构 每天开工前我都会先挑一遍皮料……注意看这个上下文里没有一句废话。它交代了角色、任务、客户画像、原文、约束、范例。模型拿到这段话输出的结果基本能直接用小改。你可能会觉得写这么长太累了但实际上下次遇到类似任务这段模板复制出来改一下对象和约束就行越用越省事。3.3 上下文写完后花十秒自查写完上下文先别急着发花十秒过一遍这个自查清单模型知道我是谁、为谁做、做什么了吗我有没有告诉它不要做什么注意这个要正面说因为后面踩坑部分会专门讲否定句式容易翻车。输出格式有没有指定表格、要点、段落、代码块格式不同可用性差很多。有没有给一个让模型模仿的样子另外还有一个进阶小技巧在上下文最后加一句如果信息不足先问我三个问题再开始。这句话能有效防止模型在信息缺失时硬编答案。实测中加了这句话之后模型经常会先追问关键信息产出质量明显更高。4. 实测对比同一个任务不同上下文的输出天差地别4.1 对比一写周报总结先来看最常见的场景。模糊写法是帮我把这周工作写进周报。模型大概率会生成一段极其通用的本周主要完成了项目推进、协调了各方资源……跟没说一样。优化后的写法是角色你是一名做事讲究结果导向的项目助理。 任务把我下面的零散工作记录整理成周报分本周完成风险与问题下周计划三块。 约束每块不超过5条每条先写结果、再写动作不要用积极推进相关工作这类空话整体语气像给老板汇报直接、利落。 记录 1. 和某供应商对完合同差价砍掉8% 2. 新版本上线后收到12个反馈其中3个是样式问题 3. 那个长期不回复的客户终于回了邮件约了周三再谈 4. 发现测试环境有个配置问题会拉长发布流程已改掉同样的工作内容模糊写法只是把流水账翻译成周报关话优化写法直接给出结论、数字和下一步行动。差异来源就是上下文里多出来的结果先行不要空话按三块组织这三条约束。4.2 对比二规划一次周末出行模糊写法是推荐个周末出去玩的地方。模型通常会给出泛泛的答案比如可以去郊区的公园野餐、博物馆看展、古镇走一走好像没错但毫无参考价值——它不知道你在哪个城市、几个人、预算多少、喜欢什么。优化写法加上这些上下文约束之后输出完全不一样角色你是一名熟悉本地及周边游的旅行规划师。 任务为一个四口之家两个大人、两个学龄前小孩规划周六一日游。 约束 1. 市区出发单程车程不超过1小时 2. 适合推婴儿车有室内备选方案以防下雨 3. 总预算控制在600元以内 4. 给出时间线几点出发、每个地点停留多久、午饭在哪解决 5. 输出成年人和孩子都感兴趣的安排。看见了没有模型不是不能给出细致可行的规划而是你给的筛选条件不够。把人的需求翻译成模型的筛选条件是上下文工程最核心的日常应用。4.3 对比三让模型帮忙检查代码这个场景对做开发的朋友很实用。模糊写法是我的代码报错了帮我看看。你没贴代码、没贴报错信息模型只能给出一堆可能的原因看着还挺有道理实际上一个都用不上。正确做法是把代码、报错信息、你尝试过的方法一次性打包给模型角色你是一名擅长调试Python代码的工程师。 任务下面这段代码用于计算一组销售额的平均值运行时出现ZeroDivisionError异常。 希望能帮忙指出1. 异常出的具体原因2. 修复方案3. 改完之后如何用一行测试用例验证。 代码 sales [120, 80, 0, 200] def avg(items): return sum(items) / len([x for x in items if x 0]) print(avg(sales))模型很快就能定位到分母是大于0的项数当列表里没有正数时分母为0自然就抛异常了。但这里的关键不是它能不能解决这个具体问题而是说上下文的完整度决定了模型是从猜测模式切换到分析模式。它拿到足够信息后可以像结对编程的同事一样跟你讨论而不是当个只会复读百科全书的查询工具。4.4 三组对比带来的启发把三组放在一起看结论非常清晰任务模糊上下文的典型结果完整上下文的典型结果周报总结空泛的本周推进多项工作分块、带结果、可直接粘贴周末规划放之四海而皆准的通用建议考虑天气、儿童车、预算的日程表代码排错可能原因有十种定位具体行、给出修法和验证方法模型还是那个模型变的是上下文。这就像同一把厨刀有人拿它切出蓑衣黄瓜有人只能切出土豆块。工具本身的能力上限就摆在那里差距全在使用者的手上功夫。5. 上下文长度的取舍不是写得越多越好5.1 信息过载会让模型抓不住重点讲了这么多上下文的重要性现在要泼一盆冷水上下文不是越长越好。很多人在学到要写清楚之后走向了另一个极端——事无巨细写一大篇背景、心路历程、所有数据全部堆进去最后模型输出时反而把次要信息当成了重点核心要求被淹没了。这背后的原因可以这样理解模型处理长文本时注意力是会被摊薄的。它像一个开会时听了一堆废话的人听到最后已经分不清哪句是领导真正下达的指令。缓解办法有几个把最重要的要求放在上下文的开头和结尾中间是背景细节关键约束可以适当重复强调如果内容太长优先把背景压缩成要点式摘要而不是全文粘贴。5.2 多轮对话的上下文污染需要主动清理另一个人人都遇到过的情况是在同一会话里聊了一堆无关话题后再让模型做一件正经事结果它的风格还停留在前面闲聊模式。这就是上下文污染。比如前面让它扮演一个幽默段子手聊了十分钟然后突然让它写一份严肃的产品说明它可能还是会夹带几句俏皮话。解决办法是在切换任务时明确告知下面是一个全新任务请忘记之前的角色设定。这句话很便宜但非常有效。更稳妥的做法是重要任务直接开新会话让模型在一个干净的上下文里工作。新会话不花任何成本别舍不得。5.3 什么时候值得用超长上下文现在很多大模型支持几十万甚至上百万字的上下文窗口于是有人习惯把整本小说、整个代码仓库一次性扔进去。但这不等于每次都该这么干。超长上下文真正好用的场景是需要模型对整份材料做全局分析比如通读一份两百页的合同找风险条款或者给它一份公司的历史项目文档让它回答我们之前有没有遇到过某类问题。这种场景下上下文里全是有效信息模型能自己定位和关联。而如果你的长文本里大部分是无关内容那效果反而不如先人工提炼一下再喂给它。我的习惯是先明确任务需要什么信息再决定喂多少材料而不是把能想到的全塞进去。5.4 上下文超限时的三种实用对策如果你真的需要处理的内容超过模型窗口上限有三种实际可用的处理方式。第一种是分段摘要法把长文档切成若干段先让模型对每段生成摘要再把所有摘要合起来让它做最终分析。第二种是分批问答法先问小问题定位关键内容在哪一段再让模型只针对那一段做深入分析。第三种是信息提取法第一次让模型提取所有涉及某主题的句子第二次基于这些句子做总结。这三种方法本质上是同一个思路把一次处理完变成先缩小范围再深入处理。这也是上下文工程里进阶的一环——学会掌控信息的流动方式而不是只会堆量。6. 踩坑实录五个最容易被忽视的上下文错误6.1 拒绝争辩式纠正模型不会因为你生气就变聪明很多人发现模型回答不对时会气冲冲地补一句不对重新想或者你刚才完全错了。这两个对话发过去之后模型大概率会道歉然后换一种方式再编一个答案——但它可能仍然错。因为问题并不在于它态度不端正而在于它一开始的信息就不够或逻辑就偏了。争辩式指令没有补充任何新信息它只是把以前的错误又生成了一遍。正确做法是补充新信息重新表达。比如你刚才的回答建立在A假设上但实际上前提是B请基于B重新推理。给模型一个新方向远比逼它重想有效。记住它不是一个会因为压力而提高正确率的考生它只是一个根据上下文重新生成内容的接话机。6.2 否定句式经常翻车模型对不要的敏感度不如要上下文里出现不要写太短不要用专业术语别提缺点这类否定表达时结果常常令人哭笑不得——模型偏偏写了很短的答案、满口术语、大谈缺点。这不是它故意唱反调而是因为否定句里包含了那个词本身模型在预测时反而倾向于生成与这个词相关的内容。解决方法是把否定句改成正向指令。把不要写太短改成请把每一条展开到至少100字把不要用专业术语改成完全用外行能看懂的白话解释遇到非用不可的术语时单独加括号注释。正面描述你想要的状态模型的命中率会高很多。6.3 在提问里漏答案模型会被你的选项带跑偏一个特别隐蔽的坑你在问题里写了这道题的答案到底是A还是B然后列出了A和B的详细内容模型经常会顺着你的选项走哪怕你隐藏了倾向。因为它看到的上下文里A和B是唯一的两个候选它只能二选一而选完它还会用一堆理由把那个选项论证得头头是道。更好的问法是这道题的正确答案是什么请给出推理过程再下结论。或者不要受我给出的候选干扰独立判断。我见过很多人把选项一字不差发给模型然后奇怪模型为什么偏偏选了错误的那个。其实不是模型蠢是你把错误答案也喂进了上下文给了它一个参考的机会。6.4 一次塞太多任务模型会取巧而非保质完成中文用户特别喜欢一口气提多个要求帮我分析这份报告总结三个要点再写一封回复邮件顺便做一个PPT大纲最后翻译成英文。模型往往会在后半程泄劲——前面还有模有样最后的任务明显敷衍。这不是模型偷懒而是它对长指令中的任务边界会模糊或者上下文太长后注意力不足。我的建议是一个对话窗口只聚焦一个主任务。如果实在有多个子任务把它们拆成连续的分步指令每完成一步确认结果再发下一步。例如先在对话里让它分析报告拿到分析结果后再追加基于上面的分析写一封回复邮件。这个习惯能显著提升输出稳定性。6.5 换场景不问重开旧角色污染新任务有人习惯在一个会话里连续处理多个独立任务比如先让模型做翻译然后切到编程再切到文案。如果不做任何提示模型很容易把之前的语感带过来——翻译完的翻译腔延续到代码注释里编程时的极简风延续到文案里。解决办法是每次切换任务时明确说接下来是一个新任务与之前无关请切换为XX身份。我个人的习惯是重要任务直接开新对话。开新对话的成本几乎为零别让上下文的历史包袱拖累新任务的质量。7. 进阶玩法让模型帮你写上下文建立自己的提示词库7.1 让模型扮演上下文优化师看到这里你已经能写出不错的上下文了。那下一步是什么让模型帮你优化上下文。这是一个很多人忽略的进阶技巧你现在写的上下文也可以作为任务交给模型来改进。你可以这样发角色你是一名上下文工程专家擅长把模糊需求改写为高质量提示词。 任务下面是我原本给模型的任务但它执行效果不佳。请帮我改写这段上下文 要求1. 明确指出我原稿缺失了哪些关键信息2. 给出一版优化后的完整上下文3. 解释每个改动的理由。 原稿 帮我写一个咖啡店的开业宣传文案要吸引人一点。模型会拆解出你缺失的信息——目标客群、门店风格、主打产品、投放渠道、文案调性、字数限制、转化目的然后给出一版结构化上下文。这个过程本身就是极好的学习素材因为它把什么是好上下文的隐性标准摊开给你看。7.2 把高频任务沉淀成模板库当你用上下文工程解决了几个高频任务后就该做沉淀了。我建议你在笔记软件里建一个提示词模板专区按场景分类写作类、分析类、编程类、生活类。每条模板记住几个字段适用场景、完整提示词、使用效果、踩过的坑。下次遇到同类任务把模板复制出来只改具体变量即可几分钟就能产出高质量结果。我自己最常用的一套模板结构是这样的模板名称产品文案评审 角色资深商品文案编辑注重转化率与品牌一致性 任务审阅下面的文案指出三个可优化的地方 输入待审文案 约束1. 每个优化点说明原因2. 直接给改后版本3. 不要客套 输出格式问题 / 原因 / 修改后文案变量只有待审文案一处其他全部固化。磨刀不误砍柴工这个模板库会随着你的使用越来越值钱。7.3 用思维链和角色扮演解锁更复杂任务先解释思维链它本质上是让模型把推理过程写出来再给结论。你在上下文里加一句请把推理步骤逐步列出来先分析再下结论输出的质量通常比直接给结论高出不少。原因很简单模型在逐步推理时每一步的上下文都在自我补充后一步能借助前一步的结果相当于它自己在扩展上下文。把思维链和角色扮演组合起来玩法就更多了。比如你可以让模型同时扮演多个角色进行辩论你一方面作为产品经理另一方面作为资深用户针对这个方案各提出三条理由然后综合两者给出最终建议。这种多维审视能暴露很多单一视角发现不了的问题特别适合决策场景。7.4 把上下文工程融入日常判断最后我想说上下文工程不只适用于大模型对话。你向同事交接工作、向设计师描述需求、向医生描述症状本质上都是在做上下文管理。你提供的信息是否完整、是否正面表达、是否有具体例子直接影响对方给你反馈的质量。练好这一套受益的不只是AI还有你所有的协作场景。我自己写了大量模板和踩坑笔记之后最深的体会是上下文工程没有什么神秘咒语它就是一种认真把需求说清楚的能力。模型的出现只是把这种能力的重要性放大了十倍。你愿意多花三十秒把背景和约束写完整它就能帮你省下三十分钟反复改稿的时间。最后分享一个小技巧当模型回答不够好时别急着否定它试试在上下文里追加一句你是否需要补充什么信息才能更好地回答这个问题很多时候模型不是不会而是它需要你多给它一个入口把真正关键的信息交出来。