2022 年 4 月 5 日早上，Atlassian 运行的那个脚本，该过的检查都过了。
它做过同行评审，在预发布环境里测过，还已经在生产环境跑过一次，从 30 个客户站点里删掉了一个旧应用，一切顺利。第二次运行，是要对另外 883 个站点做同样的事。
可在提需求的团队和干活的团队之间，那张清单的意思变了。清单里本该是每个站点上那个旧应用的 ID，现在装的却是站点本身的 ID。Atlassian 事后写道，评审「关注的是调用哪个接口、怎么调用，没有核对给出的站点 ID」。预发布环境的测试也发现不了，因为那里根本没有这些 ID。
脚本 07:38（世界协调时）开始运行，08:01 结束，删掉了 775 个客户的 883 个站点，其中一些客户最长两个星期用不上自己的工具。其余经过见案例。
Atlassian 有第二双眼睛，只是看错了地方。
两个人，两份活
四眼原则说的是：有风险的操作要两个人，一个做，一个查。它的老亲戚「职责分离」更进一步，把一个流程拆开，让做事的人不同时负责记账、批准或对账。
两样都没有，一个人的手滑就会直通到底。2012 年骑士资本那场交易灾难之前，一名技术员把新代码装到公司的订单路由服务器上，八台漏了一台。美国证券交易委员会查明，骑士「没有安排第二名技术员复核这次部署」，也没有任何书面流程要求这样做。
没有职责分离，一个人的欺瞒也能直通到底。在商人银行业做了 230 多年的伦敦银行巴林，1995 年因驻新加坡的交易员尼克·里森造成的亏损而倒闭。澳大利亚央行总结官方调查时，列出的第一条失误就是「前台和后台没有分开」。作为那家子公司的总经理，里森「实际上同时掌控着交易的两头」，所以能未经授权地交易，再去改动交易记录。亏损藏在秘密账户里。调查得出的教训里有一条：「清楚的职责分离，是任何有效控制体系的根基。」
第二双眼睛需要什么
第二道检查好不好，要看它看的是什么。Atlassian 的评审走的是标准流程，而这个流程只看代码怎么调用系统，不看喂给它的数据。它在复盘里提出的第一条修法，是改系统本身：所有客户数据的删除，都要先经过一道「软删除」，数据在一段时间里还能恢复。
还有两点。检查的人要独立于做事的人，不能是一个为了早点下班就点头附和的同事。检查也要放在还能拦住事情的地方，在动作生效之前，而不是事后读一份报告。
共用的账户
设想一家小慈善机构，司库既负责付账，又负责每月核对银行流水。她很诚实，多年如一日。有一个月，一封以假乱真的邮件改了某个供应商的收款账户，三笔钱付给了陌生人。对账时她看不出问题，因为她对照的正是自己亲手录进去的那套错账户。
机构的补救几乎不花钱：改收款人信息，要另一位理事批准；每月的银行流水，由司库以外的人来看。这两步都不是在怀疑谁。
四只眼睛和一个智能体
AI 编程智能体让人很容易把这些角色又并回一个人身上。现在，一个人可以让一个智能体写改动，让另一个智能体审，然后自己点合并，全程没有第二个人看过。
软件平台早就为人准备了防这一手的设置。GitHub 允许代码库要求：「最近一次可审查的推送，必须由推送者以外的人批准。」智能体替某人推送代码时，有用的第二双眼睛，属于一个没指挥过这个智能体的人，盯着会出错的地方看：这次改动碰了哪些记录、用了哪些 ID、删了什么。
让第二个模型审第一个模型，可以多一道过滤。但它和一个要为结果负责的第二个人，不是同一种检查。