面向生成式 UI 的 Prompt 工程：从布局描述到可渲染 JSX 的映射协议
一、生成式 UI 的输入输出鸿沟：自然语言与结构化代码的语义偏移
生成式 UI 的理想路径是：用自然语言描述界面需求，AI 直接生成可渲染的前端代码。但实际落地过程中，自然语言到 JSX 的转换存在显著的语义偏移——同样的描述，模型在不同上下文下会渲染出完全不同的 DOM 结构和样式。
比如"一个数据展示表格，支持排序和筛选"这个描述，模型可能生成一个<table>标签加手写排序逻辑，也可能生成一个集成了组件库的<DataGrid>，还可能在样式上做出完全不同的间距和配色决策。这种不确定性使得生成式 UI 的输出在工程层面不可控。
根本原因在于，自然语言本身是高度模糊的，而前端代码需要精确到每一个属性值。在这两者之间，缺少一个可靠的结构化映射协议。
flowchart LR A[自然语言描述<br/>"一个带搜索框的用户列表"] --> B{语义解析} B --> C[布局结构<br/>flex/grid 决策不确定] B --> D[组件选型<br/>原生 vs 组件库] B --> E[样式细节<br/>间距/颜色无约束] C --> F[模糊输出] D --> F E --> F F --> G["<div> <input /> <ul>...</ul> </div>"] A2[结构化描述<br/>Schema + 约束] --> B2{精确映射} B2 --> C2[布局: flex-col, gap-4] B2 --> D2[组件: SearchInput + UserCard] B2 --> E2[样式: 设计 Token 绑定] C2 --> F2[精确输出] D2 --> F2 E2 --> F2 F2 --> G2["确定性的 React 组件树"]二、结构化 Prompt 协议的设计：Schema 驱动的 UI 描述语言
解决语义偏移的核心方案是建立一套结构化的 Prompt 协议。这套协议要求在 Prompt 中明确四个维度的约束：布局骨架、组件映射、样式令牌、交互行为。
以下是一个协议示例——通过 JSON Schema 定义 UI 的精确结构，让模型在受控空间中生成代码：
// ui-prompt-protocol.ts // 定义生成式 UI 的结构化 Prompt 协议 interface UIComponentSchema { /** 组件类型标签，映射到项目组件库 */ type: 'Container' | 'Grid' | 'Card' | 'Table' | 'Form' | 'Button'; /** 子组件递归定义 */ children?: UIComponentSchema[]; /** 组件属性 */ props: Record<string, unknown>; /** 绑定数据源（不传具体值，只传数据路径） */ dataBindings?: Record<string, string>; } interface UIPromptProtocol { /** 页面整体布局描述 */ layout: { direction: 'row' | 'column' | 'grid'; gridTemplate?: string; // CSS Grid 模板，如 '1fr 3fr' gap: number; // 间距，单位 px padding: number; }; /** 组件树定义 */ components: UIComponentSchema[]; /** 设计令牌引用 */ tokens: { colorScheme: 'light' | 'dark' | 'system'; spacing: 'compact' | 'comfortable' | 'spacious'; borderRadius: number; fontSize: 'small' | 'medium' | 'large'; }; /** 约束条件 */ constraints: { maxDepth: number; // 最大嵌套深度 maxComponents: number; // 最大组件数量 forbiddenTypes: string[]; // 禁止使用的组件类型 }; } // 示例：一个后台管理仪表盘的 Prompt 协议定义 const dashboardProtocol: UIPromptProtocol = { layout: { direction: 'grid', gridTemplate: 'repeat(3, 1fr)', gap: 16, padding: 24, }, components: [ { type: 'Card', props: { title: '今日订单量' }, dataBindings: { value: 'dashboard.orders.today' }, }, { type: 'Card', props: { title: '活跃用户' }, dataBindings: { value: 'dashboard.users.active' }, }, { type: 'Card', props: { title: '转化率' }, dataBindings: { value: 'dashboard.conversion.rate' }, }, ], tokens: { colorScheme: 'light', spacing: 'comfortable', borderRadius: 8, fontSize: 'medium', }, constraints: { maxDepth: 3, maxComponents: 20, forbiddenTypes: ['iframe', 'script'], }, };三、从 Schema 到 JSX 的确定性编译
有了结构化 Schema 之后，生成 JSX 的过程就变成了确定性的编译操作，不再依赖模型对自然语言的语义理解。这套编译器的核心逻辑是将UIComponentSchema树递归展开为 React 组件树。
// schema-to-jsx-compiler.ts // 将 UIComponentSchema 编译为 JSX 的确定性编译器 import type { UIComponentSchema, UIPromptProtocol } from './ui-prompt-protocol'; // 组件类型到实际 React 组件的映射表 const componentRegistry: Record<string, React.ComponentType<unknown>> = { Container: ({ children, ...props }: Record<string, unknown> & { children?: React.ReactNode }) => ( <div className="flex flex-col" {...props}>{children}</div> ), Grid: ({ children, template, gap }: Record<string, unknown> & { children?: React.ReactNode }) => ( <div style={{ display: 'grid', gridTemplateColumns: template as string, gap: `${gap}px` }}> {children} </div> ), Card: ({ title, children, ...props }: Record<string, unknown> & { children?: React.ReactNode }) => ( <div className="bg-white rounded-lg shadow-sm p-6" {...props}> {title && <h3 className="text-lg font-semibold mb-2">{title as string}</h3>} {children} </div> ), Button: ({ label, variant = 'primary', ...props }: Record<string, unknown>) => { const baseClass = 'px-4 py-2 rounded-md font-medium transition-colors'; const variantClass = variant === 'primary' ? 'bg-blue-600 text-white hover:bg-blue-700' : 'bg-gray-200 text-gray-800 hover:bg-gray-300'; return <button className={`${baseClass} ${variantClass}`} {...props}>{label as string}</button>; }, }; function compileSchemaToJSX( schema: UIComponentSchema, dataContext: Record<string, unknown> = {} ): React.ReactNode { const Component = componentRegistry[schema.type]; if (!Component) { console.warn(`组件类型 ${schema.type} 未在注册表中找到，生成占位符`); return <div>flowchart TD A[UI 需求] --> B{是否适合 AI 生成？} B -->|"数据表格 / 图表\n动画过渡效果\n安全敏感界面"| C[人工手写] B -->|"标准表单 / 列表\n卡片布局 / 导航\n信息展示页面"| D[AI 生成 + 人工审核] D --> E[Schema 定义] E --> F[编译器生成 JSX] F --> G[视觉回归测试] G -->|通过| H[合并到代码库] G -->|未通过| I[人工修正 Schema] I --> E五、总结
生成式 UI 的工程化落点不在于追求"完全由 AI 生成"，而在于构建一套可验证、可约束的结构化映射协议。通过将模糊的自然语言转换为 Schema 驱动的确定性输入，可以有效消除语义偏移带来的不确定性。
这套协议的核心价值是：让 AI 在受控空间中生成代码，而不是在海量可能性中自由发挥。协议需要明确定义布局规则、组件映射表、设计令牌体系三个维度，同时要对不适用的场景做出明确的排除声明。最终目标是让生成式 UI 成为一种可控的工程手段，而非不可预测的概率游戏。
