基于模板的 AI 组件生成：约束 Prompt 输出的一致性与可控性-Seo优化-塔城地区网站建设公司

基于模板的 AI 组件生成：约束 Prompt 输出的一致性与可控性

一、AI 生成的同一个 Button，三次输出三个样子

把 Figma 里的一个"确认按钮"截图扔给当前流行的 AI 生成工具。第一次输出：

<button className="bg-blue-500 text-white px-6 py-2 rounded-md hover:bg-blue-600"> 确认 </button>

第二次，同样的截图：

<button className="bg-primary text-white px-24 py-8 rounded text-sm font-medium transition-colors duration-200 hover:opacity-90"> 确认 </button>

第三次：

<button className="btn btn--primary btn--medium" onClick={handleClick}> 确认 </button>

同一个人、同一张图、同一个工具——三次生成，三种 API 风格：Tailwind Utility 组合、Tailwind 混搭 Token、BEM 命名。问题不是机器没看懂图，而是机器没有"代码规范约束"。它每次都在语言模型的概率空间中独立采样，生成"统计学上最可能"的 JSX，而"设计规范"不是概率高的事件。

这就是当前 AI 代码生成最头疼的一致性问题。LLM 能生成看起来正确的 UI 代码，但它不知道你的项目里所有颜色必须走 CSS 变量、所有间距必须用 Token、所有 Button 必须从@lib/ui的Button组件导出。这种"局部看着都对，全局放进项目就炸"的输出，就是模板约束要解决的问题。

二、模板约束的三层架构

模板约束不是简单地给 Prompt 加一句"请遵守我们的样式规范"。它需要三个层面的协同工作：

组件签名约束（API Schema）：告诉 AI "这个组件有哪些 Props，类型是什么，哪些必传"。这是最低层次的约束——防止 AI 自己捏造不存在的属性名。
样式约束（Token Map）：告诉 AI"所有颜色使用var(--color-xxx)值，所有间距使用var(--space-n)值"。防止 AI 输出padding: 16px这种硬编码。
模板约束（Template Skeleton）：告诉 AI "这个组件的 HTML 结构是固定的框架，你只能在指定的<slot>区域内填充内容和样式变体"。这是最高层次的约束——保证生成的所有同类型组件共享相同的 DOM 骨架。

flowchart TD A["用户输入<br/>(Figma截图/需求描述)"] --> B["Prompt 组装器"] C["组件签名约束<br/>(TS Interface AST)"] --> B D["样式 Token 约束<br/>(Token Map JSON)"] --> B E["模板骨架约束<br/>(Handlebars 模板)"] --> B B --> F["LLM 推理"] F --> G["生成的 JSX 代码"] G --> H["后处理校验"] H --> I{"Props 签名<br/>是否匹配?"} I -->|"否"| J["降级为最接近的合法 Props"] I -->|"是"| K{"样式值是否<br/>来自 Token?"} K -->|"否"| L["替换为 Token 引用"] K -->|"是"| M["输出合规代码"] J --> K L --> M

三、模板约束引擎的实现

/** * AI 组件生成模板约束引擎 * * 三层约束策略： * 1. ComponentSchema - Props 类型约束（防止 AI 捏造属性） * 2. TokenRegistry - 样式 Token 约束（防止硬编码魔法数字） * 3. TemplateSkeleton - 骨架模板约束（保证 DOM 结构一致性） */ // === 第一层：组件签名约束 === interface PropConstraint { name: string; type: 'string' | 'number' | 'boolean' | 'enum' | 'ReactNode'; required: boolean; enumValues?: string[]; // 枚举类型的合法值 defaultValue?: unknown; // 默认值 } interface ComponentSchema { name: string; // 组件名 "Button" props: PropConstraint[]; // Props 定义 importPath: string; // 导入路径 "@lib/ui/Button" } // Button 组件的签名约束定义 const ButtonSchema: ComponentSchema = { name: 'Button', importPath: '@lib/ui/Button', props: [ { name: 'variant', type: 'enum', required: false, enumValues: ['primary', 'secondary', 'outline', 'ghost'], defaultValue: 'primary' }, { name: 'size', type: 'enum', required: false, enumValues: ['sm', 'md', 'lg'], defaultValue: 'md' }, { name: 'disabled', type: 'boolean', required: false, defaultValue: false }, { name: 'loading', type: 'boolean', required: false, defaultValue: false }, { name: 'children', type: 'ReactNode', required: true }, { name: 'onClick', type: 'ReactNode', required: false }, // 事件处理函数 ], }; // === 第二层：Token 注册表 === // 规定所有合法 Token，AI 输出中出现的任何颜色/间距都应该在这张表中 const TokenRegistry = { color: [ '--color-primary', '--color-primary-hover', '--color-text-primary', '--color-text-secondary', '--color-bg-primary', '--color-bg-secondary', '--color-border-default', '--color-danger', '--color-success', ], spacing: [ '--space-1', '--space-2', '--space-3', '--space-4', '--space-5', '--space-6', '--space-8', '--space-10', '--space-12', ], radius: [ '--radius-sm', // 4px '--radius-md', // 8px '--radius-lg', // 12px '--radius-full', // 9999px ], }; // === 第三层：骨架模板 === // 模板中的 <slot> 是 AI 可以自由发挥的填充区 // 模板外的结构是固定锁死的 const ButtonTemplate = ` <Button variant="<slot name='variant' constraint='enum' values='primary|secondary|outline|ghost' default='primary' />" size="<slot name='size' constraint='enum' values='sm|md|lg' default='md' />" disabled={<slot name='disabled' constraint='boolean' default='false' />} loading={<slot name='loading' constraint='boolean' default='false' />} onClick={<slot name='onClick' constraint='function' />} > <slot name='children' constraint='ReactNode' /> </Button> `; /** * Prompt 组装器：将三层约束注入 prompt * 这不是简单的字符串拼接—— * 每一层约束都以结构化的方式嵌入 prompt，让 LLM 理解约束边界 */ function buildConstrainedPrompt( userRequest: string, schema: ComponentSchema, template: string ): string { return ` 你是一个严格遵循设计规范的 React 组件生成器。你必须遵守以下三层约束。 ## 第一层：组件 API 约束 你只能使用组件: ${schema.name} 导入路径固定为: import { ${schema.name} } from '${schema.importPath}'; 该组件支持的 Props: ${schema.props.map(p => { const required = p.required ? '(必传)' : '(可选)'; const typeInfo = p.type === 'enum' && p.enumValues ? `${p.type}<${p.enumValues.join(' | ')}>` : p.type; return ` - ${p.name}: ${typeInfo} ${required}`; }).join('\n')} ## 第二层：样式 Token 约束 生成的代码中不得出现任何硬编码的颜色值（如 #3B82F6、blue）。 所有颜色必须使用 CSS 变量 var(--color-xxx)。 合法颜色 Token: ${TokenRegistry.color.map(c => `\`var(${c})\``).join(', ')} 合法间距 Token: ${TokenRegistry.spacing.map(s => `\`var(${s})\``).join(', ')} ## 第三层：骨架模板约束 你生成的组件结构必须基于以下模板。你的任务是在 <slot> 区域填充正确的值： \`\`\`jsx ${template} \`\`\` ## 用户需求 ${userRequest} ## 输出格式 只输出 JSX 代码块，不要包含任何解释文字。 `.trim(); } /** * 后处理校验器：检查 AI 输出是否违反约束 * 如果检测到违规，自动修复到最接近的合法值 */ function validateAndFixOutput(generatedCode: string, schema: ComponentSchema): string { let fixed = generatedCode; // 检查1：替换硬编码颜色 // 匹配常见的硬编码颜色模式 const hexColorPattern = /#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})\b/g; if (hexColorPattern.test(fixed)) { hexColorPattern.lastIndex = 0; // 将硬编码颜色映射到最接近的 Token fixed = fixed.replace(hexColorPattern, (match) => { // 简化映射：3B82F6 → --color-primary, EF4444 → --color-danger const nearestToken = mapHexToToken(match); return `var(${nearestToken})`; }); } // 检查2：替换硬编码间距 const pxPattern = /(padding|margin|gap)\s*:\s*(\d+)px/g; fixed = fixed.replace(pxPattern, (match, prop, value) => { const nearestToken = mapPxToSpacingToken(parseInt(value)); return `${prop}: var(${nearestToken})`; }); // 重置正则状态 pxPattern.lastIndex = 0; // 检查3：验证 Props 名是否在 Schema 中，如果在但类型不对，修正类型 for (const prop of schema.props) { if (prop.type === 'enum' && prop.enumValues) { const enumPattern = new RegExp(`${prop.name}=["']([^"']+)["']`, 'g'); fixed = fixed.replace(enumPattern, (match, value) => { if (!prop.enumValues!.includes(value)) { // 使用枚举的第一个值作为默认降级 const fallback = prop.defaultValue as string || prop.enumValues![0]; return `${prop.name}="${fallback}"`; } return match; }); } } return fixed; } /** * 简单的颜色映射表：常见 HEX → 最接近的 Design Token * 生产环境中应使用 OKLCH 空间的距离计算实现精确映射 */ function mapHexToToken(hex: string): string { const map: Record<string, string> = { '#3B82F6': '--color-primary', '#2563EB': '--color-primary-hover', '#EF4444': '--color-danger', '#22C55E': '--color-success', '#0F172A': '--color-text-primary', '#475569': '--color-text-secondary', '#F8FAFC': '--color-bg-primary', '#F1F5F9': '--color-bg-secondary', '#E2E8F0': '--color-border-default', }; const normalized = hex.toLowerCase(); if (map[normalized]) return map[normalized]; // 如果是未知 HEX，映射到语义上最中性的 Token return '--color-primary'; } function mapPxToSpacingToken(px: number): string { // 4px 的整数倍映射表 const spacingMap: Record<number, string> = { 4: '--space-1', 8: '--space-2', 12: '--space-3', 16: '--space-4', 20: '--space-5', 24: '--space-6', 32: '--space-8', 40: '--space-10', 48: '--space-12', }; if (spacingMap[px]) return spacingMap[px]; // 找不到精确匹配时，取最接近的 ≥4px 的倍数 const nearest = Math.max(4, Math.round(px / 4) * 4); return spacingMap[nearest] || '--space-4'; } export { buildConstrainedPrompt, validateAndFixOutput, ComponentSchema, ButtonSchema, ButtonTemplate };

四、模板约束的三个失效场景

场景一：AI 需要一个设计中不存在的变体。用户要求"生成一个绿色 Button 用于成功提示"。你的设计系统里没有variant="success"而函数mapHexToToken将绿色#22C55E映射到了--color-success——但 Button 的variant不接受success值。最终后处理校验尝试验证输出，发现variant="success"不在枚举中，降级为variant="primary"，并把绿色丢失了。这就是"约束太死"的反面——正确的修复是扩展 Schema 使variant枚举包含success，而不是在降级时丢弃用户的意图信息。

场景二：Token 注册表过小。你的注册表只包含了 9 种颜色 Token。但前端设计系统的 Token 文件实际定义了 64 种包括danger-50、danger-100、danger-200这种数字色阶。AI 生成的代码中发现一个需要danger-50的背景，但在注册表中找不到它——后处理逻辑不知道该映射到什么颜色，只能给一个 Default。解决方案：注册表应该直接从 Token JSON 文件自动生成，而不是手动维护。

场景三：模板骨架限制了交互行为的表达空间。你把组件的 DOM 结构锁在模板里，但不同的variant="modal"需要一个额外的关闭按钮在模板里没有 slot。这是模板约束设计的核心权衡：结构锁死得越多，生成的多样性越低，但一致性越高。找到平衡点的实用策略是——"核心结构锁死 + 扩展区域开放"。把按钮的 HTML 结构（<button>tag、className 前缀、事件绑定）锁死在模板里，但允许 AI 在childrenslot 中自由排列图标和文字的布局。