AI 生成组件验收：别只看页面能不能跑起来

AI 生成组件验收：别只看页面能不能跑起来

一、生成代码不是交付终点

AI 生成 UI 组件时，最容易让人产生错觉的是“页面已经能跑”。按钮能点击、弹窗能打开、列表能渲染，看起来就像完成了。但组件进入设计系统，需要的不只是运行成功，还要满足状态完整、语义清晰、样式可控、交互稳定和可维护。

如果验收只停在视觉截图，后续复用时就会暴露问题：禁用态没有设计、加载态会抖动、错误态文案溢出、键盘无法操作、Token 没有接入。AI 生成组件验收要把这些隐性要求显式化。

二、先定义验收维度

flowchart TD
  A[AI 生成组件] --> B[视觉一致性]
  A --> C[状态完整性]
  A --> D[交互可达性]
  A --> E[Token 接入]
  A --> F[代码可维护性]

组件验收清单最好写成机器和人都能理解的规则。比如按钮组件至少包含 default、hover、active、disabled、loading、focus-visible 状态；输入框至少包含 empty、filled、error、success、disabled、readonly 状态。

component_acceptance:
  states_required: true
  token_only_style: true
  keyboard_accessible: true
  visual_regression: required
  storybook_cases: required

有了清单，AI 生成结果才不会只追求第一眼好看。

三、状态覆盖要可检查

验收组件时，不要只看默认状态。默认状态往往最容易生成，真正决定复用质量的是边界状态。长文案、空数据、网络慢、权限不足、焦点停留、错误恢复，这些都要进入样例。

const cases = [
  "default",
  "hover",
  "disabled",
  "loading",
  "error",
  "longText",
  "keyboardFocus",
];

如果组件没有对应状态，就不要让它进入公共库。短期绕过会让业务页面各自补丁，最后设计系统被局部样式撕开。

四、代码要能被团队接住

AI 生成组件常见问题是样式写死、层级过深、props 命名随意。验收时要看它是否使用统一 Token，是否暴露稳定 API，是否把业务文案和基础能力混在一起。

code_review_points:
  no_magic_color: true
  no_inline_spacing_number: true
  props_named_by_intent: true
  separate_base_and_business: true

还要检查可访问性。按钮必须是按钮语义，图标按钮要有 aria-label，弹窗要有焦点圈定，错误提示要能被读屏读到。AI 很容易生成“看起来像按钮”的 div，这种组件越早拦下越好。

最后，验收结果要进入组件文档。哪些状态已覆盖，哪些场景暂不支持，哪些参数不能组合，都应该写清楚。设计系统不是组件堆积，而是约束堆积。

还可以把验收放进 Storybook 或内部组件平台。每个组件都展示完整状态矩阵，并把视觉回归、交互测试和无障碍扫描绑定到对应 story。这样 AI 生成的新版本不是靠人工翻代码确认，而是直接进入同一套质量门。

storybook_gate:
  required_stories:
    - default
    - disabled
    - loading
    - error
    - long_content
  block_merge_when_missing: true

组件 API 也要做稳定性检查。AI 有时会为临时需求新增非常具体的 props，例如 showBlueIconWhenError。这种参数会污染基础组件。更好的做法是抽象成意图明确的变体、状态或插槽，让组件能承载下一次需求。

最后，验收要保留“拒绝进入组件库”的选项。有些生成结果适合作为业务页面局部实现，不适合沉淀为公共组件。判断边界清楚，设计系统才不会被一次性代码拖重。

五、总结

AI 生成组件验收要检查视觉、状态、交互、Token、可访问性和代码结构。

页面能跑只是起点。组件能被长期复用，才算真正交付。