不可逆动作需要清单化识别
别名: 不可逆动作清单 · irreversibility audit · 破坏性操作清单
概念解释
在能够谈撤销窗口、确认强度、强制拦截这些补偿手段之前，得先知道产品里到底哪些动作是不可逆的——这件事不能靠设计师凭直觉逐个判断，而需要一份持续维护的清单，把产品里所有具有不可逆外部效果的动作明确列出来，标注清楚它为什么不可逆、影响范围有多大。没有这份清单，任何关于撤销、确认或拦截的设计决定都建立在猜测之上。
机制
不可逆性经常是悄悄引入的，而不是某个功能团队主动设计的结果——调用了一个没有取消接口的第三方支付网关、把消息直接推送给了对方设备、触发了物理世界里的一个动作（打印、寄送、开锁），做这些功能的团队关注的是"功能能不能跑通"，很可能没有意识到自己刚刚引入了一个不可逆的动作，因为不可逆性不是这个功能本身的目标，而是它调用的底层能力的副作用。等到用户真的因为一次误操作造成了后果，才发现产品里存在一个从来没有被任何人识别、评估过的不可逆动作——这时候再补救，代价已经是既成事实的损失，而不是设计阶段的一行清单条目。
边界
清单化识别管的是"这个动作是否不可逆、影响多大"这两个事实判断，它本身不决定该用撤销、确认还是强制拦截去应对——那是后续的设计决策，需要结合动作发生的频率来权衡。清单只是让这个决策有依据可查，不做这份清单，后面所有的权衡都无从谈起。
怎么落地
在产品层面维护一份持续更新的不可逆动作清单，覆盖所有涉及资金变动、消息或数据发送给第三方、物理世界效果、永久删除的动作，每一条注明触发路径、影响范围、能否补救。把核对这份清单作为任何新功能设计评审的必经环节：只要一个新功能的描述里出现"发送""扣款""删除""授权"这类词，就要求负责人先在清单里查一遍这个动作是否已经存在、是否需要新增条目。验证办法：定期抽取近期上线的功能，反向核查其中带有不可逆外部效果的动作是否都能在清单里找到对应条目——任何在生产环境里被发现不可逆、却在清单上找不到记录的动作，说明评审环节漏检了，需要补充记录并回头检查它有没有配套的撤销或拦截设计。