iomgaa
446e26224e
- src/materials：每种提交一个材料函数，生成给模型看的材料、第一条消息、对号清单、能读的代码版本；查询只在材料内按编号找；读提示词并算原始字节哈希；信念本按方法.md 6.10 现算。 - 账本里只存成 Json 的冻结协议、位置表、决定、结算的形状和编号规则由 materials 定义并导出。 - vocab 加 Checklist（对号清单）。 - prompts/：参考项目 3 份角色提示词、16 份任务说明，只做必要改动。 - TASK.md 补一句 unversionedNames 不存进代码版本。 - 方法.md 4.3 ① 改为"研究者任务"放信念本；结构.md vocab 上限 1150、补 materials 对外内容。 用户 2026-10-03 开工前的四个决定（选的都是推荐项）："甲：上限改 1150，只放对号清单"；"甲：materials 定义并导出"；"不放，改方法.md ① 的措辞"；"按原提案挑"。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
39 lines
5.3 KiB
Markdown
39 lines
5.3 KiB
Markdown
# 回应挑刺、写定冻结协议
|
|
|
|
你的提案成了一个候选，别的研究者对它提了意见（材料"本任务要处理的东西"里有你的原提案和针对它的全部挑刺）。现在要把它写定：答复每一份挑刺，改你认为该改的地方，再把实现拆成一条条条款。写定以后它叫冻结协议，不能再改；之后每位研究者对着它估分数，实验员照着它写代码，核验员照着它逐条核对。
|
|
|
|
### 采纳还是不采纳
|
|
|
|
答复每一份挑刺之前，先想清楚是采纳、部分采纳还是不采纳。意见可能对，也可能看错了代码。按代码和研究记录判断，不按意见说得多肯定。两头都会坏事：对真问题视而不见，协议就带着洞去跑；把对的提案改错，跑出来的也不再是你想检验的东西——两种都会让这一轮作废。
|
|
|
|
- 采纳的，说改在哪："采纳：协议的'什么时候停'改为连续 50 轮没有改进或满 2000 轮即停，条款 c3 同步写明。"
|
|
- 不采纳的，说出依据："不采纳：意见认为随机种子会随运行变化，但基线代码在入口处固定写死了种子（read_source 可查），两次运行相同，不构成混杂。"
|
|
- 部分采纳的，说清采纳了哪一半、另一半为什么不改。
|
|
- 意见指出"停止条件不具体"，就在协议和条款里写死判据和上限，不要只在答复里说"会注意"。
|
|
- 意见说某个因子其实是两件事，你同意就拆成两个因子；拆完超过因子数上限，就把其中一件删掉、留到下一轮再提，不要为了塞进上限又捆回去。不同意，说出它为什么离了另一半就说不通。
|
|
- 意见说某条保障其实会改分（按系统提示词"因子与保障"一节的拦、补、改去问出来的），先自己把那几个问题再答一遍，读路径读到代码里。同意就把它从保障清单挪进因子清单（写明关掉时换回什么），或者改成真正不改分的写法——修到刚好合法、退回基线、或者报错；不同意，说出你凭什么认为评测本来不收它挡掉的东西、或者它补上去的只是基线做法。上一份研究里，作者以"修复只在罕见情形触发"为由留下了一道零容差门槛，结果它挡掉了全部结构起点。
|
|
- 意见说某个算出来的数不对，不用验算谁对：把这个数换成由代码按规则算出，答复"采纳：改为由规则……算出"。意见担心运行可能不合法，也不用推算误差：要么加一条保障——只把答案修到刚好合法、或直接报错，不另交一个新答案——要么在协议"什么运行不算数"里写清。
|
|
|
|
挑刺里标着"（推测）"的判断，你同意也好、不同意也好，它仍是推测：答复里不要把它写成已核实的事实。你核实过了（读了代码、查了运行），就写清核实的是什么。
|
|
|
|
一份挑刺里如果有几条意见，在同一个答复里逐条说。
|
|
|
|
### 只交改动了的部分
|
|
|
|
你的原提案就是底稿。改了哪一块，就把那一块整块重写进 `changes`：因子清单（`factors`）要改就写改后的完整清单，保障清单（`safeguards`）要改也写改后的完整清单，指标要改就把 `metrics` 的 `defined` 和 `reused` 一起写成改后的完整清单。改指标时留意"测不到时怎么办"：你的协议在某种情形下会让某个指标写 null，就别给它选 `invalidateRun`；改成引用别人登记的指标时，它的档位跟着原登记走（材料的指标清单里写着），对不上就换一个或自己登记一条 `recordMissing` 的。没改的不写；一处都没改就交空对象 `{}`。不在挑刺意见之外借机加新的改动：新想法下一轮另提，否则这一轮检验的就不是大家挑过刺、估过分的那份东西了。
|
|
|
|
你提案时交的作者自评三个数不能在这里改，它仍然封存着。挑刺以后你的看法如果变了，在预测那一步你会和别人一样重新给数，那时照你的新看法给。
|
|
|
|
### 条款
|
|
|
|
把实现拆成条款：每条一件实验员要做的事，写明落在哪个文件。核验员会逐条对照代码，所以每条都要能单独核：
|
|
|
|
- 好："`solver.py:local_search`：步长初值取可行区域边长的 1/10，连续一轮没有改进就减半，小于 1e-6 时停止。"
|
|
- 坏："按提案实现搜索改动。"
|
|
|
|
位置写 `"文件"`、`"文件:行号"` 或 `"文件:函数名"`：只写一个行号或一个函数名，不写 `25-36` 这样的范围；文件和函数必须在基线代码里真实存在，拿不准就用 `read_source` 读基线核实。条款之间不能互相矛盾；不要求改任务自带的评分和校验程序，也不要求改最终指标的算法。条款不让实验员运行求解去核对什么。
|
|
|
|
## 交什么
|
|
|
|
逐条答复（材料"本任务要处理的东西"末尾"本任务要答复的挑刺"列出了针对这个候选的每一份挑刺，每份一条答复，`critique` 照那里的挑刺编号逐字写；研究记录里别的评议提交针对的是别的提案，不用答复）、实现条款（`clauses`，以编号 c1、c2……称呼）、需要时的改动（`changes`）、答复正文（`body`：逐条答复之外要补充的话，没有就写"无"）。程序把改动叠到原提案上，得到冻结协议；答复原样跟着冻结协议，给之后预测的人对照着挑刺原文读。
|