1. 为什么OpenAI开始劝你别再把提示词堆成论文1.1 模型能吃下的内容变多了但“能吃”不等于“会消化”前几年大家写提示词默认有一个“越长越安心”的心理只要我把背景、目标、例子、输出格式、注意事项全塞进去模型总不好意思给我“跑偏”吧于是提示词越写越离谱动不动一两千字甚至有人把整个项目文档、对话历史、角色人设全糊进上下文里。我见过最夸张的一次团队一个Agent的主提示词超过8000字里面光“你必须”就出现了40多次各种“非常重要”“千万注意”满天飞。结果模型反而开始“敷衍”中段规则大量丢失后面连格式都开始不稳定。后来把提示词砍到2800字输出质量反而上去了token消耗还省了将近一半。OpenAI最近反复强调给提示词“做减法”本质上就是在回应这个现象现在模型的能力已经不是靠“语气词加重”就能驱动的了。多轮注意力机制在实际推理中会对长上下文做取舍你堆进去的词越多真正重要的信息越容易被稀释。模型不是看人眼色办事的员工你越强调它越重视它更像一个“平均主义”的信息处理器——冗余信息会抢占注意力预算关键指令反而被挤到边缘。1.2 官方这次强调的“减法”到底减的是什么很多人一听“做减法”第一反应是“把提示词写短不就完了”。这话对但理解得太浅。官方文档和访谈里传递的信息核心不是“删字”而是“删熵”。什么叫删熵就是把不带来信息增益的内容去掉。典型的“高熵废话”有这几类重复强调型“这个任务非常重要”“请务必认真对待”“一定不要出错”。这类话不会提升模型的行为质量只会增加token。人格表演型给模型安排一堆“你是业内顶尖专家你有20年经验”之类的头衔。偶尔有用但在模型已经很强的情况下收益极其有限。过度的角色背景铺垫把AI角色的前世今生写一遍跟当前任务毫无关系。隐性冲突指令既要求“简洁”又要求“详细说明”既要“快速”又要“考虑所有可能”。两个目标互相拧巴模型只能“平均”输出。“减法”的底层逻辑是提示词应该只承担“转述意图”和“框定边界”两件事。意图说清楚边界画明白剩下的交给模型本身的能力。GPT-6这类新模型在指令理解、常识推理和工具调用上的能力大幅增强你只需要“递个话”它会自己把事情办好。1.3 GPT-6的变化给了提示词一个转变信号从GPT-6相关版本模型陆续铺开到Skills这类“可复用技能包”概念成为社区热点整个玩法都在变。最直观的变化有两个第一模型对“零样本/少样本”任务的泛化能力更强。以前你给一个“请你帮我写一个Python函数”可能不够还要塞三四个示例现在只要你把输入输出的约束说清楚模型自己就能规划步骤。第二复杂任务不再需要全部塞进主提示词。过去我们把工具使用说明、代码规范、错误处理方式全堆在一个Prompt里现在这些可以拆进Skills让主提示词只保留一句话级别的调度信息。这两个变化合在一起意味着提示词的形态会从“一坨巨型文本”变成“极短的主Prompt 按需加载的Skills”。GPT-6 Skills的组合正在把提示词工程从“写作题”变成“架构题”。你不再比谁写得长而是比谁切得干净、封装得巧。2. 提示词瘦身实操三步把长Prompt改成高效Prompt2.1 第一步把“形容词堆砌”和“复读机式强调”全删掉我建议你先做一次“暴力瘦身”把所有带感情色彩的词全部圈出来然后问自己一个问题——删掉这句话模型还会不会误解我的需求如果不会那就删。举几个典型的例子“请高质量地生成一份方案” → “生成一份方案”。质量不是靠要求出来的是靠后面的约束条件定义出来的。“非常非常非常重要” → 删掉。“你需要像一个资深架构师一样思考” → 如果后续没有具体的架构维度要求这句话等于没说。“如果遇到错误请确保不要崩溃要优雅地处理” → “遇到异常时返回结构化错误信息”就够了。这一步做完你会发现提示词往往能缩掉30%-50%。别心疼这些被删掉的词在模型眼里基本是“噪声”。2.2 第二步用“角色目标约束输出格式”四要素重新组织瘦完词之后再按四要素把剩余内容重新摆一遍。这四要素不是硬性模板但能逼你把信息归类减少漏项。角色一句话说明模型该站在什么位置。不要写“你是顶级专家”而是写“你是这个项目的后端负责人”。前者是虚名后者是决策视角。目标用一句话说清楚你要的结果。能写“把图片压缩到200KB以下并保持宽高比”就不要写“处理一下图片”。约束把不可违背的规则列出来最多三到五条。约束越多模型越容易顾此失彼。输出格式明确结果是文本、JSON、Markdown还是Markdown里的表格。这一步能省掉你后面“再格式化”的功夫。这个结构看起来简单但很多人做不到因为总想把“背景信息”也塞进去。我的建议是背景信息单独放一个“Context”小节并主动告诉模型“Context仅供理解不作为任务指令”。这样模型就知道该忽略背景里的冗余指令性词语。2.3 一组真实对比同一个任务瘦身前后的Prompt长什么样我拿一个“写周报”的任务做个对比。瘦身前你是一名非常优秀的高级产品经理拥有丰富的周报撰写经验。请你帮我写一份本周的工作周报。这周的周报非常重要大领导会看请务必体现出我的工作价值。我本周主要做了三件事第一完成了用户增长策略的初步方案撰写第二组织了跨部门的需求评审会第三推动开发团队修复了三个紧急Bug。请把这些内容写得详细一些体现出我的协调能力和推动能力。另外周报格式要清晰分点说明不要太口语化也不要太长但又要有重点。谢谢瘦身后角色产品经理面向部门负责人汇报。 目标将以下三项工作整理成周报突出推进结果与下一步计划。 事项1. 用户增长策略方案初稿已完成2. 组织跨部门需求评审会3. 推动修复3个紧急Bug。 约束每项控制在100字以内不写感受只写动作和结果。 输出格式Markdown列表每项包含“进展、结果、下一步”。肉眼可见后者的信息密度高得多。而且实测下来瘦身后的版本生成结果更稳定极少出现“车轱辘话”和“假大空”。2.4 关于长度的几条经验线我在不同模型上做过不少测试总结出几条经验线供参考如果你的主提示词超过2000字优先怀疑里面有冗余如果你的主提示词超过4000字强烈建议拆成Skills或外部配置如果你的主提示词低于300字但不稳定问题往往出在约束缺失而不是长度不足。这里要特别提一句上下文窗口大不等于提示词就该长。窗口大是给多轮对话、工具返回结果、参考资料留的空间不是让你把提示词当草稿纸用。3. 用Skills承担复杂度让主提示词从“长篇小说”变成“快递单”3.1 Skills到底是什么一个能装进文件里的“预置技能包”Skills技能包是OpenAI在Agent场景里推的一种能力封装方式。理解它最简单的角度是以前你让模型做事要把怎么做讲给模型听现在你把这些“怎么做”写成文件存成可复用的技能主提示词只需要说“用某某技能做某某事”。打个比方以前的提示词像你每次打电话给客服都要从“我姓什么、我家地址在哪”开始解释Skills则相当于你在客服系统里建好了档案一打电话对方就调出你的全部信息。从社区实践来看一个Skill本质上是一个目录里面通常包含SKILL.md技能的主说明书告诉模型这个技能做什么、什么时候用、怎么用scripts/可执行的脚本或代码片段方便模型在需要时调用assets/示例文件、模板、参考材料其他依赖比如requirements.txt、配置文件等。这种结构的核心价值是“封装”和“按需加载”。主提示词不再需要知道技能内部的实现细节只需要触发条件写得足够清晰。3.2 设计Skills时要拆解出的几个模块我自己写了几个Skills之后觉得最需要注意的是模块设计而不是“开始写代码”。每个Skill都应该把下面这几件事想清楚触发条件什么情况下模型应该调用这个Skill写清楚判断依据比如“当用户需要审查前端代码时”“当任务涉及SQL优化时”。输入输出这个Skill接收什么格式的输入对外输出什么格式的结果最好给一个明确的输入输出样例。执行步骤模型拿到输入后按什么顺序处理这一步要写得像操作手册而不是泛泛而谈。边界与局限什么情况下这个Skill不适用把这个写清楚能避免模型“强行套用”。很多开发者第一次写Skills会把“执行步骤”写成一篇长长的散文然后再次掉进“提示词过分冗长”的坑。正确的做法是执行步骤尽量用短句编号把关键判定条件用“if…then…”结构表达清楚模型才好在运行时按流程执行。3.3 从0到1写一个Skills前端代码审查实操示例我拿一个“前端代码审查Skill”举例。这个技能的目标是让模型按照团队规范审查前端改动而不是每次都在主提示词里写一遍规范。推荐目录结构frontend-review/ ├── SKILL.md ├── rules/ │ ├── react-best-practices.md │ └── css-conventions.md ├── scripts/ │ └── extract_changes.py └── examples/ └── review_report.mdSKILL.md里面的核心内容可以这样组织不是完整文件只是示意# Frontend Review Skill ## 触发条件 - 用户要求审查React/Vue前端代码 - 用户提交了git diff或批量代码片段 - 用户希望检查组件拆分、状态管理或样式规范 ## 输入 - 代码片段或git diff文本 - 可选项目技术栈React 18 / Vue 3等 ## 执行步骤 1. 读取rules/目录下的规范文件 2. 对照规范逐项检查代码重点关注 - 组件是否过大超过300行时给出拆分建议 - 状态管理是否集中在必要层级 - 样式是否复用已有CSS变量 3. 输出审查报告 - 问题清单按严重程度排序 - 修改建议 - 涉及文件与行号 ## 边界 - 不执行代码质量评分 - 不生成修改后的完整代码只给建议在主提示词里只需要写一句使用frontend-review技能审查以下前端代码并将结果以Markdown报告形式输出。剩下的细节全在Skill内部完成。主提示词长度几乎可以忽略不计但模型能执行的任务复杂度却大大提升。3.4 在GPT-6/ChatGPT/兼容API中用上Skills的三种姿势实际使用Skills不外乎三种姿势第一种在ChatGPT / 相关产品界面里通过“配置技能”或“自定义指令”挂载。这类场景适合不写代码的普通用户把Skill当作预置模板用。第二种在Codex、OpenCode这类Agent开发工具里把Skills目录放到约定位置比如把技能仓库clone到工具识别范围内。这类工具本身具备读取目录结构的能力模型会在执行任务时自动寻找匹配的Skill。第三种在兼容OpenAI协议的API调用中手动把SKILL.md的内容加载进System消息脚本和资源文件放在服务端本地通过函数调用方式触发。这适合自建Agent流水线的情况。从实践看第二种是社区里最火的方式因为它对提示词的简化作用最彻底——你甚至不用在主Prompt里写“使用xxx技能”模型会根据“触发条件”自动匹配。4. 避坑指南提示词太短、Skills冲突、上下文混乱的常见解法4.1 减法做过头关键约束被删没了提示词瘦身最大的坑不是没减够而是减过头。我有一次把一个“数据清洗”的提示词从2000字减到500字结果模型完全忘了“空值处理规则”输出的数据直接没法入库。后来我总结了一条经验可以删“表现型内容”形容词、强调、角色堆砌但绝不能删“限制型内容”数据格式、取值范围、禁止行为。每删除一条内容前先问自己“如果模型不听这句话后果多严重”后果严重的必须保留压缩而不是直接删除。好的做法是把长提示词里的“硬规则”提炼成清单每条控制在10个字以内。比如空值统一填充“N/A”日期格式一律YYYY-MM-DD禁止修改原始ID字段这些短规则即使有十几条占用的token也远小于原来大段的“详细说明”。4.2 Skills之间打架命名空间和加载顺序问题Skills用多了你会遇到一个奇怪的现象同时挂载五六个Skills时模型的行为开始变得奇怪它会莫名其妙地把A技能的处理方式套用到B技能的任务上。这通常不是模型变笨了而是Skills之间的“触发条件”重叠了。比如我同时写了frontend-review和code-quality-check两个技能触发条件里都写了“当用户提交代码时”模型就困惑了。我的解法是给每个Skill定义互斥触发词比如前端审查必须出现“组件”“JSX”“style”等关键词在SKILL.md开头的“触发条件”里加上“当以下关键词命中时才激活”在加载顺序上做控制越具体的Skill越优先。另外文件夹命名最好统一用短横线小写frontend-review避免用空格或中文否则在跨平台工具中容易出现路径解析问题。4.3 一个常见的误判上下文窗口大就可以随便塞很多人觉得现在上下文窗口动辄几十万token那我提示词长一点无所谓。这个想法在“纯统计意义”上没错但在“效果稳定性”上非常有害。我的实测经验是即使模型能记住前文内容当提示词中段出现大量低信息密度文本时后续关键指令的“关注度”也会下降。你可以把上下文窗口想象成一张会议桌——桌子再大你在一堆杂物中间放一份合同负责整理的人还是得多翻几下才能找到。所以我现在的习惯是主提示词控制在“一张A4纸”以内长资料要么塞到外部文件的摘要里要么放到对话末尾作为参考而不是全都堆在系统提示词里。4.4 提示词安全和密钥管理那些事提示词“做减法”的另一个好处是暴露面变小了。提示词越长里面越容易不小心塞进API密钥、数据库URL、内部员工姓名等敏感信息。Skills出现后这个风险更值得注意——因为Skill是一个独立文件很容易被放到Git仓库里公开分享。几个基础但重要的建议绝对不要把API密钥写进提示词或SKILL.md里用环境变量或密钥管理服务统一注入。涉及内部业务逻辑的Skill不要直接推到公开仓库“求Star”可以先在私有仓库里验证。如果用的是第三方兼容接口客户端配置里的base_url、api_key这些信息务必确认不是硬编码在会提交的代码里。我在GitHub上见过不止一次有人把API密钥提交进代码仓库的“名场面”那真的是灾难——密钥泄露后账户被陌生人调用额度还算小事如果被用于异常行为可能导致整个账号被停用得不偿失。4.5 常见问题速查表下面是把这段时间在实操和社区交流里收集到的高频问题汇总成了一张表按场景分类方便你现场排查症状可能原因建议解法同一个任务反复抽风输出不稳定约束条件不够或存在隐性冲突指令缩减并合并指令把硬规则提炼成短清单提示词“前面记得后面忘记”中间冗余信息过多注意力分散把长背景拆到独立文档或Skills里技能A莫名处理了本属于技能B的任务Skills触发条件重叠给每个Skill加互斥的关键词细化触发条件Skill文件加载后模型“没感觉”工具没有正确识别SKILL.md或目录路径不对检查目录命名确认SKILL.md头部的name、description字段完整输出内容和主提示词要求完全不符主提示词与Skills的格式指令冲突在主提示词中明确“输出格式以Skill定义为准”或相反API调用时提示词被截断超出了所选模型的上下文限制精简历史消息把参考材料移到向量库或外部检索模型开始“自由发挥”提示词过短缺少必要的边界补充“禁止”类约束或挂载对应Skills这张表并不是标准答案因为模型版本、工具链差异都会改变具体表现。但排查思路是固定的先看提示词是否足够简洁且无冲突再看Skills触发条件是否清晰最后检查工具链是否正确加载。我个人在实际操作中最深的一个体会是提示词瘦身不是一个“一次做完就完事”的动作而是一个持续迭代的过程。每隔一段时间我会把主提示词重新读一遍凡是我自己都懒得看的段落模型大概率也会忽略。你能删的就是模型可以腾出来做实事的地方。GPT-6一代的新模型和Skills这套组合最大的价值不是让你“少打字”而是让你把思考重心从“怎么把话说全”挪到“怎么把事拆对”上。等你的主提示词缩成一张“快递单”的时候那些真正重要的工作才刚开始。