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>

prompts/tasks/critique.md

@@ -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`）。作者会按挑刺编号逐条答复；正文程序不读，原样给作者和之后预测的人看。
+确实没找到问题，就说查了什么、为什么认为没有。从提案和代码核不了的地方，写"核不了"，说明需要看什么，这也是有用的意见。