AI UI 生成验收：组件能渲染，不代表能进入设计系统

AI UI 生成验收：组件能渲染，不代表能进入设计系统

一、生成结果先过系统边界

AI 生成 UI 组件时，最容易被第一眼截图欺骗。页面能渲染，按钮也能点击，但它可能绕开设计 Token，私自写颜色，状态不完整，响应式断点缺失。这样的组件进入代码库后，会变成维护债。

UI 生成验收要把“看起来像”升级成“能进入设计系统”。组件必须符合 Token、组件 API、无障碍、主题、响应式和测试要求。否则生成越快，后续修复越慢。

二、验收链路要自动化

flowchart TD A[AI 生成组件] --> B[Token 检查] B --> C[组件 API 校验] C --> D[视觉回归] D --> E[无障碍检查] E --> F[响应式快照] F --> G[入库决策]

验收不应只靠人工看稿。Token 检查确认颜色、字号、间距来自系统。API 校验确认组件接口符合已有规范。视觉回归检查多状态截图。无障碍检查确认键盘和读屏路径。

响应式快照也很重要。很多 AI 生成组件只在桌面宽度好看，移动端就挤压、溢出或遮挡。至少要覆盖窄屏、平板和常规桌面三类宽度。

三、规则要落到代码

type UiReviewResult = { tokenViolations: string[] missingStates: string[] a11yErrors: number responsiveIssues: string[] } export function assertCanMerge(result: UiReviewResult) { if (result.tokenViolations.length > 0) throw new Error("token violation") if (result.a11yErrors > 0) throw new Error("a11y failed") }

确定性问题交给工具。硬编码颜色、缺少 focus 状态、按钮无 label、文本溢出，都可以自动检查。人工评审更适合判断视觉节奏、信息层级和组件抽象是否合理。

生成组件还要保留来源信息。提示词版本、设计 Token 版本、组件模板版本和验收结果都应写入记录。以后组件出问题，团队能知道它来自哪个生成策略。

component_meta: token_version: 2026.07 prompt_version: ui-gen-v5 review_status: passed

四、入库后仍要追踪

组件通过验收不代表永远安全。设计 Token 更新后，要重新检查旧组件是否受影响。主题切换、暗色模式、国际化和长文本都可能暴露隐藏问题。

AI 生成组件还要防止重复。模型很容易为相似需求生成多个近似组件。入库前应做相似组件搜索，优先复用或扩展已有组件。设计系统的价值在一致性，不在组件数量。

验收还要覆盖主题模式。组件在浅色模式下通过，不代表暗色模式、高对比模式和品牌主题也能工作。每次入库至少跑一组主题截图，检查文本对比度、边框可见性和状态色语义。很多视觉问题不是组件默认态暴露的，而是在主题切换时出现。

组件文档也要生成。AI 生成组件如果没有用法、属性说明、状态示例和禁用场景，其他人很难正确复用。文档应和组件一起验收，避免“代码进库，使用方式靠猜”。设计系统的资产不只是源码，还包括可理解的使用协议。

还要记录人工修改。AI 初稿经过人工调整后，哪些规则被改动、为什么改动，都可以反向进入生成策略。这样系统不是一次次重新犯错，而是在验收反馈里逐步收敛。

五、总结

AI UI 生成验收要覆盖 Token、API、视觉、无障碍、响应式和重复组件检查，并把结果自动化。

组件能渲染只是第一步。能进入设计系统、能长期维护，才是 AI 生成 UI 的真正交付标准。