GPT-6 Intelligent UI 让 ChatGPT 在模型仍在思考时，就开始生成包含文字、图表、按钮、表单和交互工具的界面。OpenAI 公开的关键机制有两个：原生可流式组件库，以及在模型生成过程中处理界面的编译器。真正的架构变化因此不只是回答更好看，而是模型输出开始携带状态和动作。要把这种能力用于生产环境，系统需要一份流式运行时合同，让部分结果、组件权限、失败恢复和业务完成状态都可观测、可验证。
OpenAI 于 2026 年 10 月 7 日发布这项能力，并明确本轮更新作用于 ChatGPT 的 Chat 体验，Work 和 Codex 所使用的模型没有随之调整。官方尚未公开组件协议、编译器 API、事件格式和完整失败语义。下文提出的是基于公开事实的工程推导，不代表 OpenAI 未披露的内部实现。
编译器开始承担信任边界
文本流的合同相对简单：Token 按序到达，客户端渲染，流结束后得到一条完整消息。动态界面同时增加了多组变量：
- 模型需要选择组件、布局和数据关系；
- 组件外壳与数据可能分批抵达；
- 用户会在模型继续生成时开始操作；
- 按钮可能触发外部系统状态变化；
- 后续推理可能修订前面的部分结果；
- Web 与移动端需要保留相同语义。
原生组件库把模型可表达的界面限制在受控词汇中，编译器负责把生成结果转为客户端可以执行的结构。这种分工保留了组合自由，也给 schema 校验、属性归一化、兼容性处理和降级策略留下确定性边界。
现有一手开发文档已经展示了类似思路。Vercel AI SDK 把工具的输入就绪、输出就绪和输出错误状态映射到预定义 React 组件。Google A2UI 把界面意图与客户端渲染分开，支持组件目录、schema 版本和流式 JSON 校验。它们与 ChatGPT Intelligent UI 属于不同实现，但共同说明一件事：生产级生成式界面需要结构化意图与确定性渲染之间的边界。
因此，UI 编译器既是渲染设施，也是策略执行点。
流式界面需要明确的完成语义
OpenAI 还披露，GPT-6 可以交错执行思考与回答。多个部分响应应持续提供有效信息，同时保持最终答案的连贯和事实质量。到了交互界面中，流结束已经不足以单独定义完成。
至少需要四种状态：
| 状态 | 含义 | 用户可以据此做什么 |
|---|---|---|
provisional |
结构或内容仍可能修订 | 阅读和探索，暂不视为已提交 |
ready |
必需数据和校验已经就绪 | 操作本地控件 |
committed |
响应或动作越过验收边界 | 把结果视为稳定状态 |
failed |
组件、数据、编译或动作失败 | 查看失败范围并进入恢复路径 |
涉及实时数据、长任务或断线恢复时，还需要 stale 状态，明确组件已经过期。
这些状态直接决定渐进式体验是否可信。图表的外观可能已经完整，其中一组数据仍在加载；计算器可能显示了上一版输入的结果；旧版计划中的按钮可能在新版计划出现后继续可点。界面越早出现，系统越需要告诉用户哪些部分已经稳定。
把外观、数据、动作和结果分成四层证据
组件出现在屏幕上，只能证明渲染成功。生产系统还需要继续验证三层事实：
- 结构层：客户端识别了允许使用的组件，schema 合法。
- 数据层：组件获得了类型正确、版本有效、来源可追踪的数据。
- 动作层：用户事件被转换成有权限、可幂等执行的命令。
- 结果层：目标系统达到预期后置状态，界面也观测到了该状态。
以分账工具为例。表单漂亮地显示出来属于结构层；参与者和金额绑定正确属于数据层；点击付款生成有效请求属于动作层；支付系统确认转账才属于结果层。把四层压成一个成功状态，会让生成式界面的能力声明超过实际证据。
这与 Flint 语义可视化合同 的思路一致：模型负责提出紧凑的语义表示，确定性基础设施负责校验和编译。Intelligent UI 又增加了时间维度，合同需要在组件出现、变化和执行的全过程持续成立。
一份最小流式事件封装
OpenAI 没有公开内部协议。应用仍然可以在模型或 UI 编译器之外定义自己的事件封装：
{
"response_id": "resp_7f3",
"revision": 12,
"component_id": "trip_map",
"component_type": "map.v2",
"state": "provisional",
"data_version": "route_2026-10-08T01:20:00Z",
"capabilities": ["change_stop_order"],
"requires_confirmation": false,
"replaces_revision": 11
}
具体字段可以变化，五条约束值得保留：
- revision 单调递增并且可以重放；
- 组件在多次 patch 中保持稳定身份；
- 每个动作都映射到权限白名单中的 capability；
- 高影响动作显式声明确认边界；
- 最终事件指出哪一个 revision 构成正式答案。
模型可以提议一个按钮及其用途，宿主应用负责判断当前用户、组件状态和数据版本是否允许执行。工具权限和业务权限都应掌握在宿主侧。
静态截图看不到流式失败
视觉审核可以发现裁切、层级混乱和可读性问题，却会漏掉多类时序错误。
旧 patch 覆盖新状态
较慢的数据请求可能在新版结果之后返回。运行时应根据 revision 拒绝旧 patch，避免把到达顺序当成事实顺序。
过期按钮继续有效
revision 4 生成的按钮可能在 revision 7 改变计划后仍留在界面。capability 需要绑定 revision 或失效时间。
局部失败缺少降级
一个组件编译失败时，系统需要预先定义保留其他有效组件、退化为文本，还是整体回滚。静默删除会让用户无法判断信息是否缺失。
多端语义漂移
同一事件在 Web 和移动端可以采用不同布局，但数据、动作权限、校验结果和最终状态需要一致。测试重点应放在这些不变量，而非像素完全相同。
断线恢复重复执行
客户端重连需要检查点、最后确认的 revision 和重放规则。仅仅继续追加事件，可能导致动作重复执行。
这些都是运行时问题。最终截图把生成路径隐藏起来，设计评分再高也无法覆盖。
用真实任务验收，而不是用视觉新奇度验收
OpenAI 表示，GPT-6 的训练包含内容、布局、视觉、交互、清晰度、实用性和完整性。生产验收还应加入端到端任务证据。
可以冻结一组代表性任务：套餐比较、行程编辑、储蓄计算器、交互式概念学习，以及一个需要权限的业务动作。每项任务至少记录：
| 指标 | 验证对象 |
|---|---|
| 首个稳定有效组件出现时间 | 流式生成是否真正减少有效等待 |
| schema 合法 revision 比例 | 编译器获得的结构能否执行 |
| 旧 patch 拒绝率 | 时序约束是否生效 |
| 动作正确率 | 控件是否映射到预期 capability |
| 业务后置状态达成率 | 用户目标是否真正完成 |
| 失败恢复率 | 局部错误能否回到可用状态 |
| 多端语义一致率 | 不同客户端是否保留相同含义 |
| 人工修复时间 | 灵活性是否引入隐性运维成本 |
验收器需要位于模型回答之外。产品 AI 可用性的动态任务评测 已经讨论过这一点：模型说完成了，只能证明模型相信自己完成了；外部状态才是业务结果的证据。
稳定架构是模型表达意图，确定性系统掌握权限
Intelligent UI 指向一种新的软件形态：界面围绕当下任务临时组合，用户不必先适应固定菜单。要让这种形态稳定运行，各层职责应保持清晰：
用户目标
-> 模型提出语义界面与动作
-> 编译器校验并渲染受控组件
-> 运行时管理 revision、状态与权限
-> 工具执行获准动作
-> 外部验收器核对业务后置状态
模型负责理解和组合，组件库负责限定表达词汇，编译器负责结构合法性，运行时负责时间和状态，宿主负责权限，外部系统提供最终证据。
这套分工保留了 OpenAI 所描述的目标：让软件界面适应人的任务。同时，它也把错误拆成可定位的问题。布局错误、数据过期、动作越权和业务失败各有独立证据与责任边界。
常见问题
GPT-6 Intelligent UI 是什么？
它是 ChatGPT 中由 GPT-6 生成复合响应的能力。响应可以包含文字、视觉元素、按钮、图表、表单和交互工具。OpenAI 表示，该体验由原生可流式组件和生成期编译器支撑。
Intelligent UI 已经开放开发者 API 吗？
OpenAI 10 月 7 日的公告描述的是 ChatGPT Chat 体验，尚未公开 Intelligent UI 的组件 schema 或编译器 API。Vercel AI SDK、Google A2UI 等系统可以实现相关生成式界面模式，但它们属于独立实现。
生成式界面如何工作？
模型输出结构化界面意图，或选择工具与组件；客户端的确定性代码负责校验、绑定数据、渲染受控组件并处理用户事件。生产系统还需要补充 revision、权限、恢复和业务结果校验。
为什么流式 UI 需要编译器？
编译器可以在完整响应结束前校验和渲染部分结构，也可以集中执行 schema、组件白名单、兼容性和降级规则。
上线生成式界面前应测试什么？
至少测试 schema 合法性、乱序与局部更新、过期控件、权限边界、高影响动作确认、断线恢复、多端语义、无障碍、降级渲染和最终业务后置状态。