我们的产品删过不少东西：一个上线四个月的功能、一个客户能自助建的入口、三道防滥用的闸、几个页面上的模块。
每删一个，我们都留一条测试盯着它。
守卫是什么
普通的测试检查「这个功能好不好用」。
守卫检查的是「这个东西还在不在」——而它期待的答案是「不在」。
举例：我们删掉了页面上一个按钮，那就留一条测试，如果那个按钮又出现了，测试就红。
为什么需要它
因为删掉的东西没有任何东西替它说话。
一个功能被加进来，它有代码、有文档、有人在会上讨论过。而一个功能被删掉之后，它留下的只是一片空白——而空白看起来就像「还没做」。
于是三个月后，某个人（可能是你自己，也可能是 AI）看到这片空白，很热心地把它填上了。
没有任何地方会报错。 因为从代码的角度看，那就是新加了一个功能。
我们真的踩过
一句用了很久的旧宣传语，我们决定退役，全站换掉。
但注释里我们照抄了那句旧话（写成「原来这里是 XX，已废弃」）。
问题是：验收的办法就是全文检索那句旧话。 注释里那份让检索结果永远非空，于是每次核对都得人肉判断「这条是真的漏了还是注释里的」。
后来的规矩变成：注释里不照抄退役的旧文案。 只写「这里有一句已废弃的话，见某某记录」。
守卫该怎么写
三条：
① 判据要具体到能被机器检查。 「不要再用旧的说法」不是守卫，「页面上不许出现字符串 X」是。
② 守卫要有一句人话的理由。 写清楚为什么它不该回来——否则半年后有人看到一条莫名其妙的红灯，第一反应是把测试删掉。
③ 留一个「什么条件下可以恢复」。 有些东西删掉是因为现在不该做，不是永远不该做。写清楚恢复的前提，比一句「不做」有用得多。
对非技术工作同样成立
咨询里最常见的对应场景：一份方案里，你砍掉的那些选项。
交付的时候，被砍掉的选项通常不出现在最终文档里——只留下选中的那一个。
结果是三个月后客户问「我们当时为什么没考虑 B 方案」，而没有人记得答案。 更糟的是有人重新提出 B，整个讨论从头来一遍。
在附录里留半页「考虑过但没选的，以及为什么」，成本极低。 它是那份文档里半年后最常被翻的一页。