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

TL;DR： 没必要推倒重写。稳妥的做法是先只换模型，保留原来的 reasoning 配置，用同一批真实任务跑出基线，再对照失败样本做减法。GPT-5.6 Sol 更需要清楚的结果、边界和完成标准，不需要一份写死每个操作步骤的超长说明书。趁这次升级清理旧提示词里积攒多年的脚手架即可，业务意图通常不用动。

模型、提示词、工具集和推理强度一起变，结果无论变好还是变坏，都很难归因。OpenAI 给出的迁移建议很克制：从当前可用的配置出发，只切换到 GPT-5.6，保留 GPT-5.5 或 GPT-5.4 的推理强度，先跑一遍代表性任务，再测试同档和低一档配置。

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

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

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

每轮跑完，不要只看“答案像不像人写的”，还要记录任务是否真正完成、有没有越界修改、工具调用了几轮、消耗了多少 token、耗时多久，以及最终验证是否通过。没有这组基线，“优化提示词”很容易变成凭感觉改文案。

旧提示词经常把同一件事写上几遍，比如 Be concise、Keep it short、Avoid verbosity，说的其实都是简洁；还有些规则会互相冲突，一边要求“直接执行”，另一边又要求“不确定时必须先问”。

GPT-5 系列会认真读取提示词里的每条约定，规则越多，互相冲突的概率就越大。OpenAI 内部一组 coding-agent eval 显示，精简 system prompt 后，评测分数提高约 10% 到 15%，总 token 下降 41% 到 66%，成本下降 33% 到 67%。这些数字只能作为方向参考，替代不了自己的 eval，但至少能说明：提示词写得更多，并不代表控制得更好。

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

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

把 ALWAYS、NEVER、必须、只能 留给真正不能妥协的约束，比如不能用 --force、不能修改公开 API、输出必须满足某个 schema。至于什么时候该搜索、什么时候该追问，与其写成绝对命令，不如写清判断条件。

给 Codex 写任务，至少要让它弄清四件事：需要什么产出、去哪里找上下文、哪些边界不能碰，以及如何证明任务已经完成。

下面这种写法看起来很细，却把精力都花在了遥控执行过程上：

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

换成结果导向的写法，让 Codex 自己选择执行路径，同时明确完成标准：

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

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

第二版没有规定先读哪个文件、列几个方案，却更不容易停在“代码改了但没验证”的位置。这就是 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，再在单次任务里说明必须保留的内容，例如结论、证据、重大限制和下一步。

推理强度也是如此。不要在 prompt 里反复写“多想想”“认真推理”，先保留原来的 effort 跑出基线，再用同一批任务测试低一档配置。Extra High 只适合少数质量优先、确实能从更多推理中获益的任务，不宜设成全局默认。参数交给运行配置，提示词负责把问题说清楚，两者混在一起只会让评测更难归因。

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

只有看到能够稳定复现的回归，才增加一条针对性指令，改完后再跑同一组任务。不要一口气重构整个 prompt stack，否则最后只知道“它变了”，却不知道是哪一行导致了变化。

所以，升级到 GPT-5.6 Sol 后，我会改提示词，但不会马上添加一套“5.6 专用咒语”。我会先保留仍然有效的契约，再删掉模型已经不需要的扶手：重复的过程描述、宽泛的风格指令、无效示例和冲突规则。清理之后，留下来的应该更像一份验收标准，而不是操作手册。