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

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

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

产品设计中，交互原型的制作是连接需求与开发的桥梁。但传统原型工具（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}" >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%）。建议从简单页面（登录、注册、列表）开始验证，逐步扩展到复杂页面（仪表盘、表单流程），并将生成结果视为"初稿"而非终稿。