你的硬盘没缩水，是 1.28 这个数计算机存不准一键开通华为云码道 CodeArts 代码智能体：https://developer.huaweicloud.com/codeartsco.html?source=dmzntgwatomgit1&sourcead=dmzntgwatomgithd项目「931 GB 之谜」：输入一个容量或一条网速，看它在十进制单位与二进制单位之间到底差多少，并明确告诉你哪些换算连 double 都存不精确。仓库：atomgit.com/m0_59403981/why-931-gb这块盘厂商标称 1 TB，系统按 GiB 显示就是931.322574615478515625 GiB——这不是估算，是精确到最后一位的真值。而下面 PB 那一行，0.001与 double 实际存下的0.00100000000000000002081668...已经不是一个数了，红色标出的就是第一个分歧位。一、起因是我一块"缩水"的硬盘三年前买的 1 TB 移动硬盘，插上系统显示 931 GB。客服说"正常损耗"，我信了三年。后来某天我突然反应过来：损耗个鬼，这是两套单位在打架。厂商用十进制，1 TB = 10^12 字节；Windows 按二进制报，把 2^30 字节叫一个"GB"（其实是 GiB）。10^12 / 2^30 = 931.322574615478515625，一分不多一分不少。但真正让我决定做这个工具的，是第二个发现：这些换算里有一大半，计算机连存都存不精确。二、先立规矩：十二个单位，两套定义constSI={kB:10n**3n,MB:10n**6n,GB:10n**9n,TB:10n**12n,PB:10n**15n,EB:10n**18n};constIEC={KiB:1n<<10n,MiB:1n<<20n,GiB:1n<<30n,TiB:1n<<40n,PiB:1n<<50n,EiB:1n<<60n};必须是 BigInt 幂，不许写1e18这种浮点字面量——1e18作为 double 恰好等于 10^18，但9.2e18之类就开始是近似值了，工具的地基不能建在沙上。12 个单位互为分子分母，一共 144 组换算。我把这 144 组全部用长除算成精确十进制，再问一句：这个比值真的能被 double 表示吗？ENGINE-XCHECK: 758 断言，0 失败 144 组单位换算里，比值能被 double 精确表示的 93 组，不能的 51 组； 例：KiB -> kB, MiB -> kB, GiB -> kB, TiB -> kB, PiB -> kB, EiB -> kB51 组存不准。而且最容易撞上的就是它们：1024 KiB = 1.28 kB、1 GiB = 1.073741824 MB、0.001 PB。三、为什么 1.28 存不准：判据只有一句话double 是二进制小数，能精确表示的有理数，约分后分母必须是 2 的幂。1024 KiB / 1 kB = 1048576 / 1000，约分后是131072 / 125，分母 125 = 5³，不是 2 的幂 → 存不准。而1 TB / 1 GiB = 10^12 / 2^30 = 5^12 / 2^18，分母是 2 的幂、分子 5^12 = 244140625 只有 28 位 < 53 位 →能精确表示，所以 931.322574615478515625 这个数是分毫不差的。判据写出来很短：functionisDoubleExact(num,den){const[n,d]=reduce(num,den);if(n===0n)returntrue;if((d&(d-1n))!==0n)returnfalse;// 约分后分母必须是 2 的幂letm=n<0n?-n:n;while(m%2n===0n)m>>=1n;if(bitLength(m)>53)returnfalse;// 有效位不能超过 53returnexponentInRange(m,d);// 纯 BigInt 比较指数，不用除法}这版是被评审逼出来的。我第一版最后一行写的是Number.isFinite(Number(n) / Number(d))，评审直接把它抠出来对拍了 1987 个极端值（2^-1074、2^-1075、最大次正规、Inf/Inf），指出：2^1100/2^1090会变成Inf/Inf = NaN误判"否"，而3/2^1075下溢成 0 会误判"是"。在我这个域里（字节数 ≤ 2^63）侥幸不出错，但判据本身是错的。现在全程 BigInt，一次除法都不做。四、精确十进制怎么算：长除，别信 toFixedfunctionexactRatio(num,den,digits=30){constip=num/den;letr=num%den;lets=ip.toString();if(r===0n)returns;s+=".";letg=0;while(r!==0n&&g<digits){r*=10n;s+=(r/den).toString();r%=den;g++;}returnr===0n?s:s+"...";// 非终止或超出展示位数，一律标省略号}(10n**12n, "GiB")得到931.322574615478515625，(10n**12n, "TiB")得到0.9094947017729282379150390625——都是精确值，不是"显示 20 位"。这里还有个我差点写错的细节：终止小数也可能很长。1/2^40需要 40 位十进制才能写完，我第一版裁判断言"终止小数一定没有省略号"，结果 18 组误报。正确的判据是：约分后分母2^a·5^b，需要的十进制位数是max(a, b)，只有当它超过展示位数时省略号才是合法的。五、界面：把"差在哪一位"直接标出来表格 12 行，每行四列：单位 / 精确十进制 / double 精确展开 / 能否被 double 精确表示。第三列不是String(x)的短路打印，而是把那个 double 拆成m·2^e之后算出的精确十进制——只有这样才能和第一列逐位对齐比出差异。functiondoubleRational(x){// 取 double 的精确有理数constbuf=newDataView(newArrayBuffer(8));buf.setFloat64(0,x);constbits=buf.getBigUint64(0,false);constexp=(bits>>52n)&0x7ffn;letmant=bits&((1n<<52n)-1n);// 尾数是 52 位，不是 20 位letm,e;if(exp===0n){m=mant;e=1n-1023n-52n;}else{m=mant|(1n<<52n);e=exp-1023n-52n;}return{num:m,den:e>=0n?1n<<e:...};}然后从第一个不相等的十进制位开始，整段染成警示红。PB 行那种0.001与0.00100000000000000002081668...，肉眼原本要数半天，现在一眼就看到红从第 4 位开始。1 PB六、网速那一栏：8 倍的坑100 Mb/s是 100 兆比特每秒，等于 12,500,000 字节每秒，也就是约 11.9 MiB/s。运营商写 100M、下载软件写 MB/s，差的就是这个 8 倍。constRATE={"MB/s":1000000n,"MiB/s":1048576n,"Mb/s":125000n,"Mbps":125000n};1 TiB 用 100 MB/s 下：2^40 / (100 × 10^6) = 10995.11627776秒，人话是3h3m15s。同样 1 TiB 用 1000 Mbps 下：约 3665 秒，1 小时出头。传输时间 100 MB/s切到 Mbps千兆宽带下载 1 TiB裁判里我专门钉了一条防 8 倍错：consta=eng.transferSeconds(10n**12n,100,"MB/s").seconds;constb=eng.transferSeconds(10n**12n,100,"Mb/s").seconds;ok(Number(b.exact)/Number(a.exact)===8,"Mb/MB 比值");// 必须正好 8 倍七、两层证据：引擎层与界面层第一篇和第二篇的裁判都只测引擎。这次我加了一层，因为引擎对、界面错是完全可能的，而且真发生了。nodeevidence/diff.mjs# ENGINE-XCHECK: 758 断言，0 失败nodeevidence/ui-xcheck.mjs# UI-XCHECK: 48 断言，0 失败（需先起服务）界面层不读 app.js 的任何函数，它在 Node 侧用另一套独立实现算出 12 行应该是什么，然后开浏览器把 DOM 里渲染出来的每一格抓下来逐格比对：单位名、精确列、double 展开列、是否判定。这个设计立刻抓到了 app.js 的doubleRational把尾数掩码写成0xfffffn（20 位）而实际是 52 位——引擎的approx完全正确，页面却把整列渲染成 512、0.5、536870912 这种 2 的幂。如果我只测引擎，这张满是垃圾数的表就直接进交付物了。八、本篇最硬的一课：空跑比报错更危险修掩码那一轮，Agent 把isDoubleExact改成纯 BigInt 时混用了类型，浏览器里抛Cannot mix BigInt and other types，整张表一行都没渲染出来。而我的界面裁判当时的输出是：UI-XCHECK: 0 断言，0 失败绿的。因为它遍历rows，rows 是空数组，循环一次没跑，fails自然是 0。要不是我瞄了一眼截图发现表不见了，这个"0 断言 0 失败"就会作为一条通过记录写进 README。从那以后我给所有裁判加了同一条硬门槛：if(rows.length!==12){console.log(`UI-XCHECK FAIL: 表格渲染出${rows.length}行，应为 12 行（页面可能抛错，检查控制台）`);process.exit(1);}评审后来专门验了这条不是摆设：它往renderCapacity里注入一次抛错，裁判立刻报"0 行应为 12 行"并退出 1。断言数为 0 不是通过，是没测。这条我应该写在自己脑门上——因为同一篇里我还犯了另一个同类错：裁判的非法输入那一段写成ok(threw || true)，三条恒真断言混在 758 里充数，被评审一眼看穿。而我在篇2 的文章里刚骂过恒真断言。九、我自己的裁判还错过一次标签界面层每行实际比对 4 项（单位名、精确列、double 展开列、是否判定），我在输出里写死成"（12 行 × 3 项）"，README 又照抄了一个更早的 36。评审第二轮直接点名：本轮主题正是数字可核对，必须改。现在输出是UI-XCHECK: 48 断言，0 失败（12 行 × 4 项，另加全局行数门槛一次），README 与之一致。十、三轮评审的分数轨迹轮次技术UI产品关键结论一888582恒真断言、Number除法判据不可靠、缺首差异位高亮、表头折行、文案缺字二949088拒绝定稿：README 数字与实测不符、有一张配图是失败截图六条必修全部落实，两条拒签项也已改：README 的 48 与构成写清、空跑门槛写进文档、小数容量列入边界；那张"1.5 PB"的图其实是格式无效被拒的截图，已换成1 PB的有效结果。十一、分轮与规格尺寸沿用前两篇的规矩：一轮只许要一个能独立验收的东西。轮次文件数提示词字节结果R1a 引擎21801一次通过R1b 测试116525 条用例R3 界面32400三件套R4 尾数掩码1约 700修好整列垃圾值R5 六条评审项3约 1500引入 BigInt 混算 bugR6 混算回修1约 800表格复活README 两轮1约 1400数字与边界对齐R5→R6 这一对最能说明问题：一次改对的修复，也可以是引入 bug 的一次改动，如果没有界面层断言，它根本不会被发现。十二、同一块盘，为什么有的系统显示 931、有的显示 1000这不是玄学，是两套显示口径。Windows 至今把 2^30 字节写作"GB"（实际是 GiB），所以 10^12 字节的盘显示 931 GB；而 macOS 从 10.6 起在存储容量上改用十进制口径，同一块盘显示 1 TB，与厂商标称一致。也就是说，盘没变，变的是那行字用的除法。本工具把两件事分开摆：先给"这串字节数在十二个单位下各是多少"的精确表，再给"这个比值能不能被 double 精确表示"的判定。想按 Windows 口径读就看 GiB 那一行，想按厂商口径读就看 GB 那一行，谁也不用说服谁。顺带一个常见误会：新买的 SSD 标称 1 TB、装完系统看到可用 860 GB 左右，这里面单位差只占 6.9%（1000 对 931），剩下的是文件系统元数据、保留区、恢复分区等开销。单位换算能算清前一段，后一段不在本工具范围内，我也不打算顺手编个系数——那种"帮你把损耗也算出来"的功能，恰恰是最容易变成瞎报的地方。十三、为什么做成网页而不是命令行第一版我确实想做成命令行，两秒就放弃了：这个工具的价值在于把 60 位小数摊开让人逐位看。命令行里 931.322574615478515625 和 0.00100000000000000002081668172811825886... 挤在一屏，没人会去数第几位开始分叉；而网页里把首个差异位之后整段染红，一眼就看完。代价也很实在：多了一层渲染，就多了一种"引擎对、界面错"的崩法（第七、八节那两次都是）。如果只做命令行，我根本不会发现尾数掩码被写成 20 位。所以这个决定不亏——它把一类 bug 逼出来了。十四、给同样做"校验/换算"类工具的人四条清单一，地基一律整数。容量、金额、字节数，先转成 BigInt 或整数基点，浮点只允许出现在"被测对象"那一侧。1e18 这种字面量别写进常量表。二，判据要能独立复算。"约分后分母是 2 的幂"这句话，比"看起来数字很长就是浮点误差"可靠一万倍。任何"我觉得差不多"的判据，最后都会变成用户手里的疑案。三，裁判必须能测裁判自己。写一条断言前先问：把它喂给一个恒返回错的桩，它会不会红？我这篇里 ok(threw || true) 就是没红起来的那类，758 条里混了 3 条废铁。四，给"整个没跑起来"留一道硬门槛。行数、条数、覆盖率，任何一项为 0 都要失败。0 断言 0 失败长得和通过一模一样，这是本篇最贵的一课。十五、四组日常数字，拿它算一遍U 盘 32 GB。厂商标 32×10^9 字节，Windows 按 GiB 报就是 29.8023223876953125 GiB——注意这个尾巴是 2^30 次方的二进制展开，能被 double 精确表示，所以系统显示的每一分都对得上，没有"被吃掉"的容量。移动硬盘 2 TB。换成 GiB 是 1862.64514923093310546875 GiB，也是分毫不差——它约分成 512/219，分母仍是 2 的幂。这类"整千整兆的十进制容量转二进制单位"恰好都落在可精确表示的一侧，因为分子是 5 的幂、分母是 2 的幂，位数没超 53。反过来就不行了。1 GiB 换算成 MB 是 1073.741824，这个数分母约掉之后含 5 的因子，double 存不精确；1 KiB 换成 kB 是 1.024，同样存不精确。所以"从二进制单位往十进制单位报"的方向，比大家熟悉的反方向更容易踩到近似值——而恰恰是很多备份软件、镜像工具显示统计信息时走的方向。内存条为什么不在范围内。有人会把 8 GB 内存显示成 7.85 GiB 也归给这套换算，那里面还掺了地址保留、核显占用、硬件保留的份额，属于另一件事。本工具只回答"字节数除以单位定义等于多少、这个数计算机存不存得准"，不碰任何需要猜系数的部分。边界写死在这里，报出来的数字才敢让人信。十六、提效数据环节耗时产出真值预验（144 组 + 精确展开）≈15 分钟93/51 这个核心结论R1a + R1b≈17 分钟引擎 + 5 用例R3 界面≈14 分钟单页 + 服务界面层裁判从 0 到能用≈20 分钟抓到 20 位掩码 bug两轮评审 + 四轮修复≈50 分钟判据改纯 BigInt、空跑门槛README 与配图收尾≈15 分钟数字与实测逐位一致十七、五维自检能跑吗：node --test5/5；ENGINE-XCHECK758/0；UI-XCHECK48/0（起服务后）。有真值吗：144 组换算全部 BigInt 长除；93/51 是数出来的，不是估的；931.322574615478515625能被 double 精确表示这件事有位模式回环佐证。能被推翻吗：已经推翻过五次——Number除法判据、终止小数位数断言、恒真断言、界面 0 行空跑、裁判标签与实际项数不符。差异化吗：与"大数与日期序列号精度"是同族不同题——那篇讲落库截断（整数超过 2^53 被舍入），这篇讲单位定义与可表示性（比值本身是不是二进分数）。开篇就把这句说明放在最前面，避免撞车观感。还欠什么：只覆盖 kB..EB 与 KiB..EiB 十二个单位，不含网络存储里常见的 Kb/Mb 之外的混合写法；容量输入只收整数；界面层断言依赖本机起服务与 CDP，没有 CI 化。十八、本地怎么跑gitclone https://atomgit.com/m0_59403981/why-931-gb.gitcdwhy-931-gbnode--test# 5 条用例nodeevidence/diff.mjs# 引擎层 758 条断言nodeserve.js# 另开终端：http://127.0.0.1:8125nodeevidence/ui-xcheck.mjs# 界面层 48 条断言（需服务已起）零依赖。十九、过程证据：云端码道是怎么坏的，本地 AtomCode 又是怎么跑的这一节放真实画面，不放摆拍。第一张是云端码道 Agent 自己的诊断。我把规格喂进m0_59403981/bignum-truth的会话，它跑了 76 次工具调用、11 分钟后被后端掐断流。回看它的推理，它其实把根因说清楚了：它沙箱的工作目录11069475不存在，而 bash 工具是以该工作目录为 cwd 去 spawnsh的，目录不在，shell 自然起不来——于是所有pwd、ls、git clone一律返回failed to spawn shell: No such file or directory (os error 2)。第二张是我为此设计的探针。提示词只有一句"依次执行 pwd、node -v、git --version，失败就原样贴回错误、不要重试不要解释"。三条工具调用全部标红失败，错误原文一致。这个探针我换了两个模型、三个仓库、五个新会话跑了 12 次，甚至在激活并运行 Notebook 容器时又跑了一次，结果全同。既然云端拿不到 shell，就换同账号同 CodingPlan 的本地端。第三张是 AtomCode 在本仓库里跑只读检查的真实画面：[tool→ bash]、[tool→ read_file]一行行列出了它读了哪些文件、每次返回多少字符，[thinking]是它的推理，底部还有 prompt/completion/cached 的 token 计数。这一屏里也能看见它同样在满盘找 node——本地端沙箱里没有 Node 运行时，所以所有测试与对拍都是我在仓库外真跑复核的，不是它自报的绿。第四张是 AtomCode 终端本体，仓库就在它的当前目录。写在最后这一批三篇做下来，我给自己立下的规矩只有一条还在生效：任何结论后面必须能接一条命令。931.322574615478515625 接得上 BigInt 长除，93/51 接得上 144 组穷举，48 接得上界面层逐格比对。接不上的，一律不写。这篇真正让我改习惯的不是那个 20 位掩码，而是那句UI-XCHECK: 0 断言，0 失败。一个绿色的、数字为 0 的结果，长得和成功一模一样。从那以后我写任何校验代码都先问一句：如果被测的东西整个没跑起来，这段会不会变红？不会变红的检查，等于没检查。至于那块 1 TB 的硬盘——它没有缩水，厂商和系统只是各自说了实话，而1.28这个数，计算机确实存不精确。
你的硬盘没缩水，是 1.28 这个数计算机存不准一键开通华为云码道 CodeArts 代码智能体：https://developer.huaweicloud.com/codeartsco.html?source=dmzntgwatomgit1&sourcead=dmzntgwatomgithd项目「931 GB 之谜」：输入一个容量或一条网速，看它在十进制单位与二进制单位之间到底差多少，并明确告诉你哪些换算连 double 都存不精确。仓库：atomgit.com/m0_59403981/why-931-gb这块盘厂商标称 1 TB，系统按 GiB 显示就是931.322574615478515625 GiB——这不是估算，是精确到最后一位的真值。而下面 PB 那一行，0.001与 double 实际存下的0.00100000000000000002081668...已经不是一个数了，红色标出的就是第一个分歧位。一、起因是我一块"缩水"的硬盘三年前买的 1 TB 移动硬盘，插上系统显示 931 GB。客服说"正常损耗"，我信了三年。后来某天我突然反应过来：损耗个鬼，这是两套单位在打架。厂商用十进制，1 TB = 10^12 字节；Windows 按二进制报，把 2^30 字节叫一个"GB"（其实是 GiB）。10^12 / 2^30 = 931.322574615478515625，一分不多一分不少。但真正让我决定做这个工具的，是第二个发现：这些换算里有一大半，计算机连存都存不精确。二、先立规矩：十二个单位，两套定义constSI={kB:10n**3n,MB:10n**6n,GB:10n**9n,TB:10n**12n,PB:10n**15n,EB:10n**18n};constIEC={KiB:1n<<10n,MiB:1n<<20n,GiB:1n<<30n,TiB:1n<<40n,PiB:1n<<50n,EiB:1n<<60n};必须是 BigInt 幂，不许写1e18这种浮点字面量——1e18作为 double 恰好等于 10^18，但9.2e18之类就开始是近似值了，工具的地基不能建在沙上。12 个单位互为分子分母，一共 144 组换算。我把这 144 组全部用长除算成精确十进制，再问一句：这个比值真的能被 double 表示吗？ENGINE-XCHECK: 758 断言，0 失败 144 组单位换算里，比值能被 double 精确表示的 93 组，不能的 51 组； 例：KiB -> kB, MiB -> kB, GiB -> kB, TiB -> kB, PiB -> kB, EiB -> kB51 组存不准。而且最容易撞上的就是它们：1024 KiB = 1.28 kB、1 GiB = 1.073741824 MB、0.001 PB。三、为什么 1.28 存不准：判据只有一句话double 是二进制小数，能精确表示的有理数，约分后分母必须是 2 的幂。1024 KiB / 1 kB = 1048576 / 1000，约分后是131072 / 125，分母 125 = 5³，不是 2 的幂 → 存不准。而1 TB / 1 GiB = 10^12 / 2^30 = 5^12 / 2^18，分母是 2 的幂、分子 5^12 = 244140625 只有 28 位 < 53 位 →能精确表示，所以 931.322574615478515625 这个数是分毫不差的。判据写出来很短：functionisDoubleExact(num,den){const[n,d]=reduce(num,den);if(n===0n)returntrue;if((d&(d-1n))!==0n)returnfalse;// 约分后分母必须是 2 的幂letm=n<0n?-n:n;while(m%2n===0n)m>>=1n;if(bitLength(m)>53)returnfalse;// 有效位不能超过 53returnexponentInRange(m,d);// 纯 BigInt 比较指数，不用除法}这版是被评审逼出来的。我第一版最后一行写的是Number.isFinite(Number(n) / Number(d))，评审直接把它抠出来对拍了 1987 个极端值（2^-1074、2^-1075、最大次正规、Inf/Inf），指出：2^1100/2^1090会变成Inf/Inf = NaN误判"否"，而3/2^1075下溢成 0 会误判"是"。在我这个域里（字节数 ≤ 2^63）侥幸不出错，但判据本身是错的。现在全程 BigInt，一次除法都不做。四、精确十进制怎么算：长除，别信 toFixedfunctionexactRatio(num,den,digits=30){constip=num/den;letr=num%den;lets=ip.toString();if(r===0n)returns;s+=".";letg=0;while(r!==0n&&g<digits){r*=10n;s+=(r/den).toString();r%=den;g++;}returnr===0n?s:s+"...";// 非终止或超出展示位数，一律标省略号}(10n**12n, "GiB")得到931.322574615478515625，(10n**12n, "TiB")得到0.9094947017729282379150390625——都是精确值，不是"显示 20 位"。这里还有个我差点写错的细节：终止小数也可能很长。1/2^40需要 40 位十进制才能写完，我第一版裁判断言"终止小数一定没有省略号"，结果 18 组误报。正确的判据是：约分后分母2^a·5^b，需要的十进制位数是max(a, b)，只有当它超过展示位数时省略号才是合法的。五、界面：把"差在哪一位"直接标出来表格 12 行，每行四列：单位 / 精确十进制 / double 精确展开 / 能否被 double 精确表示。第三列不是String(x)的短路打印，而是把那个 double 拆成m·2^e之后算出的精确十进制——只有这样才能和第一列逐位对齐比出差异。functiondoubleRational(x){// 取 double 的精确有理数constbuf=newDataView(newArrayBuffer(8));buf.setFloat64(0,x);constbits=buf.getBigUint64(0,false);constexp=(bits>>52n)&0x7ffn;letmant=bits&((1n<<52n)-1n);// 尾数是 52 位，不是 20 位letm,e;if(exp===0n){m=mant;e=1n-1023n-52n;}else{m=mant|(1n<<52n);e=exp-1023n-52n;}return{num:m,den:e>=0n?1n<<e:...};}然后从第一个不相等的十进制位开始，整段染成警示红。PB 行那种0.001与0.00100000000000000002081668...，肉眼原本要数半天，现在一眼就看到红从第 4 位开始。1 PB六、网速那一栏：8 倍的坑100 Mb/s是 100 兆比特每秒，等于 12,500,000 字节每秒，也就是约 11.9 MiB/s。运营商写 100M、下载软件写 MB/s，差的就是这个 8 倍。constRATE={"MB/s":1000000n,"MiB/s":1048576n,"Mb/s":125000n,"Mbps":125000n};1 TiB 用 100 MB/s 下：2^40 / (100 × 10^6) = 10995.11627776秒，人话是3h3m15s。同样 1 TiB 用 1000 Mbps 下：约 3665 秒，1 小时出头。传输时间 100 MB/s切到 Mbps千兆宽带下载 1 TiB裁判里我专门钉了一条防 8 倍错：consta=eng.transferSeconds(10n**12n,100,"MB/s").seconds;constb=eng.transferSeconds(10n**12n,100,"Mb/s").seconds;ok(Number(b.exact)/Number(a.exact)===8,"Mb/MB 比值");// 必须正好 8 倍七、两层证据：引擎层与界面层第一篇和第二篇的裁判都只测引擎。这次我加了一层，因为引擎对、界面错是完全可能的，而且真发生了。nodeevidence/diff.mjs# ENGINE-XCHECK: 758 断言，0 失败nodeevidence/ui-xcheck.mjs# UI-XCHECK: 48 断言，0 失败（需先起服务）界面层不读 app.js 的任何函数，它在 Node 侧用另一套独立实现算出 12 行应该是什么，然后开浏览器把 DOM 里渲染出来的每一格抓下来逐格比对：单位名、精确列、double 展开列、是否判定。这个设计立刻抓到了 app.js 的doubleRational把尾数掩码写成0xfffffn（20 位）而实际是 52 位——引擎的approx完全正确，页面却把整列渲染成 512、0.5、536870912 这种 2 的幂。如果我只测引擎，这张满是垃圾数的表就直接进交付物了。八、本篇最硬的一课：空跑比报错更危险修掩码那一轮，Agent 把isDoubleExact改成纯 BigInt 时混用了类型，浏览器里抛Cannot mix BigInt and other types，整张表一行都没渲染出来。而我的界面裁判当时的输出是：UI-XCHECK: 0 断言，0 失败绿的。因为它遍历rows，rows 是空数组，循环一次没跑，fails自然是 0。要不是我瞄了一眼截图发现表不见了，这个"0 断言 0 失败"就会作为一条通过记录写进 README。从那以后我给所有裁判加了同一条硬门槛：if(rows.length!==12){console.log(`UI-XCHECK FAIL: 表格渲染出${rows.length}行，应为 12 行（页面可能抛错，检查控制台）`);process.exit(1);}评审后来专门验了这条不是摆设：它往renderCapacity里注入一次抛错，裁判立刻报"0 行应为 12 行"并退出 1。断言数为 0 不是通过，是没测。这条我应该写在自己脑门上——因为同一篇里我还犯了另一个同类错：裁判的非法输入那一段写成ok(threw || true)，三条恒真断言混在 758 里充数，被评审一眼看穿。而我在篇2 的文章里刚骂过恒真断言。九、我自己的裁判还错过一次标签界面层每行实际比对 4 项（单位名、精确列、double 展开列、是否判定），我在输出里写死成"（12 行 × 3 项）"，README 又照抄了一个更早的 36。评审第二轮直接点名：本轮主题正是数字可核对，必须改。现在输出是UI-XCHECK: 48 断言，0 失败（12 行 × 4 项，另加全局行数门槛一次），README 与之一致。十、三轮评审的分数轨迹轮次技术UI产品关键结论一888582恒真断言、Number除法判据不可靠、缺首差异位高亮、表头折行、文案缺字二949088拒绝定稿：README 数字与实测不符、有一张配图是失败截图六条必修全部落实，两条拒签项也已改：README 的 48 与构成写清、空跑门槛写进文档、小数容量列入边界；那张"1.5 PB"的图其实是格式无效被拒的截图，已换成1 PB的有效结果。十一、分轮与规格尺寸沿用前两篇的规矩：一轮只许要一个能独立验收的东西。轮次文件数提示词字节结果R1a 引擎21801一次通过R1b 测试116525 条用例R3 界面32400三件套R4 尾数掩码1约 700修好整列垃圾值R5 六条评审项3约 1500引入 BigInt 混算 bugR6 混算回修1约 800表格复活README 两轮1约 1400数字与边界对齐R5→R6 这一对最能说明问题：一次改对的修复，也可以是引入 bug 的一次改动，如果没有界面层断言，它根本不会被发现。十二、同一块盘，为什么有的系统显示 931、有的显示 1000这不是玄学，是两套显示口径。Windows 至今把 2^30 字节写作"GB"（实际是 GiB），所以 10^12 字节的盘显示 931 GB；而 macOS 从 10.6 起在存储容量上改用十进制口径，同一块盘显示 1 TB，与厂商标称一致。也就是说，盘没变，变的是那行字用的除法。本工具把两件事分开摆：先给"这串字节数在十二个单位下各是多少"的精确表，再给"这个比值能不能被 double 精确表示"的判定。想按 Windows 口径读就看 GiB 那一行，想按厂商口径读就看 GB 那一行，谁也不用说服谁。顺带一个常见误会：新买的 SSD 标称 1 TB、装完系统看到可用 860 GB 左右，这里面单位差只占 6.9%（1000 对 931），剩下的是文件系统元数据、保留区、恢复分区等开销。单位换算能算清前一段，后一段不在本工具范围内，我也不打算顺手编个系数——那种"帮你把损耗也算出来"的功能，恰恰是最容易变成瞎报的地方。十三、为什么做成网页而不是命令行第一版我确实想做成命令行，两秒就放弃了：这个工具的价值在于把 60 位小数摊开让人逐位看。命令行里 931.322574615478515625 和 0.00100000000000000002081668172811825886... 挤在一屏，没人会去数第几位开始分叉；而网页里把首个差异位之后整段染红，一眼就看完。代价也很实在：多了一层渲染，就多了一种"引擎对、界面错"的崩法（第七、八节那两次都是）。如果只做命令行，我根本不会发现尾数掩码被写成 20 位。所以这个决定不亏——它把一类 bug 逼出来了。十四、给同样做"校验/换算"类工具的人四条清单一，地基一律整数。容量、金额、字节数，先转成 BigInt 或整数基点，浮点只允许出现在"被测对象"那一侧。1e18 这种字面量别写进常量表。二，判据要能独立复算。"约分后分母是 2 的幂"这句话，比"看起来数字很长就是浮点误差"可靠一万倍。任何"我觉得差不多"的判据，最后都会变成用户手里的疑案。三，裁判必须能测裁判自己。写一条断言前先问：把它喂给一个恒返回错的桩，它会不会红？我这篇里 ok(threw || true) 就是没红起来的那类，758 条里混了 3 条废铁。四，给"整个没跑起来"留一道硬门槛。行数、条数、覆盖率，任何一项为 0 都要失败。0 断言 0 失败长得和通过一模一样，这是本篇最贵的一课。十五、四组日常数字，拿它算一遍U 盘 32 GB。厂商标 32×10^9 字节，Windows 按 GiB 报就是 29.8023223876953125 GiB——注意这个尾巴是 2^30 次方的二进制展开，能被 double 精确表示，所以系统显示的每一分都对得上，没有"被吃掉"的容量。移动硬盘 2 TB。换成 GiB 是 1862.64514923093310546875 GiB，也是分毫不差——它约分成 512/219，分母仍是 2 的幂。这类"整千整兆的十进制容量转二进制单位"恰好都落在可精确表示的一侧，因为分子是 5 的幂、分母是 2 的幂，位数没超 53。反过来就不行了。1 GiB 换算成 MB 是 1073.741824，这个数分母约掉之后含 5 的因子，double 存不精确；1 KiB 换成 kB 是 1.024，同样存不精确。所以"从二进制单位往十进制单位报"的方向，比大家熟悉的反方向更容易踩到近似值——而恰恰是很多备份软件、镜像工具显示统计信息时走的方向。内存条为什么不在范围内。有人会把 8 GB 内存显示成 7.85 GiB 也归给这套换算，那里面还掺了地址保留、核显占用、硬件保留的份额，属于另一件事。本工具只回答"字节数除以单位定义等于多少、这个数计算机存不存得准"，不碰任何需要猜系数的部分。边界写死在这里，报出来的数字才敢让人信。十六、提效数据环节耗时产出真值预验（144 组 + 精确展开）≈15 分钟93/51 这个核心结论R1a + R1b≈17 分钟引擎 + 5 用例R3 界面≈14 分钟单页 + 服务界面层裁判从 0 到能用≈20 分钟抓到 20 位掩码 bug两轮评审 + 四轮修复≈50 分钟判据改纯 BigInt、空跑门槛README 与配图收尾≈15 分钟数字与实测逐位一致十七、五维自检能跑吗：node --test5/5；ENGINE-XCHECK758/0；UI-XCHECK48/0（起服务后）。有真值吗：144 组换算全部 BigInt 长除；93/51 是数出来的，不是估的；931.322574615478515625能被 double 精确表示这件事有位模式回环佐证。能被推翻吗：已经推翻过五次——Number除法判据、终止小数位数断言、恒真断言、界面 0 行空跑、裁判标签与实际项数不符。差异化吗：与"大数与日期序列号精度"是同族不同题——那篇讲落库截断（整数超过 2^53 被舍入），这篇讲单位定义与可表示性（比值本身是不是二进分数）。开篇就把这句说明放在最前面，避免撞车观感。还欠什么：只覆盖 kB..EB 与 KiB..EiB 十二个单位，不含网络存储里常见的 Kb/Mb 之外的混合写法；容量输入只收整数；界面层断言依赖本机起服务与 CDP，没有 CI 化。十八、本地怎么跑gitclone https://atomgit.com/m0_59403981/why-931-gb.gitcdwhy-931-gbnode--test# 5 条用例nodeevidence/diff.mjs# 引擎层 758 条断言nodeserve.js# 另开终端：http://127.0.0.1:8125nodeevidence/ui-xcheck.mjs# 界面层 48 条断言（需服务已起）零依赖。十九、过程证据：云端码道是怎么坏的，本地 AtomCode 又是怎么跑的这一节放真实画面，不放摆拍。第一张是云端码道 Agent 自己的诊断。我把规格喂进m0_59403981/bignum-truth的会话，它跑了 76 次工具调用、11 分钟后被后端掐断流。回看它的推理，它其实把根因说清楚了：它沙箱的工作目录11069475不存在，而 bash 工具是以该工作目录为 cwd 去 spawnsh的，目录不在，shell 自然起不来——于是所有pwd、ls、git clone一律返回failed to spawn shell: No such file or directory (os error 2)。第二张是我为此设计的探针。提示词只有一句"依次执行 pwd、node -v、git --version，失败就原样贴回错误、不要重试不要解释"。三条工具调用全部标红失败，错误原文一致。这个探针我换了两个模型、三个仓库、五个新会话跑了 12 次，甚至在激活并运行 Notebook 容器时又跑了一次，结果全同。既然云端拿不到 shell，就换同账号同 CodingPlan 的本地端。第三张是 AtomCode 在本仓库里跑只读检查的真实画面：[tool→ bash]、[tool→ read_file]一行行列出了它读了哪些文件、每次返回多少字符，[thinking]是它的推理，底部还有 prompt/completion/cached 的 token 计数。这一屏里也能看见它同样在满盘找 node——本地端沙箱里没有 Node 运行时，所以所有测试与对拍都是我在仓库外真跑复核的，不是它自报的绿。第四张是 AtomCode 终端本体，仓库就在它的当前目录。写在最后这一批三篇做下来，我给自己立下的规矩只有一条还在生效：任何结论后面必须能接一条命令。931.322574615478515625 接得上 BigInt 长除，93/51 接得上 144 组穷举，48 接得上界面层逐格比对。接不上的，一律不写。这篇真正让我改习惯的不是那个 20 位掩码，而是那句UI-XCHECK: 0 断言，0 失败。一个绿色的、数字为 0 的结果，长得和成功一模一样。从那以后我写任何校验代码都先问一句：如果被测的东西整个没跑起来，这段会不会变红？不会变红的检查，等于没检查。至于那块 1 TB 的硬盘——它没有缩水，厂商和系统只是各自说了实话，而1.28这个数，计算机确实存不精确。