报错别只写失败，空状态别只写暂无：vibe 项目的报错与空状态实战

一个产品好不好用，往往不是看它顺的时候有多顺，而是看出问题的时候有多体贴。顺的时候人人都会点下一步；卡住的时候，用户才真正开始判断：这个产品靠不靠谱，我还要不要继续。

本文讲的就是这层“出问题时的体贴”：报错怎么写、空状态怎么摆、失败之后给不给退路。示例产品“灯塔跑团”（一款约人一起跑步的小程序）与人物“阿舟”均为虚构，用来把道理落到具体界面上；方法本身通用，做任何 vibe 项目都能直接套。

先分清：报错、空状态、加载失败是三回事

很多人把这三者混成一团，结果就是：明明只是还没数据，界面却摆出一副“出故障了”的样子；明明是网络断了，界面却轻描淡写地说“暂无内容”。用户被误导一次，信任就掉一格。

报错，是用户做了一件事、系统没办成：保存失败、支付没过、表单有错。空状态，是事情办成了、但结果是零条：新账号还没有跑步记录、筛选条件太严筛不出活动。加载失败，是连结果都还没拿到：网络断了、服务器没响应。三种情况的原因不同，用户下一步该干的事也不同，所以文案和按钮必须分开写，不能共用一句“暂无数据”。

一个简单的自查办法：给每种状态各写一句话测试——报错要能回答“哪一步没成”；空状态要能回答“为什么是空的、接下来能做什么”；加载失败要能回答“是没连上、还是对方没响应、能不能重试”。答不上来的状态页，就是还没设计完。

报错文案四条铁律

第一，说人话，不说错误码。用户看到“Error 5003”只会更慌；他想知道的是“刚才那一步成没成、我该怎么办”。错误码可以留给开发者日志，但界面上先给一句人能看懂的话：“保存没成功，你的修改还在，点重试再存一次。”

第二，指名道姓说清楚错在哪。表单报错最忌讳只在页面顶上飘一句“请检查输入”，用户要自己一个个字段去猜。正确做法是：错的字段就近标出来，文案贴在字段旁边——“手机号少了一位”“结束时间不能早于开始时间”。一次只报真正错的那几项，不要把整张表单都染红。

第三，每次报错都给一个下一步。没有下一步的报错等于把用户晾在原地。保存失败给“重试”；权限不够给“去开通”或“联系管理员”；内容违规给“看看规范”或“改一改再发”。哪怕下一步只是“返回上一步”，也比干巴巴的一句失败强。

第四，别把责任推给用户。像“你输入有误”这种话，听着就像在指责人。换成中性的说法：“这个日期格式不对，改成 2026-10-30 试试。”同样是纠错，语气一变，用户配合的意愿就完全不一样。阿舟第一次做灯塔跑团时，报名失败只写“报名失败”，用户群里骂声一片；改成“名额刚满了，点这里看看下一场”之后，投诉直接少了一半——失败本身没变，变的是失败之后的路。

三类空状态，三种写法

第一类是“新手空”：用户刚注册，什么都还没有。这时候空状态不是在汇报结果，而是在发邀请。不要只写“暂无记录”，要写“还没跑过第一场，来约一场试试”，配一个显眼的主按钮。配图可以用轻松的插画或照片，但别用那种灰扑扑的“空文件夹”图标——新手第一次打开就看到灰色，很容易直接关掉。

第二类是“筛空了”：用户设了条件，结果一条都没有。这里最重要的是告诉他“不是系统坏了，是条件太严了”，并给一条松绑的路：显示当前条件、提供“清除筛选”或“放宽到全城看看”。灯塔跑团早期有个教训：按“周六早上 + 5 公里内 + 配速 5 分”筛，经常筛出零条，用户以为产品没人用；后来在空状态里加了一句“放宽到 10 公里还有 3 场”，留存立刻好看了。

第三类是“删空了”：用户自己清空了内容，比如取消了全部收藏。这类空状态要温和地确认结果、留一条回头的路：“收藏已清空，想找回可以去浏览页重新收藏。”千万别在这里推销新功能——人刚删完东西，心情正烦，推销只会招人厌。

失败之后，状态要留得住

最伤人的失败不是报错本身，而是报错之后用户的心血没了。填了十分钟的表单，提交失败一刷新，全没了——这种产品，用户不会再给第二次机会。所以凡是用户输入过的内容，提交失败时一律保留在原地；刷新、重进之后也最好还在（本地暂存一份草稿并不难）。删除类操作更要谨慎：先确认、再执行、执行完给撤销入口，这在危险操作确认那篇指南里讲过，这里只强调一点——撤销入口的保留时间要写清楚，“30 秒内可撤销”比含糊的“可撤销”更让人安心。

还有一种容易被忽略的失败：部分成功。比如一次报名 3 场，成了 2 场、1 场满员。不要只报“报名失败”，也不要只报“报名成功”——把两部分都摊开说：“已报上 2 场，1 场因名额已满未报上”，让用户自己决定要不要换一场。这种“说清楚一半”的诚实，比任何一种漂亮的成功提示都更值得信任。

别让技术细节漏到界面上

“网络请求超时”“数据库连接失败”“参数校验未通过”——这些话是写给开发者的，不是写给用户的。用户版翻译有个笨办法：把技术原因翻译成用户能感知的原因。“网络请求超时”翻成“网络有点慢，没连上”；“参数校验未通过”翻成具体哪一项不对；“服务器错误”翻成“我们这边出了点问题，正在处理，你可以稍后再试”。翻译时顺手把下一步也补上：能重试的给重试，不能重试的给返回或联系方式。

反过来也别走向另一个极端：为了“友好”把什么都说成“出了一点小问题”。用户连续三次看到“小问题”，第四次就不会信了。问题大小要诚实：小问题说小问题，需要等的就说要等多久、等不了的就给替代方案。友好不等于含糊，诚实本身就是一种友好。

上线前按这张清单过一遍

第一，逐个触发一遍所有报错：断网、填错、权限不足、服务器报错，看看文案是不是人话、有没有下一步。第二，逐个打开所有空状态：新手、筛空、删空，看看有没有把“没数据”写成“出故障”。第三，提交失败后刷新一次，确认用户输入还在不在。第四，找一个没用过产品的人读一遍所有报错文案，他能说出“下一步该干什么”才算过关。第五，检查所有报错和空状态在手机小屏上会不会溢出、按钮点不点得到。

说到底，报错和空状态不是产品的边角料，而是产品的人品。顺的时候谁都会用，难的时候还愿意留下来，才是真的好用。把失败时的每一步都当成正式功能来设计，你的产品就已经比大多数 vibe 项目体贴一截了。

三种报错位置，千万别用混

报错放在哪里，和写什么话一样重要。用错位置，文案写得再好用户也看不见。第一种是贴在字段旁边的“就近报错”，适合表单：用户改哪一行、错就标在哪一行，改完立刻消失，不要等到点提交才一次性全冒出来。实时校验有个分寸：用户正在打字的时候别急着报错——刚敲了一个字就被判“格式不对”，谁都会烦；等到他离开这个输入框、或者点提交的时候再判，才是体贴的做法。

第二种是页面顶部或底部的“轻提示”，适合不阻塞流程的小失败：比如“头像上传失败，已保留原头像”“同步稍后重试”。这种提示不要挡住用户正在做的事，几秒后自己消失即可，但消失之前必须能点开看详情——用户想深究的时候，要有地方深究。

第三种是居中弹窗，适合必须停下来处理的大事：支付失败、删除前确认失败、会话过期。弹窗的标准是“不用不行”：一旦用了弹窗，用户就必须先处理它才能继续，所以滥用弹窗等于滥用用户的注意力。阿舟在灯塔跑团里曾经把“网络波动”也做成弹窗，用户在地铁里每过一个站就被弹一次，后来改成顶部轻提示，投诉才消停。判断标准很简单：这件事不处理会不会造成损失或误操作？会，才用弹窗；不会，就用轻提示。

好文案与坏文案，对照着改

“操作失败”改成“报名没成功，名额可能刚被抢完，点重试再看一次”——多了原因猜测和下一步，用户就知道该干什么。“请输入合法字符”改成“昵称只能用中文、字母和数字，不能带空格”——把规则本身写出来，而不是只宣布“你不合法”。“系统异常，请稍后再试”改成“我们这边出了点问题，刚才的操作没有生效，稍后再试一次；如果一直不行，可以点这里联系我们”——承认是己方问题、说明操作是否生效、给出联系方式，三要素齐了，用户才安心。

还有一类文案最容易被忽略：成功之后紧接着的失败。比如报名成功了，但短信通知没发出去。这时候不要假装一切正常，也不要把成功推翻重来——在成功提示下面补一句“报名已成功，短信通知没发出去，你可以在‘我的活动’里查看”。用户最怕的不是出问题，而是不知道到底成没成。把“成没成”说清楚，永远是第一位的。

重试不是万能药，要分情况

给重试按钮之前，先问一句：重试有没有用？网络抖动造成的失败，重试大概率有用，那就把重试按钮放在最显眼的位置；但如果是名额满了、权限不足、内容违规，重试一百次也没用，这时候按钮应该换成“看看别的场次”“去申请权限”“改一改再发”。更糟的是“自动无限重试”：页面卡在那里转个不停，用户不知道它是在重试还是死机了。自动重试最多两三次，每次都要让用户看得到进度；超过这个数，就停下来、明说失败、把选择权还给用户。

重试时还要保护用户的数据。最常见的一个坑：点重试之后，系统把同一笔报名提交了两次。解决办法不复杂——提交按钮点下之后先禁用、等结果回来再恢复；或者给每一次提交带一个唯一标识，重复提交时后端直接返回第一次的结果。这些话听着像后端细节，但用户感知到的就是“会不会被重复扣费、重复报名”。做 vibe 项目时，哪怕后端是现成的，也要亲手测一次“连点两次提交会发生什么”，这是上线前最值得花的一分钟。

空状态里的插画与按钮，别抢戏

空状态常常被做成“插画越大越好”，结果用户第一眼看到的是一幅画，而不是下一步该干什么。正确的主次是：先一句话说清现状，再一个主按钮给行动，插画只是气氛组，放在旁边或上面、占小篇幅即可。按钮文案也有讲究：“去看看”太含糊，不如“去约第一场跑步”；“立即创建”不如“创建你的第一个活动”。按钮上的动词越具体，用户越知道点下去会发生什么。

还有一个细节：空状态不要和广告位混在一起。新手第一次打开“我的收藏”，看到的应该是“还没有收藏，逛逛广场”，而不是满屏推荐。推荐可以有，但要放在主行动下面、标明“为你推荐”，别让用户分不清哪句是状态、哪句是推销。状态页的第一职责是诚实汇报现状，推销永远排在第二位。

把失败写进测试清单，而不是写进道歉信

很多团队是等用户投诉了才去补报错文案。更省事的做法，是在功能清单里给每个功能加一行“失败时怎么办”：这个功能会怎么失败？用户会看到什么？下一步是什么？数据会不会丢？写功能的时候顺手把这行填了，上线前按清单逐个触发一遍，投诉量会少一大截。灯塔跑团的阿舟后来养成了一个习惯：每做一个新功能，先写失败清单、再写成功流程——顺序一换，返工就少了很多。

最后提醒一句：报错文案也要跟着产品一起迭代。早期“名额刚满了”够用，等活动多了，可能要补“同城还有 3 场可选”；等用户量大了，可能要补“已为你排队，有名额时通知你”。每次改版都顺手读一遍旧的报错文案，把过时的说法换掉——过期的安慰，比没有安慰更让人失望。

别忘了看不见报错的人

报错不只是给眼睛看的。用读屏软件的用户，听不到红字、看不到图标颜色，报错必须能被“读”出来：错误信息要出现在读屏能找到的位置，字段报错要和字段本身关联起来，而不是只飘在页面角落。只用颜色区分对错也是个坑——红绿色盲用户分不清红绿对错，所以错误除了变红，还要有图标或文字说明。键盘用户同样不能忘：报错出现后，焦点应该移到第一个出错的字段或提示上，别让用户自己满屏找。

动效也要克制。报错时整屏抖动、红字闪烁，看着“醒目”，实际上对容易晕动的用户很不友好。一次轻微的提示、稳稳地停在原地，比花里胡哨的抖动更专业。体贴不是堆料，而是让每一种用户都能在第一时间、用自己的方式，知道发生了什么、下一步该做什么。

回头看全文，核心其实只有一句话：失败的时候，别让用户猜。说清成没成、说清为什么、说清下一步、保住用户的心血，这四件事做到了，你的产品在最难的时刻，反而最让人放心。