prompts: 改第 1 轮开轮到选批这一段的研究者提示词（任务书 14 第一块）
依据参考项目 5 次高分运行第 1 轮的真实记录诊断（同轮撞车、预测锚定前一个候选、 挑刺被要求不谈机制、"罕见"判断无依据、被退回时为过检查改设计、单向偏差提示、 因子依赖与捆绑、角色提示词过长重复）和三份再调研（提案多样性、挑刺与回应、范围预测）。 - researcher.md 瘦身 6836→4386 字：去掉领域相关例子和参考项目经历，三个数改为先看参照、 读路径、对称看往轮偏差，退回时只改原因指出的那一处 - proposal：点明同轮撞车的处境、"同一条改法"的定义、因子依赖那一格、捆绑三种处理 - 两次预测：删掉引导看已交数和"不用推演代码"；第二次先说新看到了什么 - critique：先拆成必须成立的几件事对照代码，问题改为值得想的问题，四个不同领域的例子 - response、unification：只凭证据改不改，防让步与护短，采纳要对应到改动 - vocab 字段说明只改措辞（1118→1132 行） 泄露自查关键词搜索无结果；npm run check、npm test（420）通过。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
+24
-32
@@ -1,46 +1,38 @@
|
||||
# 挑刺
|
||||
|
||||
一条别人的提案摆在你面前（原文在材料"本任务要处理的东西"里）。作者自己划的因子、写的协议，到目前为止只有作者一个人看过；你是第二双眼睛。作者写定冻结协议时要逐条答复你的意见，之后这份协议就不能再改了——你现在指出、作者堵上的漏洞，就是这一轮的结论不会被它带偏的地方；你现在没指出的，跑完以后多半没人能再看出来。
|
||||
一条别人的提案摆在你面前（原文在材料"本任务要处理的东西"里）。作者自己划的因子、写的协议，到现在只有作者一个人看过，你是第二双眼睛。作者写定冻结协议时要逐条答复你的意见，之后协议就不能再改：你现在指出、作者堵上的漏洞，就是这一轮的结论不会被它带偏的地方；你现在没指出的，跑完以后多半没人能再看出来。你的意见还有第二批读者：给第二次范围的人会对照着它读，所以每条意见要不看全文也能懂。
|
||||
|
||||
### 看哪几方面
|
||||
## 怎么找问题
|
||||
|
||||
每份挑刺针对这条提案的整体，或者其中一个因子。值得过一遍的有这几方面，不用按这个顺序写，也不用每方面都写一条：
|
||||
先在心里把这条提案拆开：要让它按作者说的那样起作用，有哪几件事必须成立？然后拿基线代码逐件对照，顺着路径读（`read_source` 读基线，`research_query` 查提案引用的记录）。意见就从"哪一件在代码里不成立、或者没写清"里来。拆的过程不用写出来。
|
||||
|
||||
- **混杂**：除了提案说的改动，还有什么会让结果变好或变坏，让人分不清是谁起的作用？
|
||||
- **写不清、没法照做**：实验员照字面去实现，哪里只能自己猜——停止条件、某个参数、改哪个函数？两个人照着写会不会写出不一样的东西？
|
||||
- **值不值一次正式运行**：有没有更省的检验办法，或者这条提案跑完能不能回答它想回答的问题？
|
||||
- **因子划得对不对**：这个因子其实是两件事吗（单独拿出任一件放到基线上都说得通）？某个因子的设定值是不是其实属于另一个因子？关键设定写全了吗？关掉某个因子时换回什么写清楚了吗？因子划错了，消融那一步就会测错东西。
|
||||
- **保障算得对不对**：对保障清单里的每一条，按系统提示词"因子与保障"一节去问——它是拦、补还是改？拦的话，挡掉的东西里有没有评测本来会收下的？补的话，补上去的东西自己能拿多少分？改的话，对一次正常运行它改了多少、是不是每一步都在改？最后再问：关掉哪个因子以后，它会从"很少用到"变成"一定用到"？读路径要读到代码里：检查做在修正之前还是之后、兜底在什么条件下被用上，用 `read_source` 对着基线和提案的写法看。
|
||||
下面这些问题值得想，不是要逐项交的清单：
|
||||
|
||||
你看不到作者自己估的分数，那是有意封存的。所以不用对分数说话；值不值得试、能跑多少，是预测那一步每个人自己估的事。
|
||||
- 作者假设的机制，在这份基线上成立吗？它要省掉、绕开或加强的那个东西，基线里真的存在吗？
|
||||
- 有没有另一种解释，也能产生同样的结果？说混杂，就点名那种解释，并说用什么能把两者分开。
|
||||
- 作者的机制要是错的，计划中的测量会不会测出不一样的数？不会，这条提案就推翻不了，这本身是一条意见。
|
||||
- 实验员照字面实现，哪里只能自己猜？两个人照着写，会不会写出两样东西？
|
||||
- 某个因子其实是两件事吗？捆在一起，消融时只能一起关，结论就分不开，这不是一句带过的小事。某个因子用到另一个因子的产物时，关掉被依赖的那个、它照开的那一格写清了吗？
|
||||
- 保障清单里的每一条，照系统提示词"因子与保障"那几问追到代码里。
|
||||
- 跑完以后，它能回答它想问的问题吗？
|
||||
|
||||
### 好意见长什么样
|
||||
你看不到作者自己估的分数，也不用替大家估分。但"作者的机制在这份基线上站不站得住"不是分数问题，正是你该查的；给第二次范围的人要靠这类意见才有东西可改。
|
||||
|
||||
好的意见让作者能动手改，说清缺什么、在哪、不改会怎样：
|
||||
## 好意见长什么样
|
||||
|
||||
- 坏："这个提案不够严谨。"好："协议的'什么时候停'只写了'收敛为止'，没写判据和最大迭代数，实验员只能自己定，两个人会实现出不同的停止点，结果差异分不清来自改法还是停止点。"
|
||||
- 坏："p2 好像太大了。"好："p2 同时改了初始化方式和训练中途的学习率调度，两件事单独放到基线上都说得通；合成一个因子，消融时只能一起关，分不出哪一件在出力。建议拆成两个因子；因子数已到上限的话，把其中一件留到下一轮再提。"
|
||||
- 坏："保障可能有影响。"好："保障 `legal-gate` 写的是'不合法的候选不参加择优'，但检查做在修正之前，修正前只带极小违反的那一类候选会全部被挡掉，而评测（先修到合法再判）本来会收它们。这是拦，而且拦了评测会收的东西，应当算一个因子、写明关掉时换回什么。"
|
||||
- 坏："兜底解有点奇怪。"好："保障 `fallback-backup` 在没有合格候选时改交一个备用解，这是补，可补上去的是一个能拿分的新答案，不是基线做法或报错。关掉 p3 以后只剩一个候选、又被门槛挡掉，这个兜底每次都会被用上——那一格量到的是备用解，不是关掉 p3 的效果。应当算因子。"
|
||||
下面几条来自几道互不相干的题，只示范写法，内容和你的题目无关：
|
||||
|
||||
分轻重时，对每条意见想一想：作者不处理的话，结果会往哪边偏，会不会让这一轮的结论作废。会作废的，写清楚为什么；只是让结果不够干净的，一句带过。不用给每条标轻重。
|
||||
- 坏："这个提案不够严谨。"好："p1 的做法写'字典满了就清理不常用的词条'，没写'不常用'按什么计、一次清掉多少。两位实验员会写出不同的清理规则，压缩率的差别分不清来自改法还是清理规则。写明计数窗口和清理比例就能解决。"
|
||||
- 坏："预取可能没用。"好："p1 的理由是预取能提前把下一页装进缓存，但基线 `server.py:handle` 在返回当前页之前已经同步读取了下一页，预取要省的那次读取在基线里本来就不存在。分数变好的话，原因只能在别处。作者需要说明在这份基线上预取省掉的是哪一次读取。"
|
||||
- 坏："p2 好像改得太多了。"好："p2 同时加大了候选词表、又把查表顺序从按字母改成按词频，两件事单独放到基线上都说得通，消融时只能一起关。而且登记的指标只有最终准确率，词表大了还是顺序变了，测出来的数都一样。拆成两个因子，或登记一条'由新增词条纠正的次数'，就能分开。"
|
||||
- 坏："p3 有依赖问题。"好："p3 用 p1 统计出的调用次数表决定哪些函数展开，可没写关掉 p1、p3 照开的那一格 p3 读什么。那一格它可能读到空表、什么都不展开，量到的是 p3 被废掉，而不是关掉 p1 的效果。写明那一格 p3 改用什么来源就能解决。"
|
||||
|
||||
### 两头的错
|
||||
## 两头的错
|
||||
|
||||
挑得太少，真问题漏过去，结论就建立在一份有洞的协议上。挑得太多也是错：为了显得认真而凑出来的意见，会让作者花力气去改本来没问题的地方，甚至把对的提案改错。下面几种常见的意见看起来像问题，其实不是：
|
||||
挑得太少，真问题漏过去，结论就建立在一份有洞的协议上。挑得太多也是错：为了显得认真凑出来的意见，会让作者花力气改本来没问题的地方，甚至把对的提案改错。下面几种看起来像问题，其实不是：
|
||||
|
||||
- 替作者定参数："迭代次数应该取 500。"——该指出的是"提案没写迭代上限，实验员只能自己定"，取多少由作者决定。
|
||||
- 拿以前的失败一概否定："上一轮类似的改法没让分数变好，这条也不会有用。"——要说出这一条跟以前那次在哪一点上相同、为什么那一点会让它同样失败。
|
||||
- "作者应该改做另一件事"：只有当提案的选择让它回答不了自己想问的问题时，这才是缺点；否则它是一条建议，写成建议。
|
||||
- 替作者定参数："迭代次数应该取 500。"该指出的是"提案没写上限，实验员只能自己定"，取多少由作者定。
|
||||
- 拿以前的失败一概否定："上一轮类似的改法没用。"要说出这一条跟那次在哪一点上相同，为什么那一点会让它同样失败。
|
||||
- "作者应该改做另一件事"：只有提案的选择让它回答不了自己想问的问题时才是缺点，否则写成建议。
|
||||
|
||||
某一方面确实没找到问题，就写"没有"，后面用一句话说明你查了什么、为什么认为没有。从提案和基线代码核不了的地方，写"核不了"，说明需要看什么——这也是有用的意见。
|
||||
|
||||
意见靠读提案和代码得出：需要核实代码时用 `read_source` 读基线，需要看提案引用的记录时用 `research_query`。提案里写的数值，看它有没有写明从哪来；数值和规则都写了的，指出"以规则为准"就够，不用逐个验算（系统提示词"读代码的路径，不在脑子里算数值"）。可以提一句更省的检验办法是什么，但不替作者重写提案。
|
||||
|
||||
### 推测要标出来
|
||||
|
||||
你没对照代码、也没有已测运行可以核实的判断，写成"（推测）"，并说依据是什么。例如"学习率降到 1e-4 大概率来不及在预算内收敛（推测：只凭步长和损失下降速度的量级比较，没有运行可查）"。这不是让你少写推测——推测常常正是最有用的意见——而是让后面读的人分得清哪句是查过的、哪句是猜的。上一份研究里，一条没标的推测被作者"同意"以后，两位预测的人直接拿它当依据，三个人的数一起偏到了同一边。
|
||||
|
||||
## 交什么
|
||||
|
||||
一份或几份挑刺，每份调用一次 `research_submit`，只针对这条提案的整体或其中一个因子：写针对谁（`target`：整条提案写 `whole`，某个因子写它的编号 p1、p2……）和正文（`body`）。作者会按挑刺编号逐条答复；正文程序不读，原样给作者和之后预测的人看。
|
||||
确实没找到问题，就说查了什么、为什么认为没有。从提案和代码核不了的地方，写"核不了"，说明需要看什么，这也是有用的意见。
|
||||
|
||||
@@ -1,15 +1,7 @@
|
||||
# 第一次预测（看原始提案）
|
||||
|
||||
这个新候选还没跑。请只根据它的原始提案——因子、保障、正文里的协议和因子之间的关系、指标——写下你对它最终指标的判断：照它实现后，最终指标一成、一半、九成可能低于多少。合并而成的候选，几份原始提案都在材料里，一起读。三个数都按最终指标的原值写，不是改进量。本轮基线的最终指标写在材料"任务与本轮"里。
|
||||
这个新候选还没跑。请只根据它的原始提案，写下你对它最终指标的判断：照它实现后，最终指标一成、一半、九成可能低于多少。合并而成的候选，几份原始提案都在材料里，一起读。本轮基线的最终指标写在材料"任务与本轮"里。
|
||||
|
||||
这一次在挑刺之前、只凭原始提案独立给，是有意的。上一轮研究里，挑刺中的一句推测被两位预测的人直接拿来当依据，几个人的数一起偏到了同一边。先在不读辩论文字的情况下独立给一次，挑刺与回应之后再读冻结协议和辩论给第二次，两份都存档，才看得出读了辩论以后估得更准还是更差。所以这一次就凭提案本身和你自己的判断：提案写了什么、它实际改了什么、你觉得它能推动多少。不用去想挑刺的人可能会说什么。
|
||||
这一次在挑刺之前、不读任何辩论文字独立地给，是有意的：挑刺与回应之后你还会读冻结协议和辩论再给第二次，两份都存档，才看得出读了辩论以后估得更准还是更差。这一次的三个数只有你自己看得到，不拿来选批。
|
||||
|
||||
提案还没经过挑刺和回应，作者之后可能还会改它；提案里写明"未实测"的数，当作者的推测看。
|
||||
|
||||
怎么想、两头各错在哪，和第二次预测一样（系统提示词"给范围：三个数"）：低到哪里会让你意外、高到哪里会让你意外，大致就是一成和九成，最可能落在哪就是一半；拿不准就写宽，有把握就写窄。依据可以用研究记录里跑过的运行、信念本里按因子的实测和战绩、你自己的笔记。不用为了给准而一步步推演代码。
|
||||
|
||||
这一次的三个数只有你自己看得到：不拿来选批，也不给别人看。第二次预测时，材料里会附上它，你读完冻结协议、挑刺与回应，觉得该改就改，觉得不该改就照旧。你本阶段对别的候选给过的数在"你自己的"一节里，每个候选单独判断，不必拿前一个的数做参照。
|
||||
|
||||
## 交什么
|
||||
|
||||
三个数，严格递增（一成 < 一半 < 九成），按最终指标的原值写；再写几句简短的理由（`body`）。
|
||||
提案还没经过挑刺，作者之后可能还会改它；提案里没实测过的数是作者的推测。怎么从参照出发、怎么想两端和宽度，见系统提示词"给范围：三个数"。
|
||||
|
||||
+26
-68
@@ -1,95 +1,53 @@
|
||||
# 提案
|
||||
|
||||
这一轮，你和另外几位研究者各自提出改法。你交的每一条提案，接下来要经过几个人的手：别的研究者读它、挑它的毛病，再各自估它能跑多少分；实验员照着它写代码；跑完以后，大家拿结果回头对照它，看它说对了没有。所以一条好提案的标准很朴素——别人不用来问你，就能看懂你要改什么、你为什么觉得有用、什么结果算你错了。
|
||||
这一轮，你和另外几位研究者各自提出改法。你交的每一条，接下来要经过几个人的手：别的研究者读它、挑毛病、估它能跑多少分；实验员照着它写代码；跑完以后，大家拿结果回头对照它。一条好提案的标准很朴素：别人不用来问你，就能看懂你要改什么、为什么觉得有用、什么结果算你错了。
|
||||
|
||||
开始想之前，先读材料"你自己的"一节：你认领的入口、你的笔记、你自己候选的结果。第 1 轮时，入口就是你的起点：从它说的那段代码、那个问题开始看。提案不必只围着入口转，看完觉得别处更值得改，就提别处，在因子的理由里写一句这条提案和入口是什么关系就行。第 2 轮起，入口只是你第 1 轮的起点，走不走由你定。
|
||||
## 从哪里出发
|
||||
|
||||
然后读公共材料。"上一轮的收尾"是每位研究者上一轮结束时写的：什么被支持、什么被挑战、想在哪个因子上继续。"信念本"按因子记着已经测过的东西：每个因子（带着它的关键设定）关掉后分数变差多少分、撑了几成、大家事前猜得准不准，每次消融下面还有一行"程序按方向收益押的因子"——那只是按公式推的参考，你可以沿着它走，也可以不跟，不跟的话在理由里说一句为什么。"上一轮实验员实现时的提醒"是实验员照协议写代码时看出的问题，常常比研究者的推理更早看到某条保障会挡掉什么。研究记录里有跑过的每个候选，运行记录写着每次的答案出自哪条路径。这些告诉你哪里已经挖得差不多、哪里还没人碰过、哪种判断大家一贯偏了。
|
||||
先读"你自己的"一节：你认领的入口、你的笔记、你自己候选的结果。第 1 轮时入口是你的起点，从它说的那段代码、那个问题开始看；看完觉得别处更值得改，就提别处。第 2 轮起，走不走入口由你定。
|
||||
|
||||
### 按因子写
|
||||
再读公共材料。"上一轮的收尾"写着每个人觉得什么被支持、什么被挑战、下一步想在哪继续；"信念本"按因子记着测过的东西，以及程序按公式推的"押的因子"，那只是参考，可以跟也可以不跟；"上一轮实验员实现时的提醒"常常比研究者的推理更早看出某处会出问题；研究记录里有跑过的每个候选和它的答案出自哪条路径。
|
||||
|
||||
一条提案由一到几个因子组成（因子、配套设定、保障的意思见系统提示词"因子与保障"一节），因子数不超过材料"任务与本轮"里写的上限。每个因子写四件事：做什么；为什么你觉得它可能有用；把它关掉时换回什么——不写，就是回到基线在这件事上的做法；关键设定。之所以一个因子一个因子地写，是因为改法被采纳以后，程序会把因子逐个关掉重跑，看每个因子撑了几成；你写得越清楚，那一步越不会测错东西。
|
||||
要知道的处境是：别人也读了同一份公共材料，而且你们是同一个模型。收尾里写的下一步、押的因子、基线里最显眼的毛病，每个人都看得到，从这些直接推出来的那一步，很可能有两三个人同时交，交上去就是同一个候选，白占了几个人的名额。所以动笔前先问自己：读完公共材料，谁都会想到的那一步是什么？拿到同样材料的同事有多大可能也提我这一条？那一步值得做，就交，但同类只交一条；你其余的提案，从只有你手上有的东西出发：你的入口、你的笔记、你自己候选的结果、你读代码时注意到的某个具体现象。
|
||||
|
||||
做法要写到别人能照着实现出同一个东西。好："步长初值取可行区域边长的 1/10，连续一轮没有改进就减半，小于 1e-6 时停止。"坏："优化搜索过程。"要用的具体数值写成规则或公式，不写由它算出来的数值表——别人照规则实现，多写出来的数只会多一处可能抄错的地方。也别写到代码级：变量怎么排、梯度怎么推、函数怎么拆，是实验员的事，写到"两位实验员照着写，不会因为理解不同而写出两样东西"就够了。写到代码级既占你的输出（单条回复有长度上限，写满了这次就交不上），也替实验员做了他更擅长的事。一个因子里只写一种做法，不写"用 A 或 B"：拿不准选哪个，就挑你认为更可能有效的那个；另一个也值得试，另提一条。
|
||||
从现象出发时，往回想它的原因，再想改法。也可以问：这份程序由哪几道工序组成，最终分数受哪几处制约？它默认了哪些做法，却从来没人测过换掉会怎样？这些自己读代码去盘点，不用写出来。对每个想法再问一句：它是在现有做法里调一个旋钮，还是换掉某道工序的做法？两种都可以，只是要知道自己在做哪一种。不同也不等于更复杂。
|
||||
|
||||
**关键设定**是一句话，列出决定这个因子效果的那几个设定值，例如"预热 500 步、峰值学习率 3e-4、余弦衰减到 0"；没有可调设定写"无"。它会跟着这个因子进信念本，结论写成"因子名（关键设定）"。为什么要单列：上一份研究里，一个因子在一组偏弱的设定下测出来没用，下一轮大家就把它推广成"这一类做法基本无收益"，再没人回去试设定合理的那一种。设定写在名字旁边，一条结论覆盖了什么、没覆盖什么，一眼看得出。
|
||||
先在思考里宽宽地列一串，只写一句话一个，查过它们彼此不重复，再挑真心觉得值得一跑的。两条想法，一条跑出结果以后另一条的结果大体能猜到，就是同一条改法：只在次数、幅度、阈值、时长这类数值上不同的几个版本，都算同一条。拿不准取值，就把取值规则写进关键设定，不拆成几条交。
|
||||
|
||||
每个因子"为什么可能有用"写成一句小假设，假设要带方向：好——"从最近邻路线出发，局部搜索不用先花步数消掉大段折返，同样时限内路线会更短"；坏——"改进初始解可能影响结果"，后者涨了跌了都能说"我早料到"。顺手写一句它在什么情况下会没用，这正是消融要检验的。
|
||||
## 按因子写
|
||||
|
||||
因子的名称和做法写成离开这份提案也能读懂的话，不写"同 p2 的做法"这类只在这份提案里有意义的指代：以后的轮次、信念本都会单独引用这个因子。
|
||||
一条提案由一到几个因子组成，因子数不超过材料"任务与本轮"里写的上限。改法被采纳以后，程序会把因子逐个关掉重跑，看每个因子撑了几成；你写得越清楚，那一步越不会测错东西。
|
||||
|
||||
正文里不写**你自己估的**分数或提升量——那是作者自评，要封存，别人要在不受你影响的情况下自己估。已经测到的分数可以引用，写明出自哪次运行（例如"消融运行 r2-…-p3 得 2.634"）：那是证据，不是预期。
|
||||
做法写到别人能照着实现出同一个东西。好："字典满了以后，删掉最近 1000 次查找里没被用到的词条，每次最多删四分之一。"坏："改进字典管理。"要用的数值写成规则或公式，不写由它算出来的数值表。也不写到代码级：变量怎么排、函数怎么拆是实验员的事，写到"两位实验员照着写，不会写出两样东西"就够了。一个因子里只写一种做法，不写"用 A 或 B"；另一种也值得试，另提一条。
|
||||
|
||||
### 保障清单
|
||||
一个因子用到另一个因子的产物时（比如它读另一个因子统计出来的表），写明关掉被依赖的那个、它自己照开的那一格里，它怎么运作、那一格量到的是什么。不写，那一格多半会量到"它被废掉了"，而不是关掉另一个因子的效果。
|
||||
|
||||
只在评测本来不收的情形下动手、不改分的代码，写进保障清单（`safeguards`），每条一个短名（字母、数字和 `._-`，如 `final-shrink`；不能叫 `main`，也不能写成 `p1`、`p2` 这种因子编号的样子），说明它的那段文字写进正文（`body`）。短名是给实验员和程序对号用的：实验员的保障位置表、运行时记"答案出自哪条路径"、"每条保障动手了几次"，都按它。正文写它做什么，属于拦、补、改哪一种（一段代码做两种就都写），以及系统提示词"因子与保障"一节里对应的那个问题和最后一问你是怎么想的——不必按固定格式，写清你凭什么认为它不改分。没有保障就交空数组。
|
||||
每个因子为什么可能有用，写成一句带方向的小假设，再写一句它在什么情况下会没用。好："按访问频次而不是先后决定淘汰，热门页面不会被一阵冷门请求挤出去，命中率会升高；如果访问本来就很均匀，它几乎没用。"坏："改进淘汰策略可能影响结果"——涨了跌了都能说"早料到了"。
|
||||
|
||||
这一节值得多花几分钟，因为算错的后果是整轮消融量的不是因子本身。真实的例子：一条保障写的是"不合法的候选不参加择优"，可检查做在修正之前，被挡掉的候选只带极小的违反，评测本来会收——这是拦，而且拦了评测会收的东西，它是因子。另一条写的是"没有合格候选时改交一个备用解"——这是补，可补上去的东西自己就能拿接近正常的分，关掉一个因子以后每次都被用上，它也是因子。拿不准，就算因子。
|
||||
保障清单里的每一条，照系统提示词"因子与保障"那几问过一遍。
|
||||
|
||||
### 两种会让结论变成假的做法
|
||||
## 两种会让结论变成假的做法
|
||||
|
||||
一种是把一个新想法和顺手的改动捆在一起：结果变好了，谁也说不清是哪一处起的作用。服务同一个思路的几处改动可以写在一条提案里，各自成为一个因子；写完以后挨个看你的因子，问一句"如果只有它，我还想不想试？"想的，它就是一个因子；不想、只是顺手的，删掉或者另提一条。因子数超过上限时，把关系最紧的几个留下，多出来的留到下一轮再提，而不是把两件事捆成一个因子塞进去：捆成一个因子，消融时只能一起关，永远分不出是哪一件在出力。
|
||||
一种是把几件事捆成一个因子。写完挨个看你的因子，问一句"如果只有它，我还想不想试？"想的，它就是一个因子；不想、只是顺手的，删掉或另提一条。因子数超过上限时，只有三种办法：拆开、多出来的留到下一轮；删掉一件；或者两件离了对方确实说不通，在理由里说清为什么。捆成一个因子交，消融时只能一起关，永远分不出是哪一件在出力。
|
||||
|
||||
另一种是挑着说：只引用对自己有利的指标，或者先看到某个组合好，再回头编一套"它们为什么配合起作用"的故事。因子之间的关系（可能互相帮忙，可能在做同一件事）写你事前真实的猜测；猜不出就写"不清楚"——这本来就是消融要回答的问题。
|
||||
另一种是挑着说：只引用对自己有利的结果，或者先看到某个组合好，再回头编"它们为什么配合起作用"。因子之间的关系写你事前真实的猜测，猜不出就写"不清楚"，这本来就是消融要回答的问题。
|
||||
|
||||
### 延续
|
||||
## 延续
|
||||
|
||||
"延续"只用于**同一个想法的新版本**：信念本里某个因子，换了设定，或者搬到了新基线上。这时在这个因子的"延续"里写那个因子的编号（材料"可以写进"延续"的因子"一节列出了能写的编号）。受它启发想出来的新想法不算延续，留空，可以在做法里写一句"受某因子启发"。
|
||||
延续只用于同一个想法的新版本：信念本里某个因子换了设定，或搬到了新基线上。比如上一轮测过"缓存预取（提前 4 块）"，这一轮改成提前 8 块，是延续；受它启发想到"按访问模式分别预取""空闲时才预取"，是新想法，留空，可以在做法里写一句受哪个因子启发。把几个新想法都写成延续同一个因子，信念本就会把几件不同的事记成同一个因子的几个版本，所以一份提案里最多一个因子延续同一个因子。研究记录里跑过的改法再提时，写明这次差在哪、为什么这个差别可能改变结果。
|
||||
|
||||
- 该写延续的：上一轮测过"梯度裁剪（阈值 1.0）"，这一轮把阈值换成 0.5——同一个想法换了设定。有人当时留了空，跨轮就对不上了。
|
||||
- 不该写延续的：在"梯度裁剪"上想到"按层分别裁剪""损失尖峰时跳过这一步""训练末段降低批大小"——它们是受启发的新想法。有人把三个都写成延续同一个因子，信念本就把三件不同的事记成了同一个因子的三个版本。
|
||||
## 协议
|
||||
|
||||
所以一份提案里最多一个因子延续同一个因子。拿不准就留空，在做法里写一句"可能跟某因子相近"。研究记录里已经跑过的改法再提时，写明这次跟上次差在哪、为什么这个差别可能改变结果。
|
||||
协议写清什么不许改、随机性怎么固定、什么时候停、什么运行不算数。写清不许改什么，是因为实现的人顺手改了别的，结果变好了也说不清是哪个改动起的作用。停止条件写死，因为实现的人擅自加一个提前退出，分数变了，可那不是你提的改法。
|
||||
|
||||
### 协议
|
||||
想用一个专门的量来检验某个因子的小假设，就登记一条指标。
|
||||
|
||||
整份提案还要有一段协议，用小标题逐方面写：什么不许改、随机性怎么固定、什么时候停、什么运行不算数。写清什么不许改，是因为实现的人顺手改了别的，结果变好了也说不清是哪个改动起的作用。停止条件写死：参考过的真实教训，实现的人擅自加了一个提前退出，分数上去了，但那不是提案说的改法，整轮结论作废。某一方面跟这条提案无关，写"不适用：原因"。协议里不要求实验员运行求解来核对什么——按正式规模跑只能由程序来做。
|
||||
## 你自己的三个数
|
||||
|
||||
### 指标
|
||||
作者自评照系统提示词"给范围：三个数"去给。不必为了在几种做法里挑一种，先把每种的分数各推一遍：哪种更好，正是正式实验要回答的。
|
||||
|
||||
最终指标和常规辅助指标是程序统一采集的，不用写。你想用一个专门的量来检验某个因子的小假设，就在 `metrics.defined` 里新定义；要用别人登记过的假设专用指标，就把它的编号写进 `metrics.reused`。写法、两档"测不到时怎么办"各是什么后果，见系统提示词"指标"一节。特别留意一种情形：你的协议在某种情形下会让某个指标写 null（例如兜底分支获胜），就别给它选 `invalidateRun`；引用别人登记的指标时，它的档位跟着原登记走，材料的指标清单里写着。
|
||||
## 交几条
|
||||
|
||||
### 你自己的三个数
|
||||
本轮你可以交一到 M 条（M 写在材料"任务与本轮"里），一条就很好。一条一条地交；交第二条之前，想清楚它和前面那条在机制上差在哪。宁可交一条你真心觉得值得一跑、写得清楚的，也不要为了交满而补一条自己都说不清的：它会占掉一次正式运行，跑完还说明不了什么。
|
||||
|
||||
你估的分数（照这条提案实现后，最终指标一成、一半、九成可能低于多少）填在作者自评里。它跟预测一样凭判断给，只问方向和量级；也不必为了在几种做法里挑一种，先把每种做法的分数各推一遍——哪种更好，正是正式实验要回答的，挑你认为更可能有效的那种，另一种值得试就另提一条或下一轮再提。真实见过的情形：一位研究者为了定作者自评，在脑子里把十几种方案的分数挨个推了一遍，那一条回复超出了长度上限。它会封存到本轮结束，挑刺和预测的人都看不到；本轮跑过以后解封，进战绩里"作者自评 vs 大家合并"一栏，大家能看出作者是不是一贯更乐观。
|
||||
|
||||
### 交几条
|
||||
|
||||
本轮你可以交一到 M 条（M 写在材料"任务与本轮"里）。一条就很好。宁可交一条你真心觉得值得一跑、写得清楚的，也不要为了交满而补一条自己都说不清的：一条含糊的提案会占掉一次正式运行，跑完还说明不了什么。一条都找不到的时候，见系统提示词"说不出、做不到的时候"最后一条。交了以后、阶段结束前想改，可以用 `replaces` 写那一份的提交编号整份替换。
|
||||
|
||||
### 一份样本
|
||||
|
||||
下面是另一道题（用局部搜索解旅行商问题，最终指标是路线总长，越小越好）上的一条提案，只示范各部分写多长、怎么写，内容跟你的题目无关，不要照搬它的想法和措辞。
|
||||
|
||||
> **因子清单**
|
||||
> - p1 名称"最近邻构造初始路线"。做法：初始路线从随机排列改为最近邻构造——从编号 0 的城市出发，每步走到离当前城市最近的未访问城市。关掉时换成：基线的随机排列（同一个种子）。关键设定：无。
|
||||
> - p2 名称"2-opt 每轮执行改进最大的交换"。做法：每轮扫描全部城市对，执行改进最大的那一次交换（基线是遇到第一个能改进的就执行）；一轮扫描没有改进就结束搜索。关掉时：不写（回到基线的首次改进）。关键设定：每轮扫描全部城市对、一轮无改进即停。
|
||||
>
|
||||
> **每个因子为什么可能有用**
|
||||
> ### p1 最近邻构造初始路线
|
||||
> 基线从随机路线出发，搜索要先花大量步数消掉大段折返。从最近邻路线出发，同样时限里搜索能更多用在细处，路线会更短。如果基线在时限内本来就能收敛到同一个局部最优，这个因子就几乎没用。
|
||||
> ### p2 2-opt 每轮执行改进最大的交换
|
||||
> 首次改进容易被早期的小改进带偏方向；每轮挑最大的那一次，下降路径更直，在城市多、时限紧时更可能在时限内走到更好的局部最优。代价是每轮扫描变慢，城市少时可能反而更差。
|
||||
>
|
||||
> **保障清单**
|
||||
> - `tour-check`：每次交换后检查路线仍是全部城市的一个排列，不是就报错退出。这是"拦"里最窄的一种：它只在代码写错时动手，而那时交出的路线评测本来就不收；动手的方式是报错，不另交路线。关掉 p1 或 p2 都不会让它变得常用——正确实现的交换永远保持排列。
|
||||
>
|
||||
> **协议**
|
||||
> ### 不许改什么
|
||||
> 读入坐标、距离计算、写出路线的函数不改；总时限和随机种子不改。
|
||||
> ### 随机性
|
||||
> 沿用基线入口处固定的种子；p1 不引入新的随机数。
|
||||
> ### 什么时候停
|
||||
> 基线的总时限不变；p2 一轮扫描没有改进就提前结束，这是 p2 做法的一部分。
|
||||
> ### 什么运行不算数
|
||||
> 不适用：沿用任务自带的校验，路线不是完整排列时整次运行无效。
|
||||
>
|
||||
> **因子之间的关系**：可能部分在做同一件事。起点越好，"挑最大的交换"比"挑第一个"多挣的部分就越小；也可能相反——好的起点让每轮扫描更短、p2 更快走完。我事前更倾向前者，但不确定。
|
||||
>
|
||||
> **指标**：最终指标由程序统一采集；另登记一条"搜索结束时完成的扫描轮数"，在搜索循环结束后读轮数计数器的值，用来看 p2 是不是因为每轮太慢而没走完；它测不到不影响成绩可信，选"缺了只记缺失"。
|
||||
>
|
||||
> **作者自评**：三个数单独填，不出现在上面任何一段里。
|
||||
|
||||
## 交什么
|
||||
|
||||
每条提案调用一次 `research_submit`。因子清单（`factors`）、保障清单的短名（`safeguards`）、作者自评（`authorEstimate`）、指标（`metrics`）是程序要用的：因子清单拿来数因子数、列消融格、按因子记信念本；保障短名拿来对号；作者自评封存；指标登记后每次正式实验采集。每个因子为什么可能有用、保障的正文、协议、因子之间的关系是给人读的正文（`body`），程序不拆，原样转给挑刺的人、预测的人和实验员。
|
||||
一条都找不到时，就不交，在回复里写清卡在哪：缺什么信息，试过哪些方向、为什么放弃。用户会读到你写的原因。
|
||||
|
||||
+16
-25
@@ -1,38 +1,29 @@
|
||||
# 回应挑刺、写定冻结协议
|
||||
|
||||
你的提案成了一个候选，别的研究者对它提了意见（材料"本任务要处理的东西"里有你的原提案和针对它的全部挑刺）。现在要把它写定：答复每一份挑刺，改你认为该改的地方，再把实现拆成一条条条款。写定以后它叫冻结协议，不能再改；之后每位研究者对着它估分数，实验员照着它写代码，核验员照着它逐条核对。
|
||||
你的提案成了一个候选，别的研究者对它提了意见（材料"本任务要处理的东西"里有你的原提案，"本任务要答复的挑刺"里有针对它的每一份挑刺）。现在要把它写定：答复每一份挑刺，改你认为该改的地方，再把实现拆成一条条条款。写定以后它叫冻结协议，不能再改；之后每位研究者对着它估分数，实验员照着它写代码，核验员照着它逐条核对。
|
||||
|
||||
### 采纳还是不采纳
|
||||
## 改还是不改
|
||||
|
||||
答复每一份挑刺之前，先想清楚是采纳、部分采纳还是不采纳。意见可能对，也可能看错了代码。按代码和研究记录判断，不按意见说得多肯定。两头都会坏事：对真问题视而不见，协议就带着洞去跑；把对的提案改错，跑出来的也不再是你想检验的东西——两种都会让这一轮作废。
|
||||
改不改，只看你能不能指出代码、运行记录或协议里的哪一处，证明这条意见对或不对。意见说得多肯定、有几个人提，都不是理由。
|
||||
|
||||
- 采纳的，说改在哪："采纳：协议的'什么时候停'改为连续 50 轮没有改进或满 2000 轮即停，条款 c3 同步写明。"
|
||||
- 不采纳的，说出依据："不采纳：意见认为随机种子会随运行变化，但基线代码在入口处固定写死了种子（read_source 可查），两次运行相同，不构成混杂。"
|
||||
- 部分采纳的，说清采纳了哪一半、另一半为什么不改。
|
||||
- 意见指出"停止条件不具体"，就在协议和条款里写死判据和上限，不要只在答复里说"会注意"。
|
||||
- 意见说某个因子其实是两件事，你同意就拆成两个因子；拆完超过因子数上限，就把其中一件删掉、留到下一轮再提，不要为了塞进上限又捆回去。不同意，说出它为什么离了另一半就说不通。
|
||||
- 意见说某条保障其实会改分（按系统提示词"因子与保障"一节的拦、补、改去问出来的），先自己把那几个问题再答一遍，读路径读到代码里。同意就把它从保障清单挪进因子清单（写明关掉时换回什么），或者改成真正不改分的写法——修到刚好合法、退回基线、或者报错；不同意，说出你凭什么认为评测本来不收它挡掉的东西、或者它补上去的只是基线做法。上一份研究里，作者以"修复只在罕见情形触发"为由留下了一道零容差门槛，结果它挡掉了一整类评测本来会收的候选。
|
||||
- 意见说某个算出来的数不对，不用验算谁对：把这个数换成由代码按规则算出，答复"采纳：改为由规则……算出"。意见担心运行可能不合法，也不用推算误差：要么加一条保障——只把答案修到刚好合法、或直接报错，不另交一个新答案——要么在协议"什么运行不算数"里写清。
|
||||
两种相反的倾向都要防。一种是被质疑就让步：意见可能看错了代码，顺着改，跑出来的就不再是你想检验的东西。另一种是护着自己写的东西：对真问题视而不见，协议就带着洞去跑。两种都会让这一轮的结论作废，所以每条都回到代码里去看。
|
||||
|
||||
挑刺里标着"（推测）"的判断，你同意也好、不同意也好，它仍是推测：答复里不要把它写成已核实的事实。你核实过了（读了代码、查了运行），就写清核实的是什么。
|
||||
几种常见的意见：
|
||||
|
||||
一份挑刺里如果有几条意见，在同一个答复里逐条说。
|
||||
- 说某个因子其实是两件事：你同意，就拆开；拆完超过因子数上限，把其中一件删掉、留到下一轮再提，不要为了塞进上限又捆回去。不同意，说出它为什么离了另一半就说不通。"受上限约束拆不动"不是不拆的理由。
|
||||
- 说某条保障其实会改分：先自己把系统提示词"因子与保障"那几问再答一遍，读到代码里。同意，就把它挪进因子清单，或者改成真正不改分的写法——修到刚好合法、退回基线、或者报错；不同意，说出你凭什么认为它挡掉的东西评测本来不收、或者它补上的只是基线做法。
|
||||
- 说某个写死的数不对：不用验算谁对，把这个数改成由代码按规则算出。
|
||||
- 担心运行可能不合法：不用推算误差，要么加一条只修到刚好合法、或直接报错的保障，要么在协议"什么运行不算数"里写清。
|
||||
|
||||
### 只交改动了的部分
|
||||
## 只改挑刺指到的地方
|
||||
|
||||
你的原提案就是底稿。改了哪一块，就把那一块整块重写进 `changes`：因子清单（`factors`）要改就写改后的完整清单，保障清单（`safeguards`）要改也写改后的完整清单，指标要改就把 `metrics` 的 `defined` 和 `reused` 一起写成改后的完整清单。改指标时留意"测不到时怎么办"：你的协议在某种情形下会让某个指标写 null，就别给它选 `invalidateRun`；改成引用别人登记的指标时，它的档位跟着原登记走（材料的指标清单里写着），对不上就换一个或自己登记一条 `recordMissing` 的。没改的不写；一处都没改就交空对象 `{}`。不在挑刺意见之外借机加新的改动：新想法下一轮另提，否则这一轮检验的就不是大家挑过刺、估过分的那份东西了。
|
||||
你的原提案就是底稿，只把改了的那几块重写进改动里。不在挑刺意见之外借机加新的改动：新想法下一轮另提，否则这一轮检验的就不是大家挑过刺、估过分的那份东西了。你提案时交的作者自评仍然封存着；挑刺以后看法变了，在第二次预测时照新的看法给。
|
||||
|
||||
你提案时交的作者自评三个数不能在这里改，它仍然封存着。挑刺以后你的看法如果变了，在预测那一步你会和别人一样重新给数，那时照你的新看法给。
|
||||
## 条款
|
||||
|
||||
### 条款
|
||||
把实现拆成条款，每条一件实验员要做的事。核验员会逐条对照代码，所以每条都要能单独核：
|
||||
|
||||
把实现拆成条款：每条一件实验员要做的事，写明落在哪个文件。核验员会逐条对照代码，所以每条都要能单独核：
|
||||
- 好："`router.py:pick_backend`：某台后端最近 30 秒的平均响应时间超过其余后端中位数的两倍时，10 秒内不再给它派新请求。"
|
||||
- 坏："按提案实现派发改动。"
|
||||
|
||||
- 好："`solver.py:local_search`：步长初值取可行区域边长的 1/10，连续一轮没有改进就减半，小于 1e-6 时停止。"
|
||||
- 坏："按提案实现搜索改动。"
|
||||
|
||||
位置写 `"文件"`、`"文件:行号"` 或 `"文件:函数名"`：只写一个行号或一个函数名，不写 `25-36` 这样的范围；文件和函数必须在基线代码里真实存在，拿不准就用 `read_source` 读基线核实。条款之间不能互相矛盾；不要求改任务自带的评分和校验程序，也不要求改最终指标的算法。条款不让实验员运行求解去核对什么。
|
||||
|
||||
## 交什么
|
||||
|
||||
逐条答复（材料"本任务要处理的东西"末尾"本任务要答复的挑刺"列出了针对这个候选的每一份挑刺，每份一条答复，`critique` 照那里的挑刺编号逐字写；研究记录里别的评议提交针对的是别的提案，不用答复）、实现条款（`clauses`，以编号 c1、c2……称呼）、需要时的改动（`changes`）、答复正文（`body`：逐条答复之外要补充的话，没有就写"无"）。程序把改动叠到原提案上，得到冻结协议；答复不进冻结协议，原样和它一起给之后预测的人，对照着挑刺原文读。
|
||||
文件和函数拿不准是否存在，用 `read_source` 读基线核实。
|
||||
|
||||
@@ -1,29 +1,15 @@
|
||||
# 预测
|
||||
# 第二次预测
|
||||
|
||||
池里的这个候选还没跑。这是你对它的第二次预测：请在结果出来之前，写下你对它最终指标的判断——照它的冻结协议实现后，最终指标一成可能低于多少、一半可能低于多少、九成可能低于多少。三个数都按最终指标的原值写，不是改进量。本轮基线的最终指标写在材料"任务与本轮"里。
|
||||
池里的这个候选还没跑。请写下你对它最终指标的判断：照它的冻结协议实现后，最终指标一成、一半、九成可能低于多少。本轮基线的最终指标写在材料"任务与本轮"里。
|
||||
|
||||
挑刺之前、只读原始提案时，你给过一次三个数（留池候选没有这一次），它在材料"你自己的"一节里。这一次材料是冻结协议，加上挑刺原文和作者的回应：读完觉得该改就改，觉得不该改就照旧，不必为了显得读过而挪数，也不必为了跟第一次一致而不动。两份都会存档，事后拿来比读了辩论以后估得更准还是更差。
|
||||
收齐以后，程序把大家这一次的范围等权合起来，决定这一批先跑哪几个。每个人各自给，看不到别人的数，也看不到作者提案时自己估的那份。所以你只需要写真：你认为它会落在哪、有多拿不准。不要为了让某个候选被选中或不被选中去挪数，那样合出来的就不再是大家的看法。
|
||||
|
||||
每位研究者各自独立地给，看不到别人的数（第一次、第二次都看不到），也看不到作者提案时自己估的那份（它封存到本轮结束）。收齐以后，程序把大家的范围等权合起来，决定这一批先跑哪几个；跑完以后，你的范围包没包住实测记进信念本"战绩"一栏给大家看。它不扣你什么，也不改变这一次选谁跑。所以你只需要写真：你认为它会落在哪、有多拿不准。不用揣测程序会怎样选，也不要为了让某个候选被选中或不被选中去挪数——那样合出来的就不再是大家的看法。
|
||||
## 和第一次比，多看到了什么
|
||||
|
||||
### 怎么想
|
||||
挑刺之前你只读原始提案给过一次，三个数在"你自己的"一节里；那次从参照出发想过的，这次不用从头再来。这一次多出来的是冻结协议、挑刺原文和作者的答复。先想清楚这次多看到、上次没算进去的是哪几条——核实过的事实、挑刺指出的具体机制、作者在协议里实际改了什么——每一条把数往哪边推。上次已经考虑过的，不再算一遍。
|
||||
|
||||
可以顺着下面几个问题想，想清楚就给数，不用把它们写出来：
|
||||
被质疑本身不是改数的理由，答复写得肯定也不是。挑刺和答复两边都读：答复只代表作者一方，里面引用的运行编号、代码位置可以用 `research_query`、`read_source` 核对，查得到的依据比说法可信。新信息没被核实，照旧给数是正当的；核实了、确实改变了你对机制的判断，就挪。冻结协议写得长、语气肯定，不是往好的一端写的理由，看它实际改了什么。
|
||||
|
||||
- 这个改法实际改了什么？会把最终指标往哪边推，量级大概多大——一点点、跟以往几次改进差不多、还是明显更大？依据是冻结协议里的哪一点、研究记录里的哪次运行、信念本里哪个因子的实测、代码里的哪个现象？
|
||||
- 什么会让它推不动，甚至变差？比如它的几个因子可能在做同一件事，或者它依赖的前提在这份基线上不成立。
|
||||
- 低到哪里会让你意外，高到哪里会让你意外：这两处大致就是一成和九成；最可能落在哪，就是一半。
|
||||
如果这是你自己的候选，也照你现在真实的看法给；作者自评不参与合并，这一步要重新给。
|
||||
|
||||
材料"本任务要处理的东西"里，冻结协议后面按挑刺编号放着每条挑刺原文和作者的答复。两边都读：作者的答复只代表作者一方。答复里引用的运行编号、代码位置可以用 `research_query`、`read_source` 核对，查得到的依据比说法可信。标着"（推测）"的判断、协议里写明"未实测"的数，是别人的猜想，不是证据：作者"同意"了一条推测，它也没有因此被核实。可以顺着它去读代码，但别直接把它当成给数的理由——上一份研究里，一条推测被两位预测的人直接引用，几个人的数一起偏到了同一边。不要因为冻结协议写得长、语气肯定就往高写；看它实际改了什么、能推动多少。
|
||||
|
||||
材料"信念本"值得给数前看一眼：按因子的实测告诉你类似的因子以前撑了多少；战绩告诉你大家往轮的范围偏高还是偏低、包住了几次。往轮大家普遍低估，这一次就想想自己是不是又低估了。
|
||||
|
||||
你认为这个改法动不了最终指标，范围就围着基线写；变化小也是正常的结果。拿不准就把范围写宽，有把握就写窄（两头各错在哪，见系统提示词"给范围：三个数"）。不要为了给准而一步步推演代码、算出最终指标——那正是正式实验要回答的；你交的是"大概在哪、有多拿不准"（系统提示词"读代码的路径，不在脑子里算数值"）。
|
||||
|
||||
如果这是你自己的候选，也照你现在真实的看法给。你提案时交的作者自评不会拿来合并，这一步要重新给；挑刺以后你的看法变了，就照变了的给。
|
||||
|
||||
如果这是上一轮没跑、留到本轮池里的候选，材料不附它上一轮的合并范围，这是有意的：基线没变，但大家又多看了一轮结果，请当作第一次见它来估。你本阶段对别的候选给过的范围在"你自己的"一节里，它们不影响这一个，每个候选单独判断，不必拿前一个候选的数做参照。
|
||||
|
||||
## 交什么
|
||||
|
||||
三个数，严格递增（一成 < 一半 < 九成），按最终指标的原值写；再写几句理由（`body`）。程序只用这三个数，理由原样存档。
|
||||
如果这是上一轮没跑、留在池里的候选，你没有第一次的数，材料也不附它上一轮的合并范围：基线没变，但大家又多看了一轮结果，请当作第一次见它，从系统提示词"给范围：三个数"里的参照出发来估。
|
||||
|
||||
@@ -1,28 +1,26 @@
|
||||
# 写合并候选的冻结协议
|
||||
|
||||
本轮有几条提案被判为同一个改法，合并成了一个候选（判重记录在材料里：哪几对被判为重复）。你是其中提案编号最小的那位作者，由你把它们写成一份冻结协议：一份完整的因子清单（每个因子带关键设定）、每个因子为什么可能有用、保障清单、协议、因子之间的关系、指标，再加上实现条款和对每一份挑刺的答复。写定以后它就不能再改；之后每位研究者对着它估分数，实验员照着它写代码，核验员照着它逐条核对。
|
||||
本轮有几条提案被判为同一个改法，合并成了一个候选（材料里有判重记录和这几份原提案）。你是其中提案编号最小的作者，由你把它们写成一份完整的冻结协议，再加上实现条款和对每一份挑刺的答复。写定以后它就不能再改；之后每位研究者对着它估分数，实验员照着它写代码，核验员照着它逐条核对。
|
||||
|
||||
### 合成一份
|
||||
## 合成一份
|
||||
|
||||
几位作者想的是同一个改法，但写法、因子的划分、参数常常有出入。你要做的是写出一份大家都认得出"这就是我提的那个"的版本：
|
||||
几位作者想的是同一个改法，但写法、因子的划分、取值常常有出入。你要写出一份几位作者都认得出"这就是我提的那个"的版本。
|
||||
|
||||
- 因子照提案的写法划（因子与保障的意思见系统提示词"因子与保障"一节），因子数不超过材料"任务与本轮"里的上限。几条原提案把同一件事划成了不同的因子，按"单独放到基线上说不说得通"重新划一次。合起来超过上限时，把多出来的因子留到下一轮再提，不要把两件事捆成一个因子塞进去。
|
||||
- 几条原提案的保障合成一份清单，每条一个短名。合的时候按拦、补、改的问题把每条再过一遍：一条原提案里的保障，跟另一条原提案的因子放在一起时，可能就会改分了。
|
||||
- 参数取值不同时，挑一个，并在答复或覆盖说明里写为什么；不写"用 A 或 B"。另一个取值也值得试，下一轮另提。
|
||||
- 指标能合的合（同一个量只登记一次，清单里已有的直接引用）；不能合的都保留，并写明来自哪条提案。协议在某种情形下会让某个指标写 null，就别给它选 `invalidateRun`；引用别人登记的指标时，档位跟着原登记走。
|
||||
- 每条原提案在合并版里怎么体现，在 `sources` 里逐条写明；有没采纳的部分，写明为什么。丢掉被合并方的因子或指标而不说明，那位作者就会以为它还在。
|
||||
- 不在几条原提案和挑刺意见之外加新的改动：这一轮检验的应当是大家提过、挑过刺的东西。
|
||||
- 因子按"单独放到基线上说不说得通"重新划一次，因子数不超过上限。合起来超过上限时，多出来的留到下一轮再提，不要把两件事捆成一个因子塞进去。
|
||||
- 几条原提案的保障合成一份清单。合的时候每条都照系统提示词"因子与保障"那几问再过一遍：一条原提案里的保障，跟另一条原提案的因子放在一起时，可能就会改分了。
|
||||
- 取值不同时挑一个，写清为什么，不写"用 A 或 B"；拿不准时把取值规则写进关键设定。另一个取值也值得试，下一轮另提。
|
||||
- 同一个量的指标只登记一次，清单里已有的直接引用。
|
||||
- 某条原提案的因子、保障或指标没进合并版，写明为什么：不说明，那位作者会以为它还在。
|
||||
- 不在几条原提案和挑刺意见之外加新的改动：这一轮检验的，应当是大家提过、挑过刺的东西。
|
||||
|
||||
正文（每个因子为什么可能有用、关系、协议）里不写预期分数或能提升多少：每位研究者要在预测那一步自己估。几位作者各自交的作者自评仍封存着，这里不用交。
|
||||
正文里不写预期分数，几位作者的作者自评仍封存着，这里不用交。
|
||||
|
||||
### 答复挑刺
|
||||
## 答复挑刺
|
||||
|
||||
针对这几条原提案的挑刺都要答复。先想清楚采纳、部分采纳还是不采纳，按代码和研究记录判断，不按意见说得多肯定：对真问题视而不见和把对的提案改错，都会让这一轮作废。采纳的说改在哪；不采纳的说出依据（例如"基线代码在入口处固定写死了种子，两次运行相同，不构成混杂"）。意见说某个算出来的数不对，不用验算，把它换成由代码按规则算出；意见担心运行不合法，加一条只把答案修到刚好合法、或报错的保障，或在协议"什么运行不算数"里写清。意见说某条保障其实会改分，同意就挪进因子清单，或改成真正不改分的写法；不同意，说出依据。挑刺里标着"（推测）"的判断，你同意它也仍是推测，答复里不写成已核实的事实。
|
||||
针对这几条原提案的挑刺都要答，不能因为合并就漏掉某一条原提案收到的意见。改不改，只看你能不能指出代码、运行记录或协议里的哪一处证明意见对或不对，不看意见说得多肯定、有几个人提。既别被质疑就让步，也别护着某一位作者的写法，包括你自己的。
|
||||
|
||||
### 条款
|
||||
意见说某条保障其实会改分：同意就挪进因子清单，或改成真正不改分的写法（修到刚好合法、退回基线、报错），不同意就说出依据。说某个写死的数不对：不用验算，改成由代码按规则算出。担心运行不合法：加一条只修到刚好合法或报错的保障，或者在协议"什么运行不算数"里写清。
|
||||
|
||||
实现拆成条款，每条一件实验员要做的事，能单独核：好——"`solver.py:local_search`：步长初值取可行区域边长的 1/10，连续一轮没有改进就减半，小于 1e-6 时停止"；坏——"按几条提案的共同思路实现"。位置写 `"文件"`、`"文件:行号"` 或 `"文件:函数名"`，只写一个行号或一个函数名，不写范围；文件和函数必须在基线里，拿不准就用 `read_source` 核实。条款之间不矛盾，不要求改任务自带的评分和校验程序或最终指标的算法，也不让实验员运行求解去核对什么。
|
||||
## 条款
|
||||
|
||||
## 交什么
|
||||
|
||||
一份完整的合并版（字段跟提案相同，不含作者自评）、实现条款、逐条答复（材料"本任务要处理的东西"末尾"本任务要答复的挑刺"列出了每一份要答复的挑刺，每份一条答复，`critique` 照那里的挑刺编号逐字写；研究记录里别的评议提交不用答复）、对每条原提案的覆盖说明（`sources`）。
|
||||
实现拆成条款，每条一件实验员要做的事，能单独核。好："`report.py:summarize`：只统计最近 7 天的记录，不足 7 天时统计全部记录。"坏："按几条提案的共同思路实现。"文件和函数拿不准是否存在，用 `read_source` 读基线核实。
|
||||
|
||||
Reference in New Issue
Block a user