AI 生成式设计落地：从提示词到可交付 UI 的工程化链路

AI 生成式设计落地：从提示词到可交付 UI 的工程化链路

一、生成式设计的承诺与现实——从概念验证到生产落地的鸿沟

生成式 AI 在 UI 设计领域的应用已从概念验证阶段进入工程化落地阶段。文本到 UI（Text-to-UI）、草图到代码（Sketch-to-Code）、设计稿到组件（Design-to-Component）等工具层出不穷，但团队在实际落地中普遍遇到三个核心障碍：第一，AI 生成的 UI 在视觉上"看起来对"，但结构上缺乏语义化，无法直接用于生产；第二，生成结果与现有设计系统脱节，每次生成都从零开始，无法复用已有的组件和 Token；第三，生成过程不可控，同一提示词在不同时间可能产出差异巨大的结果，缺乏可复现性。

解决这些障碍的关键在于：将 AI 生成从"一次性输出"升级为"约束驱动的迭代生成"，让设计系统成为 AI 的输入约束而非事后校验。

二、约束驱动生成的技术架构

2.1 从自由生成到约束生成的范式转换

flowchart TD A[用户意图描述] --> B[意图解析器] B --> C[结构化需求] C --> D[约束注入层] D --> E[设计系统约束] D --> F[布局规则约束] D --> G[交互模式约束] E --> H[约束驱动的生成引擎] F --> H G --> H H --> I[候选方案集] I --> J[合规性校验] J --> K{通过校验?} K -->|是| L[输出可交付 UI] K -->|否| M[反馈修正指令] M --> H

约束注入层是架构的核心。它将设计系统的组件注册表、Token 定义和布局规则转化为 AI 可理解的约束条件，确保生成结果在"创意空间"内探索，而非在"无约束空间"中漫游。

2.2 约束的类型与表达方式

flowchart LR A[约束类型] --> B[硬约束 - 必须满足] A --> C[软约束 - 优先满足] A --> D[偏好约束 - 风格引导] B --> B1[组件白名单] B --> B2[Token 强制引用] B --> B3[无障碍标准] C --> C1[布局模式偏好] C --> C2[间距系统遵循] C --> C3[响应式断点] D --> D1[视觉风格倾向] D --> D2[动效强度偏好] D --> D3[信息密度偏好]

硬约束违反时生成结果直接被拒绝，软约束违反时降低方案评分，偏好约束用于在多个合格方案中选择最符合团队风格的方案。

三、生产级约束驱动生成系统实现

3.1 设计系统约束的机器可读表达

interface DesignSystemConstraint { // 组件注册表：AI 只能使用已注册的组件 components: ComponentRegistry; // Token 注册表：所有样式值必须引用 Token tokens: TokenRegistry; // 布局规则：定义合法的布局模式 layoutRules: LayoutRule[]; // 无障碍规则：对比度、触摸目标等 accessibilityRules: AccessibilityRule[]; } interface ComponentRegistry { name: string; props: Record<string, PropDefinition>; variants: string[]; requiredProps: string[]; } // 将设计系统约束转换为 AI 可理解的 prompt 片段 class ConstraintPromptBuilder { buildSystemPrompt(constraint: DesignSystemConstraint): string { const componentList = constraint.components .map((c) => `- <${c.name}>: 可用变体 [${c.variants.join(', ')}]`) .join('\n'); const tokenList = Object.entries(constraint.tokens) .map(([name, value]) => `- var(--${name}): ${value}`) .join('\n'); return ` 你是一个 UI 生成引擎，必须严格遵守以下约束： ## 可用组件（禁止使用未列出的组件） ${componentList} ## 设计 Token（所有样式值必须引用 Token，禁止硬编码） ${tokenList} ## 布局规则 - 使用 CSS Grid 作为主要布局方式 - 间距必须使用 --space-* 系列 Token - 最大嵌套深度为 4 层 ## 无障碍规则 - 文本对比度不低于 4.5:1 - 可交互元素最小尺寸 44x44px - 所有图片必须包含 alt 属性 `.trim(); } }

3.2 生成结果的合规性校验

interface ComplianceReport { isCompliant: boolean; errors: ComplianceError[]; warnings: ComplianceWarning[]; score: number; // 0-100 合规评分 } class ComplianceValidator { validate( generatedCode: string, constraint: DesignSystemConstraint ): ComplianceReport { const errors: ComplianceError[] = []; const warnings: ComplianceWarning[] = []; // 检查 1：是否使用了未注册的组件 const usedComponents = this.extractComponentNames(generatedCode); const registeredNames = constraint.components.map((c) => c.name); const unregistered = usedComponents.filter( (name) => !registeredNames.includes(name) ); if (unregistered.length > 0) { errors.push({ rule: 'component-whitelist', message: `使用了未注册的组件: ${unregistered.join(', ')}`, severity: 'critical', }); } // 检查 2：是否存在硬编码的样式值 const hardcodedValues = this.detectHardcodedValues(generatedCode); if (hardcodedValues.length > 0) { errors.push({ rule: 'token-only', message: `发现硬编码样式值: ${hardcodedValues.join(', ')}`, severity: 'critical', }); } // 检查 3：间距值是否符合 Token 体系 const spacingViolations = this.checkSpacingCompliance( generatedCode, constraint.tokens ); if (spacingViolations.length > 0) { warnings.push({ rule: 'spacing-system', message: `间距值不符合 Token 体系: ${spacingViolations.join(', ')}`, severity: 'warning', }); } // 计算合规评分 const score = this.calculateScore(errors, warnings); return { isCompliant: errors.length === 0, errors, warnings, score, }; } private calculateScore( errors: ComplianceError[], warnings: ComplianceWarning[] ): number { let score = 100; // 每个 critical 错误扣 20 分 score -= errors.filter((e) => e.severity === 'critical').length * 20; // 每个 warning 扣 5 分 score -= warnings.length * 5; return Math.max(0, score); } }

3.3 迭代修正循环

class IterativeGenerator { private maxRetries = 3; async generateWithValidation( userIntent: string, constraint: DesignSystemConstraint, promptBuilder: ConstraintPromptBuilder, validator: ComplianceValidator ): Promise<{ code: string; report: ComplianceReport }> { const systemPrompt = promptBuilder.buildSystemPrompt(constraint); for (let attempt = 0; attempt < this.maxRetries; attempt++) { // 生成候选方案 const generated = await this.callGenerationModel( systemPrompt, userIntent ); // 合规性校验 const report = validator.validate(generated, constraint); if (report.isCompliant && report.score >= 80) { return { code: generated, report }; } // 未通过校验，将错误信息反馈给模型重新生成 const feedback = this.buildFeedbackPrompt(report); userIntent = `${userIntent}\n\n修正要求：\n${feedback}`; } // 超过重试次数，返回最后一次结果并标记需人工审核 const lastGenerated = await this.callGenerationModel( systemPrompt, userIntent ); const lastReport = validator.validate(lastGenerated, constraint); return { code: lastGenerated, report: { ...lastReport, isCompliant: false }, }; } private buildFeedbackPrompt(report: ComplianceReport): string { return report.errors .map((e) => `[错误] ${e.rule}: ${e.message}`) .concat( report.warnings.map((w) => `[警告] ${w.rule}: ${w.message}`) ) .join('\n'); } }

四、约束驱动生成的局限性与工程权衡

4.1 约束过严导致生成质量下降

当硬约束过多时，AI 模型的生成空间被极度压缩，产出结果趋于模板化，缺乏设计创意。例如，如果组件白名单只包含 5 个基础组件，AI 几乎无法生成有视觉层次感的复杂页面。工程实践中建议将组件白名单分为"核心组件"（必须使用）和"扩展组件"（优先使用），给 AI 留出组合创新的空间。

4.2 合规校验的误判问题

硬编码值检测是合规校验中最容易误判的环节。border-radius: 50%是创建圆形的合法写法，但会被检测为"未引用 Token"；opacity: 0是隐藏元素的常用方式，也会被标记为违规。解决这类误判需要维护一个"豁免列表"，明确哪些属性允许使用非 Token 值。

4.3 迭代修正的收敛性不确定

迭代修正循环不保证收敛——在某些情况下，AI 模型可能在"违反约束 A"和"违反约束 B"之间反复切换，无法同时满足所有约束。当重试次数超过上限时，系统应将结果标记为"需人工审核"而非继续消耗资源。建议设置 3 次重试上限，超过后转人工处理。

4.4 生成一致性的时间维度问题

同一提示词在不同时间调用 AI 模型，可能生成结构差异较大的结果。这在需要"增量生成"的场景（如在已有页面中添加新模块）中尤为严重——新生成的模块可能与已有模块的布局模式不一致。缓解策略包括：将已有页面的结构作为上下文输入，要求 AI 在已有模式基础上扩展；使用 temperature=0 降低随机性。

五、总结

约束驱动生成将 AI 从"自由创作"模式切换到"框架内创新"模式，核心价值在于确保生成结果天然融入设计系统，而非事后修补。设计系统约束的机器可读表达、合规性校验和迭代修正循环构成了完整的工程化链路。

落地路线建议：第一步，将设计系统的组件注册表和 Token 定义转换为机器可读的约束描述；第二步，实现合规性校验器，覆盖组件白名单、Token 引用和间距系统三个核心维度；第三步，搭建迭代修正循环，设置 3 次重试上限和 80 分合规评分阈值；第四步，建立"AI 生成 + 人工审核"的交付流程，将合规评分低于 80 的结果自动路由到人工审核队列。