AI 组件生成评测别只看页面能不能渲染一、生成组件最容易骗过肉眼AI 生成前端组件时第一眼能渲染并不代表质量合格。结构可能不可维护状态可能不可控样式可能和设计系统冲突交互也可能没有键盘可访问性。只靠截图验收容易把隐患放进代码库。组件生成评测要从“能不能显示”升级到“能不能长期维护”。评测维度至少包括结构、类型、可访问性、性能、设计规范和测试覆盖。生成式 UI 的核心不是多快产出而是产出能不能接进工程体系。二、评测维度要结构化flowchart TD A[AI 生成组件] -- B[类型检查] B -- C[Lint 与规范] C -- D[视觉回归] D -- E[交互测试] E -- F[性能预算] F -- G[评测报告]结构化评测可以减少主观争论。TypeScript 检查组件接口ESLint 检查副作用和依赖视觉回归检查样式漂移Playwright 检查交互路径性能预算检查包体和渲染次数。AI 输出还要看是否复用现有组件。生成一个新的 Button 看起来没问题但它绕开设计系统会制造长期债务。评测规则要识别重复组件、硬编码颜色和私自定义间距。三、规则和模型要分工type ComponentScore { typeSafe: boolean a11yIssues: number bundleDeltaKb: number duplicatedPrimitives: string[] }确定性问题交给工具。类型错误、未使用变量、ARIA 缺失、依赖数组错误都应该用规则和测试拦截。模型评审更适合看组件边界是否合理、状态是否过度提升、命名是否含糊。export function assertBudget(score: ComponentScore) { if (!score.typeSafe) throw new Error(type check failed) if (score.a11yIssues 0) throw new Error(a11y regression) if (score.bundleDeltaKb 8) throw new Error(bundle budget exceeded) }不要让模型判断所有事情。模型可以给建议但发布门禁必须由可复现规则决定。否则今天通过明天同一组件可能被另一段评语否掉。四、评测结果要能回放eval_case: prompt_version: ui-gen-v4 design_tokens: tokens-2026-07 expected_interactions: [hover, focus, submit]每次生成都要记录提示词版本、设计 token 版本、输入 Schema 和评测结果。组件生成策略升级后用历史样本回放才能知道质量是否真的提升。评测失败也要分类。类型失败说明代码不可运行视觉失败说明样式偏离交互失败说明用户路径断了性能失败说明实现太重。分类清楚优化方向才不会乱。评测还要覆盖响应式。桌面端看起来没问题不代表移动端可用。生成组件时可以固定几组视口移动端、平板、常见笔记本和宽屏。每组都跑截图、键盘焦点和文本溢出检查。很多生成组件的问题不是逻辑错而是容器一窄就挤爆。设计 token 的偏离也要量化。硬编码颜色、随意圆角、重复阴影和不在规范内的间距都应该进入报告。这样团队不是凭审美争论而是拿规则判断生成结果能不能进库。五、总结AI 组件生成评测不能只看页面是否渲染。要把类型、规范、视觉、交互、性能和复用情况放进同一条质量流水线。生成式 UI 的价值不是让代码瞬间出现而是让可维护的组件稳定进入工程系统。