“现有的规则很简单：相同device_id、相同timestamp、相同payload哈希值，判定为重复。”周哲说，“但问题在于，传输过程可能产生时间戳微秒级的差异，或者网络抖动导致同一个数据包被重复发送但带有不同的序列号。现有规则会漏掉很多。”

会议界面里又进来三个人。

都是技术部的同事，路容在之前的项目里见过他们的名字，但没直接合作过。他们依次打招呼，周哲简单介绍了路容的角色。

“若溪负责设计新的过滤规则，重点解决重复数据包和格式异常的问题。”周哲说，“我们需要在两周内拿出第一版方案，在测试环境跑通，然后逐步优化。”

一个戴眼镜的男同事开口：“重复数据包的判定，我建议加入时间窗口概念。比如同一个device_id在100毫秒内发送的多个数据包，如果payload相似度超过95%，就判定为重复。”

“相似度计算需要解密payload，计算成本很高。”另一个女同事反驳，“每天流入的数据量是tb级别，实时计算不现实。”

“可以抽样，或者只在可疑情况下触发深度检查……”

讨论持续了二十分钟。

路容大部分时间在听，偶尔提问。她的问题都很精准，直指技术方案的核心矛盾和可行性边界。周哲几次看向她的视频窗口，眼神里有欣赏。

会议结束时，分工明确。

路容负责设计重复数据包过滤规则和异常数据检测模块。技术部同事负责搭建测试环境，提供性能监控工具。周哲负责整体协调和向李剑汇报。

“若溪，你这边需要什么支持？”周哲问。

“我需要访问最近一个月‘深蓝’数据清洗的详细日志，包括每个被过滤数据包的具体原因、原始数据片段、处理时间。”路容说，“另外，我想了解这批数据的来源渠道，是直接采集还是通过第三方合作方获取。”

周哲沉默了几秒。

“日志可以给你，下午开权限。”他说，“但数据来源……这部分信息涉密，需要副总裁级别审批。我尽量申请，但不保证。”

“理解。”路容点头。

会议结束。

路容摘下耳机，关掉变声器。房间里瞬间安静下来，只有笔记本电脑风扇轻微的嗡嗡声。她靠在椅背上，闭上眼睛。

脑海里回放着刚才会议的内容。

重复数据包。格式异常。加密负载。

还有周哲提到“数据来源涉密”时，那一瞬间的迟疑。

她睁开眼，打开数据包。

解压后的文件夹里，是数百个加密文件，每个文件大小在几十mb到几百mb不等。文件名格式统一：deepblue_pre_enc_batch7_001.bin、deepblue_pre_enc_batch7_002.bin……

路容随机选择一个文件，用公司提供的解密工具尝试打开。

工具弹出提示：“需要密钥管理服务授权，请登录。”

她登录公司内网，进入密钥管理平台。平台界面简洁，显示着她已申请的权限列表。其中一条：“深蓝计划批次7数据解密权限——待审批”。

状态：审核中。

路容关掉页面。

没有解密密钥，她无法查看数据内容。但文档里描述了数据结构，她可以基于这些描述，先设计过滤规则的框架。

她打开代码编辑器。

手指放在键盘上，停顿。

然后开始敲击。

代码一行行出现在屏幕上。她写得很慢，每一个函数都仔细推敲，每一个判断条件都反复斟酌。过滤规则的核心逻辑是：识别重复数据包，但不过度过滤；检测格式异常，但不误伤正常数据。

这需要平衡。

太保守，达不到提升可用率的目标。

太激进，可能误过滤重要数据。

路容写着写着，停了下来。

她盯着屏幕上的代码，脑海里浮现出另一个场景。

三年前，天启科技“灯塔”项目。她也负责设计数据清洗流程。当时的项目负责人——一个四十多岁、总爱穿格子衬衫的技术总监——在评审会上说：“过滤规则要大胆一点，宁可错杀，不可放过。用户行为数据，干净比完整更重要。”

她当时反驳：“错杀会丢失真实用户行为模式，影响模型训练。”

“那是算法团队该操心的事。”总监说，“我们的职责是提供干净的数据。”

后来，“灯塔”项目上线三个月后，因为数据过滤过度，导致用户画像模型出现严重偏差。产品团队投诉，算法团队甩锅，最后责任落到了数据清洗流程设计上。

而那个说“宁可错杀”的总监，早已调离项目组。

路容深吸一口气。

继续写代码。

但这一次，她的思路变了。

她开始设计一个“激进”的规则——表面上是为了最大化过滤重复和异常数据，实际上，她在规则里埋下了一个微妙的漏洞。

漏洞的核心，在于对加密负载格式的判定。

现有文档描述，payload字段解密后应该是标准json格式，包含固定的几个嵌套字段。但路容知道，在实际传输过程中，可能因为加密算法、网络编码、第三方接口等各种原因，产生一些非标准但依然可解析的变体。

比如，json字符串的开头或结尾多了一个空格。

比如，某个字段的值是空数组[]，但被编码成了空字符串““。

比如，时间戳字段的值是整数，但被错误地传成了字符串。

这些变体，在严格的json解析器里会报错，但在一些宽松的解析器里可以正常处理。

路容设计的规则是：只要payload解密后不能通过严格json解析验证，就标记为“格式异常”，暂时搁置，触发人工审核。

这听起来很合理。

但她在规则里加了一个细节：对于aes-256-gcm加密的数据包，解密过程会生成一个“认证标签”，用于验证数据完整性。如果认证标签验证失败，解密工具会直接报错，不会输出任何内容。

而她的规则，在处理“认证标签验证失败”的情况时，设计了一个特殊的逻辑分支。

这个分支会检查数据包的元数据——device_id、timestamp、来源ip——然后与最近一小时内的其他数据包进行模糊匹配。如果找到相似的数据包，就假设这个解密失败的数据包是重复发送的版本，直接丢弃，不触发告警。

但如果找不到相似数据包呢？

规则会将其标记为“加密负载格式错误”，进入异常队列。