AI 生成界面为何总漏掉异常状态

只要让 Claude 生成一个界面，你得到的往往是它状态最好时的样子：内容满满，没有任何加载，没有任何失败，权限已经授予，网络一切正常。它更像是产品出现在案例研究中的样子，而不是它在某个普通星期二真实呈现的样子。

人们通常把这归结为模型的局限。但我认为，问题其实要具体得多，而弄清这种具体性非常有用。

它学习的是作品集

公开可见的界面图片，几乎全都是营销图片。Landing Page 上的界面、案例研究里的界面、设计作品展示平台上的界面——全都经过精心挑选，内容充实，展示的都是最佳状态。

几乎没有人会发布空状态。也没有人会把错误界面放进自己的作品集。因此，当模型被要求生成“一个预订界面”时，它会生成自己见过上万次的那个版本，也就是一切顺利时的版本。

这并不是模型失效了。它只是在准确返回自己曾经见过的内容。缺口不在于它的能力，而在于这个世界究竟愿意拍下并展示什么。

界面数量是最容易误导所有人的数字

以一个预订产品为例：68 项功能，MVP 包含其中 44 项，7 条流程，28 个主要界面。

28 个界面听起来像是一个小项目。但最终的画板数量却高出了好几倍，因为一个界面只有具备完整的状态才算真正完成——加载、空状态、错误、权限、离线，以及这个特定产品实际可能让用户遇到的其他任何情况。

这个倍数正是项目估算失效的地方。团队按照 28 个界面报价，生成了 28 个界面，觉得进度已经提前；然后却在项目后半程发现，每个界面还有三个或四个从未被计入的“兄弟界面”。工作量并没有变化，只是直到很晚、在最糟糕的时刻才被发现。

状态是披着视觉外衣的产品决策

这是我最想强调的部分。

空状态并不是简单地把界面中的内容移除。它需要回答一个问题：这个人在这里还没有任何内容——是因为他刚刚开始使用，因为筛选条件排除了所有内容，还是因为发生了错误？这是三种不同的情况，需要三种不同的提示信息、三种不同的操作，而其中只有一种适合显示“添加你的第一个项目”。

错误状态也不只是一个红色方框。它背后是一系列决策：用户能否从错误中恢复，已经输入的内容会不会丢失，错误是不是由用户造成的，以及告诉用户具体的技术原因究竟能提供帮助，还是只会让他们感到害怕。

模型可以逼真地生成其中任何一种状态。但它无法判断你实际面对的是哪种情况，因为 brief 中从未提供过这些信息——而且它也不会停下来询问。它会选择最常见的情况，然后把它精美地呈现出来。

所以，状态要在生成之前命名，而不是之后

在界面清单中，每个界面都应该附带它所需的状态；而且这些状态应该在你还记得这个界面为何存在时就确定下来。

事后再补状态会导致一种非常具体的失败模式，我已经见过好几次：状态被当作已完成界面的视觉变体添加，因此直接继承原界面的布局。最终，你会得到一个空状态界面：上面有一个什么也控制不了的筛选栏，还有一个下方没有任何数据行的表头。从技术上讲，它确实是空状态。但从产品角度看，它完全不合理。

提前做出决定，还能暴露出那些原本就应该在 brief 中提出的问题。在所有没有被记录下来的状态中，有一半是因为答案确实未知，而这恰恰是最值得尽早展开的讨论。

组件也是如此

如果一个组件只在某个界面中出现过一次，模型就只会为它建模一种状态，因为现有证据只有这些。

但一个输入框会有聚焦、已填写、禁用、错误和只读状态。一个按钮会有按下、禁用和加载状态。复选框还有不确定状态，只要有人实现批量选择，它就一定会出现。如果组件库只包含界面中碰巧展示过的状态，那么缺失的状态就只能由第一个遇到它的人临时发挥——通常是一名开发者，通常面临着时间压力，也通常会在三个地方做出三种不同的实现。

所以，我遵循的规则是：你不必构建每一种组件原型，但只要决定构建某个组件，就要为它提供完整的状态矩阵，无论当前是否已经有界面需要这些状态。

为什么这值得投入精力

因为状态才是产品真正与用户相遇的地方。没有人对产品的真实体验会是那张营销截图。真实体验是搜索没有返回任何结果的那一天，是支付失败的那一天，也是用户在火车上打开产品的那一天。

精美的界面是用来展示的，而各种状态才是真正被使用的。

这并不能解决什么

你可能会把状态定义得过于细致。我曾经为一些界面构建了完整的状态覆盖，结果这些界面后来被从产品中删掉了。这不仅意味着昂贵的工作被白白浪费，更糟糕的是，在所有目睹这一过程的人眼中，状态清单会变成一种官僚主义流程。

对于究竟应该做到什么程度，也不存在一条明确的规则。离线行为对现场作业工具至关重要，但对于内部 Dashboard 来说几乎无关紧要。而我所知道的唯一判断方法，就是认真思考使用者是谁，以及他们会在什么地方使用产品。这又会把你带回整个流程的起点，而真正的答案通常就在那里。

在一个真实项目中记录完整流程

我用一个项目完整记录了端到端的全过程——brief、结构与流程、生成的界面、锁定的 token 系统、在 Figma 中使用真实的组件和变量、可点击的原型，以及开发交付——其中也包括出现问题和崩坏的部分：

Claude AI UI/UX：从 Brief 到 Figma 的完整工作流——在一个真实项目中走完同样的路径，从 brief 一直到 Figma 交付。

如果你曾经被某个大多数清单都会遗漏的状态坑过，我很想知道它是什么。对我来说，那个状态是权限。

如果需要采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。