企业官网建设流程全解析

1. 从标题拆解：Intelligent UI 到底在说什么

1.1 一个被过度包装的概念，还是交互范式的真实迁移

先把话说在前面：Intelligent UI 这个词本身并不新鲜。过去几年里，从自适应界面到意图驱动交互，行业里每隔一阵就会冒出一个新说法来包装同一件事——让界面不再是一堆静态控件的堆砌，而是能根据用户当前的任务、上下文和历史行为动态调整形态与响应方式。GPT-6 这次把这个概念重新推到台前，核心变化不在于"智能"两个字，而在于它把大模型从"对话框里的助手"变成了"界面本身的运行时"。

我个人的理解是：以前的 AI 产品，模型是一个被调用的服务，界面是固定的壳子，用户输入文字，模型返回文字，界面负责渲染。而 Intelligent UI 的思路是反过来的——界面本身就是模型输出的一部分，模型根据当前情境决定该呈现什么控件、什么信息密度、什么交互路径。这听起来像是把前端和后端揉在了一起，实际上确实如此。

这个转变解决的核心问题是：传统 GUI 的交互成本是固定的。你要完成一个任务，必须先学会这个软件的菜单结构、按钮位置、操作顺序。软件越复杂，学习成本越高。Intelligent UI 试图把这个成本转嫁给模型——你只需要表达意图，界面自己重组。

适合谁来关注这个方向？三类人：一是做前端和交互设计的产品开发者，因为界面生成逻辑变了；二是做 AI 应用层的工程师，因为调用方式和上下文管理变了；三是产品经理和独立开发者，因为这意味着很多过去需要大量 UI 工作才能实现的产品，现在可能几行意图描述就能跑起来。

1.2 标题里"没给开发者的东西"指的是什么

这是整篇文章最值得聊的部分。每次大版本发布，官方演示总是光鲜的，但开发者真正关心的是：API 怎么调、上下文窗口多大、状态怎么管理、能不能自定义渲染层、有没有稳定的结构化输出格式。标题里说的"没给"，我理解是几个层面的缺失。

第一，没有公开的界面描述协议。Intelligent UI 要落地，模型必须输出一种界面能理解的中间表示——比如某种声明式的 UI schema。但官方演示里只展示了结果，没有给出这个 schema 的规范。开发者拿不到这个，就没法在自己的应用里复现同样的效果。

第二，没有状态同步机制。界面是动态生成的，那用户操作之后的状态怎么回传给模型？多轮交互中界面元素的生命周期怎么管理？这些在传统前端里有成熟方案，但在模型驱动界面里是全新的问题，官方没有给出参考实现。

第三，没有成本控制的指导。动态生成界面意味着每次交互都可能触发一次模型调用，token 消耗和延迟怎么控制？什么该缓存、什么该实时生成？这些工程细节的缺失，才是开发者真正卡住的地方。

我的判断是：官方故意留白，一方面是因为这套东西还在快速迭代，过早定协议会束缚自己；另一方面，生态的空白本身就是机会，谁先摸索出可复用的模式，谁就占先手。

2. 核心技术点拆解：Intelligent UI 背后的工程逻辑

2.1 界面即输出：从文本生成到结构化 UI 描述

要让模型生成界面，第一步是定义"界面"在模型眼里长什么样。最直接的做法是让模型输出 JSON，描述一棵组件树。比如一个简单的任务列表界面，模型可能输出这样的结构：

{ "type": "container", "layout": "vertical", "children": [ { "type": "heading", "text": "今日待办", "level": 2 }, { "type": "list", "items": [ {"text": "回复邮件", "checked": false}, {"text": "整理会议纪要", "checked": true} ] }, { "type": "button", "label": "添加任务", "action": "add_task" } ] }

前端拿到这个 JSON，用一套渲染器把它映射成真实控件。这套思路本身不复杂，难的是三件事：一是 schema 的粒度怎么定，太细了模型容易出错，太粗了灵活性不够；二是模型输出的稳定性，同样的意图两次生成的结构可能不一样，导致界面跳动；三是 action 的回传，用户点了"添加任务"之后，这个事件怎么带回模型，触发下一轮界面生成。

我实测下来的经验是：schema 不要设计得太自由。给模型限定一个相对封闭的组件集合，比如只允许 container、text、list、button、input、chart 这几种，比让它自由发挥要稳定得多。组件越少，模型出错率越低，渲染器也越好写。

2.2 上下文管理：多轮交互中界面状态怎么不丢

这是最容易踩坑的地方。传统前端里，界面状态存在内存或本地存储里，刷新页面才需要恢复。但在 Intelligent UI 里，每次模型生成新界面，旧界面的状态就可能丢失。用户填了一半的表单，模型重新生成界面后，输入框空了——这种体验是灾难性的。

常见的解法是维护一个独立于界面的状态树。界面只是状态的一个视图，模型生成的是视图描述，但状态本身存在一个持久化的 store 里。模型在生成新界面时，需要把当前状态作为上下文一起传进去，这样它才知道哪些输入已经填了、哪些选项已经选了。

具体操作上，我会在每次调用模型时，把当前状态序列化成一段紧凑的文本或 JSON，放在系统提示里。同时给模型一个明确的指令：生成界面时，已存在的状态字段要保留，不要重置。这个约束看起来简单，但不写清楚，模型十有八九会把状态清空重来。

另一个技巧是给界面元素加稳定的 ID。模型生成时，对同一个逻辑元素尽量复用同一个 ID，这样前端在 diff 新旧界面时，能识别出这是同一个输入框，从而保留它的值和焦点。没有稳定 ID，每次生成都是一棵全新的树，React 之类的框架会直接卸载重建，用户体验就断了。

2.3 意图路由：什么时候该生成界面，什么时候不该

不是每次交互都需要重新生成界面。如果用户只是在一个已经渲染好的表单里打字，没必要每敲一个字符就调一次模型。这里需要一个意图路由层，判断当前输入是"界面级操作"还是"数据级操作"。

我的做法是分两层：本地交互层处理纯数据操作，比如输入、勾选、滚动，这些不触发模型调用；只有涉及意图变化、需要新增或删除界面元素、需要跳转到不同功能模块时，才把请求发给模型。判断依据可以是一个轻量的分类器，也可以是一组规则——比如用户点击了带 action 的按钮，或者输入了自然语言指令，就触发模型。

这个分层直接决定了产品的成本和响应速度。全量走模型，延迟高、费用贵；全走本地，又失去了 Intelligent UI 的意义。找到那个平衡点，是工程上最考验判断力的地方。

3. 实操过程：从零搭一个最小可用的 Intelligent UI 原型

3.1 环境准备与技术选型

要复现这套东西，不需要等官方 SDK。核心依赖就三样：一个能稳定输出结构化文本的模型接口、一个前端渲染器、一个状态管理层。我用的组合是：模型侧用支持 JSON mode 的接口，前端用轻量框架加一个递归渲染组件，状态用简单的发布订阅模式管理。

选型逻辑很简单：渲染器要能递归处理组件树，所以组件定义必须是数据驱动的，不能写死。状态管理要独立于组件树，所以不能用组件内部 state 存关键数据。这两条是硬约束，违反了后面一定出问题。

具体目录结构我习惯这样组织：

/src /renderer 渲染器，负责把 JSON 映射成组件 /components 基础组件，button、input、list 等 /state 状态树与订阅逻辑 /agent 模型调用与意图路由 /schema 组件 schema 定义与校验

schema 目录单独放，是因为它同时被模型提示和前端校验使用，必须单一来源。模型提示里描述可用组件，前端用同一份定义做校验，两边不一致就会出现模型生成了前端不认识的组件，直接白屏。

3.2 定义组件 Schema 与模型提示

组件 schema 我建议用 JSON Schema 来描述，这样既能给模型看，也能用现成的校验库。一个 button 的定义大概是这样：

{ "type": "object", "required": ["type", "label", "action"], "properties": { "type": {"const": "button"}, "label": {"type": "string", "maxLength": 20}, "action": {"type": "string"}, "variant": {"enum": ["primary", "secondary", "danger"]} } }

模型提示里，我会把可用组件列表和每个组件的字段要求写清楚，并给一两个完整示例。关键是示例要覆盖常见组合，让模型有样学样。提示词里还要明确几条规则：只输出 JSON，不要解释；组件树深度不超过三层；每个 action 必须是预定义动作集合里的值。

预定义动作集合这点很重要。如果让模型自由生成 action 字符串，前端根本不知道该怎么处理。我会维护一个动作白名单，比如 add_task、delete_task、submit_form、navigate，模型只能从里面选。这样前端就能写一个 switch 来处理所有可能的动作。

3.3 渲染器的实现要点

渲染器本质上是一个递归函数：拿到一个节点，根据 type 找到对应组件，把 props 传进去，如果有 children 就递归渲染。听起来简单，但有几个细节决定成败。

第一，未知组件的兜底。模型偶尔会生成 schema 里没有的 type，这时候不能直接崩，要渲染一个占位符并记录日志，方便排查是提示词问题还是模型抽风。

第二，key 的稳定性。递归渲染列表时，每个节点需要一个稳定的 key。我通常用节点自带的 id 字段，如果没有就让模型生成一个，实在没有就用路径加索引兜底。key 不稳定会导致输入框失焦，这是最常见的 bug。

第三，错误边界。单个组件渲染失败不应该拖垮整个界面。用错误边界包住每个节点，出错的节点显示一个可点击重试的占位，其余部分正常渲染。

function renderNode(node, state, dispatch) { if (!node || !componentMap[node.type]) { return <UnknownComponent node={node} />; } const Component = componentMap[node.type]; const children = (node.children || []).map((child, i) => renderNode(child, state, dispatch) ); return ( <ErrorBoundary key={node.id || i}> <Component {...node} state={state} dispatch={dispatch} > {children} </Component> </ErrorBoundary> ); }

这段代码是整个原型的核心，其他都是围绕它做支撑。

3.4 状态回传与下一轮生成

用户操作触发 action 后，流程是这样的：dispatch 先更新本地状态，然后把 action 和当前状态一起发给模型，模型返回新的界面描述，渲染器重新渲染。这里有个优化点：如果 action 只是纯数据变更，不影响界面结构，可以跳过模型调用，直接本地更新。只有需要结构性变化时才走模型。

判断是否结构性变化，我用的规则是：action 在白名单里标记为 structural 的才走模型，比如 navigate、add_section；标记为 data 的只更新状态，比如 toggle_checkbox、update_input。这个标记在定义动作白名单时就定好，运行时直接查表，零成本。

实测下来，这套机制能把模型调用次数压到原来的三分之一左右，延迟和费用都明显下降。而且因为大部分交互是本地即时响应，体感反而更流畅。

4. 常见问题与排查技巧实录

4.1 模型输出不稳定导致界面跳动

这是最高频的问题。同样的意图，模型两次生成的组件树结构不一样，比如一次用 list 一次用 table，界面就会闪一下重排。排查思路是先确认是不是温度参数太高，把 temperature 调到 0 或接近 0 能大幅提升一致性。如果还不行，就在提示词里加约束：相同意图下优先复用上次的结构，只改必要字段。

我还会在服务端做一个结构缓存，把意图到界面结构的映射存下来，下次相同意图直接命中缓存，既稳定又省钱。缓存 key 用意图文本的归一化结果，比如去掉标点和空格后哈希。

4.2 输入框失焦与状态丢失

前面提过，根因是 key 不稳定或状态没独立管理。排查时先看 React DevTools 里组件是不是被卸载重建了，如果是，检查 key。如果 key 稳定但值还是丢，那就是状态没提到独立 store 里，还在组件内部 state 里存着。解决办法是把所有需要跨生成保留的值，都放到全局状态树，组件只做受控渲染。

一个容易忽略的点：焦点位置也要单独存。用户正在输入时模型重新生成界面，即使值保留了，光标位置也可能跳到末尾。把 selectionStart 和 selectionEnd 一起存进状态，渲染后恢复，体验才完整。

4.3 动作无法识别或重复触发

模型生成的 action 不在白名单里，或者一次点击触发了两次。前者是提示词约束不够，要在系统提示里把动作列表写死并强调只能从中选择。后者通常是事件绑定问题，比如渲染器在每次生成后重复绑定了监听。检查 dispatch 是否被包在 useEffect 里且依赖数组正确，避免重复注册。

下面这张表是我整理的高频问题速查：

4.4 成本与延迟的平衡

最后聊一个绕不开的工程问题。Intelligent UI 如果每次交互都调模型，成本会失控。我的经验是三条：一是意图路由分层，纯数据操作不走模型；二是结构缓存，相同意图命中缓存；三是流式渲染，模型边生成边渲染，用户感知的延迟会低很多。这三条叠加，实测能把单次交互的平均成本压到全量方案的二成左右，延迟从秒级降到几百毫秒。

流式渲染的实现要点是，让模型按组件为单位输出，每输出一个完整组件就渲染一个，而不是等整棵树生成完。这要求输出格式是逐行或逐块的，解析器要能处理不完整的 JSON 片段。实现起来有点绕，但对体验的提升是值得的。

5. 这套东西后续还能怎么扩展

5.1 从单页到多页的导航管理

原型阶段通常只有一个界面。要扩展成完整应用，需要一套导航机制。我的思路是把"当前页面"也作为一个状态字段，模型生成界面时根据这个字段决定渲染哪个页面。页面切换就是一个 structural action，触发模型重新生成。这样导航逻辑也统一在模型驱动下，不需要单独的路由配置。

5.2 个性化与记忆

Intelligent UI 真正有意思的地方在于，它可以记住用户的偏好并反映在界面上。比如用户总是把某个列表折叠起来，模型下次生成时就可以默认折叠。实现上就是把用户行为日志作为上下文的一部分传给模型，让它自己决定怎么调整。这比写死配置灵活得多，也更符合"智能"的定义。

5.3 多端适配

同一棵组件树，在不同设备上应该有不同的呈现。这个可以在渲染层做，根据屏幕尺寸选择不同的布局策略，而不需要模型重新生成。模型只负责语义结构，渲染器负责适配，职责分离，两边都简单。

我在实际项目里踩过的最大一个坑，是过早追求 schema 的完备性，结果组件越加越多，模型出错率反而上升。后来砍到只剩六个基础组件，稳定性立刻好转。这个教训是：Intelligent UI 的智能不在于组件多，而在于组合方式灵活。组件越少，模型越容易用对，渲染器也越好维护。如果你正准备动手，我的建议是从三个组件开始——容器、文本、按钮，跑通整条链路，再逐步加。