# 写合并候选的冻结协议

本轮有几条提案被判为同一个改法，合并成了一个候选（材料里有判重记录和这几份原提案）。你是其中提案编号最小的作者，由你把它们写成一份完整的冻结协议，再加上实现条款和对每一份挑刺的答复。写定以后它就不能再改；之后每位研究者对着它估分数，实验员照着它写代码，核验员照着它逐条核对。

## 合成一份

几位作者想的是同一个改法，但写法、因子的划分、取值常常有出入。你要写出一份几位作者都认得出"这就是我提的那个"的版本。

- 因子按"单独放到基线上说不说得通"重新划一次，因子数不超过上限。合起来超过上限时，多出来的留到下一轮再提，不要把两件事捆成一个因子塞进去。
- 几条原提案的保障合成一份清单。合的时候每条都照系统提示词"因子与保障"那几问再过一遍：一条原提案里的保障，跟另一条原提案的因子放在一起时，可能就会改分了。
- 取值不同时挑一个，写清为什么，不写"用 A 或 B"；拿不准时把取值规则写进关键设定。另一个取值也值得试，下一轮另提。
- 同一个量的指标只登记一次，清单里已有的直接引用。
- 某条原提案的因子、保障或指标没进合并版，写明为什么：不说明，那位作者会以为它还在。
- 不在几条原提案和挑刺意见之外加新的改动：这一轮检验的，应当是大家提过、挑过刺的东西。

正文里不写预期分数，几位作者的作者自评仍封存着，这里不用交。

## 答复挑刺

针对这几条原提案的挑刺都要答，不能因为合并就漏掉某一条原提案收到的意见。改不改，只看你能不能指出代码、运行记录或协议里的哪一处证明意见对或不对，不看意见说得多肯定、有几个人提。既别被质疑就让步，也别护着某一位作者的写法，包括你自己的。

意见说某条保障其实会改分：同意就挪进因子清单，或改成真正不改分的写法（修到刚好合法、退回基线、报错），不同意就说出依据。说某个写死的数不对：不用验算，改成由代码按规则算出。担心运行不合法：加一条只修到刚好合法或报错的保障，或者在协议"什么运行不算数"里写清。

## 条款

实现拆成条款，每条一件实验员要做的事，能单独核。好："`report.py:summarize`：只统计最近 7 天的记录，不足 7 天时统计全部记录。"坏："按几条提案的共同思路实现。"文件和函数拿不准是否存在，用 `read_source` 读基线核实。