GPT-6提示词瘦身实战：从长提示词到Skills的工程化转型

1. 先搞清楚官方为什么让我们给提示词“做减法”1.1 GPT-6 的推理结构变了长提示词反而成了负担最近关于 GPT-6 的讨论里OpenAI 官方反复强调一个意思把上下文留给真正需要模型判断的地方。这句话听起来像客套话但实际影响非常大。过去几年我们做提示词习惯把角色、背景、用户画像、历史经验、输出格式一股脑全塞进去总觉得写得越细模型就越懂我。但在 GPT-6 这批新模型上长提示词不仅不一定加分反而可能成为噪声源。我在自己常用的翻译任务上做过对比测试。旧方案是一份将近 800 字的提示词里面包含了角色设定、翻译流派、风格禁忌、三个例句、术语表、输出格式、结尾要求。换到新模型后用旧方案的输出明显“发虚”——语气生硬还会在结尾自作主张地加一段“解释一下我为什么这样翻译”。而我把它压缩成 80 字的纯指令后翻译结果反而更贴近原文的语感。这个现象不是玄学新模型在推理时会对上下文做更细粒度的注意力分配冗余描述会抢占本该落在关键词上的权重。1.2 Skills不是又一种提示词而是把能力外置跟着 GPT-6 一起火起来的还有 Skills技能。目前社区里讨论的 Skills可以理解成一组能被模型按需调用的指令、代码和外部工具集合。用生活里的例子来说提示词是你在餐厅口头告诉服务员“我要一份不要太辣、不要香菜、牛肉要嫩一点的炒饭”Skills 则是餐厅后厨墙上挂的标准化菜品卡只要你说“来一份招牌炒饭”后厨就会按卡执行不需要你把所有要求重复一遍。这正好解释了官方“做减法”的底层逻辑凡是能固定下来的高频能力都值得抽成 Skills而不是每次在提示词里手写一遍。我最早接触这个概念时走错过方向——我写了一个 500 行的“Skills”本质上只是把原来的长篇提示词换了个马甲。结果模型调用时经常因为描述气冲突而失效。后来按照官方推荐的思路重构成“描述 触发条件 执行步骤 例外规则”主提示词里只保留本次任务的具体意图问题才真正解决。1.3 瘦身的核心不是删而是划分职责先泼一盆冷水官方喊“做减法”不是让你把提示词都删到一句“帮我干活”。减法不等于简陋核心是重新划分职责——把“高频可复用逻辑”交给 Skills把“本次任务的特定目标”留给提示词。举个例子我给一个做企业服务的客户搭内容生成工作流。他们原来的提示词长达 1200 字里面至少 700 字是“如何写销售文案”的通用方法论。我做的第一轮改造没碰提示词而是先把通用方法论拆成一个名为 sales_copy_zh 的 Skill提示词只保留产品名、目标人群和本次调性。结果整个提示词从 1200 字缩到 150 字Token 消耗下降约四成模型输出的风格稳定性反而更高了。这个案例里真正值钱的不是“删了多少字”而是把职责边界划清楚了。2. 给提示词瘦身的实操三步法2.1 第一步用“任务倒推”找出真正的必要信息拿到一个老提示词先别急着删。我建议你先清空脑子只回答三个问题这个任务里模型需要知道哪些客观事实比如产品名、受众、字数、平台、语言。哪些行为约束是之前模型表现不好时你额外加的比如“不要解释、不要道歉、不要用‘首先其次最后’”。哪些内容只是在“让模型看起来更专业”的装饰比如大段人设描述、背景故事、长篇优秀案例。我刻意区分“事实”和“装饰”是因为很多提示词的问题不是信息太少而是噪音太多。像“你是一位资深的营销专家拥有十年经验”这句话在旧模型上确实能提升文风但在新模型上几乎不再参与决策。把这些装饰删掉通常不会损害输出质量。删完之后把剩下的内容按“任务目标 / 输入材料 / 约束条件 / 输出格式”四类整理。如果某句话既不属于这四类也讲不清用途它大概率就该删。这一步做扎实了后面两步才有意义。2.2 第二步把“散文式描述”改成“结构化片段”人读长句子没事模型解析长句子时会额外消耗注意力。把提示词改成结构化片段后指令边界会更清晰。看下面这个对比散文式结构化请你作为一位经验丰富的技术写作专家帮助我撰写一篇关于主题为 XX 的技术博客要求逻辑清晰、风格通俗易懂、避免使用过于官方的表达方式并且需要包含一些实际案例来辅助说明同时希望你在最后提供一个小结不少于 3000 字。任务技术博客撰写主题XX风格通俗、非官方要求必须包含实际案例结构问题描述 → 方案拆解 → 经验总结字数≥3000这两种写法表达的意思几乎一样但结构化提示词占用的 Token 只有原来的三分之一而且后续调整时也更好改。我最明显的感受是模型会严格按结构元素执行而散文里那些“并且”“同时”之类的连接词对机器来说只是纯噪音。这里有个小技巧输出格式里的符号尽量用统一的标记。比如“标题”“要点”“总结”这三个词每次都用带冒号的固定形式不要这次写“请提供标题”下次写“给出标题”避免模型在不同任务之间产生混淆。2.3 第三步用迭代收缩法找到“最小必要提示词”“最小必要提示词”是我自己起的名字意思是再删一个字输出质量就会明显下滑的临界点。找这个点的方法很简单就是逐步删减加反馈测试保留原提示词跑 5 到 10 次相同测试用例记录输出质量基线。每次删除约 20% 的内容。删除优先级从高到低背景装饰、重复强调、输出格式细节、行为约束。每次删除后都重新跑相同测试用例感受输出差异。如果发现某个版本质量明显变差回退到上一版再以更小的粒度比如 5%试探。反复迭代直到找到那个“再少一句就不稳”的临界点。我通常用同一批测试问题做评估而不是每次临时出题。因为临时出题无法排除随机性。这个流程跑下来大多数项目都能把提示词压缩 50% 到 70%同时保持输出质量持平。注意一个例外如果任务涉及安全、合规或对外发布的正式内容建议在临界点之上再保留约 20% 的冗余不值得为了省一点 Token 去冒输出失控的风险。3. Skills 开发实操怎么把可复用能力“装进技能包”3.1 先从最简单的最小 Skill 开始做一个 Skills 并没有那么玄乎。推荐的结构是文件夹内放多个文件比如skills/ summarize/ SKILL.md utils.py requirements.txt其中 SKILL.md 是核心描述文件里面包含技能名称、描述、指令、约束等信息。我写的最简单摘要技能的 SKILL.md 大约长这样--- name: summarize description: 对给定的长文本生成结构化摘要输出三个版本标题、要点、总结。 --- # Instructions - 先通读全文识别核心论点。 - 输出格式固定标题 / 要点最多5条 / 总结不超过3句。 - 不得在摘要中添加原文不存在的事实。 - 遇到争论性内容只陈述各方观点不评价对错。看起来确实像提示词但它和提示词最大的差别在于模型会通过 description 判断是否调用这个技能而且技能内部还可以挂载真正的 Python 工具函数。比如 utils.py 里写一个用来计算文本长度的函数SKILL.md 里就能指定“当文本少于 50 字时先调用 check_length 函数并返回提示”。这比在提示词里反复说“如果文本太短就怎么处理”可靠得多。3.2 开发一个可复用的 Skills完整步骤与字段说明我把 Skills 开发拆成四个阶段每一步都有对应的验收标准。第一阶段是定义触发场景。SKILL.md 顶部的 description 字段是整个技能能否正确被调用的关键。模型通常会先读 description再判断是否激活这个技能。我见过太多技能写在 description 里写“帮助用户完成各种任务”这种话既宽泛又没信息量。更好的写法是明确的触发条件比如“当用户请求创建或修改 React 组件、Tailwind 样式、页面布局时激活除非用户明确要求使用 Vue”。第二阶段是写执行流程。流程要按步骤拆分不要用大段散文。模型不是不能理解长文但按有序列表执行时的成功率明显更高。步骤与步骤之间的依赖关系要写清楚例如“先读取输入文件再识别技术栈最后给出方案”每一步末尾要交代下一步的入口。第三阶段是补充例外规则。这是很多人忽略的环节。一个技能如果缺少“什么时候不要用”的描述就会在不该触发的时候触发。我会在每个技能里至少写一条反向条件比如“当用户请求仅涉及信息查询、不涉及方案生成时不激活此技能”。第四阶段是测试与迭代。我会准备几类输入样本分别覆盖常规场景、边缘场景、冲突场景运行至少 5 次观察模型是否每次都能正确识别技能并执行到预期结果。这一步不能偷懒因为 Skills 在模型侧的判断存在一定随机性只测一次得到的结果不可信。3.3 提示词与 Skills 的结合模型实际项目里我会把主提示词压到 150 字以内然后挂载一到两个与任务相关的技能。举个例子任务写一篇产品介绍 产品xxx 受众企业 IT 决策者 语气专业但不拗口 请调用 write_copy_zh 技能处理正文结构调用 seo_check 技能生成关键词建议。主提示词里不再出现“请用三段式结构”“开头要写痛点”“结尾要加转化引导”这类描述因为这些规则已经写进 Skills 内部。整个提示词变成了一个变量替换模板换不同产品时只需要改产品名、受众和语气不用每次重新设计一套人设和流程。这种结合方式最大的收益是提示词的可维护性。原来 1000 字的提示词一旦要改你得从头到尾读一遍梳理逻辑现在改成 150 字主提示词加 3 个独立技能后要调整文案风格就只改对应的 Skill其他部分完全不动。在我看来这才是 OpenAI 官方强调“提示词做减法”的真正意图——不是让提示词变短而是让系统变清晰。4. 避坑、常见问题与我的几条真心话4.1 过度瘦身的两个典型症状我见过不少朋友在“做减法”的号召下把提示词压缩到只有一句命令比如直接写“总结全文”或“帮我写方案”。结果模型执行得很“空”——不知道该按什么格式输出不知道该面向谁也没有输出质量预期。这是典型的把减法和简陋混为一谈。另一种更隐蔽的症状是为了瘦身把关键约束全部挪到 Skills 里但 Skills 配置又没做好结果模型既没加载到技能又丢失了原提示词里的指令。我自己踩过一次很深的坑把一个底线约束写进测试用的 Skill主提示词里反而没提。后来切换场景时该 Skill 没有加载模型在输出里险些越过边界。从那以后我就给自己定了一条规矩不可漂移、不可交给场景判断的底线约束必须留在主提示词里。4.2 Skills 冲突与加载失败排查多技能环境下问题大多出在“描述识别”和“流程冲突”上。下面这张表是我常用的排查思路现象可能原因处理方式技能一直不被调用description 写得太泛或太窄重写 description明确触发条件同时命中多个技能技能描述关键词重叠为每个技能增加互斥触发条件调用后输出格式混乱SKILL.md 指令缺少执行步骤把流程拆成有序列表技能输出了完全跑偏的内容缺少边界条件和例外规则补充不适用场景和反向条件关于“做减法”这里有个反常识的点在 SKILL.md 里执行步骤时写得越明确、越步骤化模型调用越稳定。因为技能本质上不是纯自然语言指令它更像一段小型程序需要确定性的流程控制。所以提示词层可以精简便洁但技能层切忌偷工减料。4.3 版本管理与可迭代性我在实际工作中养成了给 Skills 做版本管理的习惯。技能文件放进 Git 仓库每次修改 SKILL.md 或工具脚本时强制写清楚变更原因。听起来繁琐但过两三周回头查问题时你会感谢当初的那行提交说明。没有版本管理的技能库最后一定会变成“哪个版本能用只有天知道”。同样提示词模板我也建议纳入版本管理。多个客户共用一套工作流时不要把提示词复制成十份而是做成参数化模板。模板版本更新时所有下游任务自动跟进只有真正有差异化的逻辑才单独拆出独立 Skill。把变量留给提示词把逻辑留给技能是这个体系稳定运转的关键。4.4 我的个人体会真正理解“做减法”之后我的工作方式变了很多。以前接到需求第一反应是写一篇长提示词现在会先问自己这个任务里哪些能力是可复用的能不能做成 Skills主提示词里只留变量和意图行不行说实话这个过程一开始很难受。因为拆分任务比写一篇长提示词要费脑子得多。你要先想清楚流程、边界、输入输出才能把技能写好。但坚持一段时间之后你会发现自己对任务本质的理解也更深了。很多时候不是你提示词写得不好而是你把可复用的流程和一次性需求混在了一起。最后分享一个实用小技巧在控制台里同时打开 Token 计数器和输出质量记录对同一任务分别跑“精简前”和“精简后”两个版本各记录 10 次结果。你会发现大部分场景下精简版在响应速度、稳定性和一致性上都占优。这个数据比自己对着屏幕感觉“看起来差不多”要靠谱得多。