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

重建这个博客的时候，页面方向还不清楚。我让 AI 做了三套完全不同的结构：编辑出版式、文档式、终端式。导航和文章内容尽量对齐，只改整体骨架。并排看完，选了文档式——侧栏适合反复查阅，首页直接进最新文章，也不需要终端风。配色是后来才改的。

如果当时直接说“优化这个页面”，大概会一次性拿到布局、配色、组件和示例数据。页面可能完整，看起来也够精致，然后在正式代码上反复抠“感觉不太对”的地方。三套摊开之后，讨论变成了“侧栏适不适合长期阅读”“要不要做成像终端”，能直接决定。

这里说的原型，选完就可以删。留下来的是比较过的结论，不是那批代码。

后来两回也是这么干的

运营配置页纠结的是另一件事：人围着对象转，还是围着流程转。做了双工作台、主从视图、任务流三个版本，数据和操作对齐，最后才看哪一种更顺手。那次比的是信息架构，不是颜色。

订单工作台更窄。数据、交互都一样，只比展开后的视觉分组：克制分隔、状态色轨、内嵌内容层。有人觉得内嵌层级最清楚，也有人觉得横向空间被吃掉了。那次没有重做整页，只覆盖还没想清楚的那一层。

三次下来，比较容易翻车的地方也差不多。

“重新设计整个后台”没法评审。每个版本会同时改导航、功能、术语、数据和风格，最后只能凭整体印象投票。一次只问一个问题，比如“详情放独立页还是主从面板”“展开内容怎么表现归属”。

三个版本还得共用同一份数据、字段和操作。A 用真实数据、B 用精心编排的示例、C 又少了一半操作，最后选出来的东西说不清是设计赢了，还是内容更完整赢了。写接口还没接上的话，三个版本都只在浏览器内存里模拟写，并标出来。

三种强调色、三种圆角也不算三个方案。有效差异得改变用户理解页面的方式：列表和详情并列、对象和操作分区、按任务阶段推进。两个方案容易被理解成非此即彼，第四个以后比较成本又涨得很快。我后来通常是一个克制的、一个强调关键状态的、再加一个重新组织结构的。

修单个对齐、补一个标准控件，或者设计系统里已有现成做法，就直接改正式页面。技术实现不确定先做技术验证，业务规则不确定先把需求讲清楚。只有好几种界面方向都说得通、光靠讨论分不出高下时，才值得做三个原型。

原型最好从一个入口切换，查询参数或分段控件都可以。切换时尽量保留相同的数据和操作位置。桌面端和窄屏截图也要用一致的视口，避免某个版本只是因为展示条件更有利才看起来更好。

评审时不要只问“喜欢哪一个”。常用任务要看哪些区域，重要状态能不能很快发现，分组归属清不清楚——回到一开始写下的那个问题。选完记下理由，以及丢掉的方案付出了什么代价，正式实现里抠细节时还用得上。

选中了也不要把原型文件搬进生产目录。原型为了比较，可以用局部状态、集中示例和快速切换；正式页面要接真实数据流，处理加载、空状态、失败和权限。硬把前者一点点补成后者，实验脚手架会一起进去。还没选型的时候，正式页面先不动。

还有一件事对运营后台特别容易踩：一个可点击的“发布”按钮哪怕只改本地状态，也可能让人以为正式落地只剩前端。已经实现的查询可以读真实数据；还没接入的写操作做成明确标识的内存交互；没有接口支撑的能力只能做成不可用占位。原型本身也要和生产构建隔开——“用户点不到”和“根本没进生产包”是两件事。

AI 把生成界面变便宜了，但该选哪一种不会自己消失。不确定的东西留在可丢掉的代码里，已经确认的结论再带进生产代码。