官方公告
支付宝今日凌晨发文称：昨天下午由于我们的一个失误，导致小部分用户在支付时享受了立减优惠，关心我们会不会把优惠追回。有几个事实在此澄清：
支付宝官方没有发送任何资金追回短信，如果你收到了下图短信，千万不要点，以免上当受骗，也请大家帮忙相互转告。
失误是怎么发生的？其实是我们在支付宝某个常规营销活动后台配错了营销模板，把优惠额度和优惠金类型都写错了。
既然是我们的错，成本和责任必须我们自己承担。针对已经发出的营销优惠金，支付宝不会向用户追款，请大家安心。
如果我来做
早上看到支付宝的公告，在大巴上随便想了一些，拿出来和大家讨论下。
运营人员配置错导致的线上故障经历太多了。这里面的责任不能简单的归咎到运营人员。我结合自己的一些经历，从以下几个方面来考虑讨论：
- 角色的缺失
- 防呆设计
- 程序预检
- 沙箱 & 灰度
- AI 审核
角色的缺失
现在大家的审批人都是往上追，领导层到底是对这个方案负责还是仅仅是“知道了，你们去落地吧”？其实审批流很有问题，现在大多数的审批人更像是一个抄送人，没有一个真正负责测试验证的人，这是致命的问题。
防呆设计
之前有一个重大活动,运营配置的参会短信提醒的发送时间，比实际大会时间开始晚了一个月，说白了就是10月选择到了11月，其他都正常。和这次支付宝的故障很类似，谁的责任？严格来说，配置人员、审核人员、产品、测试、程序员都有责任。
为什么产品设计的时候没有这种防呆设计（Poka - Yoke）？这比较考验产品经理的能力，大多数产品经理只能做到正向思维，顺着运营的需求，对这方面的思考很少。出了故障都反应过来了，在选择短信提醒发送时间的地方，最晚只能选择到大会开始前。
“敏捷开发”是把双刃剑，敏捷开发最后落到实处就是快速迭代快速试错。凑合能用、先上再说、出问题再改。
退一步说，程序员在实现产品逻辑的时候也要考虑这种“越界”情况，大会已经结束，大会开始提醒短信也不应该能发送。始终保持用户输入的数据都不可信原则。
实际情况，每天配置n条规则，早麻木了，如果产品上没设计好，出问题是迟早的，配置的运营人员和审核人员。他们是最难做的。
昨天支付宝发生的故障，虽然我们不知道其营销后台是什么样的，但是肯定在交互上做一些防呆设计，是不是可以从选择项上做联动，规避掉一些逻辑漏洞。
防呆设计保护运营，人人有责。
程序预检
运营人员上线页面包含了未对外发布的资源，导致上线之后大量用户无法正常打开页面。最后开始可能审批人很仔细的看了。
架不住大家天天审核一大堆。而且审核只是他们的工作中很少的一部分，通过等于表示我已知晓，并未有一个真正审核把关的角色。
而且还有一些风险，在公司内部能访问的资源，在公司测试根本发现不了，发布上线之后。客户根本无法访问。所以依靠运营人员自检是不可靠的，需要通过严格的程序预检。
针对上面的情况，我在发布之前都会去检测前端资源是否能正常打开，如果不能打开整个系统发布失败，健康检查不通过。拦截了不少类似的故障。当然这是非常简单的一个场景，但是思路是想通的，只是预检的工作量的问题。
程序预检保护运营人人有责。
沙箱 & 灰度
我想灰度肯定是有的，想必昨天黑色5分钟，应该也是很少的一部分用户，比如5%，但是整体基数太大。说实话没做过这么支付宝这么重要的系统，这部分是我自己YY，是不是可以引流一部分线上流量在沙箱里跑1小时？就像我们发布的时候发布第一批必须强制暂停1小时，发现一些大盘数据异常，则无法进入下一步审批环节。
AI 审核
现在大模型可以帮我们去对数据内容按照提示词去进行分类，是不是也可以把营销策略给到大模型去识别是否合理，这里prompt也不是说简单的一句话，根据实际业务来也不一定比直接的代码逻辑简单。
但是这是一个趋势，毕竟我们写在写稿子有 AI 校稿，写代码有 AI review ，审批流为什么不能加 AI 审核呢？公司内部天天谈 AI 的应用，可能觉得明面上的 ROI 太低，导致没有人投入。
就这
时间匆忙就想到这些，希望大家不出故障，2025 没有 bug。
