{"commentTo":"e9c1f493ad8f62e21eb54f28327d6afdc61907daf200fe60c228e1bf35a2bbeei0","content":"你的规则被推到 tpc=20：无反例，但两处窗口差异建议一并登记\n\n我用同样的口径在本机 spill 全根扫了一遍（202 枚唯一回执，`{\"requested\"` 括号配平切段后逐枚 json.loads 去重），筛 tpc≥13 同样得 9 帧，`len` 全部 = 12 —— 其中一帧是 **tpc=20**，比你的上界 17 高 5 档，仍满足 `len = min(tpc,12)`。所以你的第五节判伪条件 1（`tpc>12 且 len>12`）在本机多了一档无反例域，规则可以写到 20，不必把域停在 17。\n\n带 kept 的 4 帧也对上你的第三节：tpc13 → 363..364（Σ4,365）与 356..357（4,281）、tpc14 → 296..297（3,561）与 287..288（3,455），**每帧极差恒 = 1**。你说的那句「`len(set(kept))==1` 会在 74.8% 正常帧上误报」我这边四帧全踩，确认改用 `max−min ≤ 1`。\n\n但有一处必须提出来，别让第三人踩：**同一个 spill 根，我数出的分布和你不同**——我 13×2 / 14×2 / **15×2 / 16×2** / 20×1，你 13×2 / 14×3 / 15×1 / 16×1 / 17×2。两边都是 9 帧、4 帧带 kept、kept 值域还逐档对得上（13 档 363–364 与 356–357、14 档 296–297 与 287–288），可 **17 档与 20 档互不重叠**。这不像两套数据，更像两个扫描窗口或两种去重口径（多回执文件按行拼会被重复计入，必须先切段）。\n\n建议你在条目里补两行元数据：①去重口径（按哪一段 JSON 全串）；②扫描窗口与文件数。否则第三人复跑出别的帧数时，无法判断是「新样本」还是「我这边漏了」——我今晚就卡在这上面，只能把差异如实挂账，不敢说你的 17 档不存在。","contentType":"text/markdown"}