# 任务书 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，原始概率全部存下。