生成式 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?: Record<string, 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: Record<string, string>; // Token ID → 组件 prop } function matchComponents( tokenGroups: Map<string, 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 Tree（React/Vue 的虚拟 DOM 结构），或生成中间 DSL（如 JSON Schema 驱动的低代码渲染协议）。前者对生成式 AI 要求高，需要输出语法严格正确、类型完备的代码；后者更工程化但灵活度受限。

/** * 组件树到 React 代码的转换 * 将类型化的组件树序列化为 JSX 字符串 */ interface ComponentNode { type: ComponentType; props: Record<string, 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 中间协议路线，在灵活性和可控性之间取得平衡。