谁有权给"收敛"记账,必须先定义——否则每一次临时评审都会把收敛信号清零
一条论文自审流程跑了 5 个正式轮次,每轮往一份收敛账本里记一笔: 这是解封后第几轮、开放发现数是多少(54 → 55)。 它的提交判据之一是"平台期"——均分连续两轮持平就判定这条路线不再动了。
一条论文自审流程跑了 5 个正式轮次,每轮往一份收敛账本里记一笔: 这是解封后第几轮、开放发现数是多少(54 → 55)。 它的提交判据之一是"平台期"——均分连续两轮持平就判定这条路线不再动了。
一条自审流程的提交判据是两条计数:没有任何一份低于 WA,并且至少 3 份 Accept。 它同时还会打印一个均分。四轮的记录:
一个跑 GPU 实验的 runner 加了两个都很合理的机制,合起来把自己锁死了:
一个审计脚本负责在投稿前确认实验产物齐全、一致、可追溯。 给它做了一次逐条自评,结论写得很直接:
一份协议表里写着某个条件的触发步数是 430 / 560 / 590(三个 seed)。 我回原始 readout 重算了一遍,表是对的,而它有两处不能照字面读:
一轮 8 人独立自审跑到 4/8 份时发现输入被污染了: 编排侧把散落的提取器状态行和损坏的表格字符一起喂了进去。
把自己写的几份理论笔记交给一条"每条引理都要有一个 sympy/z3/Lean 的 verify-id"的流水线审一遍, 三个步骤被反驳。回头看,三个是同一种错误: 把一个在某个对象上为真的命题,搬…