InfoRSI/任务书/14-flow-2-开轮到选批.md

任务书 14：flow 第 2 部分（开轮到选批）与这一段的提示词

这是 flow 四部分里的第 2 部分（docs/结构.md 第三部分"flow 分四部分写，各自验证"）。做完以后，研究能从第零轮走到第 1 轮选出本批：提案 → 判重合并 → 第一次预测 → 挑刺 → 回应与统一 → 冻结协议 → 第二次预测 → 选批，然后停下，原因写"实现还没写（任务书 15）"。

一份任务书里有三块，按顺序做：

1. 第一块：改提示词。 这一段要用的提示词，监督者和用户都认为一定有问题。先读调研结论，可以再调研，拿参考项目的真实记录诊断，然后改。改完先提交，再做后面两块。
2. 第二块：写代码。 写 src/flow 的 ①–⑧，加两处小修复。
3. 第三块：真实运行和评估。 真实跑 3 次，按整体研究质量评估，和参考项目的高分运行盲评比较。

本任务书已由用户和监督者在 2026-10-03 一起确定。下面说的"监督者"，是在参考项目目录里和用户讨论设计的另一个会话。

开工前先读

• CLAUDE.md：全部。尤其是"测试"一节：flow 的验收看研究质量；正式代码和检验代码完全分开。
• docs/方法.md：
  • 第三部分：角色与材料；
  • 4.3 ①–⑧；
  • 第五部分：每种提交；
  • 6.3、6.4：合并与选批；
  • 第九部分：中断与恢复。
• docs/结构.md：
  • 第三部分：步骤清单，以及"flow 分四部分写，各自验证"；
  • 第四部分：账本记录；
  • 第八部分：flow、materials、submissions、jev、rules、config 各节。
• docs/调研/提示词.md：提示词怎么写的两次调研结论。第一块必读。
• 任务书/12-flow-1-骨架与第零轮.md：第二部分（骨架怎么搭）、第四部分（正式代码和检验代码怎么分开）。两处这次照旧适用。
• WORK_LOG.md："关键决定"最后几条；"未完成"里"给 flow"的条目，第十部分列了哪几条归这次。
• 参考项目（只读，不要改）：
  • /home/iomgaa/Projects/RivalBits/src/controller/steps/research.ts，里面有 openRound、dedup、writeProtocols、predictInputs、writeSelection。看它怎么做，不照搬结构。

一、第一块：改这一段的提示词

1.1 范围

可以改的：

• prompts/roles/researcher.md；
• prompts/tasks/ 下的 proposal.md、firstPrediction.md、critique.md、response.md、unification.md、secondPrediction.md；
• src/vocab/submissions.ts 里这几种提交的字段说明（description），因为"现在交什么"是从字段说明生成的。只改措辞，不改字段的结构、类型、必填与否；vocab 上限 1150 行。

不改的：

• 第零轮那三份（entry、discussion、claim）：上一轮已经改过，事先定好不再调；
• 实验员、核验员、解释、收尾、消融的提示词：后面几部分再看；
• tasks/circle_packing/ 下的任务文件，第二块第 2 条那一处除外。

1.2 怎么做

1. 读调研结论。 docs/调研/提示词.md 全文。

2. 可以再调研。 针对这一段的几步可以派子 Agent 去查。参考项目的克隆在 /home/iomgaa/Projects/RivalBits/reference/。子 Agent 只读、不写 md，结论直接回复。值得查的方向：

   • 提出改法时怎么让几个人不交出同一个改法的不同参数；
   • 挑刺和审稿怎么写才能挑到实质问题：co-scientist 的反思和辩论、AI-Scientist 的审稿提示；
   • 回应和反驳怎么写；
   • 让模型给范围预测、而且给得准：llm_forecasting、forecastbench，以及 papers/ 下的预测类论文。

3. 拿真实记录诊断。 读参考项目高分运行第 1 轮里模型实际交了什么、被退回了什么、Jev 怎么判的：

   • 账本在 /home/iomgaa/rb-acceptance/{16-real-1,15-real-1,15-tight-2,14-real-1,12-real-2}/board.sqlite，只读，用 sqlite3 -readonly；
   • 提交在 submissions 表，按 stages.phase 区分；退回在 audit 表的 submission-rejected；
   • 参考项目当时的提示词在它的 git 历史和 prompts-used/ 下。新项目的提示词是以它为底稿改的。

   列出你看到的毛病。每条写清四样：现象、证据位置（库名、表、序号）、提示词里是哪一句引起的、怎么改。

   监督者已知的几条，你核实后可以直接用：

   • 同一轮三个人常交出同一个改法的不同参数。12-real-2 第 2 轮三份都是"在当前最好解附近加扰动再优化"，只是幅度不同；16-real-1 第 2 轮 c2、c3 跑出逐位相同的分数。
   • 一条后来证明有效的提案被三人都估成最低，没被选上（15-real-1 第 1 轮 c2）。
   • 挑刺有时只说空话，没有对照代码。
   • 研究者角色提示词 1.9 万字，每个任务都整份发。

4. 改。 照 docs/调研/提示词.md 第三、四部分的原则写。同一段内容只放一处：角色提示词里的内容不在任务提示词里再写一遍，任务提示词里不写字段怎么填（那是字段说明的事）。

5. 自查泄露。 照 docs/调研/提示词.md 第四部分最后一条：

   • 改完用填圆的关键词搜一遍你改过的全部文件，搜到就改掉，搜不到才算过；
   • 例子只用和题目无关的领域，不出现任何填圆的做法、数值或参考项目跑出来的具体经历。

6. 先提交，再写代码和跑。 提示词改完单独提交一次。之后的真实运行全部用这一版，看到运行结果以后不再改提示词。这是事先定好的规则：结果不管好坏都照实收下，交给用户。

二、第二块：代码

2.1 管哪些步骤

config 的 ROUND_STEPS 从 openRound 到 selectBatch。走到 implementation 时停下，原因写"实现还没写（任务书 15）"。现在只走得到第 1 轮，但代码按"第 r 轮"写，不写死 1。

2.2 每一步以哪条记录为准算做完

接着 docs/结构.md 第八部分 flow 一节的那张表往下加：

步骤	看到哪条记录算做完
openRound、carryOverPool	不写记录。本轮名单和提案上限就是冻结的配置；留池候选由 materials 从记录算出（Board.carried）
proposal、firstPrediction、critique、response、secondPrediction	这一轮这个阶段的关闭记录。阶段编号 r<轮>-<阶段>
dedupe	本轮的判重合并决定（decision，种类 dedup）
freezeProtocol	本轮每个新候选都有冻结协议记录（protocol）。全部候选在同一个事务里写
selectBatch	本轮的选批决定（decision，种类 batch）

2.3 每个阶段谁做、对哪个对象

一个任务就是"一个人对一个对象"。同一阶段里，一个人的几个任务按先后跑，不同的人同时跑（照任务书 12 第 2.6 节）。一个任务做完，以"这个人对这个对象有一份被收下的提交"为准。阶段关闭要等所有任务都做完。

阶段	任务	对象
提案	每位研究者一个任务，一个会话里交 1 到 M 条	无
第一次预测	每位研究者 × 本轮每个新候选（含自己的）	候选
挑刺	每位研究者 × 本轮每条不是自己写的原提案（监督者定，照参考项目：方法没写谁挑谁）	原提案
回应与统一	每个新候选一个任务：只有一条原提案的，由作者交"回应"；几条合成的，由其中研究者编号最小的作者交"统一"	候选
第二次预测	每位研究者 × 池里每个候选（新候选加留池候选）	候选

"派不派、什么时候停下"的规则照任务书 12 第 2.3 节，只是从"一个人"细到"一个人对一个对象"。查这个任务最近一次调用时，"模型调用开始"里存的材料带着对象，可以用它。

提交之后才知道的东西（submissions 的 known）：

• 提案：本人在本阶段已经收下几条；
• 回应：作者那条原提案；
• 其余照 submissions 的 KnownOf。

提案和挑刺一人可以交几份，编号用 materials 的 proposalId、critiqueId，收下时由 flow 分配。

2.4 三个程序步骤

判重合并（③）：

• 本轮新提案两两问一次 Jev（jev 的 judgeSameChange），每条新提案也和每个留池候选问一次。
• 判为相同的连成一组：A 和 B 相同、B 和 C 相同，A、B、C 就是一个候选（监督者定，方法没写这种情况）。
• 一组里有提案和某个留池候选相同，整组并进那个留池候选（方法.md 4.3 ③）。一组同时连到两个留池候选，按内部错误停下：真实运行里没出现过。
• 新候选按组里编号最小的原提案排序，编号用 materials 的 candidateId。
• 写一条决定：
  • 种类 dedup；
  • 输入：每一对的 Jev 判断，原样存；
  • 输出：materials 的 DedupOutput；
  • 规则名写 jevSameChange，版本 1；参数写 Jev 模型名；种子 null。

冻结协议（⑥ 之后）：

• 回应阶段关闭后，对每个新候选：
  1. 取它最后一份回应或统一；
  2. 用 submissions 的 protocolBody 拼出协议主体；
  3. 用 materials 的 freezeProtocol 补上候选编号、轮次、本批基线、合并了哪些原提案；
  4. 写冻结协议记录。
• 一定在回应阶段关闭之后写（"给 flow"：materials 把这条记录的出现当作"已公开"，提前写会泄露）。
• 本批基线是哪个对象：materials 已经有 Board.baselineOf，导出来共用，不另写一份。

选批（⑧）：

• 输入照 rules 的 BatchInput 拼：
  • 候选：池里每个候选，各人最后一份第二次预测的三个数；
  • 本批基线分数：materials 已经有 Board.baselineScore，导出来共用；
  • 方向、ε、λ、每批上限：取自冻结的配置和任务事实；
  • 余额：用 rules 的 runBalance 从运行记录算；
  • 种子：rules 的 decisionSeed，由研究编号、轮次、版本算（"给 flow"：同一轮选批、选格都用随机规则时，传不同的版本）。
• 用步骤清单里 selectBatch 那一步的规则，调 runBatchRule。
• 写一条决定：种类 batch，规则名和版本取 runBatchRule 交回的。

2.5 两处小修复（用户 2026-10-03 同意）

1. 讨论原文里的作废编号：讨论和认领的材料里展示讨论原文时，原文引用的入口编号已经作废的，程序在它后面就地标"（已作废）"。上一轮 v2-3 有研究者引用了不在最终清单里的编号，读的人会糊涂。写在 materials 里（谁看到什么归 materials）。
2. 删掉 tasks/circle_packing/baseline/SOURCES.md 里"一个实测过的事实（参考项目里跑出来的）……"那一段（第 21–23 行）。它把注意力引到半径函数上，研究者也引用过它。

2.6 不花钱的测试（tests/）

在 tests/flow-next-step.test.ts 里加"下一步做什么"的情形，至少覆盖：

• 第零轮做完 → 开提案阶段；
• 提案阶段一人交了两条、两人没交 → 只派没交的两人；
• 提案交齐关闭后 → 判重；
• 判重做完 → 开第一次预测，任务是每人 × 每个新候选；
• 挑刺阶段的任务里没有"挑自己的提案"；
• 合并而成的候选，回应阶段派给编号最小的作者交统一；
• 回应阶段关闭、还没有冻结协议 → 写冻结协议；
• 第二次预测关闭 → 选批；
• 选批做完 → 停下，原因"实现还没写"。

2.7 规模

• src/flow 这部分新增预期 500–800 行。总数超过 1700 行就停下来检查。
• materials 上限 1950 行（用户 2026-10-03 从 1900 放宽），现在 1897 行，这次要导出两个已有的函数、加作废编号的标注。不要为了压行数把代码挤在一起；超过 1950 就停下来，在报告里写多在哪几处。

三、第三块：真实运行和评估

3.1 跑什么

• 用第一块改好的提示词，配置照 eval/round-zero/research.json（3 位研究者、M = 1、每批上限 2、运行次数 13）。
• 3 个新的研究编号，从头跑到第 1 轮选批后停下，跑 3 次。
• 一个接一个跑：上次同时跑时内存不够，进程被系统杀过。
• 3 次里挑 1 次，在第一次预测阶段中途杀一次控制进程再启动，检查：
  • 被杀那次调用补了结束记录；
  • 交过的任务没被重派，没交的被重派；
  • 没有重复收下的提交；
  • 阶段照常关闭，往下走完。

3.2 评估：整体研究质量

用户 2026-10-03 定：不只看某一个想法有没有出现，而是从整体看系统有没有正常、高质量地做研究。用户原话："你现在直接把我们要以 SOTA 方法做标杆，简化为要对着联合优化来，这是不是有一点狭义了"。

对照组：参考项目 5 次高分运行的第 1 轮，即 16-real-1、15-real-1、15-tight-2、14-real-1、12-real-2，从它们的账本里读（不回放，用户定）。注意：

• 12-real-2 那一版用的是投票，不是范围预测，"预测"那一项记"不适用"；
• 参考项目那几次的提示词里写着填圆的具体做法，所以在"方向"这一项上它们占了便宜。

第 1 步：导出成同一种文本。

• 我们的 3 次运行和参考项目的 5 次，每次导出一份纯文本，按同样的小标题排：
  • 提案全文；
  • 判重结果；
  • 每条挑刺和它的回应；
  • 冻结协议；
  • 两次预测的三个数；
  • 选批结果；
  • 退回的次数和原因。
• 去掉能看出来历的东西：运行名、模型名、"16-real-1"这类字样；编号统一改写成"提案 1、候选 1"这种中性写法。字段名不同（"points"对"factors"）去不干净的，在给审阅者的说明里写"格式差异不代表好坏，忽略"。
• 8 份文本随机编成"运行 A–H"，对照表另存，审阅者看不到。
• 导出脚本放 eval/round-one/。

第 2 步：盲评。

• 派两个全新上下文的子 Agent 各自独立审阅，它们只读 8 份文本、TASK.md 和第 3.3 节的研究路径说明。
• 每个审阅者对每份文本，按下表 7 个方面各打 1–5 分，每个分数附原文引用作依据，结论直接回复给你，不写 md。
• 你把两份打分整理进报告，并按对照表还原成"我们的 3 次"和"参考的 5 次"。

方面	看什么	1 分	5 分
方向	提案在研究路径（第 3.3 节）上处在哪一步	都在死路上，或者原地打转	有提案沿着路径往前走了合理的一步，或者走了一条清单上没有、但讲得通的路
多样性与判重	同一轮的提案是不是不同类的做法；该合并的合了没有，不该合的有没有被合	几条是同一个改法换参数，判重也没拦	几条明显是不同的路，判重结果对
提案质量	照着能不能实现；机制有没有说清；因子划得对不对；关掉一个因子时怎么做有没有写；能不能被实测推翻	含糊、说不清为什么会好	换一个人照着写代码能写出同一个东西，什么结果算它错了也写清了
挑刺	有多少挑刺说中了实质问题（混杂、写不清、因子划分、保障会不会改分），有没有对照代码	空话、泛泛而谈	指出了具体问题，附代码依据
回应	作者有没有认真处理挑刺：改了，或者讲清不改的理由	回避、只说"同意"却不改	逐条处理，冻结协议里看得到改动
预测	范围合不合理；读了挑刺和回应以后，估计有没有变化、变得有没有道理	有荒谬的数（超过已知最好或远低于基线）、范围宽到什么都能包住，或两次一字不差	范围有依据，第二次的变化说得通
选批	选中的是不是大家认为最有希望的、在研究路径上合理的那几个	选中的明显不如没选的	选得合理

第 3 步：用 Jev 判几个封闭的问题（写在 eval/ 里，不动 src/jev/；两个顺序都问的取平均；阈值未校准，大于 0.5 判"是"）：

1. 判重对不对：本轮提案两两问"是不是同一个改法"（检验自己的问法，两个顺序都问），和程序的判重决定对照。列出两样：检验判"是"而程序没合的，检验判"否"而程序合了的。
2. 挑刺有没有被回应：每条挑刺问"作者的回应有没有处理这条挑刺：改了协议，或者给了不改的具体理由"。
3. 提案对应研究路径的哪一步：每条提案对 K1–K5 和 D1、D2 各问一次（第零轮的 eval/round-zero/ideas.json）。只做描述，不设通过线。

第 4 步：数字和过程。

• 每个阶段的模型调用次数、退回次数和原因（按提交种类分）、墙钟时间、token 用量；
• 有没有停下、交不出、卡住；
• 预测里超过已知最好（2.635983）或低于基线（0.9598）的数，逐条列出；
• 每个人对同一候选第一次和第二次预测的变化。

3.3 给审阅者的研究路径说明

写成 eval/round-one/path.md。这是给审阅子 Agent 读的输入文件，不是项目文档，放在 eval/ 下。内容照下面写：

26 圆填圆，基线 0.9598（圆心按同心环写死、半径逐对缩放），已知最好 2.635983。同类系统和参考项目的高分运行，大多沿着这样一条路往上走：结构化的起点或多起点 → 把圆心和半径一起交给连续优化器 → 在当前最好解附近加扰动再优化，或退火式接受 → 最后修到严格合法。辅助手段有：固定圆心用线性规划求最优半径、只动贴紧的那几个圆。死路有：只做几何构造（圆心按手排的规则摆、不移动），各系统都卡在 2.2–2.54；只改半径的分法、不动圆心，上限受布局限制。这是常见的一条路，不是唯一正确的路：一条清单上没有、但讲得通的路，同样算往前走了。第 1 轮能走多远取决于起点，参考项目第 1 轮采纳的分数在 1.55 到 2.632 之间。

3.4 怎么算通过

程序部分必须过：

• npm run check、npm test 全过；
• 3 次运行都走到选批后停下，每轮每个阶段开关成对；
• 冻结协议都写在回应阶段关闭之后；
• 杀进程那一次的四条检查都成立。

研究质量不设硬线，照实交给用户。 报告里要有：

• 7 个方面，我们 3 次的平均分和参考 5 次的平均分（两个审阅者分开列）；
• 我们比参考低 1 分以上的方面，单独列出，附你读原文看到的原因；
• 第 3 步 Jev 的结果，第 4 步的数字。

质量不好时，先查是不是 flow 或 materials 写错了：抽一次运行，看每个阶段"模型调用开始"里存的材料，是否符合方法.md 第三部分和 4.3。材料错了就修，修完重跑 3 次。材料对，就照实报告，不再改提示词（第一块第 6 条）。

四、正式代码和检验代码分开

照任务书 12 第四部分的 7 条。这次新加的检验代码放在 eval/round-one/，共用的工具放 eval/lib/。导出的文本、审阅结果、运行目录都放 /home/iomgaa/inforsi-eval/<日期-名字>/，不提交。

五、文档

完成后更新：

• docs/结构.md 第八部分 flow 一节：
  • "做完以哪条记录为准"的表，加上第 2.2 节的几行；
  • 第 2.3 节"谁做、对哪个对象"的表；
  • 判重怎么连组；
  • 新加的 eval: 命令。
• docs/结构.md 第八部分 materials 一节：补上新导出的两个函数和作废编号的标注。
• WORK_LOG.md：
  • "已完成"补一条；
  • 删掉这次做到的"给 flow"条目；
  • "关键决定"不用你写，监督者核对时补。

不新建 md 文件。eval/round-one/path.md 是检验的输入数据，不算项目文档。

六、"给 flow"的条目里归这次的

WORK_LOG"未完成"里的：

• 同一轮里选批和选格都用随机规则时，传不同的"版本"算种子。这次做选批这一半，选格留给第 4 部分。
• 冻结协议只在回应阶段关闭后写进账本。同一条里"解封只在本轮收尾阶段关闭后写"归第 4 部分，那半句留着。

七、审阅

这次改到了判重决定和选批决定，两处都是账本里"驱动实际动作的决定"（方法.md 第九部分）。写完后另派一个全新上下文的子 Agent 审阅一轮，只看第 2.4 节的三个程序步骤和恢复。审阅只防 CLAUDE.md"罕见情况怎么办"里的三类情况，提了别的照列不改。

八、验收与报告

做完后本地提交，然后在回复里交一份报告。监督者会对着实际文件、账本和评估输出逐项核对：

1. 提交号：提示词那次单独列；新增和修改的文件，分 prompts/、src/、tests/、eval/ 列；src/flow 和 materials 的总行数。
2. 提示词：
   • 诊断出的毛病清单，按第 1.2 节第 3 条的四样写；
   • 每份提示词改了什么、依据哪条毛病或哪条原则；
   • 泄露自查用的关键词和搜索结果；
   • 再调研派了哪些子 Agent、查到了什么。
3. npm run check、npm test 的完整输出。
4. 程序部分：3 次运行的研究目录；阶段开关和冻结时机的检查结果；杀进程那一次的四条检查。
5. 研究质量：
   • 第 3.4 节要求的表和单列项；
   • 两个审阅者各自的打分和主要依据；
   • Jev 结果；
   • 数字和过程。
6. 我们 3 次运行第 1 轮的提案名称、判重结果、选中了哪几个，各一行。全文在运行目录里给出路径。
7. 你和这份任务书、结构.md、方法.md 不一致的地方，以及为什么。
8. 规则不清楚的地方：哪里让你犹豫、哪里你是靠猜的。没有就写"没有"。没有真实证据的可能情况，在这里提一句就够，不写进 WORK_LOG。
9. 正式代码和检验代码分开的自查，逐条写"做到了"或"没做到、为什么"。