给提示词做减法这件事我是怎么从“叠 buff”到被官方打脸的如果你最近刷过 OpenAI 的技术博客大概会注意到一个反常识的信号官方在 GPT-6 的模型卡里明确建议提示词要“做减法”尤其是当你在用模型自带的 Skills 能力时冗长提示词不仅不会让输出更聪明反而会拉低推理质量。我第一次看到这个结论时是有点不服气的毕竟做了这么多年提示词工程谁不是从“把需求写得越细越好”这条路走过来的直到我把手头一个 3000 多 token 的提示词脚本砍到 300 token再把剩余的关键逻辑封装成 Skill 之后输出质量和响应速度双双提升我才真正理解了官方那句话的意思。这篇文章不聊虚的直接讲清楚三件事为什么 GPT-6 时代提示词越长反而越危险如何系统地给提示词“瘦身”以及如何把瘦身后的提示词产物沉淀成可复用的 Skills 模块。适合正在做 Agent 开发、重度使用 Codex / GPT 系列模型或者被自己那一堆越写越长的 prompt 模板折磨的朋友。全文没有任何“PPT 级建议”每一步都是我实际跑过、踩过坑之后沉淀下来的方法。1. 为什么官方要喊你做减法模型越强废话越贵1.1 长提示词正在悄悄“稀释”你的核心指令先说一个可能被很多人忽略的事实GPT-6 这一代模型的推理能力确实更强了但它的注意力机制并不是“读得越多越懂你”。相反当提示词里充斥着铺垫、解释、重复性强调和无差别的示例时模型需要花更多算力去区分哪些内容是核心指令、哪些只是背景噪音。这就好比你给一个资深工程师交代任务只需要说“把支付接口的超时时间从 3 秒改成 5 秒并补上超时重试”结果你却花十分钟讲了一遍 HTTP 协议发展史、公司历史、团队分工、以及你对超时的个人理解——资深工程师不但不会更明白反而抓不住重点。我在实际测试里发现把同一任务分别用 2000 token 和 400 token 的提示词跑 50 次短版本在指令遵循准确率上反而高出不少尤其是在多步骤任务里长提示词经常出现的毛病是“模型自己发挥夹带了旧逻辑”。因为长文本里那些细节描述会激活模型关联记忆里乱七八糟的模式比如你明明是让它写 Python 代码但提示词里有几句关于其他语言的说明结果生成了混着 Java 风格的代码。官方在 GPT-6 的文档里说的也是同一个意思提示词里的每一个 token 都会参与模型的决策冗余信息越多决策被带偏的可能性越大。1.2 做减法不是拍脑袋而是“注意力预算”问题理解做减法背后的原理必须引入注意力机制这个概念。Transformer 模型在处理输入时会对所有 token 两两计算注意力权重这意味着输入越长注意力矩阵的规模呈平方级增长。虽然工程上有多头注意力和各种稀疏化优化但长输入的推理代价是实打实的更长的延迟、更高的 token 成本、以及更容易出现“注意力稀释”。“注意力稀释”这个词是我自己的说法它描述的现象很典型你把最关键的操作指令放在第 800 个 token 的位置此时模型需要跨越大段背景描述去“记住”这个指令。虽然上下文窗口足够大但关键指令的注意力占比会被大量冗余 token 摊薄。尤其在多轮对话里模型对早期指令的记忆会越来越模糊最后生成的产物越来越偏离你的本意。所以提示词瘦身的本质不是把字删短而是重新分配模型的注意力预算。把宝贵的上下文空间留给真正影响输出的关键信息——角色定义、任务目标、约束条件、输出格式。至于那些背景故事、类比解释、无关示例该删就删。我的经验是一个合格的提示词里每一个句子都应该能回答“删掉它输出会不会变差”这个问题。如果删掉后输出几乎没变化这句话就是冗余就要干掉。1.3 token 成本数学账算清楚了才知道有多亏很多个人开发者不关心 token 成本觉得一次调用几厘钱而已但如果你在做 Agent、批量任务或者 Skill 调用这笔账就不得不算了。以 GPT-6 系列模型为例假设输入价格为每百万 token 2 美元一个 3000 token 的提示词和 300 token 的提示词单次调用成本相差 9 倍。如果每天调用 1 万次一天下来成本差异就是 54 美元一个月就是 1600 多美元——这还只是输入部分输出部分如果也受到影响差距更大。延迟也是一样。在同样的算力条件下短提示词的 prefill 时间明显更短响应更快。我做 Agent 开发时对这一点感受极深因为 Agent 经常要串行调用多次模型如果每次 prompt 都肥得流油一次任务链跑下来用户要等半天。所以提示词瘦身不只是“洁癖”它直接影响产品的成本和用户体验。官方建议做减法本质上也是在引导开发者往更高效的方向使用模型。2. Skills 的本质提示词做减法后的最佳归宿2.1 为什么瘦身后的提示词不能只存在聊天记录里这里有个很现实的问题你把提示词从 3000 字砍到 300 字然后呢如果每次用的时候还是从文档里复制粘贴那省下的 token 很快会被复制粘贴过程中的调整、修改、重新适配吃掉。更糟糕的是你会发现同一个任务在不同场景下需要微调于是又慢慢把 300 字改回 800 字过了两周提示词又膨胀了。Skills 就是来解决这个问题的。它的核心思想是把一段成熟的、经过提炼的提示词逻辑封装成一个可复用的技能模块。系统里有了 Skills 之后你不需要每次对话都把完整提示词粘贴进去只需要在需要时调用对应的 Skill模型会自动加载 Skill 里定义好的精简指令、参考样例和输出规范。这就像把做菜的秘方从“每次口头复述一遍”升级为“写进菜谱卡片要用时直接抽出来”。GPT-6 原生支持 Skills 机制社区里也有类似 Codex Skills、Claude Code Skills 的开源实现。它们的核心逻辑是一样的通过一个结构化目录和一份核心说明文件让模型在触发特定场景时自动加载对应的“技能知识”。所以提示词瘦身和 Skills 天然是一对瘦身把提示词中的味精和水分抽干Skills 把剩下的干货固化下来随取随用。2.2 Skill 的内部结构SKILL.md 和它的伙伴们一个标准的 Skill 通常是一个目录里面有若干文件。最核心的是SKILL.md它相当于这个技能的“主文档”模型加载 Skill 时首先读它。除了主文档通常还有参考资料、示例数据、脚本文件等。我在实践中用过的典型结构是这样code-review-skill/ ├── SKILL.md ├── reference/ │ ├── bug-patterns.md │ └── security-checklist.md ├── examples/ │ ├── bad-code.py │ └── good-code.py └── scripts/ └── extract_diff.pySKILL.md里写什么、多长直接决定了这个 Skill 瘦不瘦。我的经验是SKILL.md最好控制在 150-300 行之内它只负责定义三件事触发条件、工作流程、输出规范。详细的技术背景、代码模式、边界案例放到reference/目录里由模型按需加载。这样设计的好处是日常调用时模型只需读取精简的主文档快速进入工作状态只有在遇到特殊情况时它才会深入参考资料里找线索。2.3 模型是怎么决定“要不要用某个 Skill”的这个机制值得多说一句因为很多人把 Skill 当成普通的“预设提示词包”但实际的检索逻辑要复杂一点。模型会先将当前对话内容与每个 Skill 的描述description 字段做相似度匹配找到可能相关的 Skill 后再读取其SKILL.md。所以“技能描述写得好不好”直接影响被调用的准确率。这带来两个实操启示。第一描述要写“触发场景”而不是写“技能功能”。比如一个前端开发 Skill描述里写“在用户需要生成 React 组件、处理 CSS 兼容性、调试前端页面时使用”就比“这是一个前端开发工具”好用得多。第二描述要短一般不超过 50 个 token。因为描述本身就是被检索的索引太长会干扰匹配精度。这其实又是一次“做减法”。3. 提示词瘦身实操从 2000 token 到 200 token 的完整过程3.1 第一步不要急着删先给提示词做个“体检”很多人一听“做减法”就直接上手删字删完发现输出质量崩了然后得出“官方建议不靠谱”的结论。这是不对的。正确做法是先把提示词拆解开做一次结构化体检。我习惯把提示词拆成四类内容角色与场景设定比如“你是一名资深 Python 工程师”任务目标与约束比如“重构以下函数保持接口不变”示例与参考比如“期望输入输出对”输出格式要求比如“用 JSON 返回包含 result 和 reason 字段”拆完之后对每一段内容问三组问题它对输出结果有没有直接影响它和别的段落是否在重复表达同一个意思如果删掉它模型的输出会不会明显变差我在给一个库存管理 Agent 做体检时发现原提示词里光“要准确”这个意思就重复了五遍每一遍的措辞还不同——模型收到这种信号反而会困惑到底按哪一遍“准确”的标准执行。体检的结果最好记成一张表类似这样内容块长度token是否核心指令可否删除删除影响角色说明120否可精简影响极小背景描述600否可删除几乎无任务目标150是不可删删除即跑题示例 1300部分可压缩需保留关键模式示例 2200否可删除无输出格式120是不可删删除即解析失败重复强调510否可删除无做完这张表你立刻就知道该删什么了。我那次体检下来原提示词里约 62% 的内容属于“可删除或可大幅精简”的范畴真正决定输出质量的只有不到 400 token。3.2 第二步四个高效动作把水分挤干体检之后具体怎么删也有讲究。我总结的四个动作分别是去重、压示例、改否定为肯定、后置背景。去重这个动作最简单把意思相同的句子只保留表达最精确的一句即可。比如“请确保代码质量”和“代码要健壮、可读、易维护”其实是一个意思保留后者就够了。压示例是技术含量最高的。很多人的提示词里放了三四个长示例每个都占几百 token。我的做法是只保留一个最典型的示例然后用一句话概括这个示例的核心模式。比如写 SQL 生成任务的提示词与其放五个不同的查询案例不如写一句“所有生成的查询必须符合既定格式先写 EXPLAIN 确认索引命中再输出完整 SQL”。模型其实不需要那么多具体例子它需要的是规则。改否定为肯定也很有用。大量“不要做什么”的指令会让模型不知所措因为“不要”本质上是在反复激活错误模式。与其写“不要使用递归”不如写“使用迭代方式实现”。与其写“不要返回多余字段”不如写“只返回 result 和 reason 两个字段”。肯定式指令更短而且执行准确率更高。后置背景的意思是那些必须保留但属于“理解辅助”的信息比如项目背景、用户画像、业务语境统一放到提示词的最后作为一个可选的“背景上下文”区块。这样核心指令在模型注意力中的占比最高背景又保留了理解所需的上下文。实际操作中后置背景还有个额外好处当你修改背景信息时不需要动核心指令维护成本大幅降低。3.3 第三步瘦身结果对比与测试闭环瘦身不是一次性的删完必须测试。我的测试方法论是准备 5 个典型的输入场景在瘦身前和瘦身后分别跑一遍对比输出质量。注意这里不能用“看着差不多”来评判最好设定可量化的指标。比如生成代码的任务看编译是否通过、单测是否覆盖生成文案的任务看关键词是否包含、字数是否达标。举个例子我优化过一个“鹈鹕测试提示词”风格的创意生成任务原始提示词写了很多关于幽默风格的描述将近 500 token甚至描述了“像鹈鹕骑车一样滑稽”这种画面。瘦身之后我只保留一句“风格自然幽默避免刻意押韵和网络烂梗”。实测下来瘦身后的结果明显更自然因为模型不再被那一大段“滑稽”描述带偏到尬笑区。每次测试如果发现某个删除导致输出变差就把那部分内容加回来但加回时也要精简——提取它真正起作用的句子而不是整段还原。经过两三轮迭代你的提示词会稳定在一个比较精简的形态。我个人的经验是大部分任务型提示词从 2000 token 瘦到 300-500 token 是完全可行的而且输出质量不降反而更稳定。4. Skills 瘦身实操把提示词沉淀成轻量可复用的技能4.1 从一段好的提示词到一个可用的 Skill假设你刚完成了一次成功的提示词瘦身现在要把这段提示词做成 Skill。直接把它塞进SKILL.md是最常见的错误。因为提示词解决的是“一次对话中的指令问题”而 Skill 解决的是“一个场景中的稳定能力问题”后者需要更结构化的组织方式。我的做法是分三步转译。第一步把提示词里的“角色设定”转化为 Skill 的“适用场景”写入元信息中的 description让模型知道什么时候该调用。第二步把提示词里的“任务目标与约束”转化为SKILL.md中的工作流程用 3-5 个步骤描述这个技能怎么执行每个步骤一句话拒绝长篇大论。第三步把提示词里的“示例与参考”转移到reference/目录按类型拆分并在主文档里只保留指向参考文件的引用。打个比方提示词做减法像是把一篇赘述的文章改写成清晰的摘要而 Skill 像是把摘要编入词典词典不能长篇大论但要能让人快速查到词条并知道去哪里看完整的词条解释。4.2 SKILL.md 的最小骨架与写法实例一个合格的SKILL.md我建议只包含四个区块技能名称、适用场景、执行步骤、输出规范。下面是一个真实可用的“前后端联调接口文档生成”Skill 的骨架示例--- name: api-doc-generator description: 在需要根据后端接口定义生成前端调用文档时使用。 --- # 接口文档生成器 ## 执行步骤 1. 阅读后端接口定义提取请求方法、路径、参数、响应结构。 2. 为每个接口生成前端 TypeScript 调用函数。 3. 标注错误码与异常处理建议。 ## 输出规范 - 使用 Markdown 表格列出所有接口。 - 每个接口包含函数签名、参数说明、返回值类型、错误处理示例。 - 如遇到不明确的字段使用 TODO 标注不要自行猜测。注意看整个主文档只有不到 30 行没有背景故事没有技术教程没有长篇示例。因为那些内容如果模型需要应该从reference/里按需读取。一个 Skill 的体积就应该这么轻。我在实践里见过有人把SKILL.md写成 1000 行的“百科全书”结果模型每次加载都要消耗大量 token而且常常抓不住重点——这和提示词不瘦身是同一个问题只是换了个马甲。4.3 参考资料的精简与组织只留模型“算不出来”的内容Skill 的reference/目录同样需要做减法而不是把网上的长篇文档整篇丢进去。我筛选参考资料时有一条铁律只保留模型无法通过自身知识可靠推理出来的内容。具体来说包括这几类项目的私有接口规范、特定的数据格式定义、团队内部的代码风格约定、目标框架的版本差异说明。举个例子我做过一个“前端开发 Skill”最初我在参考目录里放了一整本 React 官方文档的某些章节后来发现模型本身对 React 基础用法非常熟悉放这些文档只会增加检索负担。真正有用的是我自己整理的一份“本项目组件库使用注意事项”里面记录了组件命名规则、样式变量、mock 数据开关等模型不可能知道的项目私有信息。把公开文档删掉之后这个 Skill 的调用成功率和响应速度都提升了。参考资料的组织也有一点讲究。每个参考文件的标题要尽量具体比如payment-refund-api.md就比api-notes.md好用得多。模型在SKILL.md里看到引用时一眼就能判断该不该深入查看。同时每个文件内部也保持精简——用短句、代码块和表格减少解释性文字。4.4 用“最小可运行版本”思维来迭代 Skill很多人的第一个 Skill 就想做到“大而全”结果写了两周还没发布。正确的做法是先做一个“最小可运行版本”只覆盖最高频的 3 个场景核心代码就 30 行然后在真实使用中逐步补充。这其实也是做减法——把技能的范围先收敛到最小跑通之后再扩展。我在开发一个图片生成提示词类 Skill 时就是这么干的。第一版只支持“根据主题生成详细的英文图像描述”没有额外的风格库没有负面提示词库。跑了几天之后发现模型经常把风格描述得过于抽象于是我在参考目录里加了一个style-vocabulary.md里面列了 20 个具体的艺术风格词每个词配一两句解释。这个 Skill 始终控制在很小的规模但效果比那些动辄几百行风格定义的大技能好很多。Skill 迭代还有一个要点每次修改后都要回归测试。我用最简单的办法——准备 10 个固定的测试输入每次更新 Skill 后跑一遍记录输出质量是否有变化。如果某个更新让 3 个以上输入的结果变差就回滚这次更新。这保证了技能只会越用越好而不是越改越乱。5. 避坑指南关于提示词瘦身和 Skills我踩过的那些坑5.1 常见问题速查表把实操中遇到的高频问题整理成表方便你直接对照排查。症状根本原因解决办法瘦身后模型突然“变笨”误删了关键约束或核心示例用二分法恢复内容找到影响输出的最小语句组合提示词已经很短但输出还是漂上下文里有历史对话干扰开启新会话或使用 System Prompt 隔离核心指令Skill 经常不被触发description 写成了功能说明而非场景说明改为“当用户需要…时使用”句式加入高频同义词SKILL.md 太长导致调用超时主文档塞了太多背景和示例把细节移到 reference/主文档控制在 30-50 行模型回复风格不像“技能该有的样子”输出规范写得过于抽象给 1 个真实输出样例作为风格锚点但只保留 1 个更新 Skill 后效果反而变差缺少回归测试准备固定测试集更新后全量回归效果变差立即回滚5.2 避坑经验一别把“做减法”理解成“越短越好”我必须强调一点做减法的目标是去掉冗余而不是删光所有细节。有些约束是绝对不能删的比如安全边界、输出格式、禁止使用的库、必须兼容的版本。我在一个支付相关 Skill 里把“禁止将支付日志打印到控制台”这句话精简掉之后模型偶尔会在调试代码里输出敏感字段——这就是典型的“减法做得过火”。判断标准其实很简单凡是删掉后可能导致安全事故、数据泄露、解析失败的内容一律保留。安全相关的指令不但不能减还要写明确、写具体。另一种“减过头”的表现是只留干巴巴的任务描述完全不交代输出风格和边界条件。比如让模型写一封客户道歉邮件只写“写一封道歉邮件”它可能写出 2000 字的忏悔录。但如果你只加一句“控制在 150 字内语气诚恳但不过度卑微”同样很精简效果却完全不同。所以做减法不是追求字数最少而是追求“每个字都发挥作用”。5.3 避坑经验二Skill 之间要避免“互相打架”当你积累到十几个 Skill 之后会遇到一个新的问题不同 Skill 的适用范围有重叠模型可能会抓错。比如我有一个“代码审查 Skill”和一个“安全审查 Skill”两者在检查代码时都会关注安全问题导致模型时而加载 A 时而加载 B输出风格不稳定。解决办法有两个。一是把重叠的部分抽出来做成公共 Skill各个业务 Skill 在reference/里引用它而不是各自维护一套。二是完善 Skill 的 description明确各自的边界。我当时给“安全审查 Skill”的 description 加了一句“只关注安全漏洞不关注代码风格和性能”交叉误触发率立刻降了大半。听起来像是小事但实际部署过多个 Skill 的人都会明白这种“技能互踩”的问题有多磨人。5.4 避坑经验三保留失败样本比保留漂亮示例更值钱最后分享一个很多人忽略的点。在做 Skill 参考资料时大家习惯往reference/里放“最佳实践”“标准答案”但我在维护几个长期使用的 Skill 后发现真正提升模型表现的是那些“失败案例”。比如我在“SQL 优化 Skill”里保存了几个常见的错误查询案例每个案例都标明“为什么慢、怎么改”。模型在生成候选 SQL 时会主动规避这些错误模式生成质量明显高于只看正例的情况。这个经验同样适用于提示词瘦身本身。当你删掉某段内容导致输出变差时不要急着把那段内容原样加回而是先记录下这个“失败样本”当时的输入是什么、输出为什么差、删掉的内容和输出变差之间的因果链是什么。这些记录既是你后续调优的依据也是你沉淀 Skill 参考材料时最宝贵的素材。我在本地维护了一个“prompt 事故档案”至今存了 40 多个案例每次写新提示词前翻一翻能避开一大半常见的坑。5.5 关于 GPT-6 时代的一个趋势判断提示词工程正在变成“技能工程”最后说一点个人观察。OpenAI 既然在 GPT-6 的官方文档里强调提示词要精简、建议把逻辑封装进 Skills那传递的信号其实很明确单次对话中尽量用最少的话说清需求把重复性的复杂经验交给 Skill 体系来承载。这对开发者意味着埋头写长提示词的时代正在过去取而代之的是“结构化管理技能库”的能力——定义好触发条件组织好精简的指令和参考材料再配上回归测试。你可以把 Skills 想象成一个持续演进的知识库提示词只是它的索引。我个人在实际操作中的体会是提示词瘦身和 Skill 建设从来不是一次性的工作而是一个持续迭代的过程。每次模型升级、每次业务场景变化都可能意味着你现有的 Skill 需要重新做一次减法。这套方法和心态是我做了大量项目之后沉淀下来的。希望能帮你少踩几个坑早点把提示词从 3000 字解放出来。 GPT-6时代提示词做减法：瘦身与Skills封装实战
给提示词做减法这件事我是怎么从“叠 buff”到被官方打脸的如果你最近刷过 OpenAI 的技术博客大概会注意到一个反常识的信号官方在 GPT-6 的模型卡里明确建议提示词要“做减法”尤其是当你在用模型自带的 Skills 能力时冗长提示词不仅不会让输出更聪明反而会拉低推理质量。我第一次看到这个结论时是有点不服气的毕竟做了这么多年提示词工程谁不是从“把需求写得越细越好”这条路走过来的直到我把手头一个 3000 多 token 的提示词脚本砍到 300 token再把剩余的关键逻辑封装成 Skill 之后输出质量和响应速度双双提升我才真正理解了官方那句话的意思。这篇文章不聊虚的直接讲清楚三件事为什么 GPT-6 时代提示词越长反而越危险如何系统地给提示词“瘦身”以及如何把瘦身后的提示词产物沉淀成可复用的 Skills 模块。适合正在做 Agent 开发、重度使用 Codex / GPT 系列模型或者被自己那一堆越写越长的 prompt 模板折磨的朋友。全文没有任何“PPT 级建议”每一步都是我实际跑过、踩过坑之后沉淀下来的方法。1. 为什么官方要喊你做减法模型越强废话越贵1.1 长提示词正在悄悄“稀释”你的核心指令先说一个可能被很多人忽略的事实GPT-6 这一代模型的推理能力确实更强了但它的注意力机制并不是“读得越多越懂你”。相反当提示词里充斥着铺垫、解释、重复性强调和无差别的示例时模型需要花更多算力去区分哪些内容是核心指令、哪些只是背景噪音。这就好比你给一个资深工程师交代任务只需要说“把支付接口的超时时间从 3 秒改成 5 秒并补上超时重试”结果你却花十分钟讲了一遍 HTTP 协议发展史、公司历史、团队分工、以及你对超时的个人理解——资深工程师不但不会更明白反而抓不住重点。我在实际测试里发现把同一任务分别用 2000 token 和 400 token 的提示词跑 50 次短版本在指令遵循准确率上反而高出不少尤其是在多步骤任务里长提示词经常出现的毛病是“模型自己发挥夹带了旧逻辑”。因为长文本里那些细节描述会激活模型关联记忆里乱七八糟的模式比如你明明是让它写 Python 代码但提示词里有几句关于其他语言的说明结果生成了混着 Java 风格的代码。官方在 GPT-6 的文档里说的也是同一个意思提示词里的每一个 token 都会参与模型的决策冗余信息越多决策被带偏的可能性越大。1.2 做减法不是拍脑袋而是“注意力预算”问题理解做减法背后的原理必须引入注意力机制这个概念。Transformer 模型在处理输入时会对所有 token 两两计算注意力权重这意味着输入越长注意力矩阵的规模呈平方级增长。虽然工程上有多头注意力和各种稀疏化优化但长输入的推理代价是实打实的更长的延迟、更高的 token 成本、以及更容易出现“注意力稀释”。“注意力稀释”这个词是我自己的说法它描述的现象很典型你把最关键的操作指令放在第 800 个 token 的位置此时模型需要跨越大段背景描述去“记住”这个指令。虽然上下文窗口足够大但关键指令的注意力占比会被大量冗余 token 摊薄。尤其在多轮对话里模型对早期指令的记忆会越来越模糊最后生成的产物越来越偏离你的本意。所以提示词瘦身的本质不是把字删短而是重新分配模型的注意力预算。把宝贵的上下文空间留给真正影响输出的关键信息——角色定义、任务目标、约束条件、输出格式。至于那些背景故事、类比解释、无关示例该删就删。我的经验是一个合格的提示词里每一个句子都应该能回答“删掉它输出会不会变差”这个问题。如果删掉后输出几乎没变化这句话就是冗余就要干掉。1.3 token 成本数学账算清楚了才知道有多亏很多个人开发者不关心 token 成本觉得一次调用几厘钱而已但如果你在做 Agent、批量任务或者 Skill 调用这笔账就不得不算了。以 GPT-6 系列模型为例假设输入价格为每百万 token 2 美元一个 3000 token 的提示词和 300 token 的提示词单次调用成本相差 9 倍。如果每天调用 1 万次一天下来成本差异就是 54 美元一个月就是 1600 多美元——这还只是输入部分输出部分如果也受到影响差距更大。延迟也是一样。在同样的算力条件下短提示词的 prefill 时间明显更短响应更快。我做 Agent 开发时对这一点感受极深因为 Agent 经常要串行调用多次模型如果每次 prompt 都肥得流油一次任务链跑下来用户要等半天。所以提示词瘦身不只是“洁癖”它直接影响产品的成本和用户体验。官方建议做减法本质上也是在引导开发者往更高效的方向使用模型。2. Skills 的本质提示词做减法后的最佳归宿2.1 为什么瘦身后的提示词不能只存在聊天记录里这里有个很现实的问题你把提示词从 3000 字砍到 300 字然后呢如果每次用的时候还是从文档里复制粘贴那省下的 token 很快会被复制粘贴过程中的调整、修改、重新适配吃掉。更糟糕的是你会发现同一个任务在不同场景下需要微调于是又慢慢把 300 字改回 800 字过了两周提示词又膨胀了。Skills 就是来解决这个问题的。它的核心思想是把一段成熟的、经过提炼的提示词逻辑封装成一个可复用的技能模块。系统里有了 Skills 之后你不需要每次对话都把完整提示词粘贴进去只需要在需要时调用对应的 Skill模型会自动加载 Skill 里定义好的精简指令、参考样例和输出规范。这就像把做菜的秘方从“每次口头复述一遍”升级为“写进菜谱卡片要用时直接抽出来”。GPT-6 原生支持 Skills 机制社区里也有类似 Codex Skills、Claude Code Skills 的开源实现。它们的核心逻辑是一样的通过一个结构化目录和一份核心说明文件让模型在触发特定场景时自动加载对应的“技能知识”。所以提示词瘦身和 Skills 天然是一对瘦身把提示词中的味精和水分抽干Skills 把剩下的干货固化下来随取随用。2.2 Skill 的内部结构SKILL.md 和它的伙伴们一个标准的 Skill 通常是一个目录里面有若干文件。最核心的是SKILL.md它相当于这个技能的“主文档”模型加载 Skill 时首先读它。除了主文档通常还有参考资料、示例数据、脚本文件等。我在实践中用过的典型结构是这样code-review-skill/ ├── SKILL.md ├── reference/ │ ├── bug-patterns.md │ └── security-checklist.md ├── examples/ │ ├── bad-code.py │ └── good-code.py └── scripts/ └── extract_diff.pySKILL.md里写什么、多长直接决定了这个 Skill 瘦不瘦。我的经验是SKILL.md最好控制在 150-300 行之内它只负责定义三件事触发条件、工作流程、输出规范。详细的技术背景、代码模式、边界案例放到reference/目录里由模型按需加载。这样设计的好处是日常调用时模型只需读取精简的主文档快速进入工作状态只有在遇到特殊情况时它才会深入参考资料里找线索。2.3 模型是怎么决定“要不要用某个 Skill”的这个机制值得多说一句因为很多人把 Skill 当成普通的“预设提示词包”但实际的检索逻辑要复杂一点。模型会先将当前对话内容与每个 Skill 的描述description 字段做相似度匹配找到可能相关的 Skill 后再读取其SKILL.md。所以“技能描述写得好不好”直接影响被调用的准确率。这带来两个实操启示。第一描述要写“触发场景”而不是写“技能功能”。比如一个前端开发 Skill描述里写“在用户需要生成 React 组件、处理 CSS 兼容性、调试前端页面时使用”就比“这是一个前端开发工具”好用得多。第二描述要短一般不超过 50 个 token。因为描述本身就是被检索的索引太长会干扰匹配精度。这其实又是一次“做减法”。3. 提示词瘦身实操从 2000 token 到 200 token 的完整过程3.1 第一步不要急着删先给提示词做个“体检”很多人一听“做减法”就直接上手删字删完发现输出质量崩了然后得出“官方建议不靠谱”的结论。这是不对的。正确做法是先把提示词拆解开做一次结构化体检。我习惯把提示词拆成四类内容角色与场景设定比如“你是一名资深 Python 工程师”任务目标与约束比如“重构以下函数保持接口不变”示例与参考比如“期望输入输出对”输出格式要求比如“用 JSON 返回包含 result 和 reason 字段”拆完之后对每一段内容问三组问题它对输出结果有没有直接影响它和别的段落是否在重复表达同一个意思如果删掉它模型的输出会不会明显变差我在给一个库存管理 Agent 做体检时发现原提示词里光“要准确”这个意思就重复了五遍每一遍的措辞还不同——模型收到这种信号反而会困惑到底按哪一遍“准确”的标准执行。体检的结果最好记成一张表类似这样内容块长度token是否核心指令可否删除删除影响角色说明120否可精简影响极小背景描述600否可删除几乎无任务目标150是不可删删除即跑题示例 1300部分可压缩需保留关键模式示例 2200否可删除无输出格式120是不可删删除即解析失败重复强调510否可删除无做完这张表你立刻就知道该删什么了。我那次体检下来原提示词里约 62% 的内容属于“可删除或可大幅精简”的范畴真正决定输出质量的只有不到 400 token。3.2 第二步四个高效动作把水分挤干体检之后具体怎么删也有讲究。我总结的四个动作分别是去重、压示例、改否定为肯定、后置背景。去重这个动作最简单把意思相同的句子只保留表达最精确的一句即可。比如“请确保代码质量”和“代码要健壮、可读、易维护”其实是一个意思保留后者就够了。压示例是技术含量最高的。很多人的提示词里放了三四个长示例每个都占几百 token。我的做法是只保留一个最典型的示例然后用一句话概括这个示例的核心模式。比如写 SQL 生成任务的提示词与其放五个不同的查询案例不如写一句“所有生成的查询必须符合既定格式先写 EXPLAIN 确认索引命中再输出完整 SQL”。模型其实不需要那么多具体例子它需要的是规则。改否定为肯定也很有用。大量“不要做什么”的指令会让模型不知所措因为“不要”本质上是在反复激活错误模式。与其写“不要使用递归”不如写“使用迭代方式实现”。与其写“不要返回多余字段”不如写“只返回 result 和 reason 两个字段”。肯定式指令更短而且执行准确率更高。后置背景的意思是那些必须保留但属于“理解辅助”的信息比如项目背景、用户画像、业务语境统一放到提示词的最后作为一个可选的“背景上下文”区块。这样核心指令在模型注意力中的占比最高背景又保留了理解所需的上下文。实际操作中后置背景还有个额外好处当你修改背景信息时不需要动核心指令维护成本大幅降低。3.3 第三步瘦身结果对比与测试闭环瘦身不是一次性的删完必须测试。我的测试方法论是准备 5 个典型的输入场景在瘦身前和瘦身后分别跑一遍对比输出质量。注意这里不能用“看着差不多”来评判最好设定可量化的指标。比如生成代码的任务看编译是否通过、单测是否覆盖生成文案的任务看关键词是否包含、字数是否达标。举个例子我优化过一个“鹈鹕测试提示词”风格的创意生成任务原始提示词写了很多关于幽默风格的描述将近 500 token甚至描述了“像鹈鹕骑车一样滑稽”这种画面。瘦身之后我只保留一句“风格自然幽默避免刻意押韵和网络烂梗”。实测下来瘦身后的结果明显更自然因为模型不再被那一大段“滑稽”描述带偏到尬笑区。每次测试如果发现某个删除导致输出变差就把那部分内容加回来但加回时也要精简——提取它真正起作用的句子而不是整段还原。经过两三轮迭代你的提示词会稳定在一个比较精简的形态。我个人的经验是大部分任务型提示词从 2000 token 瘦到 300-500 token 是完全可行的而且输出质量不降反而更稳定。4. Skills 瘦身实操把提示词沉淀成轻量可复用的技能4.1 从一段好的提示词到一个可用的 Skill假设你刚完成了一次成功的提示词瘦身现在要把这段提示词做成 Skill。直接把它塞进SKILL.md是最常见的错误。因为提示词解决的是“一次对话中的指令问题”而 Skill 解决的是“一个场景中的稳定能力问题”后者需要更结构化的组织方式。我的做法是分三步转译。第一步把提示词里的“角色设定”转化为 Skill 的“适用场景”写入元信息中的 description让模型知道什么时候该调用。第二步把提示词里的“任务目标与约束”转化为SKILL.md中的工作流程用 3-5 个步骤描述这个技能怎么执行每个步骤一句话拒绝长篇大论。第三步把提示词里的“示例与参考”转移到reference/目录按类型拆分并在主文档里只保留指向参考文件的引用。打个比方提示词做减法像是把一篇赘述的文章改写成清晰的摘要而 Skill 像是把摘要编入词典词典不能长篇大论但要能让人快速查到词条并知道去哪里看完整的词条解释。4.2 SKILL.md 的最小骨架与写法实例一个合格的SKILL.md我建议只包含四个区块技能名称、适用场景、执行步骤、输出规范。下面是一个真实可用的“前后端联调接口文档生成”Skill 的骨架示例--- name: api-doc-generator description: 在需要根据后端接口定义生成前端调用文档时使用。 --- # 接口文档生成器 ## 执行步骤 1. 阅读后端接口定义提取请求方法、路径、参数、响应结构。 2. 为每个接口生成前端 TypeScript 调用函数。 3. 标注错误码与异常处理建议。 ## 输出规范 - 使用 Markdown 表格列出所有接口。 - 每个接口包含函数签名、参数说明、返回值类型、错误处理示例。 - 如遇到不明确的字段使用 TODO 标注不要自行猜测。注意看整个主文档只有不到 30 行没有背景故事没有技术教程没有长篇示例。因为那些内容如果模型需要应该从reference/里按需读取。一个 Skill 的体积就应该这么轻。我在实践里见过有人把SKILL.md写成 1000 行的“百科全书”结果模型每次加载都要消耗大量 token而且常常抓不住重点——这和提示词不瘦身是同一个问题只是换了个马甲。4.3 参考资料的精简与组织只留模型“算不出来”的内容Skill 的reference/目录同样需要做减法而不是把网上的长篇文档整篇丢进去。我筛选参考资料时有一条铁律只保留模型无法通过自身知识可靠推理出来的内容。具体来说包括这几类项目的私有接口规范、特定的数据格式定义、团队内部的代码风格约定、目标框架的版本差异说明。举个例子我做过一个“前端开发 Skill”最初我在参考目录里放了一整本 React 官方文档的某些章节后来发现模型本身对 React 基础用法非常熟悉放这些文档只会增加检索负担。真正有用的是我自己整理的一份“本项目组件库使用注意事项”里面记录了组件命名规则、样式变量、mock 数据开关等模型不可能知道的项目私有信息。把公开文档删掉之后这个 Skill 的调用成功率和响应速度都提升了。参考资料的组织也有一点讲究。每个参考文件的标题要尽量具体比如payment-refund-api.md就比api-notes.md好用得多。模型在SKILL.md里看到引用时一眼就能判断该不该深入查看。同时每个文件内部也保持精简——用短句、代码块和表格减少解释性文字。4.4 用“最小可运行版本”思维来迭代 Skill很多人的第一个 Skill 就想做到“大而全”结果写了两周还没发布。正确的做法是先做一个“最小可运行版本”只覆盖最高频的 3 个场景核心代码就 30 行然后在真实使用中逐步补充。这其实也是做减法——把技能的范围先收敛到最小跑通之后再扩展。我在开发一个图片生成提示词类 Skill 时就是这么干的。第一版只支持“根据主题生成详细的英文图像描述”没有额外的风格库没有负面提示词库。跑了几天之后发现模型经常把风格描述得过于抽象于是我在参考目录里加了一个style-vocabulary.md里面列了 20 个具体的艺术风格词每个词配一两句解释。这个 Skill 始终控制在很小的规模但效果比那些动辄几百行风格定义的大技能好很多。Skill 迭代还有一个要点每次修改后都要回归测试。我用最简单的办法——准备 10 个固定的测试输入每次更新 Skill 后跑一遍记录输出质量是否有变化。如果某个更新让 3 个以上输入的结果变差就回滚这次更新。这保证了技能只会越用越好而不是越改越乱。5. 避坑指南关于提示词瘦身和 Skills我踩过的那些坑5.1 常见问题速查表把实操中遇到的高频问题整理成表方便你直接对照排查。症状根本原因解决办法瘦身后模型突然“变笨”误删了关键约束或核心示例用二分法恢复内容找到影响输出的最小语句组合提示词已经很短但输出还是漂上下文里有历史对话干扰开启新会话或使用 System Prompt 隔离核心指令Skill 经常不被触发description 写成了功能说明而非场景说明改为“当用户需要…时使用”句式加入高频同义词SKILL.md 太长导致调用超时主文档塞了太多背景和示例把细节移到 reference/主文档控制在 30-50 行模型回复风格不像“技能该有的样子”输出规范写得过于抽象给 1 个真实输出样例作为风格锚点但只保留 1 个更新 Skill 后效果反而变差缺少回归测试准备固定测试集更新后全量回归效果变差立即回滚5.2 避坑经验一别把“做减法”理解成“越短越好”我必须强调一点做减法的目标是去掉冗余而不是删光所有细节。有些约束是绝对不能删的比如安全边界、输出格式、禁止使用的库、必须兼容的版本。我在一个支付相关 Skill 里把“禁止将支付日志打印到控制台”这句话精简掉之后模型偶尔会在调试代码里输出敏感字段——这就是典型的“减法做得过火”。判断标准其实很简单凡是删掉后可能导致安全事故、数据泄露、解析失败的内容一律保留。安全相关的指令不但不能减还要写明确、写具体。另一种“减过头”的表现是只留干巴巴的任务描述完全不交代输出风格和边界条件。比如让模型写一封客户道歉邮件只写“写一封道歉邮件”它可能写出 2000 字的忏悔录。但如果你只加一句“控制在 150 字内语气诚恳但不过度卑微”同样很精简效果却完全不同。所以做减法不是追求字数最少而是追求“每个字都发挥作用”。5.3 避坑经验二Skill 之间要避免“互相打架”当你积累到十几个 Skill 之后会遇到一个新的问题不同 Skill 的适用范围有重叠模型可能会抓错。比如我有一个“代码审查 Skill”和一个“安全审查 Skill”两者在检查代码时都会关注安全问题导致模型时而加载 A 时而加载 B输出风格不稳定。解决办法有两个。一是把重叠的部分抽出来做成公共 Skill各个业务 Skill 在reference/里引用它而不是各自维护一套。二是完善 Skill 的 description明确各自的边界。我当时给“安全审查 Skill”的 description 加了一句“只关注安全漏洞不关注代码风格和性能”交叉误触发率立刻降了大半。听起来像是小事但实际部署过多个 Skill 的人都会明白这种“技能互踩”的问题有多磨人。5.4 避坑经验三保留失败样本比保留漂亮示例更值钱最后分享一个很多人忽略的点。在做 Skill 参考资料时大家习惯往reference/里放“最佳实践”“标准答案”但我在维护几个长期使用的 Skill 后发现真正提升模型表现的是那些“失败案例”。比如我在“SQL 优化 Skill”里保存了几个常见的错误查询案例每个案例都标明“为什么慢、怎么改”。模型在生成候选 SQL 时会主动规避这些错误模式生成质量明显高于只看正例的情况。这个经验同样适用于提示词瘦身本身。当你删掉某段内容导致输出变差时不要急着把那段内容原样加回而是先记录下这个“失败样本”当时的输入是什么、输出为什么差、删掉的内容和输出变差之间的因果链是什么。这些记录既是你后续调优的依据也是你沉淀 Skill 参考材料时最宝贵的素材。我在本地维护了一个“prompt 事故档案”至今存了 40 多个案例每次写新提示词前翻一翻能避开一大半常见的坑。5.5 关于 GPT-6 时代的一个趋势判断提示词工程正在变成“技能工程”最后说一点个人观察。OpenAI 既然在 GPT-6 的官方文档里强调提示词要精简、建议把逻辑封装进 Skills那传递的信号其实很明确单次对话中尽量用最少的话说清需求把重复性的复杂经验交给 Skill 体系来承载。这对开发者意味着埋头写长提示词的时代正在过去取而代之的是“结构化管理技能库”的能力——定义好触发条件组织好精简的指令和参考材料再配上回归测试。你可以把 Skills 想象成一个持续演进的知识库提示词只是它的索引。我个人在实际操作中的体会是提示词瘦身和 Skill 建设从来不是一次性的工作而是一个持续迭代的过程。每次模型升级、每次业务场景变化都可能意味着你现有的 Skill 需要重新做一次减法。这套方法和心态是我做了大量项目之后沉淀下来的。希望能帮你少踩几个坑早点把提示词从 3000 字解放出来。