界面能被实时生成以后，原型里最不能交出去的是异常情况

9 月 1 日 Runway 发了 Solaris，说是第一个界面世界模型，能实时生成操作系统级的交互界面。演示视频我看了：你在用的时候，界面在被生成。

我出页面初稿，已经是让 AI 生成

其实在我自己的工作里，页面已经在被生成了。

现在出一个页面的初稿，我让 AI 直接生成，一般用 Claude：说清楚这个页面要做什么，有哪些信息，主要操作是什么，它出一版能点的页面，我在上面改。以前这一步是画原型，现在是改生成出来的页面。用 Claude 生成页面，最省事的是正常流程那一段，说清楚要什么，页面基本就出来了；花时间的，是我在生成出来的页面上，一个个补异常状态。

所以 Solaris 让我意外的，不是界面能被生成，是它能实时生成：不是先生成一版再用，而是用的时候在生成。

收参数那次，原型改了很多版

回想 Smart Photo 收参数那次，原型改了很多版。

一开始参数全露着，后来收进后台，只留场景和风格。中间来来回回，有的版本收得太多，有的收得太少。每一版都要画，要评审，要找运营看。

那些版本里，花力气的不只是页面长什么样，还有每一种情况下页面该怎么反应。

离能用有多远，说不好

看完 Solaris 的演示，要说它离实际能用有多远，我说不好。

演示里的界面很流畅，生成得很快，看起来已经能用了。可演示走的都是顺的路。它离能用多远，要看它在不顺的路上怎么表现，而这正是演示里看不到的部分。

我说不好，不是客气，是真没有依据。这也不是在唱衰它，只是一个做过内部工具的人的习惯：先问出错的时候怎么办。

最不能交出去的，是异常情况

所以如果界面能被实时生成，原型里我最不能交出去的，是异常情况怎么处理。

正常流程，生成得出来。上传一张图，选一个场景，点生成，出结果，这条路很好生成，演示里走的也几乎都是这条路。

异常情况不一样。图片格式不对怎么办，生成失败怎么提示，排队太久要不要让人先去做别的，出来的几张都不能用，下一步引导去哪。每一种都是一个判断，而且和业务、和用户的习惯绑在一起。生成模型不知道我们的运营在失败以后最想看到什么。

Smart Photo 那很多版原型里，有不少改动就是在改这些。

印象最深的异常：出来的图都不能用

Smart Photo 的界面里，我印象最深的一个异常，是出来的图都不能用。

不是报错，不是失败，生成成功了，几张图都出来了，可一张都不能用。商品变了形，或者场景完全不对。

这种情况最难设计。系统觉得自己做完了，用户却什么都没拿到。页面上如果只有一个重新生成的按钮，用户会一直点，一直失望。

我们最后的处理，是引导用户去换模板或者换图。出来的都不能用，多半不是运气不好，是这张图和这个模板合不来。与其让人一遍遍重试，不如告诉用户换一个起点。

这个引导看起来很小，只是一句话和两个按钮。但它背后，是我们对哪些图和哪些模板合不来的理解，攒了很久。

这个异常，生成模型不知道怎么处理

出来的图都不能用，这个异常为什么不能交给生成？

因为判断图能不能用的，不是系统，是运营。系统只知道任务成功了；运营看了一眼，知道这批不行。界面要在这个时刻给出引导，就得先知道运营心里那个不行是什么意思，再知道不行的时候，换什么最可能行。

这两层知识，都在我们做 Smart Photo 的过程里，不在任何一个通用的界面模型里。它能生成一个出错提示，生成不出去换模板或者换图这个判断。界面可以被生成，经验不行。

原型会变成什么

所以界面被生成以后，我觉得产品经理的原型会变成一份清单：正常的路交给生成，异常的每一种情况怎么处理，写清楚。清单里第一条，大概就是出来的都不能用的时候，页面告诉用户什么、引导去哪。

长什么样可以交出去。出了问题以后怎么办，还是我们的，至少现在是。这一点，演示里看不出来，做过的人才知道。