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改成高效Prompt
2.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这套组合，最大的价值不是让你“少打字”，而是让你把思考重心从“怎么把话说全”挪到“怎么把事拆对”上。等你的主提示词缩成一张“快递单”的时候，那些真正重要的工作，才刚开始。
