本文是「Agent 工程实战」系列的第 13 篇属于界面线。系列索引21 篇阅读路线Agent 放权前先补权限、出站、发现这三道口子摘要10 月 7 日 OpenAI 把 Intelligent UI 做进了 ChatGPTGPT-6 不仅能说还能直接生成可交互界面官方原话是软件适应人而不是人适应软件。这篇文章从组件库、编译器、渐进渲染三个机制拆开这套智能 UI再落到一个跟前端切身相关的问题当界面可以现场生成前端的活就从写页面变成了定规则——组件库怎么管、流式渲染怎么接、AI 生成的界面怎么验收。文末附一张可直接落地的「前端应对检查清单」。文章目录现象回答开始自带界面机制拆解组件库、编译器、渐进渲染前端三件事从写页面到定规则边界别把愿景当现状产出物前端应对检查清单参考资料昨天 OpenAI 发了篇公告说 ChatGPT 里的 GPT-6 现在能直接生成界面了。不是给你一段文字描述是生成真正能点的界面——图形、按钮、表单、图表甚至账单分摊器这种小工具在对话里就能直接用。这不是多模态输出的升级而是把界面本身变成了模型的输出格式。公告里有句话我看了好几遍“Instead of people adapting to software, software will adapt to people.”软件适应人而不是人适应软件。做了十几年 WebView我的第一反应不是前端要失业了。这个逻辑反过来看更有意思当 AI 能自己画界面前端的活不会消失但它会从写页面变成定规则。写页面是体力活定规则是话语权——这个换位我觉得是好事。这篇文章把 Intelligent UI 的三个工程机制拆开讲再说说对前端意味着什么。官方目前只把它做进了 ChatGPT 的聊天界面没开放给开发者所以下面基于官方发布文和演示做的拆解是机制梳理不是接入实战。现象回答开始自带界面先看它到底做了什么。以前用 ChatGPT模型给你一段文本最多配个 markdown 表格。现在 GPT-6 会自己决定怎么用文本、图形和交互组件来回答你。官方给了三个典型场景场景例子界面形态日常答案更直观周日烤肉的流程、自驾路线的地图文字配图表跟着文字走复杂主题更好学中心极限定理、蒙提霍尔问题可交互图示改参数看结果现场造工具账单分摊器、退休储蓄计算器对话里直接用的完整小应用关键在最后一句用什么样的界面取决于问题本身。该并排对比就并排该用交互图讲原理就用交互图纯文本能说清的就给纯文本。这个看情况选格式的能力拆到底其实是三个机制在配合。机制拆解组件库、编译器、渐进渲染发布文里说他们给 GPT-6 配了一套原生可流式组件库native, streamable components加一个边生成边编译的编译器compiler that processes the interface as the model generates it训练上让模型自己决定内容、布局、视觉、交互怎么搭。我按自己的理解拆成三层模型输出组件序列文本层 │ 组件库native, streamable components ▼ 编译器边生成边编译processes the interface as it generates │ ▼ 渐进渲染界面像流式文本一样陆续出现不等整个响应完成 │ ▼ 用户直接操作按钮可点、表单可填、图表可交互第一层是组件库。以前让模型生成个页面它给你一堆 HTML能不能跑看运气。OpenAI 现在给模型一套可流式的原生组件库——图表就是图表按钮就是按钮每个组件带着平台统一的设计基础而怎么挑、怎么拼、怎么排官方说是留给模型自己决定的。这个设计把界面生成从自由发挥变成组合问题出错面一下就小了。第二层是编译器。模型一边生成编译器一边把界面处理成可以渲染的东西。你不用等它把整个界面想完先出来的部分就能先展示。第三层是渐进渲染也是我理解里最有意思的一层界面像流式文本一样一段一段长出来。你看着它先出个标题再出个图表再出个表单全程不用等。前两层是工程意义上的可控第三层改变了交互模式界面不再是一次性交付而是边生成边可用。这也埋了个雷生成顺序等于显示顺序。你可以想象这个场景——AI 给后台首页生成组件它很可能最先想到待办列表就先画了待办然后才轮到今日营收。运营打开页面第一眼看到的是一堆待办而不是今天赚了多少钱。这不是我编的场景这个机制我演练里真实复现过完整的 21 个组件顺序里核心指标被埋到第 6 位。具体输出在陪跑文里。训练上官方说扩展了训练方法让模型自己做内容、布局、视觉、交互的决策并且用清晰度、有用性、完整性三个维度评估它生成的界面。注意原文还补了一句模型的设计判断力还有提升空间“There’s still work ahead to improve the model’s design judgment”。这个后半句很重要我后面那篇演练文专门把它当主角。换句话说官方自己都承认能生成不等于生成得好这正是前端验收规则存在的理由。前端三件事从写页面到定规则拆完机制落回我们自己身上。如果AI 生成界面以后成为标配前端干的事情会往三个方向挪。一个方向是组件库本身。AI 生成界面的质量上限基本等于组件库和设计系统的质量上限。模型再聪明也只能在给定的组件里挑。你定义好metricCard 只放核心指标、按钮必须有明确的动作语义AI 能组装出来的东西就差不到哪去。反过来组件库一团乱AI 拼出来的页面就是一团乱。这跟我们反复讲的上下文工程是同一个逻辑AI 不知道你没告诉它的约定组件库就是界面生成最直接的约定载体。落到代码上组件库语义化可以这样约束。下面用 TypeScript 定义 metricCard 组件的类型和业务语义校验AI 生成界面时按这套约束组装组件// 组件库语义化用类型约束 运行时校验把业务语义写进组件定义// AI 生成界面时只能从这些带语义的组件里挑拼出来的页面质量就有下限。// 1. 先定义组件的基础形态每个组件都带 type 和业务语义typeComponentTypemetricCard|table|chart|button;interfaceBaseComponent{type:ComponentType;// 业务语义这个组件在页面上代表什么AI 组装时据此判断该不该用semantic:string;}// 2. metricCard 的强约束只放核心指标且必须有明确的指标名和数值interfaceMetricCardextendsBaseComponent{type:metricCard;semantic:核心指标;// 语义固定不允许 AI 把它当普通卡片用metricName:string;// 指标名如今日销售额value:number;// 指标数值unit?:string;// 可选单位如元}// 3. 运行时校验AI 生成的组件序列逐个过这道闸functionvalidateMetricCard(card:MetricCard):boolean{// 语义必须命中核心指标否则直接判为不合格if(card.semantic!核心指标){console.warn([校验失败] metricCard 语义错误${card.semantic});returnfalse;}// 指标名和数值不能为空避免 AI 拼出空壳卡片if(!card.metricName||card.valueundefined){console.warn([校验失败] metricCard 缺少指标名或数值);returnfalse;}returntrue;}// 4. AI 组装入口生成界面时组件必须通过校验才能进入渲染序列functionassembleComponent(raw:unknown):BaseComponent|null{// 先按 type 分派再走各自的语义校验if((rawasBaseComponent).typemetricCard){constcardrawasMetricCard;returnvalidateMetricCard(card)?card:null;// 不过校验就丢弃}// 其它组件类型同理……returnrawasBaseComponent;}这段代码把metricCard 只放核心指标从口头约定变成了可执行的约束类型定义管住组件形态validateMetricCard管住业务语义assembleComponent作为 AI 生成界面的统一入口保证只有语义正确的组件能进渲染序列。组件库语义化做到这一步AI 拼出来的页面质量就有了工程兜底。另一个方向是渐进渲染带来的工程问题。按我的判断这是三个方向里最需要提前准备的界面边生成边渲染用户很可能在一个组件还没渲染完的时候就已经在操作了。状态一致性、中断恢复、竞态处理这些前端都很熟但流式 UI是个新的组合。流式文本我们做过——打字机效果、SSE 推送。流式界面呢组件一个接一个出现用户随时可能点到还不存在的按钮。这个坑我用真实输出演示过生成顺序一旦决定显示顺序信息架构就会跟着生成顺序走而不是跟着重要性走。具体数据在陪跑文里。第三个方向是验收标准。怎么判断一个 AI 生成的界面好还是烂官方给的是清晰度、有用性、完整性落到工程上需要更具体的检查项。这个不是玄学可以写成校验规则。我搭了一套 5 条规则的信息架构校验翻车界面 3/5改完 4/5。验收会像代码 review 一样变成 AI 生成界面流程里的固定一环。规则长什么样一个例子判断核心指标放没放在页面顶部{rule:核心指标前置,targetTypes:[kpiSummary,metricCard],keywords:[销售额,订单量,转化率],check:位置必须在组件序列前3位,level:fatal}这段是验收规则的一种配置形态声明哪些组件类型放核心指标、命中哪些关键词、位置要求多靠前、不满足算什么级别。规则本身是数据脚本就能跑不用人肉看。它跑出来的结果长这样——这是我演练里真实输出的判定# R1 规则对翻车界面的判定 扫描组件序列……命中「今日销售额」(metricCard) 位置 6 3 → R1 FAIL核心指标前置未达标具体翻车界面怎么被揪出来的后面一篇文章我会具体讲讲。边界别把愿景当现状把话说清楚免得误读。Intelligent UI 目前只做进了 ChatGPT 的 Chat 体验API 没开放Work 和 Codex 也不在这次更新范围里。也就是说现在它是平台能力不是开放 SDK。我们自己产品想用得等官方开放或者自己搭一套类似的东西。官方自己承认模型的设计判断力还在提升路上。它会选错组件、排错顺序做出功能全对但没人会用的界面——这不是猜的我演练里真实复现了。软件适应人是个很好的方向但从方向到落地中间隔着一整套组件库规范、流式渲染方案和验收标准——恰好是前端最擅长的事。产出物前端应对检查清单不管你现在做不做 AI 生成界面这张清单可以先留一份。等官方开放或者你自己要搭类似能力直接对着过一遍。检查项说明现在能做的动作组件库语义化每个组件有明确的业务语义metricCard核心指标、table明细审查现有组件库去掉万金油组件组件库可流式组件支持渐进渲染分片加载、骨架屏给重组件做 streaming 渲染方案生成顺序约束核心信息必须在生成序列前段生成前先让模型输出信息架构规划验收规则脚本化把核心指标前置/趋势用图/操作可见写成校验规则搭生成后自动校验不过就重生成兜底人工审核AI 生成界面不能直接上线保留人工抽查和回滚一句话总结当界面开始由 AI 现场生成前端的价值不在画本身而在画之前的规则和画之后的验收。写页面是体力活定规则是话语权——这个换位我觉得是好事。如果你也在关注 AI 生成界面欢迎在评论区聊聊你的组件库和验收规则怎么设计的。参考资料OpenAI 官方发布文GPT-6 for Everyone —— 本文机制拆解的主要依据含 Intelligent UI 的官方表述与演示。OpenAI 官方公告Intelligent UI 进入 ChatGPT —— 官方对组件库、编译器、渐进渲染的原始说明。OpenAI 开发者文档Streamable UI Components —— 了解可流式组件库的工程形态与接入思路。MDNServer-Sent Events —— 流式文本/流式界面的底层推送机制参考。React Server Components 官方文档 —— 理解边生成边渲染在组件模型上的落地方式。「Agent 工程实战」系列路线界面线computer use / Agent UI上一篇12 点界面贵 30 倍下一篇14 报表界面没人会用系列索引21 篇阅读路线Agent 放权前先补权限、出站、发现这三道口子专栏Agent 工程实战如果这篇对你有用欢迎收藏想追更可以关注「Agent 工程实战」专栏。