为什么直接把 PRD 丢给 AI，生成的原型通常又丑又残？
第二天下午，我让不同小组拿同一份 PRD 直接生成原型。结果非常有代表性：有的页面缺功能，有的把 HTML 源码直接展示出来，有的结构勉强完整但视觉完全不可用。
问题不只是“模型审美差”，而是 PRD 并没有回答生成原型所需的全部问题。
PRD 为什么不能直接决定原型
PRD 主要描述用户、流程、功能和规则。生成原型还需要额外决策：
- 使用 HTML、React 还是现有前端工程？
- 这次覆盖 C 端、B 端还是全部页面？
- 原型是低保真流程验证，还是接近产品的高保真版本？
- 设计风格、色彩、组件密度和目标设备是什么？
- 多个模块如何共享导航、状态和设计规范？
- 生成后用什么方式验证页面确实可用？
如果这些问题没有答案，AI 只能在执行中自行选择。每一次选择都可能合理，但组合起来未必符合你的预期。
三种生成方式的差别
第一种是直接生成。它适合一次性、小范围 Demo，速度快，但功能完整性和视觉稳定性最不可控。
第二种是 Plan 后生成。AI 先澄清技术栈、页面范围、保真度和交付方式，再输出任务清单。它会慢一些，却能在写代码前暴露分歧。
第三种是按模块并行。将 C 端、管理后台或不同业务模块交给独立上下文生成，再由主任务统一导航、设计规范和数据。它能降低单个上下文压力，但拆分边界和最终整合必须经过人工设计。
不是子 Agent 越多越好。页面强耦合、共享状态复杂时，盲目并行会制造更多合并问题。
先做风格 Demo，再生成全量页面
我在课堂里最推荐的一步，是不要一上来生成二十个页面。
先选择一个信息密度较高的代表页面，让 AI 分别生成三到五个风格 Demo。B 端可以比较简洁数据风、深色技术风和高密度运营风；C 端可以比较生活方式、轻量电商和极简产品风。
选中方向后，再把颜色、字体、间距、组件、圆角、阴影和交互规则整理成设计规范，作为后续页面的共同上下文。
这一步用很小成本解决了最昂贵的问题：大家脑中“好看”的定义并不一样。
原型生成也需要工程边界
为了避免上下文和文件互相污染，建议：
- 为原型建立独立工程目录。
- 放入确认过的 PRD 和设计规范。
- 明确页面清单、路由和共享布局。
- 按业务模块拆任务，不按文件数量机械拆分。
- 每完成一个模块就启动真实页面检查。
- 最后统一导航、响应式和视觉细节。
不要在同一对话里先生成一个风格、又推翻重做另一个风格，最后再让 AI 猜哪部分需要保留。方向变化时，新开任务或回退到干净版本更安全。
原型完成的标准不是“生成结束”
至少要验证：
- 所有计划页面都能打开。
- 核心按钮和页面跳转可用。
- 表单具有必要校验和反馈。
- 列表、详情、空状态和错误状态合理。
- 桌面端与移动端没有明显溢出。
- 页面使用同一套导航和设计规范。
- 主流程可以从头走到尾。
可以使用浏览器自动化工具逐页打开、点击和截图，但测试目标仍然来自产品流程，而不是让工具随意浏览。
讲师判断：原型生成要像搭积木，而不是开盲盒
直接生成完整项目时，任何一次理解偏差都会扩散到多个页面。更稳妥的节奏是先做导航与布局骨架，再做一个代表性页面，确认设计语言和组件规则后逐块扩展。每完成一块就运行、截图、走主流程，并把确认过的模式沉淀为组件，而不是让 AI 在下一页重新设计。
我还会要求学生保留三次关键截图：风格样板、主流程完成、响应式验收。它们不只是展示材料，也是后续修改的视觉基线。出现偏差时，能够明确指出“与哪一版、哪一区域不一致”，AI 才有机会做局部、可控的修正。
最后要把生成顺序写进计划：先完成公共组件和一条主流程，再补异常状态与次要页面，最后统一视觉和响应式。每一阶段都有明确出口，任何阶段失败都能停在一个仍可运行的版本。这样做看似比“一次生成全部”慢，实际却减少了最昂贵的整站返工。
课后练习
选择同一份 PRD 做三轮实验：直接生成、Plan 后生成、先做风格 Demo 再生成。记录耗时、缺失功能、视觉返工次数和可通过的主流程数量。比较结果时，不要只看第一眼效果，而要看最终达到可评审状态的总成本。