1. 先搞明白为什么GPT-6/Astra时代要反着来给提示词做减法1.1 提示词越长越聪明是被GPT-4时代驯化出来的惯性做提示词工程的人过去两年多多少少都有点堆料强迫症。系统提示词里恨不得把角色背景、行为准则、输出格式、禁止事项、few-shot示例、边界条件全部塞进去一个Prompt写下来动辄一两千字还要用XML、JSON Schema、Markdown标题层层包裹。这个习惯不怪大家GPT-4时代的指令遵循能力有限模型对上下文的注意力是平均分配的你不多写几遍关键约束、不给足示例它在复杂任务上就是容易飘。所以社区里总结出一套共识上下文越长、约束越细输出越可控。这套思路在GPT-4时代确实管用。但凡是拿同一套方法论去套新模型的多半已经在GPT-6相关的讨论里碰过壁了。我在好几个项目群里看到同样的现象某个团队把一套精心打磨了两千字的提示词从GPT-4迁到新模型上原本期待的更强的指令遵循没出现反而是输出变得僵化、冗长甚至出现了自己给自己加戏的情况。问题不出在新模型变笨了而是我们还在用旧时代的药方治新时代的病。1.2 GPT-6 Astra对指令的解析方式变了从官方先后释放的信息和开发者社区的实测反馈来看GPT-6家族包括Astra方向在指令解析上有一个明显的变化模型的意图理解能力大幅前移。它不再依赖你在提示词里反复强调你必须你应当请务必这类祈使句来维持约束而是能从更简洁的指令里直接推断出任务目标、推断出潜在规则甚至能自动补全你没写出来的隐含步骤。这意味着什么意味着过去那些用来喂饱模型的冗余话术现在反而成了噪声。举个直观的例子你在提示词里用三句话描述你是一个资深前端工程师熟悉React、Vue、TypeScript擅长性能优化新模型读到你是资深前端工程师就已经把后面三句都推断出来了。你再把熟悉React、Vue写一遍它不会因此更专业只会因为这些重复信息在解析时占据注意力拖慢首字响应甚至干扰它对当前任务核心的判定。换句话说GPT-6要的不是更长的说明书而是更准的任务卡。提示词越长任务边界反而越模糊。1.3 官方rethinking skills and prompts的核心理念Rethinking skills and prompts for GPT-6 Astra这个方向外界讨论热度一直很高。把它翻译成人话核心是在推动两件事第一把提示词里描述性内容和可执行内容拆开第二把一次性写入的长期指令重构成按需加载的技能模块。传统提示词是一个大杂烩身份、目标、技能、规则、示例、输出模板全堵在一个System Prompt里每次对话不管干不干相关这些内容全部被解析一遍。而GPT-6的Skills机制则主张把知识性的描述和行为性的约束模块化让模型自己判断什么时候该加载哪一块。官方明确建议开发者减小主提示词的体量主提示词只保留任务身份和最高优先级的核心准则其余内容全部下沉到Skill里。这个思路对我们的直接影响是如果你还在用GPT-4时代的千字长文硬上新模型你会同时踩中两个坑——主提示词太长导致指令聚焦变差以及Skills机制完全没有用起来导致模型无法动态调度能力。后面我会把瘦身和Skill化分开讲因为它们是两个技术动作但必须按顺序做。2. Skills官方用技能模块替代超长提示词的底层逻辑2.1 Skills和传统提示词的本质区别很多人第一次接触Skills会下意识把它理解成多个提示词文件。这个理解方向对了一半但漏掉了最关键的部分Skills不仅仅是一段文本它是一套带元数据、可触发、可组合的指令单元。传统提示词是静态的无论干什么任务都要整体过一遍Skills是动态的模型根据用户请求判断现在需要调用哪个技能只把那一个技能注入上下文。用个不那么严谨但很好懂的比较传统提示词像是给员工发了一本一百页的员工手册让他把所有规章制度都背下来再干活Skills像是给员工配了一个工具箱每把工具上贴着适用场景标签他接到具体任务时自己挑合适的工具而不是把整个工具箱背在身上。这个差异在长会话场景里尤其明显。过去一个带十项职能的System Prompt每轮对话都要占掉将近两千tokens四次对话下来光吃上下文就耗了一万tokens改成Skills之后主提示词只占三百模型按需加载多数时候真正激活的技能只有一到两个上下文成本直接砍掉一半以上。2.2 Skill的目录结构、元数据和触发方式虽然GPT-6生态里Skills的玩法还在快速迭代但基本结构已经稳定下来了。一个标准Skill通常包含这几个部分SKILL.md核心指令文件用Markdown书写描述这个技能的目标、适用场景、执行步骤和输出规范。元数据头写在SKILL.md文件开头一般用YAML或TOML格式声明技能名称、描述、触发关键词、适用任务类型。这段是模型判断何时加载该技能的主要依据所以描述要写清楚这个技能解决什么问题而不是写这个技能很强大。参考文件目录放示例输出、模板、知识库片段。需要避免把大量背景知识全部堆进SKILL.md可以拆成独立文件在需要时由模型按路径读取。触发方式我实测下来有两大类。一类是自动触发模型根据用户问题语义匹配技能描述命中后自动加载。这个依赖元数据描述写得准。另一类是显式触发用户或上层应用在请求里直接指定使用XX技能处理相当于告诉模型不用猜了就用这个。显式触发在API场景里更稳定我建议生产环境优先用显式方式。2.3 什么适合做成Skill什么仍然应该留在System Prompt里这是我把提示词瘦身和Skill化结合之后踩了很多坑才总结出来的划分原则。不是所有提示词内容都该下沉到Skills下沉错了反而坏事。适合做成Skill的内容通常具备三个特征低频、强流程、可独立评估。比如生成一个React组件的单元测试、把Markdown表格转换成JSON、按公司规范写发布公告这类任务不是每轮对话都发生但一旦触发步骤相对固定且有明确的产出物。把它们做成技能后模型只在需要时加载完整流程其余时间不被无关指令干扰。必须留在System Prompt里的内容则和任务身份、安全边界、全局输出偏好强关联。比如你是前端开发助手所有代码必须兼容Chrome和Safari、禁止输出政治敏感内容、回复默认使用中文这类每次都适用的约束。一旦把这些也下沉到Skill就会出现模型在某些轮次里忘记遵守底线规则的严重问题——因为技能没触发约束就没加载。一句话总结全局规则走System Prompt专项流程走Skill身份设定尽量精简。这个分层我后面会反复用到。3. 提示词瘦身实操从1126字压到180字的完整过程3.1 瘦身前先做信息分层拿到一条旧提示词别上来就删先做信息分层。我自己习惯用一个简单的标注法把所有句子按四类打标A类身份与全局约束模型是谁、最核心的不可违背规则。这类必须留。B类任务流程接到任务后按什么步骤做。这类适合转成Skill。C类示例与格式few-shot和输出模板。留一两个最强的其余进Skill参考文件。D类冗余与情绪化强化诸如请务必、你一定要牢记、这非常重要之类的强调性表述。这类在新模型上基本可以全删它只会让指令变得臃肿。我给你看一个真实项目里的压缩过程。这是一条面向GPT-4写的前端开发专家提示词原文1126字结构是身份介绍180字、技术栈清单160字、编码规范十条320字、工作流程五步200字、输出格式要求150字、禁止事项116字。如果直接把这1126字原封不动地用在新模型上实测下来首字响应时间大约多出20%而且模型经常在编码规范十条上过度纠结把简单任务复杂化。所以必须拆。3.2 我的实际操作步骤与对比第一步把A类内容压缩。原提示词的身份介绍180字我压到35字你是资深前端开发专家输出代码必须兼容Chrome和Safari移动端优先。技术栈清单160字整个删除——模型本身对主流技术栈足够熟悉不需要你教它什么叫React、什么叫TypeScript。第二步把B类内容迁移。原提示词的工作流程五步共200字内容大致是分析需求、确认关键边界、编写代码、自查边界条件、输出说明。我把它改造成一个名为frontend-code-review的Skill的SKILL.md主体在元数据描述里写明适用场景是前端编码任务、代码评审任务。第三步C类处理。原文有两条few-shot一条演示组件写法一条演示优化建议格式。组件那条保留在主提示词里因为它是高频刚需优化建议那条挪进Skill的参考目录。第四步D类直接删。原提示词里三处请务必、两处非常重要、一处严格遵循全部删除。语言模型推理时不会因为你写了务必就提高执行概率这类词只会增加指令前缀的长度不会带来任何收益。瘦身后的System Prompt全文只有180字再贴一下最终版的结构供你参考你是资深前端开发专家。 - 全局约束代码兼容Chrome/Safari移动端优先涉及安全事项必须显式声明。 - 默认行为先给结论再给细节如果需求边界模糊先列假设再编码。 - 注意事项无需在回复中复述本规则。3.3 瘦身后的效果延迟、稳定性、成本改完之后我跑了一周对比测试三组数据很能说明问题首字响应时间降低18%到22%。原因是每轮请求要解析的前置指令变短了模型能更快进入任务状态。指令遵循稳定性反而提升了。之前那种规则十条里有两条互相冲突、导致模型时而遵守A时而遵守B的情况消失了。因为我在压缩的时候发现原提示词里的编码规范十条里有一条禁止使用any类型和一条类型不明确时可先用any占位存在明显矛盾——以前根本没注意到因为提示词太长了根本不会逐条检查。单次会话的平均tokens消耗下降约35%。原来每轮请求都带着一千多字指令跑现在只有180字省下来的空间全部变成了可用的上下文窗口模型回答质量也跟着提升。这个对比给我最大的启发是瘦身不是牺牲控制力来换性能而是把无效控制删掉之后有效控制的占比反而提高了。这完全就是做减法的收益逻辑。4. 从瘦身到技能化Skill开发与部署的完整链路4.1 版本选择与运行时配置提到Skills就绕不开Claude Code的Skills和OpenAI生态的Skills之间的关系。目前社区里大量被验证过的Skills范例来自Claude Code生态比如Superpower Skills这套开源集合里面涵盖了文档生成、代码审查、测试编写、SVG生成等场景。而GPT-6相关方向也在推自己的Skills机制两者的设计语言高度相似核心都是SKILL.md加元数据。所以哪怕你先在Claude Code里写好、调好一个Skill迁移到GPT-6生态也不是推倒重来改改元数据格式就能复用大部分内容。运行时配置方面重点提醒一个点如果你走API方式接入要注意兼容层的请求格式。OpenAI的Chat Completion协议和较新的Response协议在返回结构、流式处理、工具调用上都有差异。我见过不少团队在协议切换上翻车——上层代码按Chat Completion的格式解析返回结果服务端返回的是Response协议的结构导致工具调用结果解析不出来。建议先明确你用的服务商支持哪套协议再决定SDK版本。国内开发者如果直接用官方API不方便可以通过火山引擎方舟这类兼容层接入base_url指向对应服务地址即可。示例配置如下key需要替换为你自己的from openai import OpenAI client OpenAI( base_urlhttps://ark.cn-beijing.volces.com/api/v3, api_keyyour-api-key-here ) response client.chat.completions.create( modelgpt-6-x, messages[ {role: system, content: system_prompt} ], tools[skill_tool_schema] )这里有个容易踩的细节model参数在不同兼容层里可能不是官方模型名而是你开通的接入点ID。写代码时最好把模型名抽成配置项别写死。4.2 一个前端开发Skill的样例拆解下面这个是我在生产环境里用着的frontend-code-reviewSkill的简化版你可以直接参考结构--- name: frontend-code-review description: 审查前端代码输出兼容性风险、性能瓶颈和可维护性建议。 当用户提交React/Vue组件代码、页面样式或要求帮我看看这段代码时使用。 triggers: - 前端代码审查 - code review - 组件优化 --- # 前端代码审查 ## 任务目标 在不修改用户代码的前提下找出风险点并给出可执行建议。 ## 执行步骤 1. 识别用户代码的技术栈React/Vue/原生并声明你假设的版本。 2. 检查以下维度浏览器兼容性、移动端布局、状态管理、副作用、可访问性。 3. 按优先级输出问题列表P0阻断级 / P1建议修改 / P2可选优化。 4. 每一条问题必须给出修改示例禁止只说建议优化而不给代码。 ## 输出模板 ### P0 - [问题简述] - 位置文件名:行号 - 原因XX - 修改建议\\\代码\\\这个Skill的关键设计点在第2步到第3步我强制它先声明技术栈版本防止模型拿旧版本的写法去套新项目同时把输出格式固化成优先级位置原因修改建议保证审查结果是可执行的而不是一堆正确但无用的废话。4.3 本地调试与回归测试Skill写完之后调试这步可能比写本体更花时间。我目前稳定的流程分三步单触发测试给模型一个明确触发词比如直接说帮我审查这段代码确认Skill能正确加载、执行流程完整。模糊触发测试用没有出现任何触发词、但语义相关的请求去试比如这组件在手机上会不会有问题确认自动触发机制能通过description里的语义描述命中技能。回归对比准备一组固定测试用例分别记录使用Skill前后的输出质量和耗时。我一般会保留上一次的稳定版本只有新版本在全部用例上的有效输出率不低于旧版本才切换。特别是第三条很多人没做就上线结果模型行为突变排查半天发现是Skill改坏了。这里强烈建议给每个Skill加一个version字段出现问题时能快速定位。5. 避坑实录我在削提示词和写Skills时踩过的五类坑5.1 坑一把提示词规则全塞进Skill主提示词被架空这是我把做减法理解过头时犯的错。当时我把全局约束也搬进了Skill比如回答必须使用中文这种规则也放进了文档写作Skill里。结果在用户不提文档写作、只问这个bug怎么修的场景下模型完全没触发写作Skill回复直接用了英文。教训很明确全局约束一旦下沉到按需加载的技能就变成了非全局约束。主提示词里的规则虽然少但那是模型每轮对话都会看到的内容权威性最高。安全底线和基础偏好必须留在这里宁可主提示词多几行也不能让它们活在技能里。5.2 坑二技能命名模糊触发率急剧下降另一个常见问题是元数据里的description写得模棱两可。我早期写过一个代码优化Skilldescription只写了优化代码四个字。结果模型要么频繁误触发——用户问请帮我优化这段文字它也把代码优化Skill加载出来了要么该触发时不触发——用户说这段查询能不能跑快点模型没意识到这是代码优化任务。后来我把description改成了带场景和示例的版本用于审查和优化代码性能包括SQL查询优化、前端渲染优化、接口响应优化。当用户表达出变快、变卡、超时、性能差等意图时使用。触发准确率一下子从不到60%提到了85%以上。元数据description的价值不是给人看的是给模型语义匹配用的所以要多写用户会怎么说少写这个技能多有用。5.3 坑三过度结构化把模型锁死做提示词工程的人容易有控制欲想把模型的每一步都框死。我在Skill里试过把七个步骤全部编号、每一步限定字数、每一步必须输出特定格式理论上很完美实测输出变得极其机械模型在步骤之间来回打转甚至出现第2步已完成正在进入第3步这样的废话填充。新模型本身的规划能力已经很强Skill里只需要定义起点任务目标、检查点必须覆盖的维度、终点输出格式中间过程放给模型自己发挥。结构化到掌握方向就够了结构化到规定步幅就会适得其反。这个度的把握建议你在调试时从粗到细一旦发现输出机械化就退一步。5.4 坑四忽略了tokens缩减对历史上下文的影响瘦身之后系统提示词短了、上下文余量大了这本来是好事但也可能带来一个隐蔽的副作用。我遇到过的情况是上下文窗口变大之后模型开始过度回忆早期对话内容甚至把几轮之前的一次性任务要求又捡起来执行导致输出内容串味。这个问题的本质是提示词瘦身释放的上下文空间如果没有被正确引导模型会自己拿来填充一些你并不需要它关注的信息。解决办法不是把提示词再加回去而是在系统提示里明确一行默认只基于当前对话最近上下文和本次用户输入进行回应除非用户明确要求调用历史信息。这行字能省掉大量长会话里的上下文干扰。5.5 坑五API兼容层下的能力差异最后这个坑基本只在API接入场景里出现。OpenAI生态的兼容服务商很多但各家对工具调用、结构化输出、Streaming事件的支持程度并不完全一致。我之前在一个项目里用了一套基于Chat Completion协议写的工具调用逻辑服务端换成兼容层之后工具调用参数突然解析不出来查了两小时才发现是上游把tools参数改成了functions命名空间。避免方案有两条一是接任何服务商之前先跑一遍官方的连通性测试脚本别急着写业务代码二是把API调用层封装成独立模块底层协议变化时只改一个文件而不是满项目到处改。代码里最好对协议类型做显式判断不要假设所有OpenAI兼容层都是100%相同的。6. 衡量做减法是否成功的四个量化指标6.1 从小样本盲测到留存验证改完提示词和Skill之后一定要用数据确认改动方向是对的不能凭感觉。我自己固定看四个指标指标测量方式合格线指令遵循率100条固定测试用例人工判定模型输出是否满足核心约束≥90%首字响应时间同网络环境下对同一批请求取均值对比优化前后降低≥15%上下文tokens消耗统计10轮连续对话的平均总tokens降低≥30%有效输出率输出中可直接使用的内容占比去掉废话、错误格式、编造内容≥85%先说指令遵循率。这个指标很多人测得太随意直接用眼扫一遍就下结论。我建议做盲测让两个人分别打分一个人知道新旧版本另一个人不知道避免先入为主。测100条用例不需要很多时间但能直观暴露某些规则在新提示词里被丢了的问题。再说有效输出率。这个指标是我在对比Skill化前后最看重的。瘦身之前模型输出经常带一段漂亮但没有实际意义的总结性开头比如好的收到您的需求我来分析一下。做成Skill、并加了禁止输出任务理解过程的约束之后这类废话明显减少有效输出率从78%提到了91%。对生产环境来说这十几个百分点的提升比首字响应时间更值钱因为它直接决定了产物的交付质量。6.2 一些值得保留的经验法则技术细节说完了最后沉淀几条我测试下来觉得能复用的判断标准。第一条一份提示词如果能用一句话说清目标就一定不要用三段话绕弯子。你觉得不写清楚模型就不知道但其实它知道你越克制它越聚焦。第二条Skill的粒度宁可细一点、数量多一点不要贪一个万能技能。万能技能的描述很难写准触发准确率很难提高反而把技能拆成前端代码审查、SQL性能分析、生成单元测试这种窄技能每个都清晰可查。第三条把做减法当成一次持续迭代而不是一次性的重构。模型在更新任务在变化你每周抽出半小时回顾一次线上提示词和Skill的触发记录删掉三个月没触发过的旧技能比憋大招写一套新体系有用得多。还有一条关于测试数据集的建议不要只准备顺利场景的测试用例。至少留20%的用例是边界模糊、需求不全、容易引发幻觉的难题比如这个组件有点慢你看着办。这些边角场景才是真正检验提示词和Skill好坏的地方。顺利场景谁都能过难缠场景才是你沉淀的护城河。