AI 组件生成评测：别只看页面能不能渲染

一、生成组件最容易骗过肉眼

AI 生成前端组件时，第一眼能渲染并不代表质量合格。结构可能不可维护，状态可能不可控，样式可能和设计系统冲突，交互也可能没有键盘可访问性。只靠截图验收，容易把隐患放进代码库。

组件生成评测要从"能不能显示"升级到"能不能长期维护"。评测维度至少包括结构、类型、可访问性、性能、设计规范和测试覆盖。生成式 UI 的核心不是多快产出，而是产出能不能接进工程体系。

二、评测维度要结构化

flowchart TD A[AI 生成组件] --> B[类型检查] B --> C[Lint 与规范] C --> D[视觉回归] D --> E[交互测试] E --> F[性能预算] F --> G[评测报告]

结构化评测可以减少主观争论。TypeScript 检查组件接口，ESLint 检查副作用和依赖，视觉回归检查样式漂移，Playwright 检查交互路径，性能预算检查包体和渲染次数。

AI 输出还要看是否复用现有组件。生成一个新的 Button 看起来没问题，但它绕开设计系统，会制造长期债务。评测规则要识别重复组件、硬编码颜色和私自定义间距。

三、规则和模型要分工

ts 复制代码

type ComponentScore = {
  typeSafe: boolean
  a11yIssues: number
  bundleDeltaKb: number
  duplicatedPrimitives: string[]
}

确定性问题交给工具。类型错误、未使用变量、ARIA 缺失、依赖数组错误，都应该用规则和测试拦截。模型评审更适合看组件边界是否合理、状态是否过度提升、命名是否含糊。

ts 复制代码

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")
}

不要让模型判断所有事情。模型可以给建议，但发布门禁必须由可复现规则决定。否则今天通过，明天同一组件可能被另一段评语否掉。

四、评测结果要能回放

yaml 复制代码

eval_case:
  prompt_version: ui-gen-v4
  design_tokens: tokens-2026-07
  expected_interactions: [hover, focus, submit]

每次生成都要记录提示词版本、设计 token 版本、输入 Schema 和评测结果。组件生成策略升级后，用历史样本回放，才能知道质量是否真的提升。

评测失败也要分类。类型失败说明代码不可运行，视觉失败说明样式偏离，交互失败说明用户路径断了，性能失败说明实现太重。分类清楚，优化方向才不会乱。

评测还要覆盖响应式。桌面端看起来没问题，不代表移动端可用。生成组件时可以固定几组视口：移动端、平板、常见笔记本和宽屏。每组都跑截图、键盘焦点和文本溢出检查。很多生成组件的问题，不是逻辑错，而是容器一窄就挤爆。

设计 token 的偏离也要量化。硬编码颜色、随意圆角、重复阴影和不在规范内的间距，都应该进入报告。这样团队不是凭审美争论，而是拿规则判断生成结果能不能进库。

五、总结

AI 组件生成评测不能只看页面是否渲染。要把类型、规范、视觉、交互、性能和复用情况放进同一条质量流水线。

生成式 UI 的价值，不是让代码瞬间出现，而是让可维护的组件稳定进入工程系统。