InfoRSI/任务书/15-冲分与先想后看-重测.md

任务书 15：改提示词后重测第零轮到第 1 轮选批，按路线分析对照

这份任务书不写新的正式代码。监督者已经改好了提示词（提交 ff5c8dd），你的事是：

1. 用新提示词真实跑 3 次，从研究开始跑到第 1 轮选批后停下；
2. 和已有的 6 次运行对照，看研究者选方向的倾向变了没有；
3. 顺手改一处字样。

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

一、为什么改提示词

监督者把 6 次真实运行逐份读过：3 次只到第零轮，/home/iomgaa/inforsi-eval/2026-10-03-r0-v2-{1,2,3}；3 次到第 1 轮选批，/home/iomgaa/inforsi-eval/2026-10-03-r1-v1-{a,b,kill}。读的时候不看某一个想法有没有出现，而看整条路线排在什么位置。

这里说的"能走到最好的路线"指一条完整的解法：

• 从像样的起点出发（结构化的布局或很多个起点）；
• 把全部圆心连同半径连续地挪到局部最优；
• 再做多起点或扰动重来；
• 最后保证严格合法。

挪圆心的手段不限一种：交给约束优化器一起解是一种，"固定圆心解线性规划、再按对偶方向挪圆心"反复交替也是一种。

看到的现象：

• 这类解法 6 次运行里都有人想到，但往往排在后面、写成"备选"，或者只是"做法类别"里的一个选项。
  • 6 次里有 5 次，有人分到了带这类解法的入口；但有的入口从基线那份被压坏的圆心起步，有的只被写成"方法类别与预算怎么花"。
  • 第 1 轮 3 次里，有 2 次交出了完整的高上限路线，而且都被选中了（b 的 r1-c3、kill 的 r1-c2）。
• **18 位研究者闭门写的第一个入口，全都是从读基线的半径函数出发。**三个入口的先后几乎总是"半径 → 圆心布局 → 做法类别"，正好对着基线代码的几个函数。讨论时也按这几道工序分工，一人管一道。
• 压低这类解法的理由几乎都不是技术理由，而是"求确定"。
  • 原文："第 1 轮宜小而确定""先把确定的钱落袋""好归因""消融分得开""白烧 1/12 次运行"。
  • 线性规划的耗时被反复估算，约束优化器的耗时从没人估过。
  • 研究者三人都说"分数大头在圆心布局"，第一志愿却常常是量尺、评测口径或布局族。

用户据此定了两处改法（2026-10-03，用户原话见 WORK_LOG.md"关键决定"），由监督者直接改提示词：

1. 正向只管冲分，消融负责解释。
   • 研究者角色提示词开头写明：正向实验选最可能拿到最高分的路，哪怕要换掉整道工序、结果难以预料。冲失败了基线不倒退（采纳规则保底），"为什么"由消融和解释去拆。
   • 估分照实，不因为方案激进就往高报。
   • 写入口、讨论、认领、提案的任务提示词跟着改。去掉了"一条就很好""别占掉一次正式运行"这类往保守推的句子。
2. 先不看代码自己解题，再拆基线工序，最后两边对照。
   • 写入口时三步：
     1. 用 read_source 读基线之前，在思考里列出从零写会怎么解、哪种最可能拿最高分（不用交）；
     2. 读基线，拆成工序；
     3. 逐道对照。
   • 提案提示词在第 1 轮让研究者在认领的入口上再做一遍。

另外，消融解释提示词里有一个例子带着填圆的做法，已经换成缓存领域的例子。

事先定好的规则（用户定，改不得）：

• 这次只换了提示词，跑 3 次，结果不管好坏都照实收下。
• 你不改提示词，不改配置，不改下面附录里的问卷和 Jev 问题。
• 研究质量不设通过线：这次要的是一份可信的对照，交给用户判断。
• 用 Jev 代替研究者押注这件事，这次不做（用户定），只留在 WORK_LOG 待办里。

开工前先读

• CLAUDE.md："测试"一节，尤其是"正式代码和检验代码完全分开"。
• 任务书/14-flow-2-开轮到选批.md 第三部分：怎么跑、怎么导出。这次照样用 npm run r1:run 跑。
• 监督者的提示词改动：git show ff5c8dd。
• 监督者留下的对照材料，在 /home/iomgaa/inforsi-eval/2026-10-03-route-control/：
  • texts/：6 次运行的第零轮全文（入口、讨论、认领，按书写先后）和第 1 轮提案、两次预测的三个数、选批、第二次预测正文；
  • extract.py：生成这些文本的脚本；
  • items.json、items.py：每次运行的最终入口和提案，共 57 条；
  • jevroutes.ts、jev1.json：对这 57 条问 Jev 四个问题的脚本和结果；
  • mylabels.json：监督者自己的判断，供监督者核对时用，你不用。
• WORK_LOG.md。

二、一处字样

flow 停下的原因现在写"实现还没写（任务书 15）"，在 src/flow/next-step.ts 和 tests/flow-next-step.test.ts。flow 第 3 部分顺延为任务书 16，这两处改成"实现还没写（任务书 16）"。docs/结构.md 里的同一句由监督者改。

三、重跑

• 配置照 eval/round-zero/research.json，只换研究编号，其余一律不动。三个编号：r1-v2-a、r1-v2-b、r1-v2-c。
• 每次跑到第 1 轮选批后，按"实现还没写"停下。
• 中途出错先查原因：
  • 是程序的毛病，按 CLAUDE.md 修了重跑，修了什么写进报告；
  • 是服务一时调不通，接着跑（node eval/lib/cli.ts --resume --dir <研究目录>）。
• 不杀进程，不跑回放。

四、对照分析

对照组是已有的 6 次运行，实验组是这次的 3 次。分析都写在 eval/ 下的新目录 eval/route/，产出放 /home/iomgaa/inforsi-eval/ 下。

4.1 导出文本

• 把 extract.py 移植进 eval/route/，可以用 TypeScript 重写，也可以照原样。
• 对新的 3 次运行导出同样格式的文本。
• 对 6 次对照运行也用你移植后的版本重新导出一遍，和 texts/ 里的逐字比对。不一致说明移植有误，先修好再往下做。

4.2 逐份阅读

• 9 次运行，每次派一个全新上下文的子 Agent，用附录一的问卷读全文、带原文引用回答。对照组也重新读一遍，保证两组用的是同一种读法。
• 子 Agent 不写文件，直接回复；你把 9 份回复原样存进产出目录。
• 子 Agent 只给文本路径，不告诉它是哪一组、提示词改过什么。

4.3 Jev

用 jevroutes.ts 的四个问题，问的方式和阈值都不改，对 9 次运行的全部最终入口和提案各问一次。对照组也重问，不用 jev1.json 的旧结果：同一组问题隔一段时间再问，概率会有浮动，重问以后两组的结果才能比。要花钱。

4.4 思考核查

新提示词要求研究者先在思考里自己解题，再读基线代码。研究目录 calls/<调用>/sessions/ 下的会话文件存着模型的思考和工具调用。新的 3 次运行里：

• 每个"闭门写入口"调用；
• 每个第 1 轮提案调用。

每个调用查三件事：

1. 第一次调用 read_source 读基线代码之前，思考里有没有列出几种从零写的解法；
2. 列了几种，各是什么，一句话一个；
3. 它判为最可能拿最高分的是哪一种。

列成表，每格附原文短引用。对照组也查第一件事，看改之前本来就有多少人先想再读。

4.5 要交的对照表（事先登记，改不得）

每次运行一行，9 行，标明组别：

列	说明
A	闭门写的第一个入口从基线某段代码出发的人数（共 3 人）
B	能走到最好的路线有没有出现在最终入口里
C	这类入口在每人志愿里最早排第几
D	有没有人分到这类入口
E	第 1 轮有没有这类完整路线的提案；有的话入选没有
F	各候选第二次预测合并后的一半那个数和九成那个数
G	最终入口和提案里，Jev"做好了能不能到最好的 1% 以内"判"是"的条数 / 总条数
H	同上，Jev"相对基线算不算激进"判"是"的条数 / 总条数
I	讨论里出现"求确定""好归因""先做稳的一步"这类理由的次数，附出处
J	思考核查第一件事：先想后读的调用数 / 调用数

• A 到 F 和 I 由你按 9 份阅读回复填，回复之间有出入的，回原文核实。
• 第零轮只到认领的对照运行，E、F 填"无第 1 轮"。

另附一张表：新的 3 次运行，每条最终入口和每条提案的名称、路线代号、Jev 四个概率。

五、测试与规模

• npm run check、npm test 通过。
• 正式代码只改第二部分那一处字样。
• eval/route/ 预期 300–500 行。

六、文档

• WORK_LOG.md："已完成"补一条，写明 3 次运行的目录、对照表所在位置和主要结果。
• 不新建 md 文件。

七、验收与报告

做完后本地提交，然后在回复里交一份报告：

1. 提交号；修改的文件，分 src/、tests/、eval/ 列。
2. npm run check、npm test 的完整输出。
3. 3 次运行的研究目录、停下原因、出过什么错和怎么处理的。
4. 4.1 移植后重新导出与 texts/ 逐字比对的结果。
5. 4.5 的对照表和附表。
6. 4.4 思考核查的表。
7. 新的 3 次运行，每次的最终入口名称、分配结果、第 1 轮提案名称、判重、入选，各一行。全文给路径。
8. 你读下来觉得新旧两组最大的不同在哪里，最可能被误读的地方在哪里。只写有原文支撑的，推断标"（推断）"。
9. 你和这份任务书不一致的地方，以及为什么。
10. 规则不清楚的地方：哪里让你犹豫、哪里你是靠猜的。没有就写"没有"。
11. 正式代码和检验代码分开的自查，逐条写"做到了"或"没做到、为什么"。

附录一：阅读问卷（原样发给子 Agent，只替换"文件"一行）

你在帮一位科研监督者分析一次自动化科研系统的真实运行记录。不要写任何文件，结论直接用中文回复给我。

背景

三位 AI 研究者（同一个模型）在研究一道题：单位正方形里放 26 个互不重叠的圆，最大化半径之和。基线程序得分 0.9598（圆心用同心环构造、被 clip 压到边上、半径用逐对缩放分），已知最好 2.635983。

研究先有"第零轮"：每人闭门写 2–3 个"入口"（从哪里开始看）→ 两次讨论分工（可整份换入口）→ 每人排志愿、程序分配入口。部分运行还继续了第 1 轮：每人交提案 → 第一次预测 → 挑刺 → 回应 → 第二次预测（三个数 q1/q5/q9 = 一成/一半/九成可能低于的分数）→ 程序选批（最多选 2 个跑）。

文件：〈文本路径〉（没有第 1 轮的，第 5 题写"无第 1 轮"） （全文用 Read 读，分段读完，别只看开头。）

路线分类（用这些代号归类）

• R-NLP：把全部圆心和半径（78 个数）一起交给连续约束优化器（SLSQP、罚函数梯度等）。
• R-SLP：固定圆心解 LP 得半径，再用 LP 对偶/敏感度指引挪圆心，交替或序列线性化。
• R-PHYS：生长式/物理式模拟，圆互相推开、慢慢长大。
• R-FAM：结构化布局族（网格、六角、行式、环）做参数扫描，半径用 LP 或构造给，圆心不做连续移动。
• R-LP：只在给定圆心上把半径分配做到最优（作为整条路线，不是作为某路线的部件）。
• R-GREEDY：往空隙里贪心塞圆。
• R-SEARCH：多起点、扰动、重启这类外层搜索（可与上面组合）。
• R-OTHER：评测口径、预算框架、几何分析、量尺诊断等不直接产出更好答案的。

一条入口或提案可以涉及多个代号，写主代号加部件代号。

要回答的问题（每条尽量附原文短引用，≤60 字，注明作者和大致行号）

1. 闭门写入口：每位研究者按书写先后列出入口，标路线代号；有没有自贴的"主/备选/兜底"标签；每人的第一个入口是不是从基线的某段代码出发。
2. 讨论：
   • a. 每份讨论里，作者认为"哪条路走对了收益最大"，原文怎么说。
   • b. 谈到 R-NLP、R-SLP 时，支持或压低它们的理由（预算 120 秒单核、非凸局部最优、容差为 0 的合法性、实现复杂、不好归因/测量等），原文引用。
   • c. 分工最终是按什么分的：按"层"（半径层/圆心层/搜索层）还是按完整路线？有没有人指出"层"不是独立路线、单做某一层到不了好答案？
   • d. 换入口时，换的方向是更保守还是更激进。
3. 有没有人写出一条"完整解法"（起点从哪来 + 怎样把全部圆连续改进到局部最优 + 多起点或扰动 + 最后保证合法），它被放在什么位置（主/备选/没人认领）？
4. 最终入口与志愿：每条最终入口的路线代号和标签；每位研究者的志愿里，R-NLP / R-SLP / R-FAM / R-LP 各自第一次出现在第几位；最后分到了什么。
5. 第 1 轮（若有）：
   • 每条提案的路线；
   • 各候选的第二次预测合并范围；
   • 研究者是否预期 R-NLP/R-SLP 高于或低于 R-FAM；
   • 第二次预测正文里关于"上限""平台""局部最优""风险"的判断原文；
   • 哪些被选中；
   • 提案相对认领的入口，是更保守还是更激进了。
6. 风险倾向：研究者是偏保守（先做确定能涨、可测、好归因的一步）还是偏激进（直接换掉核心做法、押大收益）？给出证据原文。有没有人明确说出自己在押注或在求稳？
7. 你觉得还有什么更深层的模式值得监督者注意（比如对某路线代价的误判、对上限的认识、把"量尺/诊断"当成提案、被基线代码牵着走等），给证据。

回复控制在 1800 字以内，按上面 7 个问题分节。只陈述文件里有的东西，推断要标"（推断）"。

附录二：Jev 四问

问题原文和判"是""否"的说明，以 /home/iomgaa/inforsi-eval/2026-10-03-route-control/jevroutes.ts 为准，原样搬进 eval/route/。四问：

• bold：相对基线程序，是不是激进的方向：换掉产出答案的核心做法，结果很不确定。
• standard：在数值优化行家眼里，这是不是这类填装问题常规、通常可靠的做法。
• reach：在 120 秒单核内认真做下去，能不能到已知最好 2.635983 的 1% 以内。
• complete：是不是一条本身就能产出最终答案的完整路线，而不是一个部件、一次测量或一个框架问题。

对 jevroutes.ts 只改文件路径：

• 读 items.json 的位置；
• import Jev 客户端的路径，改成仓库里 eval/lib/jev.ts 的相对路径。

阈值一律 0.5，原始概率全部存下。