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 的结果自动路由到人工审核队列。
