生成式 UI 与设计系统的共生：何时用 AI 生成，何时用传统组件

生成式 UI 与设计系统的共生：何时用 AI 生成，何时用传统组件

生成式 UI（Generative UI）在 2026 年已不再是概念验证阶段。多个团队开始在产品界面中引入 AI 动态生成的组件，但随之而来的问题是：设计系统花了三年建立的组件一致性与可维护性，是否会被 AI 的"即兴创作"侵蚀？本文通过五个决策维度，界定 AI 生成与传统组件的使用边界。

一、生成式 UI 与设计系统的冲突本质

设计系统的核心价值是"一致性"——同一个按钮在所有页面上的外观和行为完全相同。生成式 UI 的核心价值是"适应性"——根据用户上下文动态呈现最优界面形态。

这两者天然冲突。一致性的代价是僵化，适应性的代价是失控。如果 AI 生成的界面与设计系统的 Token 不对齐，就会出现：

• 同一页面出现两种按钮样式（设计系统的 + AI 生成的）
• AI 生成的表单布局与设计系统的间距规范不一致
• 交互行为差异导致用户预期混乱

共生的核心思路是"约束下的生成"——AI 的生成范围被设计系统的 Token 和组件骨架限定，超出约束的部分不允许生成。

二、五个决策维度：生成还是选用

维度一：界面形态的可预测性

如果界面形态可以枚举（如登录页、列表页、详情页），使用设计系统的预设组件。如果形态不可枚举（如数据分析 Dashboard 的布局因用户数据集而异），使用 AI 生成。

可预测性高 → 传统组件
可预测性低 → AI 生成（在约束范围内）

维度二：交互逻辑的确定性

按钮的点击行为是确定的（提交、取消、跳转），使用传统组件。交互路径依赖用户输入的动态推断（如智能客服的回复界面形态），使用 AI 生成。

维度三：视觉一致性的硬性要求

品牌级界面（首页、Logo 区域、核心操作按钮）必须使用设计系统组件，不允许 AI 生成。非品牌级界面（辅助面板、数据探索区域）可以由 AI 在约束下生成。

维度四：组件库的覆盖度

如果设计系统已有对应组件，优先选用。如果设计系统尚未覆盖该场景，且开发成本高于 AI 生成成本，由 AI 在约束下生成后，再评估是否纳入设计系统。

维度五：变更频率

高频变更的界面（A/B 测试、活动页、个性化推荐区域）适合 AI 生成——每次变更不需要走设计系统的组件审批流程。低频变更的界面（核心导航、全局布局）使用传统组件。

/**
* 生成式 UI 决策引擎
* 根据五个维度综合判断使用传统组件还是 AI 生成
*/
interface ComponentDecisionInput {
predictability: 'high' | 'medium' | 'low';
interactionDeterminism: 'deterministic' | 'semi-dynamic' | 'dynamic';
visualConsistencyRequirement: 'strict' | 'moderate' | 'flexible';
componentCoverage: 'covered' | 'partial' | 'missing';
changeFrequency: 'low' | 'medium' | 'high';
}

interface ComponentDecision {
strategy: 'system' | 'constrained-gen' | 'free-gen';
constraints?: {
tokens: string[]; // 必须使用的设计系统 Token
layoutSkeleton?: string; // 必须遵守的布局骨架
maxVariants: number; // AI 可生成的变体上限
};
reason: string;
}

function decideComponentStrategy(
input: ComponentDecisionInput
): ComponentDecision {
// 维度一：可预测性高 → 传统组件
if (input.predictability === 'high') {
return {
strategy: 'system',
reason: '界面形态可枚举，使用设计系统预设组件',
};
}

// 维度三：品牌级视觉一致性 → 传统组件
if (input.visualConsistencyRequirement === 'strict') {
return {
strategy: 'system',
reason: '品牌级界面，不允许 AI 生成',
};
}

// 维度四：设计系统已有覆盖 → 优先选用
if (input.componentCoverage === 'covered') {
return {
strategy: 'system',
reason: '设计系统已有对应组件，优先选用',
};
}

// 维度五：高频变更 + 可预测性中 → 约束生成
if (input.changeFrequency === 'high' && input.predictability !== 'low') {
return {
strategy: 'constrained-gen',
constraints: {
tokens: ['spacing', 'color', 'typography'],
maxVariants: 3,
},
reason: '高频变更场景，AI 在 Token 约束下生成',
};
}

// 其余场景：自由生成（但仍需通过质量门禁）
return {
strategy: 'free-gen',
constraints: {
tokens: ['color', 'typography'], // 颜色和字体仍必须对齐
maxVariants: 5,
},
reason: '形态不可枚举，AI 自由生成但需通过质量门禁',
};
}

三、约束下的生成：Token 锁定与骨架模板

"约束下的生成"是共生的关键机制。AI 可以自由决定布局细节，但必须遵守设计系统的 Token 约定。

Token 锁定机制

将设计系统的 Token（间距、颜色、字体、圆角）作为 AI 生成的硬约束输入。AI 生成的任何组件，其样式属性必须映射到 Token，不允许使用任意值。

/**
* Token 锁定验证器
* 检查 AI 生成的组件是否对齐设计系统 Token
*/
interface DesignToken {
category: 'spacing' | 'color' | 'typography' | 'border-radius' | 'shadow';
name: string;
value: string;
}

interface GeneratedStyle {
property: string;
value: string;
resolvedToken?: DesignToken;
}

async function validateTokenAlignment(
generatedStyles: GeneratedStyle[],
systemTokens: DesignToken[]
): Promise<ValidationResult> {
const violations: TokenViolation[] = [];

for (const style of generatedStyles) {
// 需要映射到 Token 的 CSS 属性
const tokenRequiredProperties = [
'margin', 'padding', 'gap',
'color', 'background-color', 'border-color',
'font-size', 'font-weight', 'line-height',
'border-radius', 'box-shadow',
];

if (tokenRequiredProperties.includes(style.property)) {
// 检查该值是否在设计系统 Token 中存在
const matchedToken = systemTokens.find(
t => t.value === style.value || t.name === style.value
);

if (!matchedToken) {
violations.push({
property: style.property,
value: style.value,
reason: `值 "${style.value}" 不在设计系统 Token 中`,
suggestedToken: findClosestToken(style.value, systemTokens),
});
} else {
style.resolvedToken = matchedToken;
}
}
}

return {
valid: violations.length === 0,
violations,
tokenCoverageRate: calculateTokenCoverage(generatedStyles, systemTokens),
};
}

// 查找最接近的 Token 替代建议
function findClosestToken(
value: string,
tokens: DesignToken[]
): DesignToken | null {
// 数值型 Token：取最接近的
const numericValue = parseFloat(value);
if (!isNaN(numericValue)) {
const numericTokens = tokens.filter(t => !isNaN(parseFloat(t.value)));
return numericTokens.sort(
(a, b) =>
Math.abs(parseFloat(a.value) – numericValue) –
Math.abs(parseFloat(b.value) – numericValue)
)[0] || null;
}
return null;
}

骨架模板机制

对于布局类场景（Dashboard、数据面板），提供骨架模板作为 AI 生成的起点。AI 只能在骨架模板的"槽位"内自由填充内容，不能修改骨架的整体结构。

四、质量门禁：AI 生成组件的验收标准

AI 生成的组件必须通过质量门禁才能上线。门禁包含四个检查项：

/**
* 生成式 UI 质量门禁
* AI 生成的组件必须通过四项检查才能上线
*/
interface QualityGateResult {
tokenAlignment: { rate: number; violations: number };
interactionConsistency: { passed: boolean; mismatches: string[] };
accessibility: { score: number; issues: string[] };
renderPerformance: { lcp: number; rerenderCount: number };
overallPassed: boolean;
}

async function runQualityGate(
componentPath: string,
systemTokens: DesignToken[]
): Promise<QualityGateResult> {
try {
// 检查项一：Token 对齐率
const styles = await extractGeneratedStyles(componentPath);
const tokenValidation = await validateTokenAlignment(styles, systemTokens);

// 检查项二：交互一致性（需人工标注的自动化辅助）
const interactionCheck = await compareInteractionBehavior(componentPath);

// 检查项三：可访问性
const a11yResult = await runAxeCoreScan(componentPath);

// 检查项四：渲染性能
const perfResult = await measureRenderPerformance(componentPath);

const overallPassed =
tokenValidation.valid &&
tokenValidation.tokenCoverageRate >= 0.9 &&
interactionCheck.passed &&
a11yResult.score >= 85 &&
perfResult.lcp < 2000 &&
perfResult.rerenderCount <= 3;

return {
tokenAlignment: {
rate: tokenValidation.tokenCoverageRate,
violations: tokenValidation.violations.length,
},
interactionConsistency: {
passed: interactionCheck.passed,
mismatches: interactionCheck.mismatches,
},
accessibility: { score: a11yResult.score, issues: a11yResult.issues },
renderPerformance: {
lcp: perfResult.lcp,
rerenderCount: perfResult.rerenderCount,
},
overallPassed,
};
} catch (error) {
console.error(
`质量门禁执行失败: ${error instanceof Error ? error.message : String(error)}`
);
// 门禁失败时默认阻止上线
return {
tokenAlignment: { rate: 0, violations: Infinity },
interactionConsistency: { passed: false, mismatches: ['门禁执行异常'] },
accessibility: { score: 0, issues: ['门禁执行异常'] },
renderPerformance: { lcp: Infinity, rerenderCount: Infinity },
overallPassed: false,
};
}
}

结论

生成式 UI 与设计系统的关系不是替代，而是共生。核心结论有三点：

第一，AI 生成不是设计系统的对立面。在 Token 约束和骨架模板的限制下，AI 生成可以补充设计系统未覆盖的动态场景，同时不侵蚀一致性基础。

第二，决策的关键是五个维度：可预测性、交互确定性、视觉一致性、组件覆盖度、变更频率。每一个维度都有明确的"传统组件 vs AI 生成"的分界线。

第三，质量门禁是共生关系的保障。没有门禁的 AI 生成是失控的生成，没有约束的自由是破坏一致性的自由。

设计系统负责确定性的基础，生成式 UI 负责适应性的上层。两者协作而非竞争，才能在一致性与灵活性之间找到可持续的平衡点。