> 三条可读性修改加了约 155 个字符，页数上限崩了两次——而两道质量门禁拉的方向相反

结论先行¶

一个可读性检查器给出的建议被接受了三条。这是唯一一次有人把它的下游代价量下来：

• 三条修改让渲染后的正文多出约 155 个字符；
• 那篇论文的正文正好结束在第 9 页最后一行；
• 页数上限崩了两次，两次都靠删字恢复 —— 删的是同一个工具的 writer 读者独立指出"长度超过其重要性"的那两节。 工具自己的输出，付了工具自己修改的账。

其中一次删过了头，被那个项目的 claim 守卫抓到： 删掉 not a verified **common** training intervention 里的 common， 让一个主张检查从 444/0 变成 443/1 —— 因为 common 区分的是 "共享的训练干预"和"供应商标签"，它承重。

于是两道门禁的方向是相反的：可读性修改要加字，主张守卫要那些字在原位， 而只有守卫知道哪几个词承重。

这一轮产出的规则不是"截稿日别动论文"，是： 由作者决定拿什么换什么，工具和 agent 都不决定。

为什么¶

一条建议的成本很少出现在建议里。可读性修改的典型形态是 "把这个结果在句子里直接说出来"、"给这个术语加一句解释"、 "把附录里那个常数搬到正文" —— 全部是加内容， 而加内容在一个硬页数限制下是零和的。所以这类工具的建议 天然带一个它看不见的预算约束，必须在接受的时候由人补上。

更要紧的是第二层：在一个硬约束下，一个修改的真实代价是被它挤掉的那段话。 "加 155 个字符"听起来可以忽略，而它实际的代价是两节文字被压缩， 其中一次把一个承重的限定词删掉了。局部看每一步都是改进， 整体看可能净亏 —— 而发现净亏的唯一办法是另一道门禁还在跑。

这也是为什么"两道门禁方向相反"不是设计缺陷。 可读性门禁知道哪里读不懂，主张门禁知道哪个词承重， 两者的知识不重叠，所以它们必须同时存在，并且在冲突时交给人。 一个把两者合并成单一分数的系统会自动选一边，而它没有依据选。

怎么用¶

接受建议的时候，把它的下游预算一起算。 在硬约束（页数、延迟、显存、二进制大小）下工作时， "加一点"永远要配一句"从哪里减"。写不出减哪里，就是还没决定要不要做。

修改之后把另一道门禁重跑一遍。 这是整件事里最便宜的一步， 也是唯一能发现"为了修 A 弄坏了 B"的一步。 444/0 → 443/1 之所以被看见，只是因为那个检查还在跑。

两道门禁冲突时不要自动裁决，升级给人。 Agent 尤其要守这一条：两边都有理由、而权衡依赖只有作者知道的信息 （哪条结论是坐实的、哪个词是和审稿人吵过的）。 相关的一条见 三个独立读者一致命中也不是指令——"读不懂"和"这是你的立场"要分开： 一致的读者意见也只是定位，不是指令。

压缩的时候只压词，不动数，然后逐个 grep 回去确认。 另一个项目的 camera-ready 给了这条的正面做法：审稿意见引起的修正与披露 新增约 30 行，正文溢出 8 页上限，于是集中压缩恢复—— 图宽 \linewidth → 0.78、一个 caption 少两行、四节做词级压缩。 硬约束是零 claim 改动、零数字改动，做完之后把表体里的每个数 （lead、假阳性时刻、两个三位有效数字的量）逐个 grep 过一遍确认没被碰到。 分界线很清楚：词是可压的，数不是——因为压词最坏的后果是句子变生硬， 而碰到数最坏的后果是论文和自己的原始产物不一致， 见 同一个数出现在图和表里，两者不能互相裁判——换算因子只住在生成器里。 而上面 common 那一次说明词也不是都可压，所以压完要重跑主张守卫。

工具的运行时机本身是个决定。 同一轮里有一个 3/3 的结构性发现 （八个没定义的统计术语）是对的，但在那个截稿时点只能部分执行。 这是关于什么时候跑这个工具的发现，不是关于它有没有用的发现。

出处¶

~/Tools/nonexpert-review：CALIBRATION.md 的 「输出在下游花了多少」与「代价，量过一次」两节 （约 155 个渲染字符、页数上限崩两次、 444/0 → 443/1 与 common 承重、 "由作者决定拿什么换什么，工具和 agent 都不决定"的原话）。 正面做法那一段出自 JEPA-Verify 在 CL4FMAgents @ NeurIPS 2026 的 camera-ready 页面预算记录（录用稿，逐条处置账）。