删之前先拦一下：vibe 项目的危险操作确认设计实战

每个产品都有过这样一个客服工单：用户说他只是想删一张照片，结果整个相册都没了；或者他只是想取消一个成员，结果把整个团队解散了。追查下来，代码往往没有 bug，按钮也确实是他自己点的。真正的问题出在按钮和后果之间，少了一道应有的停顿。危险操作的确认设计，做的就是这道停顿：不是拦住用户不让他做，而是确保他动手之前，真的知道自己在做什么。本文讲怎么给危险操作分级、配摩擦、写文案，让“删错了”这件事从事故变成小概率事件。

先说清楚本文的例子：文中出现的“松果相册”和用户“阿远”均为虚构，只是为了把道理讲具体而编的例子，不是真实产品和真实用户。方法本身是通用的，放到任何一个 vibe 项目里都能直接套用。

先定一个观点：确认不是弹窗数量，是摩擦分级

一提到危险操作，很多人的第一反应是多弹几个确认框。删之前弹一个，弹完再弹一个，确认框里再加一个输入框。结果用户练出了肌肉记忆：不管框里写什么，一律点最右边的按钮。确认框弹得越多，每个框的可信度就越低，最后等于没有确认。确认设计的核心不是数量，而是分级：后果越严重，摩擦越大；后果越轻微，摩擦越小。把所有删除都配上最高级别的确认，和把所有删除都不配确认，犯的是同一个错误：没有区分。

分级之前，先把“危险”说清楚。危险不是一个感觉，而是三个维度的乘积：可不可逆、影响范围有多大、能不能补救。能一键撤销的删除，和删完就从服务器上物理清除的删除，根本不是同一档操作。只影响自己的删除，和会把全组人的东西一起带走的删除，也不是同一档操作。分级表就是要把这三个维度摆到台面上，而不是凭手感决定弹几个框。

还有一个容易被忽略的原则：确认框只能确认意图，不能代替设计。按钮放错位置、文案写得含糊、批量操作的范围没说清楚，这些问题靠确认框是补不回来的。确认框是最后一道关，不是第一道关。如果用户经常在确认框前停下来困惑，说明前面的界面已经有问题了，应该先修界面，再谈确认。

危险四档：从可逆到连锁不可逆

我推荐把危险操作分成四档，每一档对应固定的摩擦级别，团队里所有人按同一张表执行，就不会出现“这个删除弹三层、那个删除不弹”的随意局面。

第一档是可逆操作，比如把一条记录移进回收站、取消关注、关闭一个标签页。这类操作的正确处理是不弹确认框，而是做完之后给一个撤销入口。用户点错了，点一下撤销就回来了，确认框反而打断了正常流程。这一档的重点不在确认，而在撤销入口要足够明显、停留足够久。

第二档是单条不可逆操作，比如永久删除一条笔记、删除一张照片、取消一个订单。这一档配一次模态确认就够了，但确认框里必须写清楚对象和后果：“删除《旅行清单》后无法恢复”，而不是“确定要删除吗”。对象要用用户认识的名字，不要用编号和内部名称。按钮文案也要说人话：用“删除”而不是“确定”，用“保留”而不是“取消”，让用户在按钮上就能读出自己的选择。

第三档是批量不可逆操作，比如一次删除五十张照片、一次移除二十个成员。批量操作的危险在于范围容易被低估，用户以为自己选了三条，实际上选了三十条。这一档的确认框必须先报数：列出数量，列出范围，超过一定数量时列出清单的前几项，并给一个“查看全部”的入口。报数不清的批量确认，和没有确认没有区别。

第四档是连锁不可逆操作，比如解散团队、删除工作区、注销账号。这类操作的特点是后果会扩散：删掉工作区，里面的项目、成员关系、历史记录可能一起消失。这一档需要最高摩擦：输入确认、二次验证、延迟执行，三者里至少用两个。输入确认不是让用户抄一段话，而是让他输入操作对象的名字，输入的过程就是再想一遍的过程。延迟执行则是给冲动留一个冷静期：点了删除，先进入待删除状态，二十四小时内可以反悔，过期才真正执行。

分档表定下来之后，还要定一条升级规则：任何操作只要沾上第四档的特征，就按第四档处理。比如删除一条记录本身是第二档，但这条记录被十个项目引用，删掉会连带影响十个项目，那就按第四档处理。按最严重的后果定档，不要按最常见的场景定档。

五种确认模式：什么时候用哪一种

确认模式一共有五种，每种都有自己的适用场景，用错场景比不用更糟。第一种是内联确认，按钮点下去之后，原地变成“再点一次确认”的状态，适合低风险但容易误触的操作，比如取消关注、移除单个标签。它的优点是不打断流程，缺点是用户可能没注意到按钮变了，所以只适合后果轻微的操作。

第二种是模态确认框，遮住背景、聚焦在选择上，适合第二档和第三档操作。模态框的规矩是：标题说后果，正文说范围，按钮说动作。标题不要写“请确认”，要写“删除这五十张照片后无法恢复”。正文不要重复标题，要补充标题没说的信息：影响谁、有没有备份、能不能撤销。按钮不要用“确定”和“取消”这种读不出后果的词，要用“删除五十张照片”和“保留照片”这种读得出后果的词。

第三种是输入确认，让用户输入对象名或者关键词，适合第四档操作。输入确认的关键是输入内容要有意义：输入工作区的名字，比输入一段固定的“我确认删除”有意义得多，因为前者逼用户确认自己删的是哪一个。输入框旁边要提示对象名，不要让用户靠记忆去拼写一个长名字。

第四种是二次验证，比如短信码、邮箱链接、重新输入密码，适合涉及资金、身份和所有权的交接操作。二次验证防的不是误触，而是盗号和冒操作，所以它不应该被当成通用的确认手段滥用。每个操作都要求二次验证，用户很快就会觉得产品在刁难他。

第五种是延迟执行和冷却期，点了删除先不真正删，给用户一段时间反悔，适合第四档里那些“现在不删也不会出事”的操作。延迟执行的重点是状态要透明：用户要随时能看到“待删除”列表，能提前恢复，也能提前确认立即执行。悄悄延迟而不告诉用户，和悄悄删除一样糟糕。

选模式的时候用一张决策表：先问可不可逆，不可逆再问影响范围，影响范围大再问会不会连锁。三问答完，模式基本就定了。团队里如果有人想给某个操作加一层确认，先查表，不要凭感觉加。

文案四要素：对象、后果、范围、出路

确认框的文案有四要素，缺一个就可能出事。第一是对象：删的是什么，要用用户认识的名字。第二是后果：删完会发生什么，要说到不可逆就写不可逆，不要用“可能无法恢复”这种含糊的词。第三是范围：影响多少条、影响哪些人、会不会连带影响别的东西。第四是出路：除了确认和取消，用户还有没有第三条路，比如先导出备份、比如先转移所有权、比如改成归档而不是删除。

反模式的文案长什么样，举几个例子。第一种是只问意图不说后果：“确定要删除吗？”用户当然确定，他点按钮的时候就是确定的，这句话没有提供任何新信息。第二种是对象含糊：“确定要删除该项目吗？”哪个项目？用户在批量操作里可能根本不知道自己选了哪个。第三种是按钮误导：删除按钮放在右边、颜色最醒目，保留按钮灰扑扑的，用户凭肌肉记忆一点就中招。按钮的视觉权重应该和后果的严重程度反着来：越危险的按钮，越不应该是最容易点的那个。

出路这个要素最容易被漏掉，但它往往是最有用的。很多“删除”其实是“不想看见了”，归档就能解决；很多“解散”其实是“想换负责人”，转让就能解决。确认框里给一条出路，比如“或者先导出一份备份”，能把一部分不可逆操作变成可逆操作。这比把确认框做得再吓人都有用。

拿虚构的松果相册做一组前后对照，就能看出四要素的威力。改之前的确认框写的是“确定要删除吗？”，按钮是“确定”和“取消”，阿远根本不知道自己选中的是哪个相册、有多少张照片、删了还能不能找回来。改之后标题变成“删除相册《去年夏天》后无法恢复”，正文写清“一共一百二十三张照片，其中九张被两个共享相册引用，删除后引用也会失效”，按钮变成“删除这个相册”和“先留着”，下面再给一条出路：“或者先导出一份备份”。同一件事，改之前用户只能凭运气点按钮，改之后用户手里有了全部信息，做出的才是真正的决定。写文案的时候就按这个对照自查：标题有没有后果、正文有没有范围、按钮有没有动作、下面有没有出路，四个格子填满了，文案才算合格。

文案还要考虑语言本身。不要用“该操作不可逆转”这种翻译腔，要用“删了就找不回来了”这种大白话。用户在确认框前停留的时间只有几秒，文案必须一遍读懂。写完文案后念一遍，念的时候卡住的地方，用户读的时候一定也会卡住。

批量与连锁：范围不清，确认就是摆设

批量操作和连锁操作是确认设计的重灾区，因为它们的范围最容易被低估。批量操作的第一条规矩是执行前报数、执行中报进度、执行后报结果。报数不是写一个数字就够了，要写清楚数字是怎么来的：选了多少条、过滤条件是什么、有没有包含子项。用户在确认框里看到“将删除五十二张照片，其中三张已被三个相册引用”，他才能做出真正的判断。

第二条规矩是部分失败要有交代。批量操作很少百分之百成功，总有几条因为权限、网络或者状态问题失败。失败了不能只报一句“部分失败”，要列出失败的是哪几条、失败的原因、能不能重试。用户最怕的不是失败，而是不知道到底哪些成功了、哪些没成功，最后只能一条一条去核对。

连锁操作的第一条规矩是先算影响再动手。删除工作区之前，系统应该先算出来：里面有多少项目、多少成员、多少公开链接会失效，把这张影响清单摆在确认框里。算不出来的影响，就不要让用户在不知情的情况下承担。连锁操作的确认框里，影响清单比警告语更重要，因为警告语只能吓唬人，影响清单才能帮助人判断。

第二条规矩是给连锁操作留一条降级路径。删工作区之前，能不能先转让给别人？能不能先归档而不是删除？能不能先把公开链接批量下线、确认没人用了再删？降级路径不是多余的功能，而是确认设计的一部分：用户有了不那么极端的选项，就不会被逼着在“全删”和“全留”之间二选一。

确认与撤销的分工：一个管动手前，一个管动手后

确认和撤销经常被混为一谈，其实它们的分工很清楚：确认管动手之前，撤销管动手之后。确认的任务是让用户在动手前想清楚，撤销的任务是让用户在动手后有后悔药。两者不是二选一，而是双保险，但双保险不等于双重确认：确认框已经弹过了，撤销入口就应该简单直接，不要再弹一次确认。

分工的原则是按档位来：第一档操作以撤销为主，不弹确认；第二档操作以确认为主，撤销作为补充；第三档和第四档操作两者都要有，确认负责讲清范围，撤销负责兜底。撤销窗口的长度也要按档位来：第一档操作撤销窗口可以短一点，第四档操作的撤销窗口应该长得多，至少给用户一个睡一觉再决定的机会。

撤销入口的设计同样有讲究。撤销提示不能只闪两秒就消失，用户还没反应过来就没了；也不能一直占着屏幕不走，挡住正常操作。合理的做法是提示停留足够久，并且在操作记录里留一条可撤销的入口，让用户晚一点回来还能找到。撤销操作本身不能再弹确认框，否则撤销的意义就没了。

最后是度量。确认设计做完之后，要看三个数字：误操作率，也就是撤销和客服工单里“删错了”的比例；确认放弃率，也就是弹了确认框之后用户点取消的比例；以及危险操作的客服工单数。确认放弃率高不一定是坏事，它可能说明确认框确实拦住了冲动操作；但如果某个操作的放弃率长期超过一半，就要回头检查：是不是按钮放错了地方，是不是文案写得吓人，是不是用户根本不想删、只是想找另一个功能。数字不会直接告诉你答案，但它会告诉你该去哪里找答案。

移动端与无障碍：误触最多的地方，恰恰最容易被忽视

确认设计还有一块经常被漏掉的阵地：手机和小屏幕。手指比鼠标大得多，按钮之间的距离一旦不够，误触率立刻上升。危险按钮和普通按钮之间要留出足够的间距，删除按钮不能紧贴着编辑按钮，更不能放在用户拇指最容易误触的区域。手势操作也要小心：左滑删除这种手势，滑错了方向或者滑多了，都可能触发不想要的操作，所以手势删除之后一定要配撤销入口，而不是再弹一个确认框去打断手势的流畅感。

无障碍同样是确认设计的一部分。确认框弹出来之后，键盘焦点要落在确认框里，读屏软件要能读出标题、后果和按钮的完整含义，而不是只读出“对话框”三个字。按钮不能只靠颜色区分危险和安全，色弱用户分不清红和灰，按钮文案本身必须说清楚。关闭确认框的叉号和“取消”按钮要足够大、足够好点，因为“不想删了”这个选择，和“确认删除”同样重要，甚至更重要。一个只方便删除、不方便取消的确认框，本身就是一种诱导。

说到底，确认设计不是在用户和按钮之间砌墙，而是在冲动和后果之间留一道缝。分级定清楚，模式选对地方，文案说清对象、后果、范围和出路，批量和连锁操作先算影响再动手，确认和撤销各司其职，产品就会少很多“我只是手滑了一下”的工单。而少一次删错，对用户来说就是一次信任的保全。这道缝，就是产品对用户最体贴的一次让步。