生成式 UI 的第一步将设计 Token 转化为可渲染的组件树一、设计 Token 到组件树的映射问题生成式 UI 的核心流程可以概括为输入自然语言或结构化配置输出可运行的界面代码。在这个链条中设计 Token 作为设计意图的形式化表达承担了从模糊需求到精确产物的翻译角色。但 Token 本身只是原子化的设计属性——颜色值、间距值、圆角半径——它们不携带布局逻辑、不表达交互行为、不包含响应式规则。flowchart LR A[设计意图\n自然语言/结构化配置] -- B[Token 解析层] B -- C[Token 分类\n颜色/间距/字号/阴影] C -- D[组件映射引擎] D -- E[布局推导] D -- F[样式绑定] D -- G[交互逻辑生成] E -- H[可渲染组件树] F -- H G -- H H -- I[React/Vue 代码输出]问题的关键不是怎么把 Token 变成 CSS而是怎么把一组 Token 变成有语义的组件树。一个颜色 Token 是用于背景还是边框是静态值还是随状态变化的——这些语义信息不在 Token 中而在设计系统的上下文中。二、Token 的语义化扩展层要让 Token 驱动组件生成必须将 Token 从原子值扩展为语义三元组属性名、作用域、关联规则。/** * 语义化 Design Token 的类型定义 * 从原子值扩展为带上下文的三元组 */ interface SemanticToken { /** Token 唯一标识 */ id: string; /** 属性类别color, spacing, typography, radius 等 */ category: TokenCategory; /** 原始值设计侧定义的底层值 */ value: string | number; /** 语义角色描述该 Token 在 UI 中的用途 */ role: TokenRole; /** 适用范围哪些组件类型可使用此 Token */ applicableComponents: ComponentType[]; /** 关联规则与该 Token 存在约束关系的其他 Token */ constraints: TokenConstraint[]; /** 暗色模式 / 高对比度模式变体 */ variants?: Recordstring, string | number; } type TokenCategory color | spacing | typography | radius | shadow; type TokenRole primary-background | text-primary | border-default | interactive-hover; type ComponentType Button | Card | Input | Modal | Table; interface TokenConstraint { /** 关联 Token 的 ID */ relatedTokenId: string; /** 约束类型必须一致 / 最小值差 / 比例关系 */ rule: equal | min-diff | ratio; /** 约束参数 */ value: number; }这套类型体系让 Token 不再是孤立的设计变量而是一个有拓扑关系的语义网络。组件映射引擎可以根据role判断一个颜色 Token 应该映射到组件的哪个样式属性上根据applicableComponents过滤出合法的组件类型根据constraints校验 Token 组合的合理性。三、组件映射引擎的设计引擎的核心逻辑分为三个阶段Token 分组、组件匹配、布局推导。Token 分组阶段按语义角色将 Token 聚类。所有role包含button的 Token 归为一组所有role包含card的归为另一组。分组后的 Token 集合成为对应组件的样式输入。组件匹配阶段根据 Token 组的规模判断组件的复杂度。简单组3-5 个 Token通常映射为原子组件Button、Input中等组5-15 个 Token映射为复合组件Card、FormItem复杂组则触发模板匹配逻辑。/** * 组件匹配引擎根据 Token 组特征推导组件类型 */ interface ComponentCandidate { componentType: ComponentType; confidence: number; // 匹配置信度 0-1 tokens: SemanticToken[]; // 匹配到的 Token 集合 templateMapping: Recordstring, string; // Token ID → 组件 prop } function matchComponents( tokenGroups: Mapstring, SemanticToken[] ): ComponentCandidate[] { const candidates: ComponentCandidate[] []; for (const [groupKey, tokens] of tokenGroups) { // 优先匹配所有 Token 的 applicableComponents 交集中的组件类型 const intersection tokens.reduce((acc, t) acc.filter(c t.applicableComponents.includes(c)), tokens[0].applicableComponents ); if (intersection.length 0) { console.warn(Token 组 ${groupKey} 无匹配组件类型); continue; } for (const compType of intersection) { candidates.push({ componentType: compType, confidence: calculateConfidence(tokens, compType), tokens, templateMapping: resolveTemplateMapping(tokens, compType), }); } } // 按置信度降序排列 return candidates.sort((a, b) b.confidence - a.confidence); }布局推导阶段使用基于约束的布局算法。如果一组 Token 中包含多个ComponentType按设计系统的层级规范通常来自原子设计方法论决定嵌套关系。四、从组件树到可运行代码组件树确定后最后一步是代码生成。这一步的关键决策是生成什么格式的输出。当前行业实践分两派直接生成 Render TreeReact/Vue 的虚拟 DOM 结构或生成中间 DSL如 JSON Schema 驱动的低代码渲染协议。前者对生成式 AI 要求高需要输出语法严格正确、类型完备的代码后者更工程化但灵活度受限。/** * 组件树到 React 代码的转换 * 将类型化的组件树序列化为 JSX 字符串 */ interface ComponentNode { type: ComponentType; props: Recordstring, unknown; children: ComponentNode[]; } function renderToJSX(node: ComponentNode, indent 0): string { const pad .repeat(indent); const propEntries Object.entries(node.props) .filter(([_, v]) v ! undefined) .map(([k, v]) ${k}{${JSON.stringify(v)}}) .join( ); const openTag propEntries ? ${node.type} ${propEntries} : ${node.type}; if (node.children.length 0) { // 自闭合无法用于自定义组件统一使用完整标签 return ${pad}${openTag}/${node.type}; } const childrenStr node.children .map(child renderToJSX(child, indent 2)) .join(\n); return ${pad}${openTag}\n${childrenStr}\n${pad}/${node.type}; }生成式 UI 的工程化落地推荐走中间 DSL路线。让 AI 输出结构化的组件描述协议再由确定性的渲染引擎转换为代码。这样既降低了 AI 出错的概率结构化输出比自然代码更可控又保留了产物的可调试性。五、总结设计 Token 到组件树的转化核心瓶颈在于 Token 缺乏语义信息。解决方案是为 Token 扩充角色标签、适用组件类型和约束规则使其成为有拓扑结构的语义网络。组件映射引擎通过分组、匹配、推导三步将 Token 转换为类型化的组件树最终由渲染引擎输出可运行代码。当前最稳妥的工程策略是 DSAL 中间协议路线在灵活性和可控性之间取得平衡。
生成式 UI 的第一步：将设计 Token 转化为可渲染的组件树
生成式 UI 的第一步将设计 Token 转化为可渲染的组件树一、设计 Token 到组件树的映射问题生成式 UI 的核心流程可以概括为输入自然语言或结构化配置输出可运行的界面代码。在这个链条中设计 Token 作为设计意图的形式化表达承担了从模糊需求到精确产物的翻译角色。但 Token 本身只是原子化的设计属性——颜色值、间距值、圆角半径——它们不携带布局逻辑、不表达交互行为、不包含响应式规则。flowchart LR A[设计意图\n自然语言/结构化配置] -- B[Token 解析层] B -- C[Token 分类\n颜色/间距/字号/阴影] C -- D[组件映射引擎] D -- E[布局推导] D -- F[样式绑定] D -- G[交互逻辑生成] E -- H[可渲染组件树] F -- H G -- H H -- I[React/Vue 代码输出]问题的关键不是怎么把 Token 变成 CSS而是怎么把一组 Token 变成有语义的组件树。一个颜色 Token 是用于背景还是边框是静态值还是随状态变化的——这些语义信息不在 Token 中而在设计系统的上下文中。二、Token 的语义化扩展层要让 Token 驱动组件生成必须将 Token 从原子值扩展为语义三元组属性名、作用域、关联规则。/** * 语义化 Design Token 的类型定义 * 从原子值扩展为带上下文的三元组 */ interface SemanticToken { /** Token 唯一标识 */ id: string; /** 属性类别color, spacing, typography, radius 等 */ category: TokenCategory; /** 原始值设计侧定义的底层值 */ value: string | number; /** 语义角色描述该 Token 在 UI 中的用途 */ role: TokenRole; /** 适用范围哪些组件类型可使用此 Token */ applicableComponents: ComponentType[]; /** 关联规则与该 Token 存在约束关系的其他 Token */ constraints: TokenConstraint[]; /** 暗色模式 / 高对比度模式变体 */ variants?: Recordstring, string | number; } type TokenCategory color | spacing | typography | radius | shadow; type TokenRole primary-background | text-primary | border-default | interactive-hover; type ComponentType Button | Card | Input | Modal | Table; interface TokenConstraint { /** 关联 Token 的 ID */ relatedTokenId: string; /** 约束类型必须一致 / 最小值差 / 比例关系 */ rule: equal | min-diff | ratio; /** 约束参数 */ value: number; }这套类型体系让 Token 不再是孤立的设计变量而是一个有拓扑关系的语义网络。组件映射引擎可以根据role判断一个颜色 Token 应该映射到组件的哪个样式属性上根据applicableComponents过滤出合法的组件类型根据constraints校验 Token 组合的合理性。三、组件映射引擎的设计引擎的核心逻辑分为三个阶段Token 分组、组件匹配、布局推导。Token 分组阶段按语义角色将 Token 聚类。所有role包含button的 Token 归为一组所有role包含card的归为另一组。分组后的 Token 集合成为对应组件的样式输入。组件匹配阶段根据 Token 组的规模判断组件的复杂度。简单组3-5 个 Token通常映射为原子组件Button、Input中等组5-15 个 Token映射为复合组件Card、FormItem复杂组则触发模板匹配逻辑。/** * 组件匹配引擎根据 Token 组特征推导组件类型 */ interface ComponentCandidate { componentType: ComponentType; confidence: number; // 匹配置信度 0-1 tokens: SemanticToken[]; // 匹配到的 Token 集合 templateMapping: Recordstring, string; // Token ID → 组件 prop } function matchComponents( tokenGroups: Mapstring, SemanticToken[] ): ComponentCandidate[] { const candidates: ComponentCandidate[] []; for (const [groupKey, tokens] of tokenGroups) { // 优先匹配所有 Token 的 applicableComponents 交集中的组件类型 const intersection tokens.reduce((acc, t) acc.filter(c t.applicableComponents.includes(c)), tokens[0].applicableComponents ); if (intersection.length 0) { console.warn(Token 组 ${groupKey} 无匹配组件类型); continue; } for (const compType of intersection) { candidates.push({ componentType: compType, confidence: calculateConfidence(tokens, compType), tokens, templateMapping: resolveTemplateMapping(tokens, compType), }); } } // 按置信度降序排列 return candidates.sort((a, b) b.confidence - a.confidence); }布局推导阶段使用基于约束的布局算法。如果一组 Token 中包含多个ComponentType按设计系统的层级规范通常来自原子设计方法论决定嵌套关系。四、从组件树到可运行代码组件树确定后最后一步是代码生成。这一步的关键决策是生成什么格式的输出。当前行业实践分两派直接生成 Render TreeReact/Vue 的虚拟 DOM 结构或生成中间 DSL如 JSON Schema 驱动的低代码渲染协议。前者对生成式 AI 要求高需要输出语法严格正确、类型完备的代码后者更工程化但灵活度受限。/** * 组件树到 React 代码的转换 * 将类型化的组件树序列化为 JSX 字符串 */ interface ComponentNode { type: ComponentType; props: Recordstring, unknown; children: ComponentNode[]; } function renderToJSX(node: ComponentNode, indent 0): string { const pad .repeat(indent); const propEntries Object.entries(node.props) .filter(([_, v]) v ! undefined) .map(([k, v]) ${k}{${JSON.stringify(v)}}) .join( ); const openTag propEntries ? ${node.type} ${propEntries} : ${node.type}; if (node.children.length 0) { // 自闭合无法用于自定义组件统一使用完整标签 return ${pad}${openTag}/${node.type}; } const childrenStr node.children .map(child renderToJSX(child, indent 2)) .join(\n); return ${pad}${openTag}\n${childrenStr}\n${pad}/${node.type}; }生成式 UI 的工程化落地推荐走中间 DSL路线。让 AI 输出结构化的组件描述协议再由确定性的渲染引擎转换为代码。这样既降低了 AI 出错的概率结构化输出比自然代码更可控又保留了产物的可调试性。五、总结设计 Token 到组件树的转化核心瓶颈在于 Token 缺乏语义信息。解决方案是为 Token 扩充角色标签、适用组件类型和约束规则使其成为有拓扑结构的语义网络。组件映射引擎通过分组、匹配、推导三步将 Token 转换为类型化的组件树最终由渲染引擎输出可运行代码。当前最稳妥的工程策略是 DSAL 中间协议路线在灵活性和可控性之间取得平衡。
