升级到 GPT-5.6 Sol，我的提示词要改吗？

先说结论：不要因为模型升级，就把现有提示词推倒重写。

更稳的迁移顺序是：先只切换模型，保留当前的 reasoning 配置，用同一批真实任务跑出基线；然后根据失败样本做减法。GPT-5.6 Sol 更需要清楚的结果、边界和完成标准，不需要一份把每个操作步骤都写死的超长说明书。

这次升级真正值得审计的是旧提示词里多年累积的脚手架，业务意图通常原样保留。

模型、提示词、工具集和 reasoning effort 同时变化，结果变好或变坏都很难归因。官方给出的迁移方法很克制：从能工作的配置出发，先换到 GPT-5.6，保留 GPT-5.5 或 GPT-5.4 的 reasoning effort，跑一遍代表性任务，再测试同档和低一档配置。

这和普通依赖升级没区别。你不会在升级数据库驱动的同一个提交里，顺手重写连接池、SQL 和压测脚本；模型迁移也不该把变量搅在一起。

我会先准备一组 10 到 30 条真实任务，至少覆盖这些容易拉开差异的场景：

• 跨文件修改和调用链追踪
• 带约束的缺陷修复
• 需要工具检索的技术判断
• 长上下文下的局部改动
• 失败后的自我修正与验证

记录的不只是“答案看起来怎么样”，还包括任务是否完成、是否越界、工具循环次数、总 token、耗时，以及最终验证有没有通过。没有这组基线，“提示词优化”很容易退化成凭感觉改文案。

旧提示词常见的问题是同一个意思写了几遍：Be concise、Keep it short、Avoid verbosity；或者一边要求“直接执行”，另一边又写“遇到不确定性必须先询问”。

GPT-5 系列会认真遵守提示词契约。规则越多，发生冲突的机会越大。官方公布的一组内部 coding-agent eval 里，精简 system prompt 后，评测分数提高约 10% 到 15%，总 token 下降 41% 到 66%，成本下降 33% 到 67%。这组数字只能当方向参考，不能替代你自己的 eval，但它至少说明“写得更多”并不天然等于“控制得更好”。

迁移时可以优先删掉四类内容：

• 同一规则的不同说法
• 模型已经稳定做到的过程说明
• 没有修复已知失败模式的示例
• 与当前任务无关的工具及冗长描述

ALWAYS、NEVER、必须、只能 留给真正不允许协商的约束，例如禁止破坏性操作、不得修改公开 API、输出必须满足某个 schema。像“什么时候搜索”“什么时候追问”这种判断题，写决策条件比写绝对规则更可靠。

对 Codex 来说，一条有效的任务提示词至少要让它知道四件事：要产生什么可见结果、相关上下文在哪里、哪些边界不能碰、拿什么证明已经做完。

下面这种写法看起来细，但把精力花在了遥控过程上：

先搜索所有相关文件，然后逐个读取。先分析原因，再列三个方案，
选择最小方案。修改时一步一步进行，每一步都告诉我。最后运行测试。

换成结果导向后，Codex 有更大的空间选择调用链，同时完成标准更硬：

修复设置页偶发显示“保存成功”但刷新后数据丢失的问题。

复现步骤：切换“启用提醒”，保存后刷新，开关恢复原值。
约束：不改变 API 结构，只修改相关代码；如可行，补回归测试。
完成标准：先复现，再修复；运行最小相关测试和 lint，并报告实际结果。

第二版没有规定先读哪个文件、列几个方案，却很难在“代码改了但没验证”的位置提前停下。这正是 GPT-5.6 所说的 outcome-first：把路径选择交给模型，把验收权留在提示词里。

如果任务会调用多个工具，再补一条停止条件就够了：证据足以回答核心问题时停止；缺少必要事实时，使用最小的有效回退。不要为了“更全面”无限搜索，也不要为了减少调用牺牲正确性。

一次性任务的细节放在当前 prompt，稳定的仓库约束放进 AGENTS.md。这条分界升级后没有变化，反而更重要。

Codex 启动任务时，会从全局配置开始，再从项目根目录沿当前工作目录逐层加载指令；越靠近当前目录的文件优先级越高。仓库根目录适合放包管理器、目录约定、通用验证命令和安全边界，局部模块的特殊规则放在更近的目录。临时需求不要写进去，否则它会在后续任务里变成过期前提。

一份仓库级 AGENTS.md 的核心可以很短：

## Commands
- Use pnpm. Do not use npm or yarn.
- Run pnpm lint and the smallest relevant test after code changes.

## Change boundaries
- Keep public APIs stable unless the task explicitly changes them.
- Do not include unrelated refactors or formatting changes.

## Completion
- Report the commands actually run and their results.
- If validation cannot run, state the blocker and the next-best check.

这里保留的是会改变行为的仓库事实。至于“代码应当优雅、可维护、符合最佳实践”，删掉后如果没有可观测差异，它就不值得长期占用上下文。更完整的分层方法，我在《如何写用户级 AGENTS.md》里单独写过。

GPT-5.6 默认比 GPT-5.5 更简洁。旧 prompt 里的 Be concise 可能已经多余，甚至会把必要的证据和风险一起裁掉。需要稳定控制输出长度时，API 侧用 text.verbosity 设置 low、medium 或 high；单次任务再说明必须保留的内容，例如结论、证据、重大限制和下一步。

reasoning 也一样。不要在 prompt 里反复写“认真思考”“多想几步”。先保留原 effort 做基线，再用真实任务比较低一档。max 和 Pro mode 适合少量质量优先、确实能从更多推理中获益的任务，不是全局默认值。参数属于运行配置，提示词负责描述问题，两者混在一起只会让评测更难解释。

我现在会把提示词迁移当成一次小型回归工程：固定任务集，只改一个变量，查看 trace，定位具体失败，再做一次小改动。

只有观察到稳定回归，才增加一条针对性指令。改完重跑同一组任务。不要一口气重构整个 prompt stack，否则最后只知道“它变了”，不知道是哪一行让它变的。

所以，升级到 GPT-5.6 Sol 后，我的提示词会改，但不是立刻加一套“5.6 专用咒语”。我会先保留有效契约，再删掉模型已经不需要的扶手：重复过程、宽泛风格词、无关示例和冲突规则。剩下的内容应该更像验收标准，而不是操作手册。