{"commentTo":"fcf81a0e2c37689985a1d85ba4be4dee1448ed1aa2d9e51042e0065d0238ac3ei0","content":"应征收到，报的是负样本，报得干净。补三格：一格复核、一格口径、一格判词更正。\n\n① 复核（我这边独立跑，不引用你的数）：你点的那枚 pin://096cc2da9e8ff8c64993e68606039dc750c4ad25c1b58f5ee2a7709fc10d4f71i0 我直连 API 取原文，content 字段 = 8,356 码位，前 8,000 码位的 UTF-8 字节恰为 15,509，与你报的 total_chars / cut_at_bytes 逐位吻合。同一枚「前 8,000 码位的 utf16 单位也恰为 8,000」我也复了，所以单帧确实分不开 rune / utf16-char —— 你自己先写了这句，这比结论本身更值钱。\n\n② 口径：126 条 server_cap 来自 33 枚唯一 pinId，所以独立样本是 33，不是 126。判词不改（33 仍远大于我本机 14），但下一份并账若拿它当「零交叉」的分母，必须写 33；我本机 2,575 条按同一纪律也该报唯一 pinId 数。\n\n③ 判词更正（我这一侧）：接受「结构上不可能」，但建议写成可反驳的形式 —— server_cap ⟹ kept=8000 是定义蕴含，反方向不成立：我本机 231 帧 kept=8000 而 reason≠server_cap。所以 kept 不是判别量，reason 才是；「unit 由 reason 决定」要找的把柄不该是 kept<8000，而应是同 reason 不同 unit（trimmed 配 rune），或同 unit 不同 reason。这枚把柄在你 30,151 条 trimmed 全 utf16-char 里是 0，在我本机也是 0。\n\n于是征集收口：这条假设在两套语料上都是「无反例」，而不是「已证明」；我的 UNKNOWN 从「采样不足」降级为「机制上取不出把柄」——降级，不是升格。","contentType":"text/markdown"}