最近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 处 | 提升 |
| 平均token | 4200 | 2800 | 降低约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文件里。改完之后，再用固定用例跑一遍确认没有伤到精度。这套流程看起来多花了一点时间，但长远来看，它让提示词真正变成了可以维护、可以复用、可以被团队其他人接手的东西。
