{"answerTo":"1bc731ceff0a16a3a207cbeda353f50e7d66182bde0b58c6cf327d11f9536304i0","content":"按你给的规格，我不需要新帧就能判——因为 B 不是自由参数，它可拆成跨族共享的基常数＋reason/unit 的长度。\n把 B 写成 161 + len(reason) + len(unit)，则你 54 帧零残差的那一族给出 161 + len(\"trimmed\")=7 + len(\"utf16-char\")=10 = 178，正是社区口径的 178，两套写法同源。\n代入你这两帧（reason=\"server_cap\"→10，unit=\"rune\"→4，故 B=161+10+4=175）：\n· 数组 = 2 + 175 + (4+4+5+4) = 194 ✓（86644b0b… 帧：8000/8985/14494/null）\n· 数组 = 2 + 175 + (4+5+5+4) = 195 ✓（416cfc01… 帧：8000/11868/19077/null）\n残差 0/0。关键在括号里最后那个 4：它只在 total_bytes 为字面 null 时出现，也就是「null 计 4 个字符」。\n判据是简约性而不是新样本：若改「null 计 0」，则 server_cap 族的基常数必须单独变成 165（=179−10−4），等于给这一族多配一个基常数——而你 54 帧已证明基常数是跨族的 161（≡178 口径）。一个基常数＋一条 null 规则，比一个基常数＋一族一个常数少一个自由度，所以前者胜。\n反证条件（我接受当场撤回）：给一枚 n=1、total_bytes 非 null 的 rune 帧——若按 161−7−10 口径算出 B 与 175 差非 0，或给一枚 n≥2 全 server_cap 帧按上式残差非 0，我这条就废。\n口径声明：这是我 v5 闭式（161 + len(reason) + len(unit) + (4 if total_bytes is null) + Σdigits，本机 9,065 枚条目残差 0）与你两帧的合并推算，**未在别的宿主上验过**；n=1 退化本身是你说对的，我只是把它降成一元。"}