麦式参考 MickerBook Reference

轻提示

Toast

也常被叫作:Toast气泡提示浮动提示吐司通知通知条

你可能会这么说

「用户点了个按钮,页面角落飘出一小行字说「保存成功」,过几秒自己消失。」

轻提示 Toast

短暂出现在屏幕角落、几秒后自动消失的小提示,用来告知一次轻量操作的结果。

轻提示(Toast)是一闪而过、不需要用户动手的通知:它出现在屏幕角落,过几秒自己消失,不挡路、不用点关闭。它的用途很窄——告知一个已经发生且影响很小的动作的结果,比如「已保存」「已复制」。

因为它会自动消失,所以它只能装非关键信息。关键信息、需要用户确认或记住的信息,绝不能放进轻提示:比如「账号已被封」「付款失败,请重试」——这些要是几秒后消失了,用户根本来不及处理。

轻提示最常被 AI 用错的地方,是把它当成唯一的反馈通道。轻提示应该和就地反馈搭配:提交表单成功了,按钮附近或表单里要有确认;轻提示只负责补充一句「成功了」。另外,轻提示消失得比用户读完快、同一时间弹好几条挤在一起、把关键错误也做成会消失的提示——这几个是翻车高发区。

长什么样 真实可交互,不是截图

已保存:你的修改已生效

注意「已保存」这类轻提示只是锦上添花。真正关键的错误(比如删除失败)不应该做成几秒后就消失的轻提示,否则用户还没看清楚就没了。

拆开看,里面有这几块

  1. 1
    内容文案 Message

    一句话说明发生了什么。避免「操作成功」这种没说清成功了个啥的空话。

  2. 2
    出现位置 Placement

    通常是屏幕顶部或右下角,全站要统一,别有的在左上有的在右下。

  3. 3
    持续时间 Duration

    几秒后自动消失。关键信息不能放这里,因为它没人看管就会消失。

  4. 4
    动作按钮 Action

    可选,比如「撤销」。给了动作按钮,就不能太短就消失,要给用户留出反应时间。

  5. 5
    类型 Type

    成功 / 错误 / 提示,通常配不同颜色和图标,但颜色不能是唯一的区分方式。

常见的有哪几种

成功提示Success

告知一个动作做成了,比如「已保存」「已发送」。

用在:复制、保存、发送成功

错误提示Error

告知一个动作失败了。非关键的失败才适合,且要让用户有办法处理,不只是闪一下就没了。

用在:复制失败、网络抖动

带动作的提示With Action

附一个「撤销」之类的按钮,给用户反悔的机会。

用在:误删、误发后撤销

信息提示Info

一句补充说明,提醒正在发生什么。

用在:后台任务开始、已自动刷新

容易搞混?这样区分

轻提示 提示条 Banner / Alert

轻提示自动消失、不挡流程、适合轻结果;提示条常驻在页面顶部,会挡住部分内容、需要用户或系统主动解除,适合需要持续可见的重要信息(比如「正在维护」「网络断开」)。

轻提示 弹窗 Modal

弹窗需要用户主动关掉才能继续操作,适合需要确认或输入的阻塞信息;轻提示不需要任何操作、自动消失。把需要确认的弹窗做成轻提示,等于把决定权交给了倒计时。

看 弹窗

什么时候用得上

复制成功

点复制按钮,右下角飘一句「已复制到剪贴板」,几秒后消失,不打断当前操作。

提交保存

表单就地显示成功反馈,轻提示补一句「已保存」,两者配合而不是互相替代。

误删撤销

删除成功后弹一个带「撤销」按钮的轻提示,给用户几秒反悔的窗口。

你可以这样跟 AI 说

直接复制下面这段,把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了:改哪里、不许动啥、做完交什么。

【范围】只改 [这个页面] 的操作反馈,不动其他页面
【要求】
  - 「保存」「复制」这类轻量操作成功后,用轻提示(Toast)告知,位置固定在右下角,几秒后自动消失
  - 轻提示只放**非关键**的轻量结果;关键信息(账号被封、付款失败、删除失败)不要做成几秒就消失的轻提示
  - 同一时间不要叠好几条,后一条要等前一条消失或统一堆叠
  - 轻提示文案说清「发生了什么」,不要写「操作成功」这种空话
【边界】不要新增第三方通知库;不要改页面整体布局;不要把需要用户确认的事情改成自动消失的轻提示
【交付】告诉我改了哪些文件、我触发哪个动作能看到哪句提示、它几秒消失、以及哪部分你没验证

这段话最关键的是那句「关键信息不要做成几秒就消失的轻提示」——这是 AI 最容易踩的坑:把错误和成功都无脑套进同一个自动消失的组件里。

它说「做好了」,你怎么自己验

这是本站的重头戏。AI 最会的不是写代码,是说「已完成」。这一条,它通常最多做到「主路径」这层:真实用户的正常操作能走通,不靠特殊参数。

要亲眼看到这些,才算数

  • 触发一次成功动作(比如复制):看到一条轻提示出现,过几秒真的自动消失
  • 连续快速触发两次:提示没有叠成一坨看不清的乱码,要么堆叠整齐,要么后一条等前一条。
  • 故意触发一个关键错误(如果页面有):它不是做成几秒就消失的轻提示,而是有办法让用户看到并处理。
  • 文案说清了「发生了什么」,不是一句「操作成功」。
  • 轻提示不遮挡页面上其他按钮,出现和消失都没有把布局挤得乱跳。

它常这么糊弄你

  • 「已加轻提示」——但只有代码里写了,界面上根本没触发。自己点一次看它真的弹出来。
  • 所有消息(包括关键错误)都套同一个自动消失的轻提示——关键错误几秒就没了,用户根本没机会处理。
  • 文案写「操作成功」——成功了个啥没说。要求它说具体内容。
  • 连续操作时叠了一屏幕轻提示,看不清哪条是哪条。
  • 用颜色(红色/绿色)当成功与错误的唯一区别——色弱用户分不出来,必须有文字或图标。

轻提示能验到「主路径」层:你亲手触发几个动作,看它出现、消失、不叠成乱码、关键信息没有消失,就验完了。

考考你 选一个你觉得对的

下面哪个情况不该用几秒后自动消失的轻提示?