AI 生成组件验收清单：组件能看，不代表能复用

一、生成出来只是第一步

AI 可以很快生成一个按钮、弹窗、卡片或表单组件。第一眼看起来像设计稿，代码也能跑。但组件能复用，需要满足更严格的要求：状态完整、接口清楚、样式可控、无障碍可用、文档齐全。

如果验收只看截图，组件库很快会堆满一次性代码。组件能看，不代表能复用。

二、验收从状态开始

flowchart TD
  A[AI 生成组件] --> B[默认状态]
  A --> C[加载状态]
  A --> D[错误状态]
  A --> E[禁用状态]
  A --> F[空状态]

每个组件都要列出必要状态。按钮有 hover、active、disabled、loading；输入框有 focused、filled、error、readonly；列表有 loading、empty、error、partial。

component_acceptance:
  required_states:
    - default
    - loading
    - error
    - disabled
  storybook_required: true

状态不完整的组件，不应该进入公共组件库。

状态验收中最容易被跳过的是过渡态。按钮从 loading 变回 normal 时，文案和图标是否回到正确位置？弹窗关闭动画中用户再次点击是否会重复打开？这些边界不只在文档里写清楚，更要用交互测试覆盖。Storybook 的 play function 或 Testing Library 可以模拟用户操作序列，把状态过渡路径也作为验收的一部分。

三、Props 要表达意图

AI 常生成很多临时 props，例如 isBlue、showBigIcon、useNewStyle。这些名字暴露实现细节，也会让后续维护越来越混乱。组件 props 应该表达业务意图或视觉语义。

<EmptyState
  tone="warning"
  action={{ label: "重新导入", onClick: retry }}
/>

tone 比 yellow 更稳定，因为未来设计 Token 改变时，调用方不需要跟着改。

四、把验收写进自动化

验收清单不能只放在文档里。可以把 Storybook、视觉回归、无障碍扫描、类型检查和单元测试串起来。AI 生成组件后，必须过同一套质量门。

quality_gate:
  type_check: required
  visual_regression: required
  a11y_check: required
  interaction_test: required

还要检查文档。组件用途、参数、状态、反例和迁移说明，都应该随着组件一起生成。没有文档的组件，只是另一个维护负担。

最后，验收要允许拒绝。有些 AI 生成结果适合业务页面，不适合公共组件。把边界守住，组件库才不会变成杂物间。

还要检查组合能力。组件单独展示没问题，不代表放进表单、弹窗、列表、暗色模式和窄屏里也没问题。验收时至少要准备几个组合场景，观察间距、焦点、层级和溢出。

composition_cases:
  inside_modal: true
  inside_form: true
  dark_mode: true
  narrow_container: true
  long_content: true

组件的样式入口也要收口。AI 生成代码容易把 className、style、variant、size 混在一起暴露。公共组件应该明确哪些能配置，哪些由设计系统控制。配置越自由，越容易把一致性打散。

最后，验收记录要留下结论：通过、业务内使用、需要重构、拒绝入库。这样以后回看组件来源时，团队能知道当时为什么做这个判断。

把验收跑进自动化不是一次性配置，需要持续维护验收用例。每新增一类检查（比如暗色模式适配、国际化、焦点管理），都要有对应的测试样本。这些样本本身也可以让 AI 辅助生成：

interface AcceptanceCheck {
  name: string
  description: string
  severity: "blocker" | "warning"
  check: (component: string) => Promise<CheckResult>
}
const checks: AcceptanceCheck[] = [
  {
    name: "typecheck",
    description: "组件代码通过 TypeScript 编译",
    severity: "blocker",
    check: async (code) => {
      const { exitCode, stderr } = await tsc(code, { noEmit: true })
      return { passed: exitCode === 0, detail: stderr }
    },
  },
  {
    name: "a11y_check",
    description: "无障碍扫描无阻断项",
    severity: "blocker",
    check: async (code) => {
      const results = await axe.run(render(code))
      return { passed: results.violations.length === 0, detail: results.violations.map(v => v.id).join(", ") }
    },
  },
]

这段抽验流水线的设计要点是每个检查独立运行，不依赖执行顺序。后期团队如果想加新的检查项（比如检查是否使用设计系统 Token 而非硬编码颜色值），只需要在数组里追加一条规则，不会影响已有检查。实际项目里这样设计后，从“看到问题想加规则”到“规则生效”的时间从几天缩短到了半小时。

五、总结

AI 生成组件验收要覆盖状态、Props、Token、无障碍、测试和文档。

组件能看，不代表能复用。真正可复用的组件，必须经得起下一次需求。

验收条目的执行顺序也很重要。类型检查最快，应该最先跑，阻塞性错误尽早暴露。视觉回归最慢，放在流水线末端。a11y 扫描居中。这样整体反馈时间最短，开发者在提交后几秒就能知道是否通过类型门槛，不需要等完整流水线跑完。

文章版权归作者所有，未经允许请勿转载。

AI 生成组件验收清单：组件能看，不代表能复用