OpenAI 公布 GPT-5.6 提示词指南，内部测试发现，把冗长的 system prompt 精简之后，分数不降反升 10% 到 15%，token 用量还省下 41% 到 66%。指南建议开发者只给模型结果、限制与停止标准，不用规定每一步该怎么走。 （前情提要：GPT-5.6 秘密测试疯传：ChatGPT 突变聪明、用户测试碾压 Fable 5） （背景补充：Harness Engineering（AI 驭控工程）入门篇：OpenAI 最新编程标准，教你轻松做到 Lv.1）
本文目录
Toggle
OpenAI 内部测试显示，把一份原本落落长的 system prompt 大幅精简之后，分数不但没有掉，反而上升 10% 到 15%，同时 token 用量还省下 41% 到 66%。换句话说，叫模型「少做一点准备动作」，它反而跑得更快、答得更准。
这是 OpenAI 官方发布的 GPT-5.6 提示词指南里说明的重点，下面笔者整理三个重点：为什么精简指令反而更有效、OpenAI 建议的新写法是什么，以及开发者实际上要怎么改。
过去工程师写 prompt 的直觉是「讲越细，模型越听话」，把每一个步骤、每个例外情况都写进去，深怕模型漏做什么。但 OpenAI 在指南里点名，这套直觉在 GPT-5.6 身上失灵了。工程团队实测发现，一份 system prompt，简单来说就是，开发者在用戶对话开始前，先塞给模型的一段隐藏设定指令，如果塞满重复规则、对行为没有实质影响的风格叮嘱、冗余范例，以及模型本来就做得到的流程指导，拿掉之后模型的表现反而更好。
指南给的具体做法，是「从能跑的版本开始逐步删」：先留着目前有效的 prompt，一段一段拔掉可疑的部分，同时盯着 eval（AI 量化评估分数），简单来说就是，拿一组固定任务让模型跑，用分数衡量它答得好不好，有没有掉。
真正该留下来的，是用户看得到的结果、成功与停止的判断标准、安全与商业上的限制、依情境变化的工具选用规则，以及要求的输出格式。其余的，多是工程师自己心安用的赘字。
指南同时点出一个常被忽略的环节：工具描述本身也是 prompt 的一部分。给模型的工具越多、描述越含糊，模型判断该用哪个工具的成本就越高。OpenAI 建议只给任务相关的工具，每个工具描述都要交代做什么、何时该用、出错时怎么表现。换句话说，精简的对象不仅是「指令」，连「工具箱」本身都该一起瘦身。
指南里最核心的一句话是：「定义结果、重要限制、可用证据、完成标准，然后留空空间让模型自己选择有效率的路径。」简单来说就是，只告诉模型要去哪儿、有哪些不能碰的红线，不用规定它每一步该怎么走。
OpenAI 举的例子是「用最少的有用工具迭代解决请求，但不能让减少迭代次数牺牲正确性、必要证据或引用」，这是一条「若 X 则 Y」的决策规则，而不是一条死命令。
另一个容易被忽略的细节，是 GPT-5.6 默认回答就比较精简。以前工程师写在 prompt 里的「请简短回答」这类叮嘱，现在可能是多余甚至有害的。指南建议改用引数 text.verbosity，简单来说就是，单独用一个引数控制模型回答要多长，把语气和正式度分开处理，分成 low、medium、high 三档专门管长度，语气与正式度则另外描述个性，两者都写短。
如果真的需要更短的答案，指南建议明讲「留什么、砍什么」，而不是笼统丢一句「短一点」。至于模型要花多少力气思考，也就是 reasoning effort，简单来说就是，在模型回答前要花多少「思考力气」，指南把它分成 low、medium、high、xhigh、max 五级。调高之前，OpenAI 建议先检查 prompt 本身有没有写清楚成功标准与验证迭代，很多时候「把话讲清楚」比「加码让模型多想」更有效。
对开发者最实际的影响，是指南附的一套 prompt 迁移工作流。
OpenAI 讲得很直白：换模型时不要一次重写整套 prompt，原因是如果同时改模型、推理设置、prompt、工具集，之后根本分不出行为变化是哪一项造成的。正确顺序是先换模型、保留原本的推理强度设置，跑一次代表性的 eval 当基准，再拿掉过时的鹰架与重复指令，只针对「eval 显示真的退步」的地方做最小幅度的修正，然后重新测一次，每改一个变因，就重新量测一次，绝不同时乱动。
指南也要求开发者把「模型能自己做多少决定」写清楚，而不是模糊带过。OpenAI 给的示例政策是：回答、解释、检视这类请求，模型只能检查与回报，不能动手改；涉及变更或修复的请求，可以在范围内自行做本地变更并跑非破坏性的验证；真正牵涉对外写入、破坏性动作或扩大任务范围的，一律要先停下来询问。
指令越写越多，曾经是工程师求心安的方式。现在看来，这可能会拖慢模型、也在拖累账单。模型越聪明，人反而该学会少说话，把力气留给量测与验证。
114.87万 热度
22.72万 热度
393.79万 热度
182.73万 热度
21.44万 热度
OpenAI 发布 GPT-5.6 提示词指南：只给结果与红线，其余交给模型
OpenAI 公布 GPT-5.6 提示词指南，内部测试发现，把冗长的 system prompt 精简之后，分数不降反升 10% 到 15%，token 用量还省下 41% 到 66%。指南建议开发者只给模型结果、限制与停止标准，不用规定每一步该怎么走。
（前情提要：GPT-5.6 秘密测试疯传：ChatGPT 突变聪明、用户测试碾压 Fable 5）
（背景补充：Harness Engineering（AI 驭控工程）入门篇：OpenAI 最新编程标准，教你轻松做到 Lv.1）
本文目录
Toggle
OpenAI 内部测试显示，把一份原本落落长的 system prompt 大幅精简之后，分数不但没有掉，反而上升 10% 到 15%，同时 token 用量还省下 41% 到 66%。换句话说，叫模型「少做一点准备动作」，它反而跑得更快、答得更准。
这是 OpenAI 官方发布的 GPT-5.6 提示词指南里说明的重点，下面笔者整理三个重点：为什么精简指令反而更有效、OpenAI 建议的新写法是什么，以及开发者实际上要怎么改。
指令越少，模型越准？
过去工程师写 prompt 的直觉是「讲越细，模型越听话」，把每一个步骤、每个例外情况都写进去，深怕模型漏做什么。但 OpenAI 在指南里点名，这套直觉在 GPT-5.6 身上失灵了。工程团队实测发现，一份 system prompt，简单来说就是，开发者在用戶对话开始前，先塞给模型的一段隐藏设定指令，如果塞满重复规则、对行为没有实质影响的风格叮嘱、冗余范例，以及模型本来就做得到的流程指导，拿掉之后模型的表现反而更好。
指南给的具体做法，是「从能跑的版本开始逐步删」：先留着目前有效的 prompt，一段一段拔掉可疑的部分，同时盯着 eval（AI 量化评估分数），简单来说就是，拿一组固定任务让模型跑，用分数衡量它答得好不好，有没有掉。
真正该留下来的，是用户看得到的结果、成功与停止的判断标准、安全与商业上的限制、依情境变化的工具选用规则，以及要求的输出格式。其余的，多是工程师自己心安用的赘字。
指南同时点出一个常被忽略的环节：工具描述本身也是 prompt 的一部分。给模型的工具越多、描述越含糊，模型判断该用哪个工具的成本就越高。OpenAI 建议只给任务相关的工具，每个工具描述都要交代做什么、何时该用、出错时怎么表现。换句话说，精简的对象不仅是「指令」，连「工具箱」本身都该一起瘦身。
别再写步骤，写「终点」就好
指南里最核心的一句话是：「定义结果、重要限制、可用证据、完成标准，然后留空空间让模型自己选择有效率的路径。」简单来说就是，只告诉模型要去哪儿、有哪些不能碰的红线，不用规定它每一步该怎么走。
OpenAI 举的例子是「用最少的有用工具迭代解决请求，但不能让减少迭代次数牺牲正确性、必要证据或引用」，这是一条「若 X 则 Y」的决策规则，而不是一条死命令。
另一个容易被忽略的细节，是 GPT-5.6 默认回答就比较精简。以前工程师写在 prompt 里的「请简短回答」这类叮嘱，现在可能是多余甚至有害的。指南建议改用引数 text.verbosity，简单来说就是，单独用一个引数控制模型回答要多长，把语气和正式度分开处理，分成 low、medium、high 三档专门管长度，语气与正式度则另外描述个性，两者都写短。
如果真的需要更短的答案，指南建议明讲「留什么、砍什么」，而不是笼统丢一句「短一点」。至于模型要花多少力气思考，也就是 reasoning effort，简单来说就是，在模型回答前要花多少「思考力气」，指南把它分成 low、medium、high、xhigh、max 五级。调高之前，OpenAI 建议先检查 prompt 本身有没有写清楚成功标准与验证迭代，很多时候「把话讲清楚」比「加码让模型多想」更有效。
从「堆指令」到「量测式调整」
对开发者最实际的影响，是指南附的一套 prompt 迁移工作流。
OpenAI 讲得很直白：换模型时不要一次重写整套 prompt，原因是如果同时改模型、推理设置、prompt、工具集，之后根本分不出行为变化是哪一项造成的。正确顺序是先换模型、保留原本的推理强度设置，跑一次代表性的 eval 当基准，再拿掉过时的鹰架与重复指令，只针对「eval 显示真的退步」的地方做最小幅度的修正，然后重新测一次，每改一个变因，就重新量测一次，绝不同时乱动。
指南也要求开发者把「模型能自己做多少决定」写清楚，而不是模糊带过。OpenAI 给的示例政策是：回答、解释、检视这类请求，模型只能检查与回报，不能动手改；涉及变更或修复的请求，可以在范围内自行做本地变更并跑非破坏性的验证；真正牵涉对外写入、破坏性动作或扩大任务范围的，一律要先停下来询问。
指令越写越多，曾经是工程师求心安的方式。现在看来，这可能会拖慢模型、也在拖累账单。模型越聪明，人反而该学会少说话，把力气留给量测与验证。