加载、空、错误：最能看出产品教养的三张界面

加载态、空态、错误态不是边角情况，而是用户最常遇到的三种界面：网慢时是加载态，新账号时是空态，出问题时是错误态。很多 vibe 项目花几周打磨“一切正常”的界面，却把这三种状态交给默认实现：白屏、转个不停的圈、或者一串原始报错。本指南逐个讲这三种状态怎么做，附上可以直接抄的文案和上线前能跑一遍的验收清单。

先定一条贯穿三种状态的原则：永远不要让用户猜。加载态要回答“是不是在跑、要不要等”；空态要回答“是真的没有，还是出了问题”；错误态要回答“坏了什么、丢了什么、怎么回去”。如果某个状态这三个问题一个都回答不了，那它不是设计，而是设计的缺席。

加载态：给进度，不要给耐心测试

加载态的第一条规则讲的是时长，而不是动画。如果加载在约 300 毫秒内就能完成，什么都不要显示；一闪而过的转圈看起来像故障，不像反馈。300 毫秒到几秒之间，用骨架屏：按即将出现的内容形状画灰块，文字行画成灰条、图片位置留出方块。骨架屏管用，是因为它先把布局预期定下来，真实内容到来时页面不会跳动。超过几秒，就不能只靠骨架屏了：要给进度指示、取消选项，或者至少一句诚实的话，说明到底在等什么。

vibe 项目里最常见的两个加载错误，值得点名。第一是整页白屏加居中转圈：它既不告诉用户在加载什么，又把本可以用的导航也遮住了。正确做法是局部加载：保留页面框架、导航和已经加载好的部分，只加载缺失的那一块。第二是假进度条：爬到 90% 就卡住不动的那种。用户一个会话就能学会不信它，而这种不信任会转移到产品说的其他话上。测不出真实进度时，就诚实地用不定态指示，并用一句话说明在做什么：“正在拉取你的项目”永远比一个沉默的转圈强。

分页与列表还有一条单独的规则：加载更多时，在列表末尾追加骨架行，而不是把整个列表换成转圈。筛选条件变化时，等新请求开始返回再清空旧结果，或者至少标明列表正在刷新；用户改了筛选条件后还闪一下旧数据，是最容易让人点错条目的情况。

空态：先分清四种“没有”

“空”这个字底下藏着四种完全不同的情况，每种需要的界面都不一样。第一是真的没有：新用户还没有创建任何内容。第二是筛空了：用户搜了、筛了，没有匹配项。第三是加载失败装成空：请求悄悄失败了，界面看起来像一张空列表。第四是没有权限：东西存在，但当前用户看不到。把四种情况都画成同一张“暂无数据”插画，用户要么困惑，要么更糟——以为自己的数据丢了，其实只是被筛掉了。

一张好的空态界面有三部分：用大白话说明现状、有原因就说原因、给一个下一步动作。新用户的情况，下一步是创建：“你还没有创建项目”加一个“创建第一个项目”按钮，最好再加一句说明项目是用来做什么的。筛空的情况，下一步是调整：“没有匹配‘发票’的项目”加“清除筛选条件”，并建议换一个更宽泛的词。权限不足的情况，要直接说出来：“你没有权限查看这个工作区的项目”，并告诉用户去找谁，而不是假装什么都不存在。永远不要用空态来上一堂功能介绍课，也永远不要留下一个没有下一步动作的空态：没有出路的空屏，就是一张画得好看的死胡同。

还有一个空态的语气陷阱：在“还没有订单”的屏幕上放一张大大的庆祝插画。对一个等第一单的卖家来说，这读起来像风凉话。语气要跟情况匹配：新用户的空态可以带点鼓励，筛空的空态应该中性、 helpful，与错误有关的空态不应该庆祝任何东西。

错误态：说清坏了什么，保住用户填的东西，给一条回去的路

错误态最重要的一条，排在所有文案之前：不要让用户丢工作。表单提交失败时，保留用户填过的所有字段，把错误显示在失败的操作旁边，让用户不用重填就能重试。一张长表单因为一次网络波动就清空，是用户会记住、并且会讲给别人听的体验。字段稍多的表单就做自动保存草稿；短暂的网络失败先自动重试一次，实在不行再把错误亮出来。

错误文案按一个固定结构写：发生了什么（大白话）、对用户意味着什么、下一步做什么。“出错了”三条全都不满足；“因为网络中断，没能保存你的项目。你的修改还在。再点一次保存”三条全都满足。错误码要留，但放小、放次要位置：“错误码 503”能帮客服帮你，但它永远不应该当标题。还要区分能重试的错误和不能重试的错误：网络超时值得给一个重试按钮；权限拒绝值得给一个解释和联系人，而不是一个点多少次都会同样失败的重试按钮。

错误也要分级。后台同步失败，用一条安静的横幅就够了，不值得全屏接管；支付失败、发布失败值得全屏，因为用户不解决它就没法安全地继续。如果每个错误都是挡住整个页面的弹窗，用户会养成不看就关的习惯——而这对那个真正重要的错误来说，是最坏的结果。

状态之间切换的地方，才是 bug 最多的地方

单个状态本身不难，难的是状态之间的切换：先发出的旧请求晚到了，覆盖了新结果；筛选条件改了，屏幕上闪了一下昨天那份列表；提交按钮点了两次，建了两条记录；错误先出现，一秒后又被迟到的成功结果冲掉。这些是竞态问题，值得单独测一轮，因为用户感受到的是“应用给我看了错的东西”，这种信任损耗比任何一条错误文案都快。

三条防御能覆盖大多数情况。第一，给每次请求打上它所属的状态标签，用户已经离开的状态对应的响应直接丢弃：搜“苹果”的响应再晚到，也不应该覆盖搜“杏子”的结果。第二，提交按钮点第一次之后就禁用，失败时再恢复，这样双击建不出两条记录。第三，请求失败但之前有成功数据时，继续显示上一次的好数据，附上“上次更新时间”和重试入口，而不是把好数据换成一张错误屏。带警告的旧数据，几乎总是比没有数据强。

验收清单

功能上线前，在真机、节流网络下把这些状态逐项跑一遍。加载态：有没有低于 300 毫秒一闪而过的东西？骨架屏的形状和随后出现的内容对得上吗？加载很慢时有没有取消或解释？空态：新用户、筛空、权限不足、加载失败，四种情况分得清吗？每一种是不是都恰好给了一个明确的下一步？错误态：提交失败后用户填的东西还在吗？文案是不是说了发生了什么、意味着什么、下一步做什么？有没有给客服用的错误码，并且放在次要位置？切换：快速连改三次筛选条件，最终列表和最终条件一致吗？双击提交只建了一条记录吗？加载中途断网，界面是退到可重试的状态，而不是一张白屏？

加载态、空态、错误态是产品教养的体现。顺境界面展示的是产品能做什么；这三种状态展示的是产品在慢、新、坏的时候怎么对待人。用户对慢和坏的容忍度，远高于对“被晾在一边猜”的容忍度，而这两者的差别，往往就是几句诚实的话和一个明确的下一步。

文案对照：同一件事，两种写法

三态文案的好坏，往往一眼就能看出来。下面是几组可以直接抄的对照。加载态不要写“加载中……”，改成“正在拉取你的项目列表”——前者只说系统在忙，后者说了在忙什么。空态不要写“暂无数据”，改成“你还没有创建项目，创建一个来开始”——前者是数据库的语言，后者是用户的语言。筛空不要写“没有找到相关内容”，改成“没有匹配‘发票’的项目，试试更宽泛的词或清除筛选”——前者把责任推给用户，后者给了出路。错误态不要写“系统异常，请稍后重试”，改成“保存失败，网络中断了。你的修改还在，再点一次保存”——前者没有信息，后者有原因、有状态、有动作。

写文案时有一个简单的自测方法：把文案念给一个不写代码的朋友听，如果对方听完还要问“所以我现在该干嘛”，这句文案就不合格。技术细节（错误码、请求 ID、服务名）可以保留，但要放在次要位置，给客服与排查用，而不是放在标题里吓用户。文案的标题说人话，细节说技术话，两者各就其位。

骨架屏的三种画法与取舍

骨架屏不是一种画法，而是三种，取舍取决于页面类型。第一种是按行画：列表页每行画一条灰条加一个方块头像，适合内容结构固定的列表，成本最低。第二种是按区块画：详情页按“标题区、正文区、操作区”分块画，适合结构差异大的页面，能让用户提前感知页面结构。第三种是直接复用真实布局、只把文字与图片换成灰块，适合已经有稳定布局的关键页面，效果最好、成本最高。选择时按页面重要性排：核心页面用第三种，普通列表用第一种，介于中间的用第二种。不要为了统一而全站只用一种——骨架屏的作用是设定预期，预期越接近真实布局，效果越好。

骨架屏还有两个细节容易被忽略。第一是数量：列表骨架行的数量要接近首屏真实条数，画三行却一次返回二十条，或者画二十行却只返回三条，都会让用户在内容到来时感到跳变。第二是时长：骨架屏出现超过几秒，就要升级为带说明的等待状态，而不是让灰块一直闪下去。骨架屏是“马上就好”的承诺，承诺兑现不了时，要换一种说法。

离线与弱网：可以算作第四种状态

严格说，离线不是加载、空、错误之外的第四种状态，但它值得单独处理，因为它的用户预期完全不同。离线时用户已经知道网络有问题，他们需要的是两件事：第一，明确知道当前是离线状态，而不是反复看到“加载失败”；第二，知道哪些功能离线也能用、哪些要等联网。实用的做法是：顶部常驻一条离线提示，离线可用的内容（已缓存的列表、已保存的草稿）正常显示，不可用的操作（新建、提交、支付）置灰并说明“联网后可用”，而不是让用户点进去才报错。离线写下的内容要本地暂存，联网后自动同步，并告诉用户同步结果——“你离线时创建的 2 条记录已同步”是一句很能建立信任的话。

弱网介于在线与离线之间，处理原则是降级而不是报错：图片先出低清占位、再渐进加载高清；列表先出缓存数据并标注“上次更新于 10 分钟前”、再后台刷新；提交操作先本地确认“已收到，正在发送”、失败时再提示重试。弱网下的目标不是让一切都像在线时一样快，而是让用户始终知道当前状态、并且永远有下一步可走。

交给 agent 写三态时，先要一份状态清单

vibe 开发里，三态常常是交给 agent 顺手生成的，而 agent 最容易漏掉的，恰恰是“哪些状态存在”这件事本身。给 agent 的提示词里，与其写“把加载态、空态、错误态都做好”，不如先要一份状态清单：这个页面有哪些数据源、每个数据源的加载态长什么样、空态分几种、失败时分别显示什么、切换时怎么处理竞态。清单先行，界面后行——清单列出来之后，缺失的状态会自己暴露出来，agent 也不会用一个通用转圈打发所有情况。

清单里还要包括一条验收要求：每个状态都要有对应的测试路径。加载态用节流网络测，空态用新账号与筛空条件测，错误态用断网与接口报错测，竞态用快速连点与快速切换筛选测。没有测试路径的状态，等于没有实现的状态。把这份清单写进功能的验收标准里，三态就不再是上线前才想起来的边角工作，而是功能定义的一部分。

三态文案的语气标尺

三态文案还有一根语气标尺值得单独说明：同一个状态，对新用户、对老用户、对付费用户的语气应该不一样。新用户看到的空态可以多一句引导，因为对方还不知道这个产品是干嘛的；老用户看到的筛空应该直接给调整建议，因为对方已经知道自己在找什么；付费用户看到的错误态要格外谨慎，因为对方为服务付了钱，一句轻飘飘的“出错了”会显得不负责任。语气不是装饰，它是产品对用户处境的理解程度。写文案时先问一句“此刻的用户是谁、他急不急、他损失了什么”，再动笔，文案自然就对了。

语气标尺的另一端是克制：不要在错误态里讲笑话，不要在加载很久时说“马上就好”然后继续等三十秒，不要在用户丢了数据的错误里放庆祝插画。幽默与轻松只适合低风险、低损失的状态；风险与损失越高，文案越应该平实、具体、有行动指引。用户在顺境里会欣赏产品的个性，在逆境里只想要产品的可靠——三态界面恰恰是逆境界面，可靠比个性重要得多。