我不止一次跟身边搞AI应用的朋友说提示词工程这东西做加法容易做减法难。最近OpenAI在GPT-6相关的官方技术材料里明确提出要“重新思考 Skills 和提示词”核心方向居然就是让大家给提示词“做减法”。看到这个信号我第一反应是早就该这么干了。过去这两年我见过太多把提示词写到两千字、恨不得把模型每个动作都编排一遍的“剧本党”。结果模型不但没变听话反而经常在奇怪的地方自作主张。这次官方把“少写一点”当成正经工程方向来推说明一个问题我们对提示词的理解可能从根上就要调整了。这篇文章我就结合自己折腾GPT-6模型、Skills功能以及日常提示词工程的实操经验把瘦身的思路、具体改法、避坑要点一次说清楚。不管你是刚接触提示词的新手还是已经在用Agent类产品做应用的老手这篇文章应该都能给你一点参考。1. 官方“做减法”背后的信号提示词不是越长越好先说说我为什么对这次“做减法”这么有共鸣。早期做提示词工程大家普遍有个错觉写得多说得清模型懂我。于是各种几百行的“人设小传”、“思维链剧本”、“禁忌清单”满天飞。我也干过这事给一个内容总结提示词配了二十多条输出规范最后模型为了满足格式把核心内容都挤没了。后来跟几个做模型推理的朋友聊才慢慢明白一个道理提示词越冗长占用的上下文越多模型要“记住”的约束就越重。你每加一条规则都会分散模型对核心任务的注意力。有些规则之间甚至互相打架比如“回答要简短”和“请分五部分详细说明”同时出现模型只能猜你到底想要哪个。官方这次在GPT-6的研究方向里强调“更少的提示词、更稳定的Skills”本质上就是在引导大家把注意力还给模型。1.1 长提示词时代我踩过的三个坑第一个坑是“角色设定过头”。以前我写提示词特别喜欢给AI安排一个完整人设从性格到说话习惯恨不得写三百字。结果模型确实“入戏”了但经常为了符合人设而牺牲内容准确性。你问它一个技术问题它先来一段“作为您的私人顾问我深感荣幸”你说气不气。第二个坑是“约束条件堆叠”。一个简单的翻译任务我非要加上“专业术语保留英文”“语气要正式”“不要使用被动语态”“每句不超过20字”“要体现原文风格”……这些条件单个看都对但堆在一起就是灾难。模型每句话都要同时满足五六个约束最后产出的内容又硬又别扭。第三个坑是“把提示词当代码写”。有些人痴迷于“结构化提示词”搞一堆XML标签、JSON格式、变量占位符。这种思路在做复杂Agent流程时确实有用但用在普通对话任务上反而让模型花大量时间去“解析格式”而不是思考内容。我见过最夸张的提示词开头一段“你是我的私人助手接下来请严格按照以下schema输出”就直接占了上下文一千多个token。1.2 OpenAI为什么选在这个节点喊“瘦身”这次跟GPT-6一起被反复提及的还有Skills这个概念。官方公开材料里专门有一篇叫“考虑GPT-6 Astra的Skills和提示词重构”的东西核心观点就是模型能力越强越不需要你在提示词里替它把每一步都想好你更需要的是给它一个清晰的目标以及必要的工具。为什么是现在我的理解是早期GPT-4那批模型推理能力有限你不写细一点它真的会跑偏。但到了GPT-6这个阶段模型本身的理解和规划能力已经上了一个台阶。你再拿写给小学生的说明书去指挥一个研究生只会限制他的发挥。提示词瘦身不是官方一拍脑袋的决定而是模型能力进化之后的必然选择。1.3 做减法的本质是重新分配智能说白了“给提示词做减法”不是让你把需求说简单而是让你把“怎么做的空间”还给模型。你要管的是目标和边界模型擅长的是路径和细节。这个认知不转变你写多少提示词都觉得不够用。我自己的体会是把提示词从一千字压到两百字之后输出质量反而提升了一个档次。原因是模型可以把更多“精力”放在理解和生成上而不是在提示词的字里行间寻找你到底要什么。这个过程有点像项目管理你给团队定清楚目标和红线剩下的让他们自己发挥如果你天天插手每个执行细节团队反而不会干活了。2. GPT-6 与 Skills先看清这波更新的全貌既然要聊“GPT-6 Skills 瘦身实操”就不能不先把这两件事的底细摸清楚。很多朋友一听说“Skills”第一反应是“这不就是插件吗”“这不就是自定义指令吗”其实对但又不完全对。2.1 GPT-6 给使用方式带来的变化GPT-6这一代我听一些先行测试的朋友反馈最明显的变化是长上下文能力和指令遵循能力的提升。过去你让模型做一件复杂的多步任务它经常做到一半就忘了初始目标或者把步骤顺序搞乱。到了GPT-6这类问题明显少了。这也带来一个新的使用思路以前需要你用提示词反复“拽”着模型往前走现在你只要给它一个终点它能自己规划路径。比如以前写“你要先分析用户需求再拆解任务再制定计划再……”这些步骤提示词现在可以直接简化为“帮用户解决XX问题”。模型自己就知道该怎么分步。这是提示词能瘦身的底层原因之一。2.2 Skills 到底是什么Skills可以理解为一组预置的指令、示例和工具调用的组合体。它在启动时被注入到模型上下文中相当于给模型植入一个“专业身份”或“操作手册”。跟传统提示词不同的是Skills通常更结构化可以包含多个文件也可以挂载工具调用逻辑。举个例子你想让模型帮你做前端开发传统做法是把“你是前端专家请遵循以下编码规范……”写进系统提示词。有了Skills之后你可以把编码规范、常用组件库、项目结构说明、代码风格样例这些内容拆分成一个Skill包。需要的时候加载它不需要的时候就卸载不会长期占用上下文。这对资源效率的提升是实打实的。2.3 提示词与Skills的边界我在实操中总结了一条经验提示词管“目标”Skills管“能力”。提示词回答的是“用户这次想要什么”Skills回答的是“模型遇到这类任务时应该具备什么背景知识”。两者配合才能让模型在正确的轨道上发挥。所以我在设计提示词时基本不往里面塞背景知识了。需要历史文档、行业术语、代码规范这些静态内容我会优先做成Skill提示词里只写最核心的任务描述和必要的输出约束。这个习惯形成之后我的提示词文件普遍减少了60%以上的体积但模型的表现反而更稳定。2.4 一种简单优雅的管理方式我的建议是把你的完整提示词拆成三层第一层是“系统级精简指令”管全局目标和通用规范控制在一百字以内第二层是“任务级提示词”每次跟模型对话时按需撰写控制在两百字以内第三层是“Skills包”把重复使用的知识、流程、样例放进去按需加载。这样的分层结构胜在清晰。哪怕你接手的项目没有GPT-6用的是GPT-4或者开源的模型这套思维方式一样通用。我经常跟人说提示词瘦身不是某个模型的专属技巧而是一套通用工程素养。3. 提示词“瘦身”五步实操法空谈理念没有意义直接上实操。下面这是我目前总结的、已经跑通了一段时间的五步瘦身法每一步我都写了具体怎么操作以及我在过程中踩过的坑。3.1 从“角色描述”开刀你去看自己写的提示词开篇大概率是一段角色设定“你是一个拥有十年经验的资深文案专家擅长写各种风格的营销文案曾经服务过多个500强企业……”这段话我建议直接删掉90%保留一句“你是资深文案专家”就够了。为什么因为模型经过预训练和指令微调后对“专家”角色的理解已经不需要你额外堆砌履历来加强。你写越多的“专家背景”它反而越倾向使用华丽但空泛的措辞来“表演专家”。我做过对比测试同样一个产品文案任务简版角色描述比详细版角色描述输出内容在信息密度和落地性上反而更高。3.2 砍掉重复约束留一条主链路这个是我以前最容易犯的错。一条提示词里同时想管“语气”“结构”“长度”“风格”“格式”“禁忌”而且这些约束之间经常重复甚至矛盾。现在我给自己立了一个规矩一条提示词只设一个核心约束其他全部扔进Skill或者干脆放弃。比如做会议纪要我就只约束“按‘结论—依据—待办’三段输出”。语气、措辞、格式这些细节让模型根据内容性质自己判断。实测下来模型给出的纪要结构更清晰而且不会因为被过多规则压制而变得机械化。3.3 给模型“决策权”而不是写剧本很多人写提示词喜欢把执行步骤一条条列出来“先分析再列大纲再写初稿再修改再润色……”在早期模型上这一套确实有用但在GPT-6这一代我建议你试试不写步骤只写结果要求。比如写文章你只要告诉模型“写一篇关于XX的1500字文章要求案例详实、观点清晰”它自己会决定怎么组织内容。你会发现它给出的结构可能比你自己编排的还要合理。这不是玄学而是新一代模型的规划能力确实增强了。你给的步骤越多反而限制了它的发挥空间。我自己的原则是如果模型不按你说的步骤执行也能达到目标那就别写步骤。把步骤提示词留给那些模型不主动触发、不写就容易漏的多步任务。3.4 把稳定能力沉淀为Skill这一步是瘦身的关键升级。如果你发现某类任务你反复在提示词里写同样的背景知识、同样的样例、同样的流程那就该考虑封装成Skill了。我做过一个“竞品分析”的Skill里面包含了竞品分析的框架、数据维度、报告结构模板、几个典型案例。过去我要在每次提问时写一大段话去描述这些现在只需要在对话开头说“用竞品分析Skill分析一下A公司和B公司”。提示词从五百字降到了二十字输出质量却更稳定因为Skill里的内容是我多次调优后固定的精华版本不会每次提问时被遗漏或者改写。3.5 建立精简提示词的迭代基线很多人不知道怎么判断提示词“瘦到位”了没。我的方法是每次精简完都把旧版和新版跑同一批测试用例对比输出质量。建议准备至少10个有代表性的测试场景覆盖正常需求、边缘需求、已知的失败案例。哪个版本效果好就留哪个子虚乌有地“感觉新版变好了”不算数。我之前做翻译提示词瘦身从800字减到150字之后一开始确实有部分专业术语翻译质量下降。后来我把术语表单独拎出来放进了Skill提示词主体只保留翻译目标和语言风格效果才稳定住。没有基线测试我根本不敢确定是哪里出了问题。3.6 一个完整的瘦身对比案例给你看一个真实案例。我以前写过一个“写产品文案”的提示词结构长这样简略版你是一名拥有十年互联网营销经验的专业文案专家擅长写作直击用户痛点的产品文案尤其熟悉SaaS产品、消费电子产品和知识付费产品的营销逻辑。请你根据以下产品信息撰写一篇产品介绍文案要求1. 开头要有吸引眼球的Hook2. 正文要分点列举产品核心优势3. 每个优势都要结合使用场景说明4. 语言要生动活泼避免专业术语堆砌5. 结尾要引导用户行动6. 字数控制在800字左右7. 请先输出大纲我再确认后再写正文。现被我精简成了产品信息XXX。请写一份800字产品介绍文案要求案例感强、语言接地气、结尾引导试用。你没看错就这么多。让模型自己决定要不要先列大纲自己决定怎么组织优点和场景我只要结果质量过关就行。实测两个版本的文案质量精简版在“可读性”和“转化感”上甚至在多数对标测试里优于长版。这是因为模型不再被结构规则束缚得以把更充足的上下文注意力集中到“产品理解”和“文案表达”上。4. Skills 开发与使用避坑指南如果说提示词是“临时的指令”那Skills就是“长期的资产”。但资产也有资产的问题越用越杂、越用越乱是常态。这里我把自己开发与使用Skills的避坑经验整理一下。4.1 一个Skill只做一件事刚开始做Skills的时候我犯了跟写提示词一样的毛病恨不得把同一个领域的所有能力塞进一个包里。结果一个“前端开发”Skill里既有代码规范、又有组件库说明、还有项目部署文档模型加载后反而不知道该优先用哪部分。正确的做法是按“单一职责”拆Skill。后端开发、前端开发、数据库设计、部署运维拆成不同的Skill。哪怕它们有一定关联也先用主Skill调用子Skill的方式去管理而不是把所有内容堆在一起。单一职责的Skill更好维护也更容易测试。4.2 命名与描述决定调用成功率这是目前很多教程里都没重点讲、但实际最重要的细节模型的Skill调用机制很大程度依赖你对Skill“名称”和“描述”的填写。你写“前端开发规范”和“前端开发”看起来差不多但对模型来说前者调用意图更明确后者容易被误认为口语。我的经验是描述里要明确写清楚“这个Skill适合处理什么类型任务”“不适合处理什么任务”“调用时需要提供哪些关键信息”。比如我做了一个数据可视化Skill描述里会写“适用于需要从结构化数据生成可视化图表的场景可自动识别常见图表类型用户只需提供数据来源和展示目标”。4.3 提示词、Skill与系统消息的分工表我列一个我自己在项目中使用的分工表你可以直接抄组件职责建议长度更新频率系统消息定义全局目标、边界、通用行为准则100字以内低任务提示描述本次具体任务目标、交付物200字以内每次对话Skill承载领域知识、流程模板、样例、工具配置按需中这张表我建议你打印出来贴屏幕上每次写提示词之前先想想我现在写的东西属于哪一层。不该放系统消息的别硬塞不该写进任务提示的也别堆。各层职责清晰了模型的行为自然就清晰了。4.4 本地调试Skills的正确姿势Skills开发不能指望一次成功。我自己的调试流程是先在普通对话里把Skill里的指令直接作为提示词输入测试效果确认稳定后再封装进Skill包Skill包上线前再跑一遍预置的测试用例集。这个流程看着简单但它能帮你少走很多弯路。很多人一上来就把Skill包写好然后直接跑任务出问题了也搞不清是Skill内容的问题、还是调用时机的问题还是模型本身的问题。按“先提示词、再Skill、再回归测试”的顺序来定位问题会快很多。4.5 别陷入“Skills收集癖”千万别一看到别人分享Skill就收藏最后收藏了一大堆没几个在实际项目里派上用场。我自己的标准是一个Skill要连续遇到三次以上的同类需求才值得沉淀成Skill少于三次的场景直接用提示词手动处理就行。之前看网上有一些“200个Skills大礼包”之类的东西说实话真到用的时候你会发现很多质量参差不齐互相之间还有冲突。精挑几个你自己业务里真正能用上的打磨好比囤一堆用不上的要实在得多。5. 常见问题排查实录最后这部分我从自己实际遇到的案例出发整理一份“问题排查台账”。这些坑我都踩过希望你能绕过去。5.1 Skill加载后反而变笨了这是最让人沮丧的情况。攒了一个Skill加载之后模型表现还不如不加载。我用下来原因多半出在上下文干扰上Skill里内容太杂、描述太长或者跟当前任务根本不匹配模型看了反而糊涂被带偏方向。遇到这种情况我的排查顺序是先确认当前任务是否真的属于这个Skill的适用范围再检查Skill内容里有没有与当前任务相冲突的规则最后尝试精简Skill里的描述只保留必要部分。多数情况下把Skill里“背景介绍”这类内容删掉、只留“操作规则”问题就能解决。5.2 精简后输出不稳定的排查提示词精简后模型输出偶尔会“飘”。这通常是因为你把某些必要的约束也一起删掉了。判断方法是如果某条规则删掉后10次输出里有3次以上出现跑偏说明这条规则是不可精简的硬约束应该保留如果10次输出只偶尔有1次擦边偏离那更可能是模型概率采样问题调低温度参数更划算。5.3 不同模型对精简的敏感度不同这点我要特别提醒GPT-6对精简提示词的适应能力明显强于GPT-4时代的老模型。如果你同时接入了多个模型千万不要一套精简提示词走天下。我做过多模型对比测试同样一条200字的精简提示词新模型能稳定执行老模型可能需要你把关键步骤写明白才能跑对。所以建议在项目里给不同模型分别维护版本。提示词层做一层适配核心逻辑放在Skill里上层指令根据模型能力动态调整这样既能享受新模型的推理能力也能保证老模型的基本可用性。兼容不同模型的能力是提示词工程里一个常被忽略但回报极高的细节。5.4 团队协作时的提示词版本管理提示词和Skills也是代码也应该有版本管理。我见过太多团队用“最新版最终版终极版”这种命名方式到后来根本不知道线上跑的是哪一版。建议至少用一个文档表格管理提示词和Skills的版本信息记录以下字段版本号、修改日期、修改人、修改内容、测试结果、线上状态。如果你已经有git环境也可以直接把提示词和Skills目录纳入版本管理每次改动提交一个MRreview通过再上线。这套流程看着重但对于用过几个月的项目来说省下的排查成本远超前期投入。最后分享一点个人心得我做完这次提示词和Skills的“减法”调整后最明显的一个感受是我和模型之间的关系变了。以前我像一个啰嗦的监工事无巨细都要交代现在更像一个给方向的甲方告诉它要什么、边界在哪剩下的交给它自己折腾。老实说前几次放手的时候我也慌总觉得少写点东西会翻车。但跑了几个真实项目之后事实证明GPT-6这一代模型比你想象中更能扛事。如果你正准备上手GPT-6或者正在打磨自己的Skills我最后的建议就一句话先别想着加功能把你现有的提示词拿过来能删的都删一遍看看少了什么会翻车再看看什么删了也无所谓。这个“删一删”的过程本身就是最好的提示词工程训练。等你习惯了做减法再回头写那些动不动上千字的提示词你大概率会跟我一样浑身不自在。