大模型驱动的交互原型生成：从需求描述到可交互原型的智能推导

一、原型制作的效率瓶颈：为什么"画原型"比"写代码"还慢

产品设计中，交互原型的制作是连接需求与开发的桥梁。但传统原型工具（Figma、Axure）的操作流程仍然低效：拖拽组件、调整布局、添加交互状态、连接页面跳转——一个中等复杂度的页面原型可能需要 2-4 小时。当需求变更时，原型需要重新调整，时间成本翻倍。

更深层的问题是"原型-代码脱节"——设计师在原型工具中定义的交互逻辑，开发者需要重新理解并翻译为代码。原型中的状态转换、动画效果和边界条件，在翻译过程中容易遗漏或误解。

二、AI 原型生成架构：从自然语言到可交互原型

大模型驱动的原型生成核心思路是：将需求描述（自然语言）转化为结构化的组件树和交互定义，再渲染为可交互的 HTML 原型。

flowchart TD
    A[需求描述<br/>自然语言] --> B[LLM 语义解析]
    B --> C[组件树生成<br/>层级/类型/属性]
    C --> D[交互逻辑推导<br/>状态/事件/跳转]
    D --> E[布局计算<br/>Flexbox/Grid]
    E --> F[样式推导<br/>颜色/字体/间距]
    F --> G[HTML 原型渲染]
    G --> H[可交互原型]

    I[设计系统<br/>组件库/Token] --> C
    I --> F

    J[用户反馈] --> K[迭代优化]
    K --> B

关键设计决策在于组件树的生成精度和交互逻辑的推导准确性。组件树需要匹配设计系统的组件库（如使用 Button 而非 div），交互逻辑需要覆盖状态转换和边界条件。

三、工程实现：需求解析、组件生成与交互推导

3.1 需求语义解析

interface ParsedRequirement {
  pages: PageSpec[];
  globalNavigation: NavigationSpec;
  designSystem: string;
}

interface PageSpec {
  name: string;
  sections: SectionSpec[];
  interactions: InteractionSpec[];
}

interface SectionSpec {
  type: 'hero' | 'form' | 'list' | 'detail' | 'dashboard';
  components: ComponentSpec[];
  layout: 'stack' | 'grid' | 'flex';
}

class RequirementParser {
  private llmClient: LLMClient;

  async parse(requirement: string): Promise<ParsedRequirement> {
    const prompt = `解析以下产品需求，生成结构化的页面规格。

需求描述：
${requirement}

请输出 JSON 格式，包含：
1. pages: 页面列表，每个页面包含 sections 和 interactions
2. globalNavigation: 全局导航结构
3. 每个 section 包含 type、components 和 layout

组件类型限定为：Button, Input, Select, Card, Table, Modal, Toast, Tabs, Avatar, Badge
布局类型限定为：stack（垂直堆叠）, grid（网格）, flex（弹性）`;

    const response = await this.llmClient.chat(prompt);
    return JSON.parse(response);
  }
}

3.2 组件树与样式生成

class PrototypeRenderer {
  private designSystem: DesignSystem;

  render(spec: ParsedRequirement): string {
    const html: string[] = [];

    // 生成全局样式
    html.push(this.renderGlobalStyles());

    // 生成导航
    html.push(this.renderNavigation(spec.globalNavigation));

    // 生成各页面
    for (const page of spec.pages) {
      html.push(this.renderPage(page));
    }

    // 生成交互脚本
    html.push(this.renderInteractions(spec));

    return this.wrapInDocument(html.join('\n'));
  }

  private renderPage(page: PageSpec): string {
    const sections = page.sections.map(s =>
      this.renderSection(s)
    ).join('\n');

    return `<section id="page-${page.name}" class="page">
  ${sections}
</section>`;
  }

  private renderSection(section: SectionSpec): string {
    const layoutClass = {
      stack: 'flex flex-col gap-4',
      grid: 'grid grid-cols-3 gap-4',
      flex: 'flex flex-row gap-4 flex-wrap',
    }[section.layout];

    const components = section.components.map(c =>
      this.renderComponent(c)
    ).join('\n');

    return `<div class="${layoutClass}">
  ${components}
</div>`;
  }

  private renderComponent(spec: ComponentSpec): string {
    // 根据设计系统的组件定义渲染
    const token = this.designSystem.getComponent(spec.type);
    const styles = this.resolveStyles(token, spec.props);

    switch (spec.type) {
      case 'Button':
        return `<button class="${styles.classes}"
          style="${styles.inline}"
          data-action="${spec.action || ''}">
  ${spec.label || 'Button'}
</button>`;
      case 'Input':
        return `<div class="${styles.wrapper}">
  <label class="${styles.label}">${spec.label || ''}</label>
  <input type="${spec.inputType || 'text'}"
    class="${styles.classes}"
    placeholder="${spec.placeholder || ''}" />
</div>`;
      // ... 其他组件类型
      default:
        return `<div class="${styles.classes}">${spec.label || ''}</div>`;
    }
  }
}

3.3 交互逻辑推导

class InteractionEngine {
  private spec: ParsedRequirement;

  renderInteractions(): string {
    const scripts: string[] = [];

    for (const page of this.spec.pages) {
      for (const interaction of page.interactions) {
        scripts.push(this.renderInteraction(interaction));
      }
    }

    return `<script>
document.addEventListener('DOMContentLoaded', () => {
  ${scripts.join('\n  ')}
});
</script>`;
  }

  private renderInteraction(interaction: InteractionSpec): string {
    switch (interaction.type) {
      case 'navigate':
        return `document.querySelector('[data-action="${interaction.trigger}"]')
  ?.addEventListener('click', () => {
    document.querySelectorAll('.page').forEach(p =>
      p.classList.add('hidden'));
    document.getElementById('page-${interaction.target}')
      ?.classList.remove('hidden');
  });`;

      case 'submit':
        return `document.querySelector('[data-action="${interaction.trigger}"]')
  ?.addEventListener('click', (e) => {
    e.preventDefault();
    const form = e.target.closest('form');
    if (form?.checkValidity()) {
      // 显示成功状态
      showToast('${interaction.successMessage || "提交成功"}');
    }
  });`;

      case 'toggle':
        return `document.querySelector('[data-action="${interaction.trigger}"]')
  ?.addEventListener('click', () => {
    const target = document.getElementById('${interaction.target}');
    target?.classList.toggle('hidden');
  });`;

      default:
        return '';
    }
  }
}

四、AI 原型生成的精度边界与设计失真

组件语义的歧义：需求描述中的"表格"可能指数据表格、价格对比表或特性列表，LLM 需要根据上下文推断具体类型。推断错误会导致生成的组件与预期不符。缓解方案是在需求描述中提供更具体的组件类型标注。

布局的审美缺失：LLM 生成的布局通常是功能正确的，但缺乏设计感——间距不均匀、视觉层级不清晰、留白不足。这是因为 LLM 缺乏视觉审美能力，只能基于规则生成布局。需要结合设计系统的 Token 和布局规则做后处理优化。

交互逻辑的不完整性：需求描述通常只覆盖"正常流程"，忽略异常流程和边界条件（如表单验证失败、网络错误、空数据状态）。LLM 可以补充常见的边界条件，但无法覆盖所有场景。生成的原型需要人工审核交互逻辑的完整性。

响应式适配的局限：生成的原型通常只考虑桌面端布局，移动端适配需要额外的断点定义和布局调整。LLM 可以生成基本的响应式代码（如 @media 查询），但精细的移动端体验仍需设计师调整。

五、总结

AI 驱动原型生成的本质是将"手工画原型"转化为"需求语义解析 + 组件推导 + 交互生成"的自动化管线。本文方案的核心链路为：自然语言需求解析 → 组件树生成 → 布局与样式推导 → 交互逻辑生成 → 可交互原型渲染。落地时需重点关注三个参数：组件库覆盖率（建议 90% 以上）、交互逻辑完整度（建议覆盖正常流程 + 常见异常）、原型保真度（建议达到视觉稿的 70%）。建议从简单页面（登录、注册、列表）开始验证，逐步扩展到复杂页面（仪表盘、表单流程），并将生成结果视为"初稿"而非终稿。