最近OpenAI官方关于GPT-6与Skills方向放出的指导核心观点就一句话提示词该做减法了。这对过去两年习惯了“长提示词等于高质量”的人来说几乎是方向性急转弯。我在GPT-6上做了几轮实测又把自己手上十几个项目的提示词逐条拆开重写发现“做减法”不是简单删掉几句话而是要把提示词和Skills重新分工让推理、知识、流程各归其位。这篇文章不会劝你把提示词删到十个字而是分享一套可落地的瘦身流程哪些内容该留在提示词里哪些内容该搬进Skills搬走之后怎么验证效果没打折以及我踩过的几个“越减越弱”的坑。1. 为什么OpenAI官方这次把矛头指向“长提示词”1.1 “长提示词等于高质量”的惯性从哪来早期用GPT-3.5、GPT-4那会儿模型的指令遵循能力远没有现在强提示词里不写清楚角色、背景、步骤、示例、否定项输出就很容易飘。于是网上流行起各种“万能提示词模板”动辄几百上千字先设定角色再交代背景然后列步骤给两个示例最后补上“不要输出XXX”。这种长提示词确实解决过问题。那个阶段的模型对措辞很敏感你多写一句“你是资深前端工程师”输出质量可能就肉眼可见地变好。久而久之团队里形成了一种条件反射效果不好加提示词。上下文不够再挤一挤。这也导致很多人的提示词越来越长直到超出了模型的有效注意力范围。可问题来了长提示词提高的是“表面稳定性”不是“真实精度”。当提示词里塞了太多背景信息和规则模型反而要花精力去判断哪些话是废话、哪些话是硬约束。更麻烦的是长提示词在Agent场景下会被反复注入上下文token成本成倍增加延迟也变高。1.2 GPT-6和Agent时代长提示词开始变成负担GPT-6这一代模型的推理能力已经很强很多之前需要你手把手教的逻辑它在训练阶段就内化了。比如“代码评审要注意可维护性”“回答要直接不要绕弯子”这类通用规则你写与不写它都知道。你真正要告诉它的只有这三次任务的具体目标和边界。OpenAI官方那套“Rethinking Skills and Prompts for GPT-6 Astra”的思路我理解下来大概是三层意思。第一提示词只保留目标、输入、输出格式和不可妥协的硬约束。第二那些需要稳定的工作流、代码规范、评审标准全部下沉到Skills里。第三不要靠“感觉”判断提示词好坏要用回归测试集去量。我实测下来包括之前的“鹈鹕骑自行车”这种创意类提示词也是如此。写一大段“一只鹈鹕穿着蓝色围巾推着一辆带白色花篮的复古自行车背景是金色夕阳”的小作文效果反而不如直接给模型“鹈鹕骑自行车”几个关键词。模型自己会补齐风格和氛围你写太多细节反而限制了它的想象力。2. 提示词瘦身实操从500字减到80字的完整步骤2.1 第一步把提示词拆成“目标、输入、输出、约束”四栏我的建议是不要一上来就删先把现有提示词拆开看。找一张表格把提示词里的每一句话都归类目标、输入材料、输出格式、硬约束、软约束、背景铺垫、角色设定、示例、评分标准。实际操作中我会把“背景铺垫”和“角色设定”整段丢进垃圾桶“示例”压缩到一两个“软约束”能删就删“硬约束”逐条确认后保留最核心的“输出格式”如果不是特别复杂可以直接写进Skills里。举个例子我之前给某个招聘匹配项目写过一个提示词原版有500多字大概长这样内容原提示词写法瘦身后的写法目标你是一名资深HR。请结合JD中的每一条要求逐一对照候选人的简历内容判断候选人是否匹配...判断简历与JD的匹配度给出分数和理由输入以下是候选人的简历文本请你先通读一遍再阅读JD要求...{简历} {JD}输出请用表格形式输出第一列是JD要求第二列是候选人的对应经历第三列是匹配度评价...输出JSON含score、matched、missed格式输出不要用markdown不要加多余解释...只输出JSON对象砍完之后整个提示词还剩不到80字。第一次跑测试的时候我也很慌总觉得少了点什么。但结果出人意料模型抓重点的能力更强了而且因为提示词里没有废话它不会再花上下文空间去“理解”那些语义重复的背景介绍。2.2 第二步把角色设定和稳定策略转移到Skills拆完提示词后你会发现自己扔掉的那些角色设定和通用规则其实是好东西只不过放错了位置。它们不该出现在每次调用的提示词里而应该做成一个可以被按需加载的Skills模块。比如前端代码评审这个场景。以前我的提示词每次都写你是一位8年前端架构师精通React、TypeScript、TailwindCSS请先理解需求再检查代码可维护性、可访问性、性能隐患输出问题清单按P0/P1/P2分级不要直接修改代码。这段文字现在可以整体“搬”进一个叫做 frontend-code-review 的SKILL.md里。提示词里只留一句调用 frontend-code-review 技能评审以下代码改动需求描述见{demand}。这是“瘦身”最关键的一个动作减法不是把内容删掉而是把内容从“每次都要传递的上下文”变成“按需加载的模块”。这样做还有一个好处同一套评审规范可以在多个项目里复用改规范时只要改一个Skills文件不用翻遍所有历史提示词。2.3 第三步用A/B测试确认“减法”没伤到精度“做减法”最怕减过头。我每次改完提示词都会立刻跑一轮A/B回归测试确认不是凭感觉觉得“好像变聪明了”。回归测试的做法是准备10到20个典型任务样本分别用旧提示词和新提示词各跑一遍然后从四个维度对比任务完成率该做的事是否做了。格式合规率输出的JSON、Markdown、代码结构是否符合要求。关键约束遗漏技术栈、合规措辞、输出字段这些硬约束有没有漏。token用量平均每次调用消耗的token有没有明显下降。我一般会把结果记成表格比如下面这样指标长提示词版本瘦身版本结论完成率95%96%持平格式合规90%97%提升硬约束遗漏平均 1.2 处平均 0.3 处提升平均token42002800降低约33%如果短版本的关键指标持平或更好就放心替换如果发现格式漂移或约束遗漏先别急着把整段文字加回去而是去检查是不是某个硬约束被误删了或某个需要保留的结构被压缩得太狠了。3. Skills瘦身与复用别再写一部“巨型说明书”3.1 Skills不是大号提示词而是可加载的执行配置很多人会误以为Skills就是把原来的长提示词换了个文件名改名叫SKILL.md然后继续往里面堆内容。这样做的结果是模型每次加载这个Skill时依然要处理大量冗余信息和长提示词没有任何区别。我对Skills的理解是提示词负责“调度”Skills负责“能力”。打个比方提示词像你临时给同事安排任务时说的那句话Skills则是团队早已写好的作业指导手册。你不需要每次把手册背一遍只需要告诉同事“按手册第3套流程处理这个客户工单”。所以一个Skill应该具备三个特征有明确的用途描述、有精简的执行步骤、有稳定的输出约定。尤其那个用途描述直接决定模型在什么场景下会自动调用它写得太宽泛模型会拿不准写得太窄模型又不会主动触发。3.2 一份“干净”的Skills文件长什么样我习惯用Markdown维护Skills文件结构尽量简短。下面是一份干净的SKILL.md示例虽然各家工具和框架在明细字段上有差异但整体思路是通用的--- name: frontend-code-review description: 对前端代码执行可维护性与可访问性审查输出问题清单。 --- 1. 阅读需求说明和代码改动上下文。 2. 按检查清单逐项评审。 3. 根据严重程度为每条问题标注P0/P1/P2。 4. 输出评审结论不修改代码。 ## 检查清单 - 是否存在重复代码、魔法数字、硬编码文案 - 组件是否缺乏可访问性标签 - 页面是否有明显性能隐患 - 是否引入新的依赖且没有说明理由注意这个文件里没有“你是一位资深专家”这种角色设定没有大段背景介绍也没有“请务必、一定要”这类情绪化措辞。它只写给模型看步骤要做什么、检查哪些点、输出什么结果。给模型看的文字和信息密度成正比和感情浓度成反比。啰嗦的话越多模型越会犹豫。3.3 给Skills减脂拆分、去重、可测另一个经常被忽略的问题是Skills文件写得太贪心。一个Skill里塞了代码评审、组件开发、性能优化、发布检查、技术栈说明加起来比说明书还长。模型加载之后光解析这个文件就要消耗大量上下文也容易在互相重叠的规则里产生冲突。我的做法是拆成单一职责的小Skills。比如一个叫 frontend-code-review一个叫 frontend-performance-checklist一个叫 component-generation。每个Skill只干一件事描述写清楚触发条件模型才能在合适场景主动调用。去重也很重要。我见过有人维护了十几个Skills一半内容都在重复“使用TypeScript、遵循团队代码规范”这些话规则一多模型很可能被互相矛盾的表述带偏。每隔一段时间我会把所有Skills的关键词抽出来做一次交叉比对同一主题只保留一份权威版本。最后一个习惯是“可测”。我给每个Skills都配了一两个测试提示词专门用它来验证这个Skill是否正常工作。比如给代码评审Skill配一条最简单的测试“读一下src/utils/format.ts按你的规则输出评审结果。”如果连这种简单样例都跑不对说明Skill里的规则写得有问题需要马上调整。4. 避坑指南提示词“越减越弱”的五个常见原因4.1 硬约束被误删技术栈与格式要求要在我见过最典型的“越减越弱”案例是精简提示词的时候把技术栈约束也一并删了。原因在于长提示词里往往写着“请使用React和TypeScript”写的人觉得这是在“指导模型”删的时候觉得这是“模型本来就知道的东西”结果代码生成出来后全是另一种框架的写法。如果目标必须落在特定技术栈、特定法规或特定品牌口径上这类约束就是硬约束一个字都不能少。我会把这部分独立成“不可删清单”每次瘦身时单独对照一遍。如果你经常在同一个场景里使用同样的硬约束就直接把它们放进相关Skills的checklist里这样提示词里不用重复写但也丢不了。4.2 负面指令太多学会把“不要”翻成正向描述有人精简提示词时会把“不要输出markdown表格”“不要解释”“不要写代码”全部删掉然后发现模型真的开始输出表格了。问题不在于这些约束应不应该保留而在于这些“不要”句式本身就不是好写法。负向指令会给模型一种强烈暗示让它特别容易想起你禁止的东西。更好的写法是转成正向指令把“不要输出markdown表格”改成“只输出纯文本”把“不要直接写代码”改成“先输出评审意见最后再给示例代码”。瘦身时如果发现提示词里负面指令太多优先做的是改写而不是删除。4.3 缺少输入样例输出飘了先补示例再补约束精简提示词后输出质量下降许多人第一反应是“约束删多了”于是把大量约束又加回去。但实际问题的原因往往是少了一两个样例。模型在信息量不足时会默认按自己最熟悉的通用方式来回复结果就偏离了你的业务语境。这时候与其增加“请结合公司实际情况”这种套话不如补上一个具体的输入输出示例。一个真实样例带来的信息密度往往超过一大段描述。示例可以保留在提示词的末尾也可以作为一份单独的外部文件传入关键是要让你的场景特征被模型准确捕捉。4.4 角色设定删过头什么时候必须保留一句话人设“做减法”不等于一切角色设定都不能留。对于医疗、法律、心理、教育这类回答口径和风险敏感度都极高的领域一句精简的角色设定其实是硬约束能有效把模型拉进正确的回答框架。我之前在教学场景里试过删掉“你是一位耐心的高中数学老师”之后同样的题目讲解风格明显变得生硬学生的困惑点也照顾不到。解决办法是保留一句话人设比如“你是高中数学老师讲解时给出前因后果”但把解释风格的详细描述移入Skill里避免提示词又变成一长串“角色扮演”。4.5 缺少回归测试把“感觉好用”变成“指标稳定”最后一个坑也是最常见的减完提示词后手工试了两条觉得没问题就直接上线了结果在真实流量里翻车。提示词改动的影响很难通过一两个例子观察到必须用一批覆盖典型场景的样例做回归测试。我现在的做法是建立一个“提示词回归用例集”每次任何修改都至少要跑一遍哪怕只是改了一个标点。用例集平时放在和项目代码一起的目录里用版本管理工具管理。长期下来这个用例集会慢慢变成团队最宝贵的提示词资产因为它让每一次修改都有据可查不再是“谁改谁知道”。我个人在实际操作中最深的体会是减法的目的从来不是把提示词变得越短越好而是把“废话”和“关键信息”分辨清楚。每次写提示词先问自己一句“这句话如果删掉模型会不会变笨”不会的就删真正重要的技术栈、格式要求和领域口径确保它们要么出现在短提示词里要么躺在对应的Skills文件里。改完之后再用固定用例跑一遍确认没有伤到精度。这套流程看起来多花了一点时间但长远来看它让提示词真正变成了可以维护、可以复用、可以被团队其他人接手的东西。