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 的真正交付标准。