从邮件归档事故看规则引擎的测试盲区与算法公平

前些日子，我和一位同事复盘了一场非常有意思的线上事故：公司内部在用的智能邮件归档组件，在没有任何预警的情况下，悄悄清理了一批员工的邮件。最初我们以为是容量策略误触，清了就清了，直到数据分析组把被清理的账户清单投到屏幕上，整个会议室静了几秒——清单按姓名和资料性别维度进行透视之后，受影响人群中女性占比达到了87%，远超公司整体的性别比例。于是不少同事抛出了一句玩笑：这系统是不是跟着测试语料学会了“嫉妒”，专挑女性用户的东西删？

玩笑归玩笑，作为质量保障从业者，我太清楚这个说法只能停留在段子层面——系统连真正的情感都没有，更谈不上嫉妒。真正让我重视的，是从“87%这个数字”延伸出来的那条技术闭环：一个没有任何性别字段的规则系统，是怎么在输出上形成如此明显的群体差异的？如果把这个问题拆开找到根因，又能给同类“规则+模型”混合系统的测试留下哪些可以被复用的方法论。这篇文章就把整条溯源链路、根因拆解，以及复盘后我整理的测试改进方案完整写出来，给做内容过滤、自动归档、推荐筛选这类系统的朋友一个真实参考。

1. 事件还原：一封封消失的邮件和一个会“嫉妒”的系统

1.1 第一次收到告警时的直觉判断

我们负责的这个“模拟项目X”自动归档模块，作用是根据发件人、主题、正文、附件以及历史交互行为，把员工邮箱里那些低价值邮件自动整理到归档目录，降低主邮箱的存储压力。业务口号是“让你的收件箱永远清爽”。上线前做过安全评审，测试用例也全部通过，还额外跑了三十天的影子测试，然后选了三个部门灰度推开，整体表现一直很平稳。

那天凌晨告警平台连续推送了三条Medium级别告警，指向数据治理团队的一个部门。告警内容很简单：24小时内归档动作频次超过阈值。当时我的第一感觉是部门正在处理大批量营销邮件，归档多很正常。可早会上业务方反馈的情况完全不同：他们不是嫌归档多，而是有人的邮件“不见了”。不是归档到子目录，是连归档目录里都找不到，直接进了回收站。回收站保留期限只有30天，也就是说，再晚两天发现，这些邮件的原文就彻底无法恢复。

这种“不可逆动作”一出，问题的性质立刻变了。我们暂停了该部门的归档任务，把模块状态切到只读模式，然后才开始一点点往回拉数据。

1.2 数据特征：消失的邮件都有什么共同点

切断删除动作之后，我们第一时间把邮件系统的审计日志、模块的决策日志、以及回收站记录做了关联分析。筛选条件先按模糊记忆来：删除时间范围、发件人域名、正文长度、是否有附件、后续交互行为。去掉十几分钟内连续出现的重复项之后，被删除的邮件具有三个非常整齐的特征：

• 发件人地址是个人邮箱，域名后缀是某个生活服务类的常见服务商。
• 邮件正文长度普遍不超过200个汉字，没有附件，也没有被后来的邮件回复过。
• 邮件主题里出现过“回复”“约”“改天”这一类口语化程度较高的词。

如果只看这三个特征，这套删除逻辑确实是冲着“非正式社交闲聊内容”去的。但当我们把受影响账户清单做一次透视，数据出现了异常：被删邮件最多的两批账户中，实名制资料里性别标注为女性的员工占比达到87%。这个数字远高于公司内部女性员工比例，也远高于这三条特征在这之外的自然分布。换句话说，删除行为不是平均分布的，它是一个集中在前一号人群中的系统性偏差。

1.3 一个反直觉的规律：为什么只有女性受影响

最先怀疑的方向集中在“性别字段上”。但翻代码之后，整个决策链路里根本没有读取任何性别字段。这就很有意思——系统本身不认识性别，但执行结果偏成这样。顺着发件人规则往下查，问题出在“个人邮箱”识别逻辑上。模块判断一封邮件是不是“非工作相关”时，会用外部词库把发件人地址切分成“规范性前缀”和“昵称性前缀”。判断为“昵称性前缀”的邮件会被降权，更容易进入删除流程。

而公司内不少女同事习惯用“英文昵称+数字”或“中文昵称的拼音变体”作为个人邮箱前缀，男性同事在这方面相对更保守，更多使用标准姓名的首字母组合。于是“昵称性前缀”这一条识别规则，实际就等价于把一大批女同事的个人邮件单独筛了出来。规则本身没有主观偏好，但输入数据的分布让同一条规则产生了截然不同的实际影响。

2. 技术溯源：从“嫉妒”表象到逻辑缺陷的本质

2.1 规则引擎的决策链路：它实际上在做什么

很多同事把“智能归档”想象成一个复杂的AI模型在看邮件，其实这个模块的主要决策由一条三层规则引擎完成的。简化后的决策逻辑是这样：

def should_archive_outbound(sender, receiver, payload): # 第一层：发件人识别 if is_local_nickname(sender.email_prefix): # 第二层：内容形态识别 if is_chatty_text(payload, max_len=200): # 第三层：交互信号识别 if not has_recent_replies(receiver, sender): return "hard_delete" # 直接删除，而非归档 return "keep"

三层条件全部命中之后，邮件走了“hard_delete”分支。而测试阶段我们绝大多数用例都控制在“keep”和“archive”两个分支上，对“hard_delete”分支只验证了边界值为零的极少数情况。这是第一个漏洞：测试覆盖度虽然高达九成，但最致命的“hard_delete”路径上的覆盖其实非常薄。

这段逻辑在任何意义上都不“智能”也不“嫉妒”。它只是在发件人前缀看起来像昵称、正文短、且没人回复这三个条件同时成立时，选择了一条预设好的动作。问题不在AI的情感，而在工程上——我们把“闲聊判断”的置信度抬得太高，甚至允许它直接删除而不经过人工确认。

2.2 特征窘境：性别字段与规则匹配的交叉触发

那“性别字段”到底去哪了？答案是它不存在于程序里，却存在于验证所用的特征集里。我们在构造“昵称性前缀”词库时，参考了某公开可用的个人邮箱前缀标注样本，这个样本集中，典型的女性昵称前缀占了七成以上。当时只按照“前缀特征”做了测试矩阵，却没有对这个词库在不同人群中的命中率差异做过分析。

我拉了一份模拟数据，把结果做成了下面这个简单对照：

词库对不同人群的命中率并不均匀，而测试用例的覆盖恰好落在了高命中率区域。于是“伪验证”出现了：所有高覆盖特征都是样本命中率高的模式，真正有偏斜的“中文昵称拼音化”模式反而被低覆盖地放过了。最后这套“中性”规则所导致的删除行为，自然就在表面上呈现出让人误以为系统学会“嫉妒”的模式。

2.3 并非“嫉妒”：关于AI情感拟人化的清醒纠正

我特别想打破一个现在很流行的叙事。每次遇到这种事，标题先来一句“AI学会了嫉妒”，然后评论区开始讨论机器统治。但如果你真正打过日志、追过调用链，你会发现“嫉妒”这种拟人化归纳会严重妨碍你找到真问题。系统没有“偷偷做”任何事，它把每一次决策都写在审计日志里；它在规则明确的前提下运行，只是在某些输入分布下有系统性偏差。

但反过来讲，没有嫉妒心不等于没有责任。系统的目标不该只是“平均表现正常”。当一套规则的结果在特定群体上出现明显倾斜，哪怕代码里没有性别字段，工程团队也必须按“系统性风险”来处理。这是我在这次复盘之后最明显的变化：看一个算法系统是否安全，不再只问准确率，而是问“它的错误集中在哪一群人身上”。

3. 这条链路里藏着哪些隐藏测试盲区

3.1 测试样本的同质化：为什么我们测试了却没有发现

复盘的时候团队问得最多的一个问题：用例都写满了，为什么放过了这种问题？我翻了一圈测试数据，发现问题比想象中简单——测试用例库里的邮箱地址大量来自自动生成器和公开示例数据，这些数据里的收件人大多是英文名、简单拼音、标准格式，几乎看不到“真实公司里习惯使用个人化邮箱昵称的群体”的影子。我们用一个“理想化的世界”去测试了一个“充满习惯和例外”的真实系统。

所以，如果你们也在做此类组件，第一个建议就是：测试数据必须引入真实世界的脱敏样本。只用生成器造数据，永远测不出真实人群的特征分布差异。最好定期从线上抽取脱敏用户资料和邮箱地址样本，作为补充测试集，或者做一层“特征覆盖率评估”：每次上线前统计当前用例在姓名、昵称、域名、拼写习惯这些维度上的覆盖情况，低于阈值的强制补用例。

3.2 回归测试对“存量数据特征”的忽视

另一层盲区是回归测试的设计视角。模块已经稳定运行了六个月，所以这次上线的回归测试只关注“新增规则有没有影响旧的正常路径”，没有关注“新增规则会不会在存量数据特征上产生新式异常”。我把这个类比为修水管：你只验证了水龙头新接的管子不漏水，却没有把水压调到最大、把水质换成泥沙含量高的场景再开一次。旧的路径在新数据特征下会发生什么，被有意无意地默认成“和以前一样”。

我们在后续改进中给回归测试加了一条硬性约束：凡是涉及删除、屏蔽、自动回复、自动归档这类有副作用的数据处理规则，回归测试必须加入一条“非法输入集合”测试，里面放的是边界性样例——例如公司内部真实姓氏清单、昵称变体、多语种混写，而不只是常规路径上的等价类划分。这些用例不是为了测功能，而是为了测“当规则遇到现实世界的混乱时，会不会把人推下悬崖”。

3.3 告警与监控设计的边界陷阱

事件发生后的48小时，其实系统还在继续产生删除动作，因为告警阈值是按全站“已删除邮件总数”设定的，而这个总数一直在正常波动范围之内——一边在删、一边在收，总量从未跌破阈值。问题在于监控维度只有总量，没有分组观察。总量掩盖了局部倾斜：当异常只集中在某一个细分群体时，聚合指标是无感的。

比较有效的做法，是把监控拆成两层：第一层保留总体水位，用于判断容量和整体健康；第二层按关键维度做连续监控，至少包括发件人域名分布、收件人群体属性、正文长度分桶。对涉及删除类动作的系统，还可以增加“删除前一个月无任何交互记录”这类保守条件做二次校验。记录里的“回滚开关”和“延迟删除窗口”也一样要在此层告警中明确标出。

4. 复盘之后：我梳理出的一套防类似问题的测试方法论

4.1 基于人口统计学特征交叉的用例设计

第一件事是建矩阵。不是把所有测试用例堆在一起，而是选几个和业务强相关的可观察特征，然后做两两、三三交叉。对于这次邮件归档模块，我们选的特征包括：邮箱前缀风格、正文长度分段、是否带主题关键词、是否为自动回复、收件人群组规模。把前三个特征做交叉后，用例数量从原来的一百多条扩展到了一千多条。这件事不能手工做，我让测试脚本用参数生成器动态创建用例，再自动过滤掉明显不合法的组合。

设计原则很简单：参数之间不能独立变化，必须考虑联合影响。单独看“昵称前缀”和“正文短”都没问题，但把二者拼在一起，加上“无回复”这个条件，就等于在真实环境下构造了巨大杀伤力。交叉用例的价值就在于让这些“单点合理、组合危险”的情况暴露出来。

4.2 全链路故障注入实操

光靠静态用例还不够。我们给这类规则系统引入了“全链路故障注入”的实践。具体做法是在灰度环境里增加一个“破坏者”角色：它随机在线上样本中修改容易被系统误判的输入，制造虚构的异常样例，例如把正常的邮件样本改成“昵称前缀+超短正文+模拟自动回复缺失”的组合，故意去踩删除分支。每跑一轮，统计被触发的决策分支分布，如果发现某个分支从来没有被触发过，说明测试还没覆盖到真实场景里的那条隐藏路径。

# 模拟异常输入的故障注入脚本（伪代码） for sample in production_samples: mutated = mutate( sample, prefix="nickname", content_len=150, strip_auto_reply=True ) result = rules_engine.decide(mutated) log(result.branch, result.action)

这个玩法很像安全领域里的渗透测试，但目标不是攻破系统，而是找出“规则引擎在现实世界输入上会做出的极端决定”。建议先在灰度集群跑，把影响范围控制在最小，然后逐步扩大到全量。跑过一轮之后我们清理出了好多个“差点被删除”的危险样例，其中一部分最终成为了正式测试用例。

4.3 模型/规则的可解释性审计清单

对于规则系统，比模型系统更容易遗漏的是“可解释性”。我们后来建立了一张审计清单，每次上线前逐条过：

• 每个分支的触发条件是什么，条件是否引用了外部词库。
• 词库样本来源是否有偏向，是否覆盖主要用户群体。
• 每个分支结果是可逆动作（归档/标记）还是不可逆动作（删除/清空）。
• 不可逆动作是否设置了延迟窗口和二次确认。
• 是否存在多个“弱信号”叠加后触发强动作的组合路径。

以“删除”为例，我们的新规范是：删除动作必须至少等待48小时以上，这期间邮件先进入隔离区，随时可以恢复；只有隔离区内再次被确认后才会物理删除。对于所有不可逆动作，还要保证测试中至少有一条用例覆盖“恢复动作”。

4.4 上线前的异常模式推演

最后一块拼图是“异常模式推演”。这不是单纯写测试用例，而是把已经写好的规则当黑盒，从负外部性角度去做推理：假如这个规则被错误配置或者遇到极端输入，最能造成严重后果的是什么场景？我们把它叫作“最坏情况对拍表”，每一行都是“规则 + 输入变化 + 预期极端影响”：

这样做的好处是把“被动发现bug”升级为“主动预估风险”。对拍表可能在很多情况下过度悲观，但正是这种悲观能给产品和技术团队更充分的心理准备，也促使大家提前写好回滚预案。上线之后的那一周，团队每天都会抽取一条对拍场景，把新规则和实际采样数据丢到一起做离线推演，整体效果很稳定。

5. 写在最后：责任边界与一点私货建议

5.1 关于“算法公平”的一种务实理解

这次事件之后，有同事问我怎么用一句话总结，我说：永远不要问“AI是不是不公平”，而要问“哪一类人身上的错误成本最高”。公平本来就是一个多维概念，做规则引擎时可以从两个角度理解：一是输出指标的统计公平，二是决策路径的透明公平。前者看群体差异，后者看是否允许人介入纠偏。对中小团队来说，先把一条规则的事故影响面按人群维度和动作维度拆开看，比任何复杂的公平定义更实用。

有些同事担心过度讨论算法公平会进入伦理旋涡，我认为恰恰相反。工程师可以不懂伦理术语，但必须能回答“我的系统在出错时会让哪类用户付出最大代价”。能答出这个，距离找到系统性偏差就不远了。

5.2 实际经验：五件我希望更早知道的事情

复盘过程中，我整理了五条相当具体的经验，算是给还在写这类系统的朋友的一份私货：

1. 删除类动作一律走“延迟删除+隔离区”，永远不要在决策器里直接做不可逆操作。
2. 决策日志必须包含命中的分支编号，出事时能在十分钟内复盘，而不是靠抓取当时的内存快照。
3. 测试用例要隔着时间维度去验证——例如上线前用上一季度的脱敏真实流量回放一遍，验证旧数据在新规则下不会变色。
4. 监控维度宁可多也不可少，尤其是分组维度和组合维度；告警先设置成“提示级”再慢慢调整阈值，不要直接开静默模式。
5. 扩展词的来源要写清溯源信息和群体覆盖率，不把外部样本集当安全区。

这五条有一个共同的气质：把“不可逆操作”和“智能判断”之间强硬建一层缓冲。很多系统出事，不是因为算法不够准，而是因为给了算法太多信任、太少缓冲。

5.3 留给自己的一条执行备忘

最后再说点感性的。后来那个“AI学会了嫉妒”的段子还在公司内部被小范围传播，我没有着急去解释，因为解释清楚技术根因已经很足够了。倒是那位最早提交告警的同事后来跟我说了一句让我印象很深的话：“我当时以为这是个恶魔，后来发现它只是一个没有边界感的工具。”这句话被我贴在了测试会议室的白板上。

对我来说，测试的乐趣从来不是证明系统有多好，而是找出它会在什么情况下变坏。看日志看到凌晨四点，差一分钟就要把灰度环境回滚的那种心跳，可能很多测试同事都体会过。只要我们还愿意认真面对这类边界案例，那些带拟人色彩的惊悚标题，就永远只是标题而已。