AI 组件生成回放：每次提示词升级，都要让历史页面再跑一遍

一、生成效果不能只看这一次

AI 组件生成工具最容易在演示阶段显得很顺。输入需求，输出组件，截图看起来也不错。但真正接入前端工程后，提示词、组件模板、设计 Token 和模型版本都会变化。某次升级让新页面更好，也可能让旧需求生成结果退化。

因此，组件生成要有回放机制。把历史需求、输入 Schema、设计 Token 版本和期望行为保存下来。每次生成策略升级，都让历史样本重新跑一遍。只有这样，才能知道改动是整体进步，还是只优化了当前几个案例。

二、回放样本要保存完整上下文

flowchart TD
  A[历史生成需求] --> B[Prompt 版本]
  A --> C[Token 版本]
  A --> D[组件模板]
  B --> E[重新生成]
  C --> E
  D --> E
  E --> F[质量对比]

只保存自然语言需求不够。组件生成依赖很多上下文：设计系统版本、可用组件列表、输入数据结构、目标框架、无障碍规则。如果这些缺失，回放结果无法和历史结果公平比较。

回放样本还要覆盖失败案例。只保存生成成功的页面，会让评测过于乐观。那些曾经生成出错、样式溢出、状态缺失的案例，才最能证明新策略是否变稳。

三、评测要结构化

type ReplayCase = {
  id: string
  promptVersion: string
  tokenVersion: string
  expectedStates: string[]
  expectedA11y: boolean
}
type ReplayResult = {
  typecheck: boolean
  visualDiff: number
  missingStates: string[]
  a11yErrors: number
}

生成结果应经过类型检查、单元测试、视觉回归和无障碍检查。不要只用人工看截图。结构化结果可以做趋势统计，比如某次提示词升级后，缺失 loading 状态的比例是否下降。

replay_gate:
  typecheck: required
  a11y_errors: 0
  max_visual_diff: 0.03

门禁要分级。类型错误和无障碍硬错误应阻塞；轻微视觉差异可以进入人工复核。所有问题都阻塞，会让工具难以迭代；所有问题都放行，又没有质量意义。

回放跑起来后，还要把结果落库关联。每条回放记录应带上样本 ID、生成策略版本、各检查项得分和通过状态，方便后续做趋势对比。实际项目里可以建一张 replay_run 表，存每次跑的元信息，再把每条回放结果挂上去。这样一来，某次提示词升级后 typecheck 通过率从 78% 涨到 92%，就能直接用数据说话，而不是凭印象判断。

async function runReplay(case: ReplayCase): Promise<ReplayResult> {
  const code = await aiGen.generate(case.requirement, {
    promptVersion: case.promptVersion,
    tokenVersion: case.tokenVersion,
  })
  const typecheck = await tscCheck(code)
  if (!typecheck) return { typecheck: false, visualDiff: 1, missingStates: [], a11yErrors: 0 }
  const visualDiff = await compareScreenshot(case.id, code)
  const states = await validateStates(code, case.expectedStates)
  const a11y = await runA11yScan(code)
  return {
    typecheck: true,
    visualDiff,
    missingStates: states.missing,
    a11yErrors: a11y.errors.length,
  }
}

这里的 visualDiff 不能只对比整体截图，最好按区域做 diff，否则文案长度变化导致的整体偏移会淹没真正的布局错误。实际踩过的坑是：只比较全页面截图，一行文案从小标题变成多行，视觉差异直接飚到 0.1 以上，但用户实际看不到任何问题。把 diff 拆到组件级别后，这种噪音就自然消失了。

四、差异要能解释

回放发现差异后，要知道差异来自哪里。是模型变了、提示词变了、Token 变了，还是模板变了。生成系统应把这些版本写进结果元数据。

还要避免过拟合回放集。历史样本能防退化，但不能代表全部未来需求。可以保留一部分隐藏样本，只在发布前跑，减少“为了过回放而调提示词”的风险。

实际落地时，可以把差异拆成三类：阻塞差异、人工复核差异和可接受差异。阻塞差异包括类型错误、关键交互缺失、表单无法提交；人工复核差异包括轻微布局变化、文案顺序变化；可接受差异则是组件内部结构调整但用户行为不变。分类越清楚，回放系统越不会变成“任何变化都报警”的噪音源。

type DiffLevel = "blocker" | "review" | "accepted"
type DiffItem = {
  caseId: string
  level: DiffLevel
  reason: string
  owner: "prompt" | "token" | "template" | "model"
}

还要把回放结果接入发布节奏。日常开发可以跑小样本，合并前跑核心样本，正式发布前跑全量样本。这样既能控制耗时，也能在关键节点保住质量底线。

五、总结

AI 组件生成回放要保存历史需求、Prompt 版本、Token 版本、组件模板和期望行为，并用类型、视觉、状态和无障碍检查做质量门禁。

生成工具不是这一次能生成就够了。每次升级都能让历史页面稳定通过，才说明它适合进入工程链路。

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

AI 组件生成回放：每次提示词升级，都要让历史页面再跑一遍