先做三个原型，再写正式页面：AI 前端实现的多原型工作流

让 AI 多写两份最终不会上线的前端代码，看起来是在增加工作量。最近几次实践却反复得到相反的结果：当页面的主要问题不是“能不能实现”，而是“应该长什么样、怎样组织信息”时，先做三个可丢弃的原型，往往比直接修改正式页面更快接近正确方向。

这里的原型不是正式实现的简化版，也不是等待补全的半成品。它是一项有意隔离的设计实验：用足够真实的内容和交互暴露方案差异，完成选择后便可以删除。它的产出不是一批值得保留的代码，而是一组已经被比较过的设计结论。

这套工作流尤其适合 AI 编程。模型生成界面的速度很快，同一组约束可以在短时间内展开为多种结构；人的优势则在于结合实际使用场景判断哪种结构更清楚、更顺手。把两者放在合适的位置，AI 负责扩大可选空间，人负责收敛方向，正式实现才开始承担长期维护成本。

单方案会过早锁死问题

直接要求 AI “优化这个页面”，通常会一次性得到布局、配色、组件、交互和示例数据。页面可能完整，也可能看起来足够精致，但此时很难判断结果究竟是最合适的方案，还是模型在没有比较基准时给出的第一个自洽答案。

前端设计中的多个变量也会纠缠在一起。信息应该按对象分组，还是按任务阶段分组？状态应该依靠颜色突出，还是依靠空间层级表达？窄屏时应压缩信息，还是切换交互方式？当这些问题被塞进一次生成，评审很容易退化成“感觉不太对”，随后在正式代码上反复调整局部样式。

多原型的价值不只是多几个选项，而是把模糊的不满意改造成可指认的差异。看到并排的方案以后，讨论可以变成：“主从结构更容易定位当前对象，但任务流更适合连续操作”“内嵌内容层级最清楚，但牺牲了横向空间”。这类判断能够直接指导实现，而不是继续要求 AI 猜测“再好看一点”是什么意思。

把原型当成受控实验

三个原型只有在可比较时才有意义。最重要的原则是固定业务变量，只改变当前需要决定的设计变量。

如果 A 使用真实数据，B 使用精心编排的示例，C 又减少了一半操作，那么最终选择混合了数据质量、功能范围和视觉结构，无法说明哪种设计更好。相反，三个版本共用同一份数据、字段、操作和边界，只改变分组、导航或视觉层级，差异才会清晰。

近期的三个匿名案例呈现了这种方法在不同页面上的用法：

场景	被比较的方案	真正需要回答的问题
个人技术博客	编辑出版式、文档式、终端式	哪种整体结构最适合长期阅读，而不是哪种配色
运营配置页面	双工作台、主从视图、任务流	操作者应围绕对象浏览，还是围绕流程连续处理
订单工作台	克制分隔、状态色轨、内嵌内容层	如何表达分组归属，同时保留足够的内容宽度

前两个案例比较的是页面信息架构，第三个案例则更窄：数据和交互完全一致，只比较展开后的视觉分组。原型不必每次重做整页；它应该覆盖尚未形成结论的那一层问题。

六步完成一次多原型选型

第一步：先检查真实系统

在画新页面之前，先读现有页面、组件约定、接口和权限边界。原型可以是一次性的，但它不能建立在错误的业务理解上。现有设计系统能够复用什么、哪些字段真实存在、哪些操作需要权限、正式页面受哪些布局约束，都应该在生成方案前确认。

这一步也用于区分设计问题和功能问题。如果真正缺少的是后端能力，三个漂亮页面不会让能力自动出现；如果数据和操作已经完整，只是使用体验混乱，才适合进入视觉原型阶段。

第二步：只定义一个决策问题

一次原型探索应有明确问题，例如“详情放在独立页面还是主从面板”“展开内容如何表现归属”“全局导航采用哪种结构”。问题越具体，三个方案越容易形成有意义的差异。

“重新设计整个后台”不是一个可评审的问题。它会让每个版本同时改变导航、功能、术语、数据和风格，最后只能凭整体印象投票。大问题应拆成多轮原型，每轮只消除一类不确定性。

第三步：写下不可变化的部分

把三个版本必须共享的内容列成约束：相同的数据集、功能入口、字段语义、核心交互、响应式范围和业务状态。若原型读取现有接口，应让三个版本消费相同结果；若写接口尚未接入，三个版本都只在浏览器内存中模拟写操作，并明确标记其性质。

固定项不是越多越好。它们的作用是排除干扰，让评审集中在本轮问题。若下一轮需要比较交互模型，再重新定义那一轮的固定项和变量。

第四步：生成结构上不同的三个方案

三种强调色、三种圆角或三种阴影不构成三个方案。有效差异应该改变用户理解页面的方式，例如列表与详情并列、对象与操作分区、按任务阶段推进，或者通过不同层级表达父子关系。

三个通常是合适的数量：两个方案容易被理解成非此即彼，第四个以后比较成本又会快速上升。它们也不需要平均分配创新程度，可以包含一个克制方案、一个强调关键状态的方案，以及一个重新组织信息结构的方案。

第五步：让差异可以并排评审

原型应通过同一入口切换，查询参数、分段控件或键盘操作都可以。切换时尽量保留相同的数据和操作位置，让评审者快速建立对应关系。桌面端与窄屏截图应使用一致的视口和内容状态，避免某个版本因为展示条件更有利而胜出。

评审时不要只问“喜欢哪一个”，而要回到最初的决策问题：完成常用任务需要看哪些区域，重要状态能否被快速发现，分组归属是否清楚，信息密度是否适合重复操作。选择结果还应记录理由以及被舍弃方案的代价，因为正式实现中的细节取舍仍会用到这些判断。

第六步：依据结论重写正式页面

选中原型不等于把原型文件搬进生产目录。正式实现应重新回到项目的组件、状态管理、权限、错误处理和测试约定，只提取已经确认的信息结构与交互结论。

这种重写看似重复，实际上维持了两种代码不同的职责。原型为了比较而优化，可以使用局部状态、集中示例和快速切换；正式页面为了维护而优化，需要接入真实数据流，处理加载、空状态、失败和权限，并符合长期演进的模块边界。强行把前者逐步修补成后者，通常会把实验脚手架一起带进生产代码。

原型也需要能力边界

原型可以展示未来入口，但不能让评审者误以为功能已经存在。对已经实现的查询能力，可以读取真实数据；对尚未接入的写操作，可以使用明确标识的内存交互；对没有接口和数据模型支撑的能力，只能展示为不可用占位。

这条边界对运营后台尤其重要。一个可点击的“发布”按钮即使只修改本地状态，也可能让人误判正式落地只剩前端工作。把占位、演示数据和真实数据区分清楚，原型才能帮助规划阶段，而不是制造新的需求误解。

开发原型还应与生产构建隔离。它可以位于独立目录或仅开发环境可达的入口，但正式构建需要检查相关路由、组件名和代码块没有进入产物。原型“不会被用户点到”和“根本没有进入生产包”是两个不同的保证。

常见的失败方式

三个方案只有表面差异。 如果布局和信息流完全相同，只改变颜色、间距和装饰，评审仍然没有获得真正的选择。先要求每个方案用一句话说明结构假设，无法说明差异的版本应被重做。

没有控制比较变量。 不同方案使用不同数据量、文案或功能，容易让内容更完整的版本占优势。共用数据源和交互模型，是视觉比较成立的前提。

用原型伪造尚不存在的能力。 演示可以探索未来，但必须让不可用状态保持可见。否则选中的不只是界面，还包含一组未经确认的产品与后端承诺。

还没有选型就修改正式页面。 这会同时维护实验代码和生产代码，也会让一次探索提前背上兼容、权限和测试成本。没有形成选择时，让正式页面保持不变本身就是正确结果。

选择以后直接复制原型。 原型验证的是方向，不证明异常处理、响应式细节、无障碍、权限和构建隔离已经达到生产标准。正式落地仍需完成完整验证。

什么时候不需要三个原型

多原型适合方向性不确定且视觉结果难以通过文字确认的任务。新产品首屏、复杂运营工作台、信息层级调整和响应式结构变化，通常值得先比较。需求已经明确、设计系统已有稳定范式、只需修复单个对齐或补充标准控件时，直接修改正式实现更合适。

判断标准不是页面大小，而是不确定性的类型。技术实现不确定，应先做技术验证；业务规则不确定，应先明确需求；只有多个合理的界面方向难以仅靠讨论取舍时，才需要多原型。

先选择方向，再承担实现成本

AI 降低了生成界面的成本，却没有自动消除设计决策。若把第一次生成直接当成答案，节省下来的编码时间很容易在后续的局部返工中重新付出。多原型工作流利用的正是生成成本下降：在生产约束介入之前，主动扩大一次选择空间。

三个原型不保证得到完美页面。它们提供的是更清楚的比较对象、更具体的评审语言，以及一份能指导正式实现的选择记录。把不确定性留在可丢弃代码中，把已经确认的结论带进生产代码，AI 才真正提高了前端实现的质量，而不只是提高了首次生成的速度。