模型同名，不等于产品同版

同一个模型名称，在同一天里也可能对应不同的产品行为。

OpenAI 8 月 6 日的更新把这个问题摆到了台面上。官方称，ChatGPT 中的 GPT-5.6 Sol 将给出更聚焦的回答，提升事实可靠性，并缩小快速回答与深度思考之间的体验差异；同时又明确说明，这次更新只影响 Chat 体验，驱动 Work 与 Codex 的 GPT-5.6 Sol 版本不在此次变更范围内（官方公告）。

这不是一个无关紧要的命名细节，而是所有 AI 产品团队都该注意的实验边界。

GPT-5.6 Sol、premium 或 latest 这样的标签，无法完整描述一次实验。用户最终看到什么，还取决于产品表面、实际快照、推理档位、系统指令、工具、检索、安全层、记忆、账号策略和灰度批次。若台账只记模型家族，团队很容易把变化归错组件，把一个表面的结果移植到另一个表面，或者在没有证明两个系统等价的情况下宣称“模型回归”。

OpenAI 还报告称，在一组金融、医疗与法律内部题目中，GPT-5.6 Sol 相比 GPT-5.5 Instant 显著降低了包含事实错误的回答比例。这是厂商内部测量，不是对其他产品工作负载的保证。Y Build 没有独立复跑该评测，本文也不做模型优劣排名。下面是一套建议执行的表面变更演练，供小团队用自己的验收样例验证。

今天最值得改变的不是模型采购表，而是实验记录方式：不要只问“用了哪个模型”，要问“是哪一个完整产品表面产出了这个结果”。随后固定表面、配对跑样例，把输出质量与路由、工具行为拆开，最后只批准真正拿到证据的那套配置。

发生了什么：一个家族名，至少四个运行表面

8 月 6 日公告描述的是一次 Chat 专属更新。Plus 与 Pro 用户获得新的思考滑块；公告称，同一个 GPT-5.6 Sol 将同时驱动 Instant 与更深层推理。Free 与 Go 用户则会转向 GPT-5.6 Luna，文本聊天不限量，并获得单独的 Think 控件；工具仍有额度限制。

但当前的 GPT-5.6 ChatGPT 帮助页 仍写着：日常默认是 GPT-5.5 Instant，GPT-5.6 Sol 驱动 Medium 及以上推理档位。截至 8 月 7 日，两份官方材料形成了可观察到的路由描述冲突。较新的公告可能在描述尚未完全同步到帮助页的灰度，也可能与帮助页使用了不同层次的路由概念；公开材料没有给出答案。本文不会替厂商猜测隐藏的线上真相。

这项冲突正是本文的现场记录，而不是脚注。只看公告的团队会在台账里写入 “Sol”；只看帮助页的团队可能写入 “GPT-5.5 Instant”。两者都无法证明某一次回答背后的内部路由。正确做法是同时保留来源 URL、观察时间、账号上下文、可见控件和“冲突未解决”状态。

同一帮助页还把标准 Chat、Work、Codex 与 API 的可用模型分开列出。Work 与 Codex 会按套餐开放 Sol、Terra 与 Luna；API 则通过模型 ID 和请求参数暴露这个家族。它们共享品牌名称，却不必共享有效指令、工具契约、状态模型、灰度节奏或安全行为。

产品团队至少要区分四层：

1. 家族：能力代际，例如 GPT-5.6。
2. 档位或模型：Sol、Terra、Luna，以及 API 模型 ID 或可用的日期快照。
3. 产品表面：Chat、Work、Codex、API，或基于其中一个表面构建的第三方产品。
4. 具体配置：推理档位、工具、系统层、记忆、检索、账号策略、客户端版本和灰度状态。

家族名适合沟通，不足以支撑因果归因。

OpenAI 的 GPT-5.6 API 模型页 把 API 边界写得很清楚：别名、快照、端点、工具、上下文限制和速率限制都是独立字段。官方模型指南还建议，迁移时保留当前推理档位作为基线，再用代表性任务比较另一个档位，并依据最终任务成功率，而不是假定能力更强的路由一定更好。这些控制都无法证明 Chat 内部发生了什么，因为 Chat 产品掌握着更多未暴露的系统层。

把实验单位定义为“表面指纹”

表面指纹是能说明本次究竟测了哪个系统的最小记录。托管产品不会暴露所有内部修订，因此它未必能做到逐比特复现。它的作用，是把已知值、厂商控制但未公开的值，以及真正未知的值分开。

在解释结果前，先记录这些字段：

无法获取的字段不要靠猜测补齐，直接写 provider-controlled / not exposed。未知本身就是复现能力的证据，不该被伪装成一个精确版本。

还要防止一种常见的概念错位：UI 标签是一项观察；API 响应字段是机器可读的厂商声明。两者都不能代表厂商完整的内部部署。只保存表面真正暴露的内容，不多推一步。

这里设置一条硬门槛：若团队无法证明两次运行拥有相同的表面身份，也无法准确说明它们哪里不同，就只能报告体验差异，不能宣称模型回归。 这个限制是有意为之，它阻止一项有用的产品观察被升级成错误的因果结论。

从一个产品场景开始，而不是公共榜单

假设一个小团队正在发布 AI 研究助手，把用户的短问题转成决策简报。客户通过产品内的 API 工作流使用它；团队内部则会用 Chat 和 Codex 排查失败、改进提示词。

这份简报有五项产品要求：

• 第一段直接回答决策问题；
• 每个日期、数字和规则都在主张附近给出来源；
• 区分事实、厂商主张、推断与未知；
• 为下游保留符合 schema 的 JSON 证据对象；
• 任何外部写入或购买动作都必须先询问。

8 月 6 日的 Chat 更新看起来很相关，因为厂商主张回答更紧凑、事实错误更少。但团队不能把十道题贴进 Chat，觉得结果不错，就推断 API 产品也同步改进。Chat 可能使用不同的指令、联网方式、推理路由、来源展示与灰度策略；Codex 又多了一层工具和任务环境。

更合适的是建立 24 个样例。先选六种真实任务形状，并移除或合成其中的私密数据：

1. 含一个近期日期的产品政策问题；
2. 带单位与折扣条件的价格比较；
3. 包含两份冲突来源的发布决策；
4. 本应先追问一个问题的客服场景；
5. 需要保留安全帮助路径的双重用途请求；
6. 可以分析、但不允许直接发送的动作请求。

每种任务再做四个难度变体：干净、含歧义、缺来源、带干扰。24 个样例无法支撑模型榜单，却足够小到可以逐条复审，也覆盖了足够多的情况，能发现产品契约是否发生变化。

先写表面变更清单，再开始跑样例

把指纹和样例版本放进同一份记录，避免团队在实验中途悄悄换提示词或工具集。

surface_change_manifest:
  experiment_id: "decision-brief-surface-2026-08"
  hypothesis: "候选表面让简报更聚焦、引用更完整，同时不丢字段和审批边界"
  fixture:
    version: "brief-suite-v3"
    case_count: 24
  baseline:
    surface: "pin-current-production-surface"
    account_plan: "record"
    client_version: "record"
    observed_at: null
    visible_control: "record"
    documented_route:
      claim: "record"
      source_url: "record"
      conflict_status: "none | unresolved"
    displayed_model: "record"
    requested_model_id: "record-if-api"
    resolved_snapshot: "record-if-exposed"
    reasoning_control: "record"
    prompt_revision: "sha256-or-version"
    tools_revision: "sha256-or-version"
  candidate:
    surface: "record"
    account_plan: "record"
    client_version: "record"
    observed_at: null
    visible_control: "record"
    documented_route:
      claim: "record"
      source_url: "record"
      conflict_status: "none | unresolved"
    displayed_model: "record"
    requested_model_id: "record-if-api"
    resolved_snapshot: "record-if-exposed"
    reasoning_control: "record"
    prompt_revision: "sha256-or-version"
    tools_revision: "sha256-or-version"
  unknowns: []

工具 schema 和提示词都要哈希或版本化。带 file search 的模型与不带 file search 的模型不是同一个处理条件；两个同名工具如果返回字段不同，也不能混在一起比较。

如果托管 UI 没有暴露提示词或工具修订，就记录限制，不要声称完成了“只改变模型”的对照。实验仍可回答“哪个表面更适合人工审核”，却不能回答“哪套权重更强”。

可以跨表面比较，但不能假装它们可互换

让每项决策都绑定到真正要完成的工作：

跨表面对照当然有用，但结论的主语也必须是表面。由于外围运行环境已经变化，它不能隔离出模型修订的单独作用。

若 documented_route.conflict_status 仍是 unresolved，可以说“8 月可见灰度后，这批 Chat 回答变短了”，不能说“GPT-5.6 Sol 变短了”，除非另有证据确认实际服务身份。结论的主语必须与实验真正观察到的身份一致。

当采样或隐藏路由可能波动时，每个样例至少重复三次。打乱样例顺序；除非状态本身就是实验变量，否则每次新建会话或任务。记录被剔除的运行及基础设施错误，不要悄悄补跑后覆盖。

如果 UI 提供思考滑块，记录其可见位置与产品标签。除非厂商明确给出映射，否则不要把它翻译成 API 的 reasoning.effort。控件看起来相似，不代表背后的预算和编排相同。

分层评分，不要只给一个“质量分”

单一质量分无法解释变化发生在哪一层。至少拆成五组：

1. 表面身份。 是否保留了账号、客户端、可见控件、时间、显示路由、文档来源与冲突状态？身份不完整时，即使回答更好，也不能做模型级归因。

2. 契约完成度。 是否开门见山、保留必需章节、输出有效结构化数据，并遵守长度要求？这些项目大多可以用确定性检查。

3. 证据质量。 重要事实是否有来源？引用页面是否真的支持主张？日期、数量、单位和政策边界是否正确？关键主张通常仍需人工复核。

4. 交互行为。 是否在需要时追问、避免重复、保留上下文，并在正确时点把控制权交还给用户？Chat 专属调优可能影响这一层，即便任务事实本身没变。

5. 决策价值与修正成本。 输出是否抓住真实取舍、说明不确定性、给出可执行下一步？同时记录审稿修正分钟数、拒收结果、延迟、可获取的 token 用量、工具调用与重试。某个 UI 没有 token 数据时就写“不可得”，不要虚构对比。

OpenAI 的评估最佳实践建议使用任务专属评测、日志、持续评估、人工校准与对照，而不是模糊的开放式打分。更早但仍有参考价值的 ML Test Score 也把数据、模型、基础设施与监控测试共同视为生产就绪度。小团队不必复制大平台，但必须让分数能解释：到底是哪一层契约发生了变化。

把事实、厂商主张、推断与未知分开

在决策记录中使用四种证据标签：

已确认的产品事实： OpenAI 明确说，8 月 6 日的 GPT-5.6 Sol 更新只影响 Chat，不改变 Work/Codex 中的版本。这是一项直接的范围声明。

厂商主张： OpenAI 报告称，在其金融、医疗与法律内部评测中，GPT-5.6 Sol 相比 GPT-5.5 Instant，出现至少一项事实错误的回答约少 68%。公告页没有公开完整题集、裁决细节和结果分布，因此不能把这个数字换算成你的产品验收率。

作者推断： 同名表面应该作为不同实验条件进行版本化。这个结论来自官方描述的表面范围差异与 API 的独立配置方式，但本文清单是 Y Build 提出的方法，不是 OpenAI 标准。

未知： 某个具体账号是否已进入灰度、某次 Chat 回答来自哪个内部修订，以及 Chat 可见思考控件是否对应某个 API effort。公开页面没有给出这些答案。

这样的证据语法能减少无意中的营销口吻，也方便后续修订：若厂商以后公开快照 ID，可以只解决一项未知，而不必重写整份实验。

哪些失败会制造“假回归”

灰度批次变了。 基线与候选来自不同账号、套餐、区域、客户端或日期，团队却把权限或灰度差异归因于模型质量。

一次实验同时变更了两个层面。 模型更新与提示词、检索、工具或安全策略同时上线，输出发生变化，却无法确定原因。

把浮动别名当成固定快照。 API 台账只写家族别名，没有实际快照或运行时间，后续重跑可能落到另一个后端。

裁判和候选一起变化。 用同一个正在变化的模型或表面给新输出打分，或者中途更换评分标准，导致新旧分数不可比。

状态串入其他样例。 Chat 历史、项目记忆、保留推理、检索缓存或旧文件影响后续运行，看起来像改进，其实只是上下文延续。

把遥测缺失当成零。 某个表面无法提供 token 用量、工具失败、引用或被剔除运行等数据，仪表板却把缺失值算作更优表现。

平均值掩盖关键切片。 整体风格变好，但缺来源或动作边界样例退步；团队只看平均分，忽略阻断性失败。

把 Chat 观察写成 API 结论。 人工看到日常回答更好，就假定生产端点同步更新。OpenAI 自己对本次更新范围的说明，解释了为什么不能据此推断 API 也已变化。

微软关于遥测丢失下可信实验的研究并非专门讨论大模型表面，但支持一个更一般的测量警告：结果遥测缺失会让实验产生偏差。unknown 应是一种限制结论的状态，不是方便填入的零。

发布必须绑定到具体配置凭证

不要批准“GPT-5.6”，只批准一条完整路由。

surface_change_decision:
  experiment_id: "decision-brief-surface-2026-08"
  decision: "promote | hold | reject"
  decision_subject: "observed_surface | api_configuration | model_revision"
  causal_attribution: "available | unavailable"
  promoted_scope:
    product_job: "decision-brief generation"
    surface: "api"
    requested_model_id: "pin"
    resolved_snapshot: "pin-if-exposed"
    reasoning_control: "pin"
    prompt_revision: "pin"
    tools_revision: "pin"
  evidence:
    surface_identity_complete: false
    documentation_conflicts: []
    completed_case_runs: 0
    contract_pass_rate: null
    critical_unsupported_claims: null
    reviewer_correction_minutes_p50: null
    latency_p95_ms: null
    cost_per_accepted_brief: null
  blockers:
    invalid_json: 0
    unauthorized_external_actions: 0
    missing_required_approval: 0
    unresolved_critical_source_disagreements: 0
  rollback_trigger: "define"
  approved_by: []
  remaining_unknowns: []

发布前，阻断性不变量必须全部为零。凭证校验器还要强制执行一条规则：若 surface_identity_complete: false，则 causal_attribution 必须是 unavailable，且 decision_subject 不能是 model_revision。团队仍可把 decision 写成 promote，但批准的是“某个已观察到的工作表面更适合这项任务”，不是批准 GPT-5.6 这个模型。软指标要在实验前设好容差：1% 的风格偏好不应抵消 20% 的修正时间增长；未测到的成本也不能写成“没有变化”。

若涉及生产流量，先小比例上线 API 路由，保留基线，并监控与样例相同的任务切片和回滚触发器。若只是 Chat、Work 或 Codex 内部流程，则在操作手册中写明账号、客户端、日期和允许任务，不要把它扩写成模型家族的普遍结论。

适用范围与不适用边界

当厂商更新同名模型、UI 改变路由或推理控件、别名移动、托管工作区策略变化，或者同一家族同时出现在多个产品中时，这套表面台账很有用。尤其适合“团队用消费级表面做人工工作，同时用 API 承载客户自动化”的情况。

不要用 24 个样例宣称通用智能排名、医疗或法律安全、总体公平性，或厂商全局优劣。这些结论需要更大规模、由领域人员参与的评估与更多独立证据。合成样例不能替代上线后的监控；也不要为了复现而记录真实敏感提示词，应尽量删减、脱敏或构造安全等价样例。

NIST AI 风险管理框架强调，测量与风险处置要适配具体使用情境。表面台账正是把证据绑定到一项产品工作和一套明确配置；不能据此认证厂商、模型家族或所有下游用途。

如果变更完全是确定性的，而且已有完整单元测试，也不必使用这套协议。没有模型或托管产品行为参与时，普通版本控制与测试更合适。

一份 48 小时 Build Lab 流程

第 0–2 小时：冻结证据。 保存每项厂商声明、来源与观察时间，写明产品任务、基线路由、候选路由和允许结论。

第 2–6 小时：组装样例。 选择六种任务形状，各做四个难度变体，移除客户数据，冻结来源，定义阻断性不变量。

第 6–12 小时：生成表面指纹。 记录账号、客户端、可见控件、文档路由、模型名称或 ID、提示词、工具、状态策略、时间与灰度迹象；对团队能控制的内容做哈希。

第 12–24 小时：配对运行。 打乱顺序、重置状态，必要时每项重复三次，并保留错误和废弃运行。

第 24–36 小时：盲审并检查最弱切片。 分别评分身份、契约、证据、交互、实用性与修正成本；单看含歧义、缺来源、动作边界与长上下文样例。

第 36–42 小时：填写凭证。 只对一套配置做批准、暂缓或拒绝，写明主张边界与剩余未知。

第 42–48 小时：小范围上线并观察。 灰度一小部分流量，或先改内部操作手册；设置回滚门槛和下次复查时间。

这套流程不是让小团队模仿模型实验室，而是避免产品标签制造虚假精度。当厂商明确说某个 GPT-5.6 Sol 表面变了、另一个没变时，正确回应不是困惑，而是换一个更可靠的实验单位。

参考资料

1. OpenAI，《Improving GPT-5.6 Sol in ChatGPT—and expanding access to GPT-5.6 Luna for free users》
2. OpenAI Help Center，《GPT-5.6 in ChatGPT》
3. OpenAI API，《GPT-5.6 Sol Model》
4. OpenAI API，《Model guidance》
5. OpenAI API，《Evaluation best practices》
6. NIST，《AI Risk Management Framework》
7. Google Research，《The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction》
8. Microsoft Research，《Trustworthy Experimentation Under Telemetry Loss》