7 月 12 日，OpenAI 在 developer site 静悄悄发了「Prompting guidance for GPT-5.6 Sol」，把 GPT-5.6 这个新模型家族怎么写 prompt 的官方配方一次性公开了。我读完觉得这是 7/9 GPT-5.6 上线故事的另一半，跟今早 7/13 那篇 https://cuigh.com/zh/posts/gpt-5-6-sol-production-migration-2026/ 生产代理迁移笔记放一起才完整。
最抢眼的是这组硬数：OpenAI 自己做的内部 coding-agent eval 实测，把系统提示从 GPT-5 时代的「百科全书型」砍成 lean 版本，评测分提 10-15%、token 用量降 41-66%、成本降 33-67%。这条数据的意思不是「模型强所以写得短」，反过来：是模型能力到位之后，prompt 设计哲学整个反转了。
关键数据：lean prompt 跑出 10-15% / 41-66% / 33-67%
OpenAI 文档原话：
“In a sample of internal coding-agent eval runs, configurations with leaner system prompts improved evaluation scores by roughly 10–15% while reducing total tokens by 41–66% and cost by 33–67%. Results will vary by workload, so treat these ranges as directional and validate changes on representative tasks from your own application.”
三个区间方向一致：分涨、token 降、成本降，降幅都在 30% 以上。OpenAI 这条不是说「少写几个 token 给你省钱」这种表面账，是说系统提示里重复的指令 + 冗余的例子 + 详尽的工具描述，不只是在浪费钱，是在拖累模型表现。
这次给的设计哲学反转：从「穷举规则」到「描述目的地」
OpenAI 14 节围绕一条主线展开，核心反转是这一条：
“Describe the destination rather than prescribing every step. GPT-5.6 can usually choose an efficient search, tool, or reasoning path when the prompt states what good looks like.”
过去 12 个月，大家写 prompt 的默认姿势是「穷举规则，防模型走偏」，为每种可能情况写一条 ALWAYS / NEVER / must / only，把决策路径锁死。GPT-5.6 文档反过来：写「什么是好」，路径让模型自己选。配套规则：
“Avoid unnecessary absolute rules. Use ALWAYS, NEVER, must, and only for true invariants such as safety rules, required fields, or actions that should never happen. For judgment calls, such as when to search, ask, use a tool, or keep iterating, prefer decision rules.”
我的判断是：这条规则一改，系统提示里 80% 的 ALWAYS / NEVER 都要被重写，它们原本都是 judgment calls 被误写成 absolute rules。
5 个最关键的提示词工程反转
14 节里我挑出 5 个最影响 builder 日常的：
反转 1：verbosity 靠 API 参数，不是 “be concise”
GPT-5.6 默认比 GPT-5.5 简洁。文档原话：
“GPT-5.6 tends to be more concise by default than GPT-5.5. When migrating, check whether broad brevity instructions such as ‘Be concise’ or ‘Keep it short’ are still useful. They may be unnecessary for some tasks and can sometimes make responses too brief.”
要让 verbosity 全局可控，用 text.verbosity API 参数设三档（low / medium / high），prompt 里只写 task-specific 长度需求。软指令 “be concise” 的副作用是「有时候模型会答得过短，反而缺关键信息」。
反转 2：autonomy 是 prompt 工程，不是 runtime guard
GPT-5.6 是第一个官方明确「autonomy 应该写在 prompt 里」的模型。文档给的三段式 policy 模板：
- 读类任务（answer / explain / review / diagnose / plan）：inspect 资料、报告结果。没有要求实施时不要 implement changes。
- 改类任务（change / build / fix）：做请求范围内的 in-scope 本地改动 + 跑非破坏性 validation，不用先问。
- 外写 / 破坏性 / 采购 / scope 扩张：require confirmation。
过去我们以为 autonomy 是 runtime 层，应用代码里写「某些操作需要人审批」。OpenAI 这次明确：autonomy 边界是 prompt 的事，在 prompt 里把每类请求允许的动作讲清楚，模型自己会按规则停。runtime guard 应该只兜底 prompt 没覆盖的边界，不是替代 prompt。
反转 3：citation 是 prompt 工程，不是后处理
文档原话：
“For grounded answers, citation behavior should be part of the prompt. Define what needs support, what counts as enough evidence, and how to behave when evidence is missing. Absence of evidence should not automatically become a factual ’no.’”
这一段我读的时候愣了一下：过去大家做 RAG 应用，cite 是后处理：rerank 完了拼一段 prompt 强插引用。GPT-5.6 这次明确citation 行为本身要写进 prompt：哪些需要支持、什么算「够用的证据」、证据缺失时怎么回应（不能默认「没有证据 = 没有这件事」）。对 RAG pipeline 是结构性的改动。
反转 4：一句 preamble + 阶段稀疏更新，不要每步 narrate
文档原话：
“For multi-step or tool-heavy tasks, prompt for a short visible preamble before the first tool call, then sparse outcome-based updates at major phase changes. Do not ask the model to narrate routine tool calls.”
翻译成工程语言：第一次工具调用前写一句简短的 preamble（让用户知道 agent 要做什么）；之后只在 major phase change 给 outcome-based 更新，不要让模型 narrate 每个 routine tool call。我自己的体验里，narrate 每个 tool call 的 agent 是最差的前端体验：用户看到「正在读 X.json / 正在读 Y.json / 正在读 Z.json」，这种反馈既不增加信任也不增加控制感。OpenAI 这次官方明确这是反模式。
反转 5：升级 reasoning effort 之前，先看 prompt 缺不缺 completion bar
文档开头那句：
“GPT-5.6 works best when prompts define the outcome, important constraints, available evidence, and completion bar, then leave room for the model to choose an efficient path.”
实际工程含义：别看到模型表现不够就先升 reasoning effort（改 model 参数），先回去看 prompt 里有没有写清楚 completion bar / success criterion。OpenAI 的逻辑是：reasoning effort 是给「已经知道要做什么」的模型更长的思考预算；prompt 没定义目的地时，加 reasoning 只会让模型「更长地思考错的事」。
迁移 workflow：不要一次性重写，一次砍一组 + rerun evals
这一条我读了三遍才意识到它多重要。文档原话：
“Start with a prompt and tool set that already works. Remove one group of instructions, examples, or tools at a time, then rerun the same evals.”
工程含义：永远不要把一个跑得还行（或者已经上线）的 prompt 堆栈一次性重写。OpenAI 建议：每轮只砍一组指令 / 例子 / 工具，然后跑同一组 eval，看分是涨了还是跌了。配套还有一条：
“Review the remaining instructions for contradictions. GPT-5-class models follow prompt contracts closely, so conflicting rules can create more instability than missing detail.”
GPT-5 这一代模型对 prompt contract 的「遵守度」比上一代高，所以两条相互冲突的规则，比「少一条规则」造成的 instability 更大。迁 GPT-5.6 时，改冲突比补空缺优先级更高。
跟 7/13 Ploy 那篇的区别在哪
今早 7/13 那篇 https://cuigh.com/zh/posts/gpt-5-6-sol-production-migration-2026/ 讲的是 Ploy 把生产代理从 Claude Opus 4.8 迁到 GPT-5.6 Sol 的工程账：Opus 单任务 $3.06 → GPT-5.6 $2.22、8m00s → 3m42s，但账下面三个真坑，工具参数越权（25 字段全填默认值）、partial-prefix 缓存被砍、reasoning replay 用 server-side item reference 翻车。
这篇 OpenAI 官方 prompt 指南讲的是builder 端账：同样迁到 GPT-5.6，prompt 那一侧要重写什么。两篇放一起看才是完整迁移路径：
| 维度 | 7/13 Ploy 那篇 | 这篇 |
|---|---|---|
| 来源 | Ploy 工程团队自己的生产 trace | OpenAI 官方 doc，内部 coding-agent eval |
| 视角 | runtime / schema / cache 三个 runtime 坑 | prompt 设计 5 个反转 + 迁移 workflow |
| 给出的修法 | schema 重写 + 显式 cache key + 不依赖 server-side replay | lean prompt + text.verbosity + autonomy 在 prompt 里 + completion bar 优先 |
| 给 builder 一句话 | 「堆栈要为 GPT-5.6 主动表态」 | 「描述目的地，不穷举路径」 |
同一周，OpenAI 把 GPT-5.6 重新定位成「靠 stack 配套才能榨出最大值的模型」：Ploy 那篇从 runtime 端验证这件事，这篇 OpenAI 自己从 prompt 端给出官方 recipe。两篇互为表里。