用户点下那个编辑，你的后台执行的是一次删除加一次新建，中间那几秒他账户里一张卡都没有

摘要：81%的人会在常买的站里存下自己的信用卡，可75%的站不允许这张卡的卡号被改动，8%的站连有效期、姓名、账单地址都一个字不让动。用户想换一张卡，唯一的路是先把旧的删掉，再从头输一遍。78%的站至今没有把这条路包起来。

包不起来的原因是真的：支付合规不允许你把完整卡号存成可读可改的样子。但从这条真实的约束，到让用户自己去删、去重输、去承担删错一张的风险，中间有一大段路本该由你走完。本文讲清界面上那个动词到底承诺了什么、哪一类真相不该端给用户看、那几秒的空档有多贵，以及五个不用新埋点就能开始收的数。

为什么改一张已经存好的卡，会变成整个账户中心最难的一件事？

78%的站不做假编辑流程，75%的站不让用户改卡号。这两个数背后是同一件事：用户要的那个动作，你的系统里压根没有。

先看一个真实场景，来自一次可用性测试的原始记录。

一位参与者拿着新换的信用卡，登进常买的家居站，想把有效期从旧的改成新的。她找到已保存的卡，点开，发现只能改账单地址。她退出表单，退出支付方式页面，甚至退出了整个账户区域，绕了一圈又回来，最后确认：这里改不了。

她删掉那张卡，重新添加。这个过程花了4分钟。中途她差点把刚加好的那张也一起删了——因为两张卡在列表里长得一模一样，都只显示末四位。

她的原话是：这有点烦人，我不该为了改一个数字就把整张卡删掉。

四个数字，讲的是同一件事的四个角度

这不是个案。Baymard针对已存信用卡编辑流程的研究给出了四个数：

• 81%的测试参与者说，自己会在经常购物的站点里保存信用卡。
• 75%的受测站点，不允许已保存的卡号被编辑。
• 8%的受测站点，任何一项信用卡信息都不给编辑——连账单地址都不行。
• 83%的受测站点，删掉一张卡需要点两次：一次发起，一次确认。

还有一个更靠前的数：在同一家机构对账户功能重要性的量化调查里，管理信用卡被受访者排在了第二位。排第一的是订单相关，这不意外；意外的是排第二的不是收货地址，不是优惠券，是这件一年也做不了几次的事。

低频，但重要。这两个词凑一块，通常意味着一个被系统性低估的地方。

这篇不谈什么

为了不和站内已有的几篇撞车，先把边界划清楚。

本文不谈支付网关怎么选、怎么接、怎么配，那些在WooCommerce支付网关的配置实战里；也不谈一个市场该上哪几种付款方式，那是德国、巴西、东南亚本地支付方式选型那一篇的活儿。

不谈拒付与3DS，不谈退款争议流程，这两块分别在3DS 2新规下的拒付治理和退款与Chargeback三渠道处理里。

也不谈订阅扣款失败之后怎么挽回，那一整条链路写在WooCommerce订阅制的续费失败挽回里。本文谈的是那条链路再往前的一段：在扣款失败发生之前，用户其实自己来过一次，想把卡换掉，然后放弃了。

账户中心整体怎么搭、面板放哪些模块，看Magento 2客户账户中心的面板与地址簿；下单前的信任与政策页怎么写，在DTC退换货政策页怎么写里。

本文只做一件事：把界面上那个写着编辑的按钮，和它背后真正执行的那串操作，摆在一起看。

为什么这块地方全行业都做得差

Baymard对账户与自助服务这个主题做过一次整体评分，结果是：73%的桌面站表现在及格线以下，移动端是66%，而96%的站至少有一条关键最佳实践是做错的。

96%已经接近全员。一个领域里几乎所有人都做错，通常不是因为难，是因为没人看。

同一份研究的开头顺手交代了原因，而且交代得非常坦率：账户与自助服务和他们研究过的其他六个电商主题都不一样，它通常不属于直接购买漏斗，它发生在购买之后。

这句话本来是用来给研究主题定位的。可它同时也是这块地方被做砸的全部理由：不在漏斗里，就没有人看它的数；没有人看它的数，就没有人改它。

同一张信用卡，在漏斗内外的两种命运

这个对照还能更锋利一点。

信用卡这东西在电商站里出现在两个地方：结账页，和账户中心。同一家机构、同一套方法、同一个对象，只是位置不同。

结账页那一侧：卡号输入框自动补空格这条准则，目前还有15%的站没做到。原文顺手交代了这个数的来路：2019年它是50%，六年时间从50%降到了15%。

账户中心那一侧：假编辑流程这条准则，78%的站没做到。这个数没有配任何一句关于改善的说明，也查不到它六年前是多少。

同一样东西，落在漏斗里的那一半六年好了一大截，漏斗外的那一半原地不动。差别不在难度——补空格和包一层编辑外壳是一个量级的工程量。差别在于有没有一个指标会因为它变差而变红。

三个问题，先给自己的站定个位

往下读之前，可以先花两分钟回答三句话。三句都答得上来的站，本文后面大半内容可以跳着看。

1. 你站上有多少比例的账户存了卡？这个数决定了后面所有比例乘以多少才是真实影响。存卡率低于两成的站，这件事的绝对量可能小到不值得排期。
2. 用户想换一张卡，最短路径是几步？自己走一遍，别问产品经理。走一遍通常比问一句准确得多，也快得多。
3. 过去半年有多少笔订单是因为卡的问题失败的？如果这个数拉不出来，那本身就是第一个要补的洞。

三句话背后是同一个判断：这件事在你的站上是常青问题还是边角问题。它和结账页放弃率的九个真实成因那一篇处理的场景不一样——那边的用户是第一次来，这边的用户已经买过很多次了，他不是在犹豫买不买，他是在被自己的老账户挡住。

顺带说一句，账户中心这块地方在独立站信任体系的七层结构里位置很靠后，靠后不等于不重要，靠后意味着走到这一步的人已经付出过成本了。

还有一个容易被忽略的连带效应：账户里那张过期的卡会一路跟到结账页。用户带着满购物车走到最后一步，付款失败，才发现问题出在三个月前那次没改成的更新上。结账最后一步本来就是全流程最紧张的一段，放弃率超七成的九个成因里几乎每一条都发生在那儿；把一个陈年问题堆到那儿引爆，代价要比在账户中心解决它高出好几倍。

用户心里那个“编辑”，在你的系统里对应的是几步操作？

一步，还是三步。这个差别用户看不见，但它决定了他失手的时候还剩下什么。

用户走进账户中心，脑子里装的是一个动词：改。改一下有效期，改一下卡号，换成新发的那张。

在他的理解里，这跟改收货地址、改手机号是同一类事。都是我的信息，都存在你这儿，都应该能改。

这个理解不但合理，还是被你自己训练出来的——同一个页面上，收货地址每一格都能改，姓名能改，邮箱也能改。唯独支付方式这一栏，规则完全不同，而界面上没有任何一样东西提示过这件事。

先把这张对照表画出来

这张表是本文所有诊断动作的起点。做法很土：把账户中心里每一个写着编辑、修改、更新的入口挨个点一遍，每点一个填一行。

最后一行和上面三行不是一类东西，但它们在同一个页面上、用同一种样式、顶着同一个动词并排放着。

注意最右边那一列。前三行写没有，最后一行也写没有——用户就算完整地知道你后台在干什么，他手里也不会多出任何一个选项。他不能选择原地修改，那条路根本不存在。这一列后面还会再出现，它是本文最重要的一把尺子。

为什么真的改不了：规范里写着的那句话

卡号改不了不是偷懒，是支付行业的硬约束。这条约束的技术表述在PCI安全标准委员会的官方术语表里。

先看主账号这个词。术语表把PAN定义为能唯一识别发卡机构与持卡人账户的支付卡号。它是整张卡上最值钱的一串数字，也是所有安全要求围着转的那个对象。

然后是两个经常被混着用、其实分工明确的词：

• 掩码：在屏幕、纸质小票、打印件上显示时，遮住PAN的一部分。
• 截断：在电子存储、处理、传输时，直接删掉PAN的一段，让完整卡号无法还原。

一个管显示，一个管存储。你在账户中心看到的末四位属于前者，你数据库里那条记录属于后者。末四位不是你把卡号藏起来了，是你手上真的只剩这四位。

标准用来划线的那个词，是业务需要

掩码那条定义里还有半句，容易被读过去：当没有业务需要查看完整PAN时，使用掩码。

这半句很值得停一下。它划线用的判据不是能不能拿到，是需不需要。

标准的意思是：完成你手头这件事，不需要看到那串完整数字，所以就别看。这是一句关于目的的规定，不是一句关于能力的规定。

把这个逻辑往前推一格：用户要完成的那件事叫我要换一张卡。完成这件事，同样不需要他亲眼见证一次删除、一次新增，以及中间那段什么都没有的空白。规范早就用这个思路划过一次线了，只是没人接着往上再推一层。

你保管的从来不是那张卡，是一个指向它的引用

更彻底的一层在令牌那边。

EMVCo对支付令牌化的说明里有一句定义性的话：令牌在用途上是受限的，比如限定到某一个商户、某一台设备或某一种支付场景。

这句话的分量在于：令牌和卡号最大的区别，不是长得不一样，是它只能在一个地方用。

所以你数据库里那一行到底是什么？不是用户的信用卡，是用户的信用卡在你这一家店的一个投影。Stripe关于保存并复用卡片的文档描述的也是同一件事：你保存的是一个可复用的支付凭据对象，不是卡本身。

账户中心那一页的标题写着我的支付方式，可这一页上列出来的每一行，所有权既不在用户手里，也不在你手里，在第三方那儿。一个页面上如果没有一样东西是这个页面的主人拥有的，那它就不是一份清单，是一组指针。

指针不能被编辑，只能被换掉

指针这个说法不是打比方打上瘾，它直接解释了那三步是怎么来的。

你想改一个指针指向的内容，而那块内容不归你管、你也读不到，你唯一能做的就是：申请一个新的指针，让它指向新的内容，然后丢掉旧的。

这就是删除加新增的技术来源。它不是设计选择，是这套体系的必然结果。

但请注意接下来这句，本文后面几节都从它长出来：技术上必须走三步，不等于用户必须看见三步。这两句话之间隔着的那一段，就是78%的站没走完的路。

这张表不只能用在支付方式上

动词与序列的对照，做完信用卡这一行之后，顺手把整个账户区域扫一遍，往往还能捞出几行。

修改订阅方案那一行值得单独看一眼：很多系统里改方案就是退旧订新，中间会产生一次周期重置。用户以为自己在调档位，系统在办退订加新签。这条线的下游正好接上订阅制的定期扣款与续费管理那一篇讲的东西。

合并账户那一行是全表里最危险的，因为它同时满足三个条件：动词听起来很温和、实现含一次注销、而且完全不可逆。碰到这种组合，第五节讲的那套保护是最低要求，不是可选项。

这张对照表也解释了一个常被问到的现象：为什么有些站的支付方式页那么简陋，只有添加和删除。不是设计师偷懒，是那个页面的能力上限早在选定支付架构那天就被定死了，而做界面的人往往最后一个知道。

这跟AI代理替用户逛店下单那一篇的观察是同一类：一个界面能做什么，越来越多地取决于它下游那些你没写的代码允许它做什么。

界面上的动词，是一份关于结果的承诺，不是一份关于路径的说明

站内拆过的那些毛病，都在说某样东西缺了、错了、没被记下来。这一篇反过来：有一样真的东西，你不该给他看。

到这里可以把话说得更一般一点了，因为这件事的形状在别的地方也会出现。

站内陆续拆过十几种类似的毛病：信息在哪一层被销毁、一次动作有没有留下记录、两套报表为什么算出相反结论、一块信息能不能和另一块放进同一屏、一个算式算到哪儿停了、用户手里还剩几种动作、一次决定的现场站着几个界面。

它们分别站在不同的层上，但有一个共同点：都在主张把某样东西补上、对上、记下来。缺的信息补齐，错位的归因对齐，没记录的动作补埋点。

这一篇是第一次反着走。

一个可以照着跑的检查顺序

它只问三句话，顺序不能换：

1. 用户心里那个动词，在你的系统里对应的是一个操作，还是一串操作？
2. 如果是一串，这串里有没有一步是不可逆的——删除、销毁、作废、解绑？
3. 如果有，这一步之后、下一步之前，用户落在哪个状态？他知道自己会经过那里吗？

三句都问完，通常会得到一个让人不太舒服的结论：这个动词描述的是终点，而你把整条路径原样交给了用户，包括路上那段没有护栏的。

三个能在半天之内跑完的动作

一套说法如果不能在半天之内跑出结果，它就只是一段读起来舒服的话。下面三件事都可以手工完成，不需要任何新数据。

• 第一件，动词与序列对照表。就是上一节那张六列表，一人半天点完整个账户中心。最后一列写没有的行，那个实现细节就不该出现在界面上。
• 第二件，空档盘点。凡是被叫做修改、更新、更换，而实现上含一次删除的地方，中间都有一段用户不知道自己经过了的空白。它有多长、期间账户是什么状态、这时候关掉页面会怎样。
• 第三件，真相三分类。把你打算告诉用户的每一条信息，按知道之后他手里会不会多出一个选项，分成三堆。这一件下一节整节展开。

三种听起来很像、其实完全不同的毛病

这类说法最怕的不是错，是听起来跟别的差不多。所以把三条最容易混的界线标出来。

第一种，动作被环境拿走了。桌面上悬停和点击是两个动作，到了触屏只剩一个，于是原本由其中一个承载的那个意图，在界面上再没有任何动作能表达它。那是能力被拿走了。本文说的是另一回事：那个动作从来就不存在，可界面上明明白白写着它存在。一个是被剥夺，一个是被虚构。

第二种，算式没算完。你把两个工作日这样的半成品递给用户，让他自己拿去跟日历对，最后那一步加法你没做。那里缺的是结果，这里缺的是包装。前者用户拿到的是一堆没加起来的数，后者用户拿到的是一堆没装起来的零件。

这两种的处方方向恰好相反：算式没算完，要把它算完了摆给用户看；动词没兑现，反而有一类真相根本不该摆。看起来打架，其实是同一条判据的两侧——判据是什么，下一节说。

第三种，后端知道却不说。校验失败的时候后端一清二楚错在哪个字段，页面上只给一句输入有误。那是该说没说。本文说的是后端做了什么、前端不该说。同样是没说，一个藏起了用户需要的东西，一个收起了用户不需要的东西。

三句会反复用到的话

第一条，关于动词是什么。界面上的动词是一份关于结果的承诺，它说的是做完之后世界会变成什么样；实现是一条关于路径的说明，它说的是中间会经过哪些地方。用户买的是承诺，不是路径。你把路径摆给他看的那一刻，不是变诚实了，是把一件本该你做的事退回给他做了。

第二条，关于动词还悄悄承担了什么。编辑和删了重建，在结果上等价，在失败模式上完全不等价——编辑失败，旧值还在；删了重建失败，你什么都没有了。而用户是凭动词判断风险的：看见编辑，他就按编辑的胆量行事，反正改错了再改回来。动词同时是一份风险声明，而在这个地方，这份声明是假的。不是有人故意骗他，是没有人意识到动词在做这件事。

第三条，关于约束是怎么落到用户身上的。合规那条约束是真的、不可谈判的。但从这条约束推不出用户必须自己删了再加，那一句是没有人站出来的结果。

一条外部约束落到用户身上，从来不是它自己走过去的，中间一定有一段路是你没走。而每一条你没吸收的约束，最后都会以体验差的形式出现在你的转化率里——报表上永远不会写它的来源是一份技术规范。

这套检查什么时候不适用

把边界写清楚，它才不会被拿去当万金油。有三种情况，这套检查给不出有用的结论。

• 那串操作里没有不可逆的一步。比如改一段商品描述，实现上可能是版本化写入好几张表，但失败了旧版本还在。这种复杂度是纯技术复杂度，用户看不见也不需要看见，本来就该包起来，没什么可讨论的。
• 用户本来就想执行那个销毁动作。他点的就是删除账户、清空购物车、注销订阅，动词和实现一致。这时候要做的是把状态和后果讲清楚，让他确认一次，而不是把它包成别的东西。
• 中间那个状态对用户是有价值的。比如草稿箱、待支付订单、预约锁位——这些中间态是功能的一部分，不是缝。判别很简单：中间态有没有自己的入口和名字。有名字的是功能，没名字的是缝。

还有一类边界情况值得提一句：销毁的是数据，但那份数据用户还能从别处拿回来。比如删掉一张已保存的收货地址，而他手机通讯录里就有。这种情况风险等级要下调一档，但别下调到零——他能拿回来不等于他此刻愿意去拿。

最后补一句用法上的建议：这套检查最适合在两个时间点跑。一个是接手一个陌生系统的头两周，那时候你还没有被现有实现驯化，看得见哪些动词是虚的；另一个是每次大改版之后，因为新功能几乎必然会引入新的错配。过了这两个时间点，同一个人会越来越难发现问题，因为他脑子里装着完整的实现图，卸不掉。

还有个小提示：跑这套检查别带产品经理，他会抢在你点下去之前告诉你这里其实是删了重建。而你要测的恰恰是一个不知情的人点下去会以为发生了什么，那份不知情本身就是仪器。

哪一类真相该讲给用户听，哪一类讲了只是把架构图贴在收银台上？

判据不是这条信息真不真，是知道之后他手里会不会多出一个选项。

可用性这个领域里，几百条准则绝大多数在说同一件事：让用户知道发生了什么。别藏状态，别偷偷跳转，别在后台默默改东西。

然后有这么一条准则，标题里大大方方用了一个词：假的。用一个假的编辑流程。

这不是行业开小差，它是那条大规则的正确形态，只是多数时候看不出来。

用户要知道的从来不是发生了什么

把这句话拆开：用户需要知道的是我要的那件事成了没有，而不是你那边具体做了什么。

这两句在绝大多数场景里恰好重合，所以没人注意到它们是两句话。你点提交，订单就生成了——发生了什么和成了没有说的是同一件事。

只有在实现和心智对不上的地方，这两句才会分开。一分开，你就必须选一句说。选错的那一边，就是本文开头那个78%。

三类真相，一张表

判据就一句：一条信息该不该给用户看，不看它是不是真的，看知道之后他手里会不会多出一个选项。多不出选项的真相，展示出来只剩成本。

回到第二节那张对照表最右边那一列。改已存的卡这一行，那一列写的是没有。所以它属于第三类。

那这跟骗人的界线在哪儿

这问题必须回答，不然这套判据会被拿去给各种糊弄找理由。

界线其实很清楚：你可以包装过程，不能包装结果。

你把删除加新增包成编辑，用户对世界的判断是什么？这张卡的信息现在是新的了。这个判断完全正确。所以这是翻译。

你把不含税的价格包成最终价，用户对世界的判断是什么？我付这么多就能拿到货。这个判断是错的。所以这是欺骗。

一句尺子：包装之后，如果用户对现在世界是什么样的判断仍然完全正确，那是翻译；如果他的判断变错了，那是欺骗。真话假话这个二分法在这儿不好用，好用的是判断准不准。

顺手把一个看似矛盾的地方解掉

常见的说法是：像送达日期这种算到一半的东西要算完了讲清楚。可本节又说有一类真相不该讲。两句话放一起像是打架。

用刚才的判据一量就分开了：送达日期属于决策型——他知道是周四还是下周二，会改变买不买、买不买加急。那是必须讲的第一类。

后台先删后建属于实现型——他知道了照样只能点那一个按钮。那是不该讲的第三类。

两句话给的是同一条判据在两端的读数。真正一致的那句是：凡是能改变用户选择的，一个字都不能少；凡是改变不了的，一个字都不该多。

还有一类必须讲，很容易被误分进第三类

假编辑流程也不是万能外壳。有几样东西不管你怎么包，都得说：

• 要重新输入完整卡号这件事，必须提前说。它属于第二类。用户以为只改一个月份，结果面对一张空表，这个落差本身就会让人放弃。一句话就够：为了安全，更新时需要重新填写完整卡号。
• 这张卡正绑着订阅或分期，必须说。换卡会影响下一次扣款，这直接改变他的选择——他可能想先看看下次扣款是哪天。
• 这张卡是默认支付方式，必须说。换完之后默认还是不是它，影响他要不要再检查一遍。

三条的共同点：它们都会让用户接下来的动作不一样。而删还是改，不会。

顺带一提，这条判据在别处也好用

这套三分法不只管信用卡。任何一个你正在犹豫要不要向用户解释的技术细节，都可以拿去过一遍。

库存显示为什么有延迟、图片为什么走了另一个域名、优惠为什么是在下一页才减掉——挨个问一句：他知道之后，手里会多出哪个选项？

多不出来的，就别写在页面上。把架构图贴在收银台上，顾客不会觉得你坦诚，只会觉得排队变慢了。

反过来的一个例子：什么时候必须把实现讲出来

第三类真相不该讲，这句话有一个重要的例外，值得单独立一段，因为它很容易被拿来当挡箭牌。

例外是：当这个实现细节会影响用户对时间的判断的时候，它就不再是纯实现了，它变成了第二类。

举个具体的：退款走原路返回，你这边点了退款，钱到账要三到十个工作日，这段时间取决于发卡行。这条从架构上看纯属实现细节——用户知道了也改变不了什么，他没有第二个选项。

但它必须讲。因为不讲的话，用户会按自己的默认预期去等，等到第四天开始怀疑你没退，第六天开始联系客服，第八天开始写差评。他手里确实没多出选项，但他多出了一段需要被安放的等待。

所以第三类真相的完整判据要补一句：知道之后既不多出选项、也不改变等待方式的，才是真正不该讲的那一类。退款到账时间改变了等待方式，先删后建没有——用户点完编辑就走了，他不会在那儿等什么。

退款这条线上的口径怎么统一，在退款与退货RMA的处理流程和退换货政策页怎么写两篇里都有细说，这里不展开。

这套三分法还有一个副产品：它能让文案评审快很多，因为讨论会收敛到一个能回答的问题上。那些看着无关紧要却真能提转化的设计细节里有几条也是靠同一个思路筛出来的。

从旧卡被删到新卡生效的那几秒，用户的账户处于什么状态？

一张卡都没有。而这段空档不在任何一份需求文档里，因为没有人是故意造出它的。

把时间轴拉开慢放一遍。

用户点删除，弹窗问你确定吗，他点确定。旧卡没了。然后他要点添加新卡，输16位数字，输有效期，输安全码，输持卡人姓名，可能还要选或者重填账单地址，最后点保存。

从旧卡消失到新卡保存成功，中间这段时间，这个账户的支付方式是空的。

短的话十几秒，长的话——测试记录里有人花了4分钟，有人光是找入口就花掉2分多钟。如果他中途去翻钱包、接了个电话或者关掉页面，这段空白会一直留在那儿。

这段空白没有出现在任何一份文档里

它不是谁设计出来的。没有人在需求里写过让用户经历一段没有支付方式的状态，它是两个正常功能拼在一起之后自然出现的缝。

删除卡片这个功能，单独看没问题。添加卡片这个功能，单独看也没问题。问题出在没有人把这两件事当成一件事来看，而用户从头到尾都当成一件事。

盘点它很简单，三列就够：

放对照行是有用的：它让第一行的异常一眼可见，也让讨论没法退回到用户就该小心点这种说法上。

一份为残障用户写的标准，恰好把这条线划在了正中间

本文最意外的一份佐证来自无障碍规范。

WCAG 2.2的成功准则3.3.4，错误预防（法律、财务、数据），AA级。它的适用范围原文写着三类页面：会让用户产生法律承诺或金融交易的页面、会修改或删除数据存储系统中用户可控数据的页面、以及提交测验答案的页面。

第二类正中靶心。而且这份标准还专门解释了什么叫用户可控数据：用户能通过有意的动作去更改或删除的、他自己可见的数据，官方举的例子就是更新账户里的电话号码和地址。

已保存的信用卡，完整符合这个定义。

真正漂亮的是它的意图声明

3.3.4的意图那一段里有一句划界的话，值得逐字读：

提到修改或删除用户可控数据时，其意图是防止数据的大规模丢失，比如删掉一个文件或一条记录。其意图并不是要求对每一次保存命令、或者对文档、记录等的简单创建与编辑都做确认。

这段话把两件事划到了标准的两侧：删掉一条记录，要给保护；简单的编辑，不用给。

然后你回头看账户中心里那个按钮。

用户站在这条线的一侧，他以为自己在做的是简单的编辑。系统站在另一侧，它正在删掉一条记录。同一个动作，同时落在一条无障碍标准划出来的界线的两边。

而标准划这条线用的判据不是操作有多复杂，是错了之后能不能挽回。这也正是编辑和删了重建真正的差别所在——不是步骤多少，是失败之后你还剩什么。一份为读写困难和运动障碍用户写的文件，在这里比大多数产品需求文档更准确地描述了一个普通商业功能的风险结构。

标准给了三条出路，删卡重加一条都不占

3.3.4的要求是三选一满足：可撤销、已校验、已确认。挨个对一遍：

• 可撤销：删掉的卡号你自己也拿不回来——这正是合规要求的效果。这条从技术上就不可能满足。
• 已校验：系统压根不知道他打算加一张新的，没有任何东西可校验。这条不适用。
• 已确认：这条看起来满足了，83%的站都有那个确认弹窗。

但那个弹窗问的是什么？你确定要删除这张卡吗。

它确认的是这一步，不是这件事。它没问的是：你确定要在还没有新卡的情况下，让账户处于没有支付方式的状态吗。

确认框的措辞，暴露了系统对用户意图的理解到哪一层为止。它问删不删，说明在它眼里这就是一次删除；用户点确定，是因为在他眼里这是换卡的第一步。两边都以为自己在确认同一件事。

最贵的一次失手：删错了那张

测试记录里有一个更糟的结果：一位参与者在替换的过程中，误删了刚刚添加好的那张新卡。

这不难理解。列表里两张卡都只显示末四位，视觉上高度相似，位置还刚刚变过。他要做的判断是——哪一张是旧的。而系统能给他的全部信息，是四个数字。

这就是那段空白最贵的形态：他不但经过了一段没有卡的状态，还带着一个错误结果走了出来。而这一切，在后台日志里是两次成功的删除和一次成功的新增，三个动作全部返回200。

同样的空档，在账户之外还有几处

先加后删这条原则一旦立起来，会发现它能管的地方比想象中多。

最后一行看着不痛不痒，其实在做社会证明与内容资产那一类工作时经常出事：主图空窗期正好被抓取程序撞上，那张页面在索引里就带着一个坏图待上一阵子。

换绑手机号那一行更值得警惕：解绑之后、绑定之前，如果他恰好在这时候被登出了，找回账号的唯一凭证刚好不在了。这种概率极低但后果极重的组合，正是先加后删这条原则存在的全部理由。

做过3DS验证改造的人对这种形状会很熟悉：验证跳转出去再跳回来，中间那一段用户既不在你的页面上，也没在支付方的页面上完成任何事。区别在于3DS那段空白是被规范强制的、有明确回调的，而换卡这段空白没有任何人为它负责。

这张表还顺手回答了一个常被问到的问题：为什么换个顺序也要排一个迭代。因为它意味着某个瞬间要允许新旧两份数据共存，而共存常常撞上唯一性约束或对账口径。Magento 2订单状态与状态机那一篇里讲过类似的情形：一个看起来只是顺序问题的改动，真正的成本在状态定义那一层。

假编辑流程具体怎么做，才不会在原地挖出第二个坑？

顺序、失败落点、跟着卡走的那三样东西。做错任何一样，你只是把旧坑换了个位置。

假编辑流程说穿了只有一句：把删除旧卡和添加新卡这两件事，装进一个叫编辑的壳里，用户从头到尾只经历一个任务。

测试记录里有正面样本。一位参与者在某个百货站点点进已存卡片的卡号字段，掩码消失、安全码字段同时出现，她可以直接把新号码打进去。她的反应是：这样好，我不用把所有信息重新弄一遍。

另一位在服装站遇到同一个设计，实际上他把每一个字段都重新输了一遍——字数一个没少，感受完全不同。他的评价是这比又加又删整套走一遍要顺。

有意思的地方就在这儿：省下来的不是输入量，是任务的完整性。一次做完一件事，和分两次做完两件事，中间那道坎比键盘上的活儿贵得多。

第一件必须做对的：顺序

先加新的，成功之后再删旧的。绝不能反过来。

这条听着像废话，但它是整个改造里唯一一处技术上真正要动脑筋的地方，因为它要求你在同一时刻允许两个凭据共存——哪怕只共存两百毫秒。

顺序做对了，上一节那段空白直接消失：任何时刻用户账户里至少有一张可用的卡。不是把空白缩短了，是把它取消了。

顺便说一句，这也是唯一一处不做就白做的改动。壳包得再漂亮，里面还是先删后加，那你只是把一个坑重新刷了层漆。

第二件：失败要落回什么都没变

新卡校验不通过、网关超时、用户中途关掉页面——这三种情况的落点必须是同一个：旧卡还在，什么都没变。

这就是上一节标准里那条可撤销的可行版本。你没法让删掉的卡号复活，但你可以让失败根本不触发删除。

三种失败的提示写法也不一样：

• 校验失败：告诉他哪一个字段有问题，同时明确说原来的卡没有动过。第二句比第一句重要，因为他此刻最担心的是自己是不是把卡弄丢了。
• 网关超时：明确说这次没有成功，原卡仍可使用，请稍后再试。别用一个转圈图标把人晾在那儿。
• 中途离开：什么都不做。不要有半保存这种状态。

第三件：跟着卡走的那几样东西

这是最容易被漏掉的一件，而它在测试记录里已经出过事了。

有位参与者删卡重加之后，差点没注意到账单地址被默认成了最近添加的那个地址，而不是他原来那张卡绑的地址。他的原话带着惊险：我得在这儿小心点。

换卡的时候，至少有四样东西必须跟着一起过去：

注意最右边这一列的时间跨度：只有最后一行是当场暴露的，其余三行的账都在以后结。其中订阅那一行最狠，一个计费周期之后才发作，那时候没有人会把它和一次改卡联系起来。

第四件：让两张卡在列表里能被分清

误删的那位参与者不是马虎，是信息不够。末四位是唯一的区分依据，而两张卡恰好都以那四位结尾的概率并不低。

至少补三样，都不涉及敏感数据：

• 卡组织标识：Visa还是万事达，一个小图标解决。
• 有效期：这本来就是用户要改的那个东西，把它显示出来，他自己就能认出哪张是旧的。
• 添加时间：添加于某年某月。这一条对分清新旧最直接。

过期的卡还应该单独标一个状态，别和有效的混在一起排。一个已经过期的卡片在列表里长得和有效卡一模一样，等于每次结账都在给用户出一道题。

三档实现深度，按能吃下多少来选

第三档值得多说半句：主流收单方普遍提供某种形式的卡片信息自动更新，能在发卡行换号或换有效期时同步更新你保存的凭据。它能把这个问题的发生量直接砍掉一大块——但它砍不掉的那一部分，恰恰是用户主动想换一张不同的卡，也就是本文全篇在讲的那种。

什么时候不该假装

一条边界：如果这次操作会真的删掉一样用户可能还想要的东西，那就不能包。

比如用户要删的是唯一一张绑着进行中订阅的卡，而他并不打算换新的——这时候该做的是拦一下，告诉他这会影响哪几笔订阅，而不是悄悄办完。

判据还是那一条：他知道之后会不会做不同的选择。这里的答案是会，所以必须说。到底该说到哪一层，尺子在上一节。

上线之后先验这四件事

改造做完，验收别只看能不能改。下面四条按顺序验，每一条都是十分钟能做完的手工测试。

1. 故意让新卡校验失败，输一个作废的测试卡号。要求：报错清楚，并且明确告诉用户原来那张卡没有动过。然后回到列表确认旧卡确实还在。
2. 在提交的瞬间断网，或者直接关掉标签页。重新登录，检查列表。要求：旧卡在，没有出现半张新卡。
3. 用一个绑着订阅的账户走一遍换卡，然后去后台查那笔订阅现在绑的是哪一个凭据。这一条最容易挂，因为它的结果在界面上完全看不出来。
4. 连着加两张末四位相同的卡，看列表里能不能分清。分不清就回去补第六节说的那三样标识。

第三条建议做成自动化用例常驻，跟把备份与巡检交给cron那批任务挂在一起跑就行，因为它是唯一一个失败后要等一个计费周期才暴露的。这类延迟暴露的问题，靠人工回归几乎一定会漏——道理和备份要靠恢复演练才算数那一篇是同一个：没有被验证过的正确，和不正确在账面上长得一模一样。

还有一条容易跳过的收尾：把新流程同步给客服。他们话术库里那段先删除再添加的标准回答，上线之后就变成了误导。DTC配送政策页怎么写里提过同一个坑：页面改了、话术没改，客服还在按老口径回答，结果用户被指到一个已经不存在的按钮上。

还有一处细节值得顺手做掉：把支付方式页的入口从账户菜单的第四五位往上提。这块地方的访问量本来就低，入口再藏一层，用户只会在结账被卡住的时候才找到它，而那是全站最不适合处理这件事的时刻。提一个位置，成本约等于零。

不加一行埋点，先算哪五个数？

其中一个是全站极少见的事前指标——它告诉你谁会在哪一周被挡在门外。

这五个数有个共同点：都不需要新埋点。三个来自库里已有的字段，两个手工点一遍界面就能得出。

保哥在给客户排这类改造的时候，习惯先把这五个数拉出来再谈方案——因为它们几乎总能推翻一两个会议室里的默认判断。

指标一：动词兑现率

算法：账户中心里所有写着编辑、修改、更新的入口中，点进去之后真的只需要改那一项、不需要重来一遍的比例。

分母是动词的个数，不是用户数，也不是会话数。这一点让它和你看板上任何一个指标都不一样。

怎么收：一个人，半小时，一张纸。挨个点，兑现的记1，没兑现的记0。

怎么读：这个数第一次跑出来通常在六到八成之间，而团队的心理预期是接近满分。差距全部集中在支付相关的那几行——这本身就是结论。

指标二：删卡到加卡的间隔，和中间掉队的人

算法：同一账户里，一次删除卡片事件到下一次成功添加卡片事件之间的中位时长；以及删了之后24小时内没有加回来的账户占比。

为什么它最值钱：这批人的因果位置极其干净。他们已经登录、已经找到了账户中心、已经找到了支付方式页、已经动手了——意图强到不能再强。然后在你的流程里掉了队。

获客的钱在很久以前就付过了，这批人是全站单价最高的一种流失。

怎么读：中位间隔超过两分钟，说明添加入口不好找或者表单太重；24小时未加回的比例超过一成五，说明这条路上有人被劝退了。

指标三：过期卡存量，全站少见的事前指标

这是五个里最特别的一个。

算法：已保存的卡片中，有效期落在未来60天内的占比。一句查询就出来了。

它特别在哪儿：你的看板上几乎所有的数都是事后的——转化率、弃单率、退货率，全都在描述已经发生的事。这一个描述的是还没发生的事。

它的价值也不在这个百分比本身。真正值钱的是它是一份可以按周排期的名单：你知道哪些人会在哪一周被挡在门外。

行业默认的处理顺序是等扣款失败了再去挽回，而挽回是整条链上最贵的一环。这个数让你把整件事往前挪45天，从失败后追回变成失败前提醒。同一件事，两种成本，差着一个数量级。

指标四：支付方式页的空转率

算法：进入支付方式页、什么都没改、又原路退出去的会话占比。

怎么读：它高，说明有人想改但没找到怎么改。开头那位绕了一圈才确认改不了的参与者，在这个指标里就是一条空转记录。

它和指标一强相关，但不能互相替代：指标一是你量出来的能力，指标四是用户实际撞上的墙。

指标五：一张卡都没有的活跃账户

算法：有过购买记录、且最近一年有活跃行为、但当前保存的支付方式为零的账户占比。

怎么读：这批人里有相当一部分是删了没加回来的。拿它和指标二交叉，能定位到具体是哪一批、什么时候走的。

顺带一提，这个数在上过订阅制的站上尤其要看——一个绑着订阅、却没有可用支付方式的账户，是一颗定时的扣款失败。

把指标一和指标二交叉起来看

右上那一格是本节要重点说的：很多编辑其实是删了重建，但删完之后几乎没人掉队。团队看到这个组合，第一反应几乎一定是——看来用户不介意，这事不值得改。

更常见的真相是另一回事。

会走的人早就走了。今天还留在你账户中心里、还愿意为了换一张卡折腾四分钟的，是你的重度用户；重度用户什么都能忍，而他们本来就不会流失。你测的是一群对这件事最不敏感的人。

判别法：把这一格里账户的历史订单数拉出来，和站均比一比。明显高于站均，说明样本已经被筛过了——你手上这批数据的分母，是这个问题自己挑出来的。

这类事在别处也有对应形态。从行为数据读懂用户心理那一篇讲的是热图上红的地方未必是用户真正在意的地方；这里则是记录都在，但产生记录的那批人已经不具代表性了。一个是缺数据，一个是数据齐全而分母是筛过的，后者更难被发现，因为它看起来什么都不缺。

五个数各自最常见的误读

指标算出来只是第一步。读错了比不算更糟，因为它会带着数据的权威去支持一个错误决定。

过期卡存量那一行要多说半句。它很容易被做成看板上一个百分比，然后每周开会看它涨了还是跌了。这么用等于把一份名单降级成了一个数字，而名单能做的事，数字一件都做不了。

什么该进看板、什么只是看着好看，在砍掉虚荣指标、定准北极星指标那一篇里有完整方法，本文这五个数可以直接挂进那套体系的自助服务一档；指标分几层、谁看哪层，一套靠得住的五大指标那一篇里有现成的分法。

五个数算完之后，建议和站上已有的复购与留存指标放在同一张表上看。这块地方的收益最终要通过那两个数才显形，而它们比转化率慢得多。积分与会员体系那一篇里那套复购口径可以直接借来用，不必另起一套。

为什么“删卡”这个动作在你的报表里根本不存在？

因为决定要不要埋点的那条判据，会系统性地漏掉所有破坏性动作。

翻一下你自己的事件清单，很可能会发现：删除支付方式这个动作压根没有被埋。

添加支付方式大概率埋了，因为它离成交近。删除没有。

这不是谁疏忽。它是一条判据的必然产物，而那条判据几乎每个团队都在用，只是没人把它写下来。

那条没写下来的判据

要不要埋一个事件，绝大多数团队实际用的标准是：它在不在漏斗里。

这条标准平时很好使，它替你挡掉了大量没人会看的噪音事件。但它有一个系统性的盲区：

破坏性动作从定义上就不在通往成交的路上。删除、解绑、退订、清空、取消——它们不是漏斗里的一步，它们是漏斗的反方向。所以用在不在漏斗里当判据，会把它们一个不剩地全漏掉。

于是就出现了本文这个局面：一个问题的全部观测点，恰好落在观测规则的盲区里。不是数据不好拿，是从来没人打算拿。

再加上账户中心整体不在漏斗里

两件事叠在一起，威力就出来了。

第一层，账户与自助服务这个区域整体不在直接购买漏斗里——这是第一节引过的原话。第二层，删除这个动作在任何区域都不在漏斗里。

删除支付方式，同时中了两枪。它落在一个没人看的区域里，是一个没人埋的动作。它在数据世界里几乎不存在。

而它恰好是这一整篇文章里所有问题的发生现场。

最小埋点集合：三个事件

补起来非常便宜，三个事件就够，都是标准的自定义事件。

第一行里那个删除前有几张卡的字段，是这三行里最容易被砍掉、也最不该砍的：删掉自己唯一一张卡，和删掉三张里的一张，是两件完全不同的事，而事件名一模一样。

这和GA4核心指标最常见的四种误用处理的不是同一类毛病：那里是口径本身被读错了，这里是压根只有一个口径，而且它没在算。

客服那一侧，加两个标记

数据补上之前，客服工单是这块地方唯一的窗口。给它加两个标记，成本近乎为零：

• 改不了型：我想换卡但找不到怎么换、只能删掉重加吗、这里为什么不能改。
• 弄丢了型：我的卡不见了、我好像删错了、之前存的那张怎么没了。

改造之后这两类的走向应该相反：改不了型迅速掉到接近零，弄丢了型也跟着掉。

如果只有前者掉、后者没动，说明你只做了外壳没做顺序——用户不再抱怨找不到入口了，但他们还是在经历那段空白。这是判断改造做没做到位最快的一个信号，比任何看板都快。

把情绪和证据分开

工单和差评里的话，按有没有提到具体操作分两堆。

你们网站不好用，这是情绪，它告诉你有问题但不告诉你在哪儿。我点了编辑，结果只能改地址，卡号那一栏是灰的——这是证据，它带着可复现的路径。

第二堆的数量通常远小于第一堆，但价值高一个量级。而且它有个好处：它自带复现步骤，不需要再去问客户一遍。

一句提醒：别急着建看板

这五个数在头两个季度都应该手工算。

原因不是省事。手工算的过程里，你会点开十几个真实账户的支付方式页，看到两张只差末四位的卡，看到那张三年前就过期却还排在第一位的卡。数的过程本身就是那次走查，而看板会把这一段体验彻底省掉，只留下一个数字。

等到这五个数连着三个季度都稳定了，再谈自动化不迟。到那时候你已经知道每个数背后长什么样，看板才不会变成一排没人解释得清的绿灯。

补埋点之前，先确认三件事

埋点这件事最怕的不是漏，是补了一堆之后没人用。上手之前先确认三件事，能省掉后面半年的返工。

• 这三个事件归谁看。如果答案是没人，那就先别埋。服务器日志分析怎么读出抓取预算的浪费那一篇讲过同一个下场——日志天天在写，没人去读，还占着磁盘。
• 事件名要能跟现有命名对上。支付方式删除这个动作，在你现有的体系里是叫payment_method_removed还是别的，先查再定。同一件事两个名字，半年后没人分得清哪个是真的。
• 确认这三个事件不会把卡的任何一位数字带出去。字段里只放账户标识、时间、张数、布尔标记，一位卡号都不要碰。这一条不是提醒，是红线。

第一条最容易被跳过，但它才是决定成败的那条。埋点这件事有个规律：一个没有人固定去看的指标，会在两个季度内失去准确性，因为没人会发现它已经不准了。这个规律和自动化为什么不能放在流程尾段那一篇讲的是同一件事的两种表现。

补埋点这件事本身也有个反直觉的地方：头一两个月的数字大概率会很难看，那不是情况变糟了，是你第一次看见了它。这个坑和第一次把孤岛页面数出来那一篇里的情形一样——问题一直都在，只是今天才有人去数。

再提一句取数口径：算指标二时别把同一账户短时间内的多次删除算成多次事件。连删三张过期卡是一次清理，不是三次流失。按账户加时间窗口合并之后再算，这个数才可读。

一个乐器配件站把这件事修好了，为什么一年之后它又原样长了回来？

四个维度全绿，客服工单归零。而工单归零这件事本身，就是下一次翻车的开始。

这一节写保哥自己经手的一次，方向对、执行对、验收全绿，而且真的解决了问题。问题出在解决之后。

客户是一个出海的乐器与音频配件站，卖吉他弦、拾音器、效果器、耳返和各种线材，主要做德语区、英国和北欧，客单价从20欧到450欧不等。两年前上了一条耗材订阅线：琴弦按月补给，这条线的复购非常好看，也让存卡比例远高于普通电商。

第一年：照着改，四个数全绿

改造就是第六节那三档里的中等档：动词改成编辑，先加后删，失败回滚，列表补上卡组织、有效期和添加时间，账单地址和订阅绑定跟着卡一起迁移。前后约四周。

结果比预期好：

• 动词兑现率从0.62到0.94。
• 删卡后24小时未加回的比例，从18%降到4%。
• 支付方式页空转率降了一半多。
• 客服工单里的改不了型和弄丢了型，两个月内双双归零。

最后那条当时是我们最得意的。工单归零，白纸黑字，谁都没法说这事没做成。

于是在季度复盘会上，账户中心这一项被从复查清单里划掉了。理由写得清清楚楚：已彻底解决，无需持续跟踪。

一年后：它原样长了回来

第二年第三季度，站点上了多币种与多店铺——德语区、英国、北欧各自独立的店铺视图，价格、税率、配送策略分开配。项目本身做得不差。

副作用是：支付方式被按店铺拆开了。同一个用户在德国站存的卡，切到英国站看不到。

他要在英国站下单，就得重新输一遍卡。而在英国站里想换卡，那套假编辑流程压根没生效——它做在原来那套账户模块里，新的店铺视图走了另一条路径。

删了重加，原样回来了。

而这一次，没有任何人抱怨。工单里改不了型和弄丢了型，仍然是零。

第一层：抱怨来自落差，不来自糟糕

为什么没人抱怨，这个问题我们想了很久，答案让人不太舒服。

一年前会抱怨的那批人，他们的问题已经被解决了——他们主要在德国站买，那边一切正常，所以他们没什么可说的。

而现在遇到问题的，是跨站点买东西的用户和新用户。他们没有对照组。他们不知道这个站曾经能好好换卡，所以他们不觉得这是退步，他们觉得网上买东西大概就是这样。

抱怨来自落差，不来自糟糕。一个从来没好过的地方，永远不会有人抱怨它。而客服工单系统能看见的只有落差——它是一个专门测量变化的仪器，你却一直把它当成测量水平的仪器在用。

这句话反过来更难受：我们当初之所以能发现这个问题，正是因为那批老用户经历过别的站的正常流程，心里有个参照。参照没了，仪器就哑了。

第二层：报表为什么一点反应都没有

转化率没掉，复购没掉，订阅续费成功率没掉。所有的季度数字都很稳。

拆开才看明白。受影响的只是同时在两个店铺视图买过东西的那一小撮人——按人数算，占全站活跃账户的3%出头。3%这个数在任何一张汇总报表里都会被抹平。

可这3%是谁？会跨店铺买东西的，按定义就是买得最多、最愿意折腾、客单价最高的那批。他们贡献的营收占比是人数占比的四倍多。

一个改动的影响面，如果按人数算很小、按人的价值算很大，全站汇总会把它彻底抹平。而绝大多数看板只有人数口径，没有价值口径——它们统计的是有多少人受影响，不是受影响的是哪些人。

第三层：预警响了，而且被正式记录进了文档

这一层是整件事里保哥最在意的一层。

多店铺上线两个月后，工程侧注意到一个异常：支付服务商那边重复创建客户对象的计数明显上涨，同一个自然人在不同店铺下被建成了两个甚至三个客户对象。

工程看到了，也分析了，结论是：这是多店铺架构下的正常现象，每个店铺视图有独立的客户命名空间，符合设计预期。

然后这个结论被写进了架构文档的已知行为一节。

这段描述没有一个字是错的。技术上它就是这么回事。问题在于，它同时也是用户在两个店铺之间看不到自己的卡的直接原因——而这一层没有人接着往下走。

一件事一旦被写进架构文档的已知行为一节，它就永久失去了被当成缺陷的资格。它从一个待查的现象，变成了一条对外解释用的依据。下一个人看到它，读到的是这个已经研究过了。

预警不但响了，还留下了书面记录。只是那份记录把它归成了设计如此。

那次改了三处

• 把假编辑流程下沉到账户模块的公共层，任何店铺视图都必须经过它，而不是各自实现一遍。这条是治本的，也最贵。
• 给支付方式建立跨店铺的可见性：卡仍然按店铺授权使用，但列表里让用户看得见自己在别处存过什么，并提供一键在本店启用。
• 在季度复查清单里，把已解决这个状态取消掉。状态只有两种：在跟踪，和已停止跟踪并写明谁批准的。

第三条听起来像流程官僚，但它是三条里最便宜、也最管用的一条。

结果，以及一个没想到的

三个月后，跨店铺用户的重复输卡率降到接近零，那部分人的客单和下单频次回到了改造前的水平以上。

没想到的是另一件事：把跨店铺可见性做出来之后，有相当一部分用户第一次意识到自己可以在其他站点下单。德国站的老客户开始在英国站买那些只有英国站有货的型号。这条路以前不是被禁止的，是没人知道它通。

顺手加的一个可见性改动，带来的增量比修复本身还大。这种事不常有，但它提醒了一件事：你为了修一个漏洞而暴露出来的信息，有时候本身就是一个入口。

如果重来一次

只需要在那次庆功性质的复盘会上多问一句：这个问题修好之后，我们靠什么知道它有没有回来？

当时能回答的只有客服工单。而工单已经归零了——正是因为它归零，我们才认为可以不看了。这个循环里，唯一的报警器被它自己报出的好消息给关掉了。

那次改造并没有错。假编辑流程是对的，先加后删是对的，账单地址跟着走也是对的。我们错在以为修好一个问题就等于处理完了它。

一个问题真正被处理完，是它回来的那天你能第一时间知道。否则你只是把它修好了一次，然后顺手把眼睛闭上了。

这次教训能搬到哪儿去

抱怨来自落差这条，适用范围比信用卡宽得多。凡是你靠用户反馈来监控的东西，都吃这一条。

三个可以直接照搬的动作：

• 任何一次修复上线，同时定一个替代观测点。工单会归零，所以监控不能只挂在工单上。替代观测点最好是一个不依赖用户开口的数——本文那五个数都可以充当。
• 跟踪清单里取消已解决这个状态。只留在跟踪和已停止跟踪并写明谁批准的。这一条几乎不花钱。
• 架构文档的已知行为一节，每季度重读一遍，每条后面补一句它对用户意味着什么。答不上来的那几条，就是下一轮要查的。

第三条的道理和自动内链插件翻车之后改回手动布链那一篇是相通的：没有任何一次改动会主动通知你它破坏了什么，破坏是通过一次次正常的迭代慢慢累起来的。那篇里最后靠的也不是更聪明的工具，是一份得有人定期去看的清单。

跨店铺可见性带来的意外增量也值得记一笔。它提醒了一件容易忘掉的事：用户对你站上有什么，了解得远比你以为的少。这条在做把想再来一次设计进网站体验时也成立——很多所谓的需求不足，其实是那条路从来没被指出来过。

这件事该按什么顺序排进未来两周和下个季度？

两堆改动的分界线只有一句话。分错了，本来一周能上线的六条要跟着躺一个季度。

前面讲的东西不少，但真正吃掉大部分收益的只有前几条。这节把顺序排死。

按投入产出排的十条

1. 把动词与序列对照表做一遍。半天，零成本，它决定后面九条要不要做。
2. 顺序改成先加后删。这一条单独就消掉了那段空白。
3. 失败落回什么都没变，三种失败各配一句文案。
4. 卡片列表补上卡组织、有效期、添加时间，过期的单独标状态。
5. 把删除、新增、离开三个事件补埋上。
6. 算指标三，把未来60天要过期的卡拉成一份名单。
7. 账单地址、默认标记、订阅绑定跟着卡一起迁移。
8. 给客服工单加改不了型和弄丢了型两个标记。
9. 换卡影响订阅时的提示。
10. 接入网关侧的卡片自动更新。

前四条吃掉一大半收益，而且全部在前端，一周多就能上线。第十条价值不低，但它排在最后，因为它要动对账口径，牵扯的人最多。

三档投入

一句老话还是要说：只有最小档预算就老实只做最小档。最忌讳的是拿最小档人力去啃第七条那个迁移——迁移做一半，会留下一批账单地址和订阅绑定半新半旧的账户，比不做更难收拾，而且这种烂账要等一个计费周期之后才浮出来。

改动分两堆，判据只有一句

动不动支付服务商那一侧的对象。

第二堆为什么要拉财务：退款和对账关联的是支付服务商那边的对象标识，你自己库里怎么挪都行，那边的对象一变，历史订单的可退性和对账口径就跟着变。

要留意的是，改动分堆这件事换个场景分界线就不一样：动导航时看的是动不动分类命名与链接地址，动时效承诺时看的是改不改变对外说过的话。这里的分界在第三方那一侧，三条线互不重合，混着用会分错堆。

最常见的翻车方式：把两堆写进同一张需求单。第一堆里六条本来一周能上，跟着第二堆一起躺一个季度。

三条停手信号

• 动词兑现率补到九成以上，删卡后流失却没动。问题已经不在这一层了，多半是账户入口本身没人找得到，或者用户压根没走到这一步。继续在这儿投入是浪费。
• 过期卡存量降下来了，复购没涨。这不是失败。它说明那批人本来就打算走，你只是提前知道了这件事。判断标准这时候要换成被挡住过的用户在之后90天的留存，而不是当季复购。
• 算绝对量。如果整个站一个月只有几十次换卡，那么无论比例多难看，它都不值得一个季度的人力。先算次数再算比例，这个顺序不能反——比例是最容易把小事说成大事的一种表达。

做实验的三个坑

• 分流单位必须是账户，不能是会话，更不能是页面。同一个人两次进来落进不同的组，这个实验从第一天起就是废的。
• 观察窗口必须覆盖至少一个完整计费周期。换卡的账有相当一部分是在下一次扣款时才结的，窗口短了你只能看到当场那部分。
• 别拿完成率当唯一成功指标。误删了另一张卡的那位参与者，在完成率上是成功的——他确实成功地更新了卡片信息，顺便还成功地删掉了一张。顺利完成和达成目的是两件事。

两周排期，可以直接抄

• 第一周前两天：一个人跑完动词与序列对照表和空档盘点表，把账户中心所有写着编辑的入口点一遍。
• 第一周后三天：算指标一、三、五（三个都是现成数据），指标二和四等埋点补上再说。同时把客服近半年的工单按两个标记分一遍。
• 第二周前三天：上第一堆里的第2到4条，也就是顺序、失败落点、列表标识。
• 第二周后两天：补三个埋点，做汇报，把第二堆的东西写成下季度的立项材料。

两周结束，你手上会有一样别人没有的东西：一份写着自己站上每个动词到底兑没兑现的清单。这份清单以后每次改版都能重跑一遍。

立项的时候怎么说

不用估算收益，因为这笔钱已经在账上了。

指标二那批人——删了卡没加回来的——今天就在流失，只是这笔损失分散在无数个没人看的账户里，没有人给它开过发票。你要做的不是预测能省多少，是把已经在发生的事情拉出来给人看。

第一次会上必须有两个人：做支付对接的工程师，他知道哪一步在技术上是真的不可逆；客服，他手上有用户的原话。这两个人不在场，会议会在删到底能不能撤销这个问题上空转半小时，而这半小时本来只需要一句话。

谁该先做，谁可以往后放

• 最该先做：有订阅制或高复购、存卡比例高的站。存卡比例高意味着这个流程被触发的绝对次数够大，改造收益直接。
• 可以往后放：纯游客结账、每次都重新输卡的站。它没有这个问题，因为它没有已保存的卡这个东西——一个功能没做，顺带把这个功能的坑也一起没做，这种便宜不多见。
• 单独提醒一类：刚上订阅制、直接把结账流程复用成账户管理流程的站。结账流程天生是新增逻辑，它只需要往里加，从来不需要改。原样搬进账户中心，出来的就是一个只能加不能改的支付方式页。这类站的动词兑现率通常是全场最低的，而团队完全没意识到，因为那套流程在结账页上跑得好好的。

季度复查，半小时三件事

重跑动词与序列对照表（新功能会引入新错配）、看指标三这一季的名单兑现得如何、翻十条最近的支付方式工单。

还有第四件，是上一节那次教训换来的：确认这一项还在跟踪清单上。如果有人把它划掉了，找到那个人，问清楚划掉之后靠什么发现它回来。

最后把这件事的性价比说清楚

这套改造在预算表上不好看，因为它的收益不出现在任何一个大家熟悉的指标上。所以最后把账算明白。

成本这边：最小档两三个人周，主要是前端。中等档五到八个人周，要动后端和一次数据迁移。

收益这边：它不涨转化率，因为它作用的人群根本不在转化率的分母里——那批人已经买过很多次了。它影响的是老客户的续购顺畅度和订阅的存活率，这两样都要按季度才看得出来。

所以立项的时候不要承诺转化率。承诺三件具体的事：删卡后掉队的人变少、扣款失败的量变少、客服里那两类工单变少。三件都可验证，而且都能在一个季度内看到。

还有一层不太好写进立项材料、但确实存在的收益：做完这一轮，团队手上会多出一张动词与序列的对照表，而这张表以后每次改版都能重跑。它是本文所有产出物里生命周期最长的一个——指标会被换掉，看板会被重做，那张表不会，因为它记录的不是数据，是你自己站上哪些承诺没有兑现。

顺带说一句，这类不在漏斗里、却在长期账上有分量的活儿，站内还有几篇讲过不同侧面，比如配送政策页该把哪些话说在前面和会员忠诚度体系的分层与权益设计。它们和本文的共同点是：都发生在钱已经付过之后，都不在任何一张转化漏斗图上，也都在决定这个用户还回不回来。

最后提醒一句排期现实：这件事很难一次性拿到完整档预算，因为它讲不出漂亮的转化率故事。可行的路子是先用最小档做出前四条，拿指标二和工单的变化去换第二轮预算。做A/B测试那一篇里的一条经验在这儿同样适用：先做那些不需要证明就能上的改动，把省下来的举证成本留给真正有争议的那几条。

最后一句关于沟通：向管理层汇报别从PCI合规讲起，从那位花4分钟删卡重加、还差点删错的用户讲起。技术约束是解释不是理由，而汇报的目的是让人做决定，不是让人理解架构。

常见问题解答

假编辑流程算不算欺骗用户？

不算，前提是你包装的是过程而不是结果。用户点完编辑之后得出的判断是这张卡的信息现在是新的了，而这个判断完全正确，所以它是翻译。反过来，如果你把不含税的价格包装成最终价，用户的判断就变错了，那才是欺骗。判据不是这条信息真不真，是包装之后用户对现在世界是什么样的理解还准不准。这条界线也能拿去做文案评审：用户看到这句话之后，接下来的动作会不会不一样，会就留，不会就删。

为什么已保存的信用卡号不能直接修改？

因为支付合规不允许把完整卡号存成可读可改的形式。PCI安全标准委员会的术语表里，截断的定义是在电子存储、处理、传输时删掉卡号的一段，让完整号码无法还原；掩码的定义是在屏幕和打印件上遮住一部分。你在账户中心看到的末四位不是把卡号藏起来了，是你手上真的只剩这四位。既然读不到完整值，就无法在原值上做修改，技术上只能新建一个再丢掉旧的。

更彻底的一层在令牌那边：EMVCo写明支付令牌在用途上受限，会被限定到某个商户或某种场景，所以你保管的从来不是那张卡，是一个只在你这家店有效的引用。引用不能编辑，只能换掉。

先加新卡再删旧卡，和先删再加，差别到底有多大？

差别在于失败之后用户还剩什么。先加后删的失败落点是旧卡还在、什么都没变；先删后加的失败落点是一张卡都没有，而且删掉的那张你自己也拿不回来。两条路的成功结果完全一样，风险结构完全不同。这也是WCAG 2.2成功准则3.3.4划线用的判据——它管的不是操作复杂不复杂，是错了之后能不能挽回。这条准则给了可撤销、已校验、已确认三条替代路径，而删卡重加一条都不占：卡号删了拿不回来，系统不知道用户打算加新的，那个确认弹窗问的是你确定要删除这张卡吗——它确认的是这一步，不是这件事。

换卡的时候，除了卡号还有哪些东西必须跟着走？

至少四样：账单地址、默认支付方式标记、订阅与分期的绑定关系、列表里的排序位置。其中只有排序位置是当场就能被用户看出来的，另外三样的账都在以后结——账单地址对不上会在下一次付款时被风控挡住，默认标记丢了会在下一次结账时选错卡，订阅绑定丢了要等一个完整计费周期之后才表现为扣款失败，而那时候没人会把它和一次改卡联系起来。验收有个技巧：用一个绑着订阅的账户走一遍换卡，再去后台查那笔订阅现在绑的是哪个凭据。这一条最容易挂，因为结果在界面上完全看不出来，建议做成常驻用例。

怎么判断自己站上这个问题严不严重，需要先埋点吗？

不需要。先算三个用现成数据就能出的数：动词兑现率，也就是账户中心里写着编辑的入口有多少真的只改那一项，手工点半小时就有；过期卡存量，即已存卡里有效期落在未来60天内的占比，一句查询；以及支付方式为零的活跃账户占比。这三个数出来之后再决定要不要补埋点。补的话最小集合是三个事件：支付方式删除、支付方式新增成功、支付方式页离开。还有一条顺序不能反：先算绝对量再看比例——一个月只有几十次换卡的站，比例再难看也不值得一个季度的人力。

为什么删除支付方式这个动作，大部分站都没有埋点？

因为决定要不要埋点的实际判据是它在不在漏斗里，而破坏性动作从定义上就不在通往成交的路上——删除、解绑、退订、清空、取消，它们是漏斗的反方向。这条判据平时挡掉了很多噪音，但它会把这一整类动作一个不剩地全漏掉。账户与自助服务这个区域本身也不在直接购买漏斗里，两件事叠在一起，删卡这个动作在数据世界里几乎不存在。补埋点时还有个心理准备：头一两个月的数字大概率很难看，那不是情况变糟，是你第一次看见了它。这句话最好写进立项材料。

接了网关的卡片自动更新功能，是不是就不用做假编辑流程了？

不是。自动更新解决的是发卡行换号或换有效期时的被动同步，能把问题的发生量砍掉一大块。但它砍不掉的恰恰是用户主动想换一张不同的卡——换了发卡行、换了一张额度更高的、想把订阅扣款换到另一张上。这部分需求只能靠界面来接，而它正是本文讲的那种。所以自动更新排在改造清单第十条而不是第一条：它要动对账口径、牵扯财务和客服，属于按季度推进的那一堆。而把顺序改成先加后删、把失败落点收回到什么都没变，一周多就能上线，收益更直接。

权威参考资料