前段时间我帮朋友调一个GPT-6相关的小工具对方直接把一份几千字的提示词发给我说是经过多次优化迭代的版本。我扫了一眼里面光角色设定就堆了五个资深架构师、UX专家、性能优化师、数据库管理员、安全审计员。我问他实际效果怎么样他说说不清楚有时候很好有时候莫名其妙。后来我花了半小时帮他把提示词压缩到原来的五分之一单独跑了一轮测试集输出质量和稳定性反而都上去了。OpenAI官方在GPT-6和Skills相关文档里反复强调的那个观点——提示词要做减法某种程度上就是对这类现象的回应提示词不是越长越好堆砌设定的时代应该过去了。这篇文章我不打算讲太多理论重点分享我这段时间在GPT-6和Skills上做提示词瘦身的实操方法、压缩模板和踩坑记录给正在跟长提示词搏斗的人一个参考。1. 提示词膨胀的根源为什么上下文越大反而越要克制1.1 大上下文窗口带来的稀释效应GPT-6预览版发布后很多人第一反应是上下文窗口更大了提示词是不是可以写得更详细把需求描述得滴水不漏模型不就能更精准地执行吗结果恰恰相反。我自己的测试里把同一个任务分别用500字和5000字的提示词去跑短提示词的效果反而更稳定。这不是玄学而是大上下文窗口带来的稀释效应。当上下文很长时模型需要在海量token里定位关键信息。这就像开会时有人在会上读了40页报告真正的决策点只有两行听会的人反而容易把重点丢了。模型也一样提示词里如果存在大量重复、模糊、甚至相互矛盾的表述它就会倾向于平均用力把那些真正重要的约束也当作普通背景信息处理掉。这就是官方强调做减法的底层逻辑提示词的核心是向模型传递准确的意图而不是把文档库搬进上下文。我看到过很多几千字的提示词真正起作用的可能只有其中30%的内容剩下的70%不仅不帮忙反而在稀释关键指令的权重。上下文窗口变大本意是让模型能处理更多输入材料不是让你把提示词当仓库用。1.2 模型注意力机制的偏好与信息密度从模型推理机制来看注意力分配和信息密度直接相关。高信息密度的提示词能让模型在早期就捕捉到核心意图后续推理时持续围绕这个意图展开。而低信息密度的提示词模型需要不断在长上下文里做信息检索既增加响应延迟也容易在检索过程中跑偏。我自己做过一个对比实验同一个前端代码审查任务A版提示词是800字的详细描述B版提示词压缩到200字但保留了所有关键约束。在同样的40个测试用例上跑B版首次输出符合预期的比例明显高于A版。这不是个别现象后来我在SQL生成、文案改写、数据分析几个任务上都看到了类似的趋势。还有一个值得注意的现象当你删掉那些冗余内容后模型在关键约束上的遵循度会明显提升。比如你在提示词里写了输出必须是JSON格式但又用2000字描述了各种其他细节模型反而容易在某个环节忘记JSON格式的要求。把提示词压缩到核心之后输出必须是JSON格式这条指令在上下文里的相对权重变大模型遵守得更坚决。1.3 官方文档措辞变化的信号细心的开发者会发现OpenAI官方文档里关于提示词的建议从之前的描述需求要尽可能详细逐渐转变为用简洁明确的语言描述任务把可复用的逻辑放入Skills。这个变化不是偶然的。GPT-6引入了更复杂的推理链路和工具调用能力提示词的角色正在从说明书转向调度指令。模型不再需要你把每一步都写清楚它自己具备规划能力。你给它的应该是目标、边界和验收标准而不是具体到每个标点的操作步骤。这个转变是很多人还没意识到的——他们还在用GPT-3.5时代提示词越细越好的思路去写GPT-6的提示词结果就是上下文塞得满满当当模型执行起来反而笨手笨脚。我个人的理解是既然模型本身的推理和规划能力变强了提示词就应该把重心放在定义问题而不是定义步骤上。你告诉它要什么、不要什么、输出给谁看剩下怎么实现的部分模型自己的规划能力比你手把手教更可靠。2. 瘦身第一步给提示词做需求拆解去掉三类无效内容2.1 冗余设定与角色堆叠我见过最典型的膨胀提示词是这样的你是一位拥有20年经验的资深前端架构师也是一位UX设计师同时熟悉后端开发和数据库设计你还精通性能优化和可访问性请帮我审查这个组件。堆叠角色看似是在给模型赋能实际上是在制造混乱。角色越多模型越不知道该以谁的视角说话。更好的做法是明确一个核心角色然后用任务描述去补充上下文。比如你是一个前端开发专家任务是审查下面这段组件的可访问性这就够了。你需要的是模型在这个任务里扮演什么角色而不是给它一份简历。删掉多余的角色设定不只是在给提示词瘦身也是在降低模型切换视角时的出错概率。实测下来多角色提示词的输出风格往往比较飘忽有时偏向架构师视角有时又变成UX视角反而不如单一角色稳定。2.2 过度的边界条件列举另一种常见膨胀是穷举所有可能的边界情况如果用户输入的是数字请转成字符串如果是字符串请检查长度如果是空值请返回默认值如果是负数请报错……这些边界条件不是不能写而是应该按重要性排序。真正需要写的是那些模型容易犯错的场景而不是把所有可能情况都列一遍。GPT-6的基础能力已经能处理大部分常见边界你只需要补充它可能忽略的部分。我自己有个经验把所有边界条件写进提示词不如把关键验收标准写清楚。比如输出必须通过XXX校验——模型拿到验收标准后自己会去推演需要处理哪些边界情况。这比你逐条列举更可靠因为模型的推演是动态的能覆盖到你没想到的边界而穷举法总有遗漏。之前我在调试一个工具时遇到model provider openai not found的报错如果按以前的做法我会把整个配置文件、日志、目录结构全塞给模型然后说请帮我找到问题并修复。但实际上这个报错的定位路径很清晰配置文件里用的provider名称和实际注册的provider名称不一致导致的。把问题描述压缩成工具加载时报错model provider openai not found错误指向config.toml中的provider字段请给出修复方案反而让模型更快定位到了根因。2.3 反复重复的指令和模板套话还有一类是咒语式写法在提示词开头说一遍要求中间强调一遍结尾再强调一遍。很多人觉得重复能加强约束实际上对现代模型来说重复指令并不会显著提高遵守率反而占据宝贵的上下文空间。比较典型的是那些思维链套话比如请一步步思考、请仔细分析。GPT-6本身就具备较强的推理能力很多时候你不需要在提示词里写这些。让模型自行决定推理路径往往比强制指定步骤的稳定性更好。实测下来删掉强制思维链的指令对结果影响很小甚至在某些创造性任务上效果反而提升了因为模型不再被必须一步步来的框架束缚。模板套话还有一个隐蔽的问题它们会让提示词看起来结构完整让人产生这段提示词质量很高的错觉。但实际上那些通用的过渡句、客套语、背景铺垫对模型理解任务几乎没有任何帮助。你真正需要保留的是那些具体到这个任务的信息而不是任何任务都能套用的废话。3. Skills模块化把固定逻辑从提示词里搬出来3.1 从一个案例看Skills能替代什么这里说的Skills就是指OpenAI推出的技能包功能。它允许你提前定义一组可复用的逻辑让模型在需要时自动调用。听起来和提示词有点像但理念完全不同提示词是每次对话都要携带的随身行李Skills是按需加载的工具包。我拿前端开发举例。以前我写一个审查组件可访问性的提示词需要把无障碍规范、常见问题清单、检查步骤全部写进提示词里每次都复制粘贴一大段既占上下文又容易在复制过程中出岔子。有了Skills之后我把这些规范封装成一个可复用的技能提示词里只需要一句使用a11y-review技能审查以下组件剩下的事情交给技能去处理。这带来的直接好处是对话上下文里不再需要塞满那些固定知识模型能聚焦在具体的组件代码上。提示词变短了效果却更稳定了因为技能里的逻辑是经过验证和迭代的不用每次都在提示词里碰运气。我在几个常规任务上都做了这样的改造整体体感是上下文空间被释放出来了模型输出质量更稳定了。3.2 Skills文件结构的组织思路Skills具体怎么组织官方文档给的是参考结构这里分享我个人比较顺手的配置方式。我习惯把Skills设计成三个层次目标定义、执行规则、验收标准。目标定义负责说明这个技能是干什么的执行规则负责描述处理的流程和约束验收标准负责说明什么样的输出是合格的。比如一个代码评审技能目标定义就是对指定代码进行静态评审执行规则包括优先检查安全问题、再检查性能问题、最后检查代码风格验收标准是输出按严重程度排序的问题清单每条建议附带修改示例。把它落到配置里大概是下面这个样子name: code-review description: 对指定代码进行静态评审输出按严重程度排序的问题清单 rules: - 优先检查安全漏洞包括注入、越权、敏感信息泄露 - 其次检查性能问题包括不必要的渲染、过大的依赖、内存泄漏风险 - 最后检查代码风格包括命名、结构、注释 output: format: markdown fields: - severity: 问题严重程度critical/warning/suggestion - description: 问题描述 - suggestion: 修改建议附带代码示例这样做的好处是当模型调用这个技能时它拿到的不只是一堆规则而是一个完整的执行框架。它知道自己要做什么、按什么顺序做、做到什么程度算完成。这比在提示词里写请帮我仔细检查代码要可靠得多。3.3 提示词Skills的推荐比例根据我这段时间的实测比较理想的状态是提示词只负责描述本次任务的具体目标和输入材料Skills负责处理这类任务的一般逻辑。两者分工明确就不容易出现提示词和技能冲突的情况。以我的实际使用习惯来说一个50行的提示词加上一个100到200行的技能配置文件就能覆盖过去那种500行提示词的效果。而且维护起来更舒服提示词每次按任务微调技能则是稳定沉淀。提示词瘦身和技能沉淀是同一件事的两面——把可复用的部分抽出去剩下的自然就精简了。需要注意的一点是技能文件里的内容本身也需要保持精简。不要把所有历史经验都塞进技能里只保留那些对你的任务真正有效的规则。一个臃肿的技能和一条臃肿的提示词本质上是同一个问题信息过载。技能里规则太多模型在调用时同样会面临注意力稀释的问题。我见过有人把一个技能写成了上万字的操作手册那还不如直接在提示词里写呢。4. 实操三段式压缩模板与前后对比4.1 基础模板角色、任务、约束我最后沉淀下来的提示词基础结构其实特别简单就三个部分角色、任务、约束。角色用一句话说明模型的视角任务用一两句描述要做什么约束负责说明这个任务里的红线、输出格式和其他硬性要求。粗暴一点的示例是这样的角色你是一名资深前端工程师 任务审查以下React组件的性能问题 约束 - 只输出具体可执行的建议每条建议附带代码示例 - 不讨论代码风格问题 - 不确定的问题标注待确认这样一个提示词用不到100字就能写清楚。很多人会觉得这也太简单了吧但实测下来稍微复杂的任务也能跑得不错。复杂任务的处理逻辑应该交给模型自己规划而不是在提示词里事无巨细地铺开。4.2 压缩案例从300行到60行的完整过程这里我拿一个实际案例来演示。之前我写过一个SQL生成器的提示词有300多行里面包含了各种表结构的描述、各种查询模式的示例、各种禁止事项。后来我做了三轮压缩。第一轮把各种查询模式的示例改成只保留两个最典型的示例其余用一句话概括规律。这一刀下去去掉了大概100行。第二轮把各种禁止事项整理成一条总则输出必须在语法正确的前提下最简宁可少查询不可错查询。又去掉了约80行。第三轮把表结构的描述拆到外部数据源里提示词里只留表名和关键字段并加了一句完整表结构参看data/schema.md。最终提示词压到了60行左右。结果如何在同样的测试集上60行版的SQL正确率反而比300行版略高错误类型从问东答西变成了偶发小错误。这说明压缩掉的那些内容里大部分确实是噪声而不是有效信息。其中让我印象最深的是第三轮改动。以前我总觉得表结构必须写进提示词模型才知道有哪些字段可用。但实际上把表结构放到外部文件里提示词里给它明确的读取路径效果反而更好。因为表结构是稳定的数据不需要每次对话都重复加载而提示词里只需要保留当前这次查询要关注哪些表这样的灵活信息。4.3 用输出示例代替过程描述最后这个技巧是我觉得最值得推荐的把你要怎么做的描述替换成你要输出什么的示例。比如以前我会写请先分析需求然后设计数据库表结构接着编写SQL语句最后检查语法……其实这一整段流程描述完全可以删掉只要给一个输入和对应的期望输出示例模型自然能学会。在技能或提示词里加一个输入-输出示例块比大段规则的效果好得多。尤其是那些格式要求严格的任务比如JSON输出、函数签名、表格渲染等给一个完整示例模型的输出格式稳定率能上一个台阶。我目前的习惯是每个重要任务都会维护一个3到5组的示例库每组包含一个典型输入和对应的理想输出。这些示例不需要多但一定要覆盖最常见的场景。模型从示例里学到的格式感觉比从规则描述里学到的要准确得多。5. 避坑清单瘦身失败的五个常见原因5.1 把做减法理解成删内容很多人在听到提示词做减法之后第一反应就是把提示词删短。这其实是个误解。减法的本质是去掉无效内容保留有效信息而不是越短越好。如果为了短而砍掉了关键约束那么模型输出质量必然下降然后大家就会得出做减法没用的结论。我自己有一个经验每删掉一段内容都要问一句这个信息模型能不能从别的地方获取。如果能那可以删如果不能那就要保留或者把它转移到技能里。比如任务背景、行业术语、特定规范这些如果模型没有内置知识你就不能指望删掉后它还能凭空知道。判断信息是否有效一个简单的标准是如果把这段内容删掉模型输出会不会出现明显的偏差。如果会说明它是有效信息如果不会说明它是可有可无的噪声。用这个标准去扫自己的提示词基本上就能扫出一批可以压缩的内容。5.2 压缩后上下文信息不足还有一种情况是提示词瘦身到位了但输入材料里信息不足。模型明明需要某个数据你的提示词里又没提到它在哪里可以找到模型就只能靠猜。瘦身应该瘦冗余的指导但不能瘦必要的事实。举个我踩过的坑。我之前写过一个数据清洗的提示词为了瘦身把原始数据的字段含义说明整段删掉了结果模型在清洗时把两个语义接近的字段搞混了。后来我把字段含义重新加回去问题就消失了。这个字段含义属于必要的事实不是冗余的指导不该删。解决办法是把那些必要的事实在提示词外补齐比如放到附件、数据文件里或者在提示词里明确给出获取路径。不要把模型当作什么都知道它只知道你给它的东西——以及它在训练数据里学过的东西。凡是任务相关的特有信息都必须显式提供给模型。5.3 模型版本切换时提示词失效这个问题在GPT-6这类新模型上特别明显。新模型对提示词的理解方式和旧模型有差异同一段提示词在旧模型上效果很好换到新模型上可能就不稳定了。这不是提示词本身的错而是模型行为发生了变化。所以每次切换模型版本都应该重新跑一遍你的核心测试用例看看提示词是否需要调整。特别是那些依赖旧模型行为习惯的历史提示词大概率需要针对新版做一轮再瘦身。我可以提一个具体的信号如果你发现同一段提示词在旧模型上输出格式稳定但在新模型上偶尔会出现格式漂移那很可能就是你提示词里某些冗余表述在新模型的注意力机制下被忽略了。这时候需要做的不是把提示词加长而是精简表达把关键指令放到更显眼的位置。5.4 Skills优先级与提示词冲突如果同时使用技能和提示词还可能遇到两者冲突的情况。比如技能里定义了一套输出格式提示词里又指定了另一套格式模型就会犹豫到底听谁的。我建议在提示词里明确边界在关键处写明以下为本次任务的具体要求或者反过来指定技能规则的优先级更高。二选一但一定要明确不能模棱两可。我自己习惯在提示词里加一句本次任务以提示词要求为准技能规则仅作为补充参考这样模型在两者冲突时就知道该怎么取舍了。这种冲突在刚开始使用技能的阶段特别容易出现因为你会下意识地在提示词里保留过去那些完整描述同时又新建了技能两者内容高度重叠。正确的做法是一旦把某个逻辑写进技能就把提示词里对应的部分删掉让技能接管。5.5 没有建立效果回测机制最后一个坑比较隐蔽很多人瘦身之后凭感觉判断效果好像跟之前差不多或者感觉变好了这种判断方式太主观。这里分享一个我自己的做法维护一个小的测试集里面放上5到10个典型输入每次调整完提示词或技能就拿这组测试集跑一遍记录输出质量的对比。我自己就是这么干的看起来有点麻烦但实际上是效率最高的做法——没有回测所谓优化很可能只是在原地打转。回测的时候不需要太复杂的评分体系我一般只看三个维度输出格式是否稳定、关键约束是否全部满足、结果是否符合任务目标。每个维度打一个通过/不通过的标记对比调整前后的通过率。这个通过率比任何感觉都靠谱。说回我自己。提示词瘦身这件事真正的难点不是技术而是克制。我自己也经历过那种多写一点才安心的阶段总觉得把所有情况都说明白模型才不会出错。但后来我发现模型的容错能力比我想象中强得多真正让它出错的反而是那些互相矛盾、信息过载的提示词。给提示词做减法本质上是信任模型的基础能力把精力放在定义清楚目标和边界上。如果你正在GPT-6上调试提示词不妨先从删掉三分之一的字数开始看看效果。大概率会有惊喜也可能会踩到上面提到的某个坑——但这两件事加在一起才算是真正入了做减法的门。