InfoRSI/任务书/18-诊断.md

任务书 18：诊断（每轮提案之前，在当前基线上做诊断实验）

做完以后，每一轮在提案之前多走一段诊断：

1. 研究者写诊断解释和诊断实验；
2. Jev 合并重复的实验，研究者对每个实验交三个数；
3. 程序用信息价值减成本，定这轮做不做、做哪几个实验；
4. 实验员把选中的实验写进一份诊断程序，核验员核对，然后跑一次正式运行；
5. 程序结算，结果放进本轮提案以及之后全部研究者任务的材料。

同时，消融改成默认关闭。

方法以 docs/方法.md 为准，这次改了这几处：第一部分、第二部分、4.3（开轮之后的"诊断"一段，以及 ② ⑨ ⑫）、第五部分、6.3、6.9–6.11、新增的 6.12、第七、九、十一、十二部分。docs/结构.md 第三部分的步骤清单、第四部分的账本表、"flow 分几部分"表的第 5 行也同步改了。

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

1. 第一块：写代码。
2. **第二块：写诊断这一段的提示词。**这一块单独提交，提交以后才跑第三块。
3. **第三块：真实运行和评估。**从头真实跑 3 份完整研究，按研究质量评估。

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

开工前先读

• CLAUDE.md：全部。
• docs/方法.md：上面列的改动处全文，以及 6.7（诊断的数学规则大部分沿用它）、6.8、第三部分（材料顺序）。
• docs/结构.md：第二、三、四、五部分；第八部分 flow、rules、materials、submissions、tasks、runner、workspace、jev 各节。
• docs/调研/提示词.md：第二块必读。
• 任务书/17-flow-4-消融到收尾.md：消融这一段的写法。诊断的实现、核验、修复、运行、结算，大体照着消融和正向的写法来。
• WORK_LOG.md："未完成"里的"B、D 两份完整研究的分析"和"文献精读"两条。这两条说明了为什么要加诊断。
• 论文原文在 reference-paper/（不进仓库）。第二块用得到的：human-practice/mly.txt（Ng）、human-practice/platt1964.txt、ai-scientist/popper.pdf、ai-scientist/ai-coscientist.pdf、llm-search/AdaEvolve_2602.20133.txt。

一、第一块：代码

1.1 配置与步骤清单

• flow 里加一个 diagnosis，写法同 ablation：
  • { enabled: false }；
  • 或者 { enabled: true, perResearcher, maxExperiments }：每人每轮诊断实验上限 A，现行值 2；一次诊断最多做几个实验 D，现行值 4（方法.md 6.11）。
  • 两个都是方法参数。
• ROUND_STEPS 在 carryOverPool 和 proposal 之间加诊断的步骤。名字照现有的风格自己起，至少分开这几步：
  1. 诊断解释与实验；
  2. 判重合并；
  3. 诊断预测；
  4. 选诊断实验（决策点，带规则）；
  5. 实现、核验、修复；
  6. 诊断运行；
  7. 诊断结算。
• 诊断关掉时，这几步都标"按配置跳过"。
• 消融关掉时，explanation 也跟着跳过（方法.md 4.3 ⑫）。改 steps.ts 里那句注释，以及 schema 里 ablation.enabled: false 的说明。
• 选诊断实验的规则只有一条，就是"信息价值减成本"。照选格的做法登记进 rules 的登记表，步骤清单里带规则名和版本。不为它另造别的规则。
• 验收配置 eval/round-zero/research.json 不改。第三块用的配置放在 eval/diagnosis/research.json：照抄这份，改两处：诊断开（A = 2，D = 4），消融关。

1.2 rules：诊断的数学（方法.md 6.12）

要算的东西

• 成分模型；
• 方向收益 g_d(x) = x − b，外加一个收益为 0 的"都不走"；
• 信息价值；
• 价值减成本；
• 选实验，只比较装满的组合；
• 结算：每个实验的结局、确认与否定、世界比特、惊讶、诊断推出的方向。

复用，不另抄一份公式

• 6.7 的成分权重、权重更新、精确积分和部分格网格，现在写在 value.ts 里，是按"撑几成"刻度写的。把它抽成能接两种"实测 → 收益"换算的形式：
  • 消融：撑几成乘 h；
  • 诊断：x − b，再和 0 取大。
• 消融的数字必须逐位不变。拿现有的消融测试和 B、D 账本里的选格决定重算对照。
• 确认与否定、世界比特、惊讶，直接用 ablation.ts、bits.ts 现有的函数。

和消融不同的地方

• 有一个"都不走"的 0 选项：VOI 公式里两处都和 0 取大。
• 成本固定按 1 次运行算，ĝ₀ 取 max(0, ·)。
• R̂ = ⌈(余额 − 1) ÷ 每批上限⌉。
• 只比较装满的组合：实验数 ≤ D 时只有"全做"一个组合；超过 D 时，比较所有恰好 D 个的组合。
• 平票时按实验编号比。

选实验的决定记录要附上：全部组合的价值、成本、净值，选中的组合，以及每个没选中的实验的原因和净值。数字写到能离线重算的程度，同选格（方法.md 6.7、结构.md 第五部分第 2 条）。

战绩和信息账的 Phase 加一个 diagnosis，按人、按正向 / 诊断 / 消融分开报（方法.md 6.9、6.10）。

测试用独立算出的预期值，不复制实现的公式。至少覆盖：

• 两条解释对一个实验预测相反时信息价值为正，预测一样时信息价值为 0（只剩开放预留的部分）；
• 余额 < 2 时不诊断；
• 实验数超过 D 时只比较装满的组合；
• 证据不足的实验不判、不记账；
• 诊断推出的方向：全部实验收益不为正时，记"没有指出能涨分的方向"。

1.3 vocab、submissions、jev

vocab：新加四种提交（方法.md 第五部分表里"诊断"三行）：

• 诊断解释与实验；
• 诊断预测；
• 诊断实现（修复同一种）；
• 诊断核验。

字段说明照现有提交的写法：每样都有出口。

submissions 收件时查：

• 解释 1 至 M 条，实验 1 至 A 个；
• 诊断预测覆盖"自己每条解释 × 每个合并后的实验"，不多不少，三个数严格递增；
• 诊断实验登记的指标只能是"缺了只记缺失"；
• 诊断核验的逐个实验结果覆盖全部选中的实验。

jev：

• 诊断实验判重：新加一个问法，照 dedup 写，对象是"在当前基线上动一处的诊断实验"。阈值暂用 dedup 的 0.3，等真实数据再校准，照实写进注释。
• 诊断实验交上来时，查"改动了评测、自相矛盾、太含糊"：直接用 freeze 那三问。如果问法里的措辞只适合冻结协议，就照 dedup 的办法加一个变体，不改原问法。
• 诊断程序的代码改动：直接用 diff 那五问。

1.4 tasks、runner、workspace：一次运行跑几个实验

运行方式

• 一次诊断运行就是一个容器、一次登记、一次确认启动、一次扣次。runner 的现有规矩（限时、限核、断网、记资源、按容器名恢复）照旧。
• 总时限、核数照任务规定（填圆：120 秒、1 核）。容器里由任务的 harness 按顺序跑每个实验，每个实验分到"总时限 ÷ 实验数"。
• harness 记下每个实验实际用了多久、是不是超时。一个实验超时或跑崩，不影响后面的实验。

每个实验从哪里出发

• 从当前基线的代码，以及产出当前基线的那次正式运行的原始产物出发。
• 这份产物在运行目录里，用只读的方式交给每个实验。
• 怎么交（文件路径、参数还是环境变量），由 tasks 定，写进 TASK.md 给实验员看。

判分

• 每个实验交出的答案，用任务现有的校验器和合法化单独判分。
• 判分结果按实验分开记在这一次运行的结果里：分数、合法化、登记的指标、用时、结局。
• 资源用量记整次运行的。

workspace

• 诊断程序存成一个版本，记进冻结代码记录，同时附上每个实验的位置表。
• 实验员的工作目录从当前基线代码取出，再放进那份原始产物。

改动范围

• 改 tasks 和 runner 时，正向运行、消融运行、基线运行的行为一个字节都不能变。
• 用现有测试，加上任务书 17 的一次正向运行定义前后对照来证明。

1.5 ledger、materials

ledger

• 决定加一种：选诊断实验。
• 结算加一种：诊断结算，按轮次唯一。
• 写入时要拒绝"这次诊断运行已经确认启动，才冻结诊断预测"，照消融拒绝晚冻结解释的写法。

materials：给谁看什么（方法.md 第三部分、4.3 诊断一段）

• 诊 1
  • 当前基线的代码，产出它的那次运行的答案、分数、指标，信念本，上一轮收尾；
  • 第 1 轮还要放第零轮的全部记录。
• 诊 2
  • 合并后的实验清单（标明作者），全部诊断解释，自己的解释；
  • 看不到别人这一步交的数。
• 实现、修复
  • 选中的实验原文，当前基线代码，原始产物的路径；
  • 修复时还要放核验意见。
• 核验
  • 选中的实验原文，以及"当前基线 → 诊断程序"的改动，加上位置表。
• 从 ② 提案开始，本轮之后全部研究者任务
  • 公共材料里加"本轮诊断结果"一节：每个实验做了什么、实测、用时、结局，每条解释确认或否定，诊断推出的方向；
  • 本轮没诊断时，写原因。
• 实现正向候选的实验员
  • 本轮有诊断时，材料里给出诊断程序代码的位置（只读），注明"冻结协议引用诊断实验时作参考"。
• 信念本
  • 加"诊断历史"（方法.md 6.10 第 3 条）。

规模

• materials 现在 1930 行，上限 2250（第五部分）。
• 先把诊断材料写清楚，再看能不能和消融材料共用写法。

1.6 flow

怎么走

• 照步骤清单走。方法.md 4.3 诊断一段每一条都要落实。
• 余额 < 2 时，诊 1–诊 4 都不做：不开阶段，不写记录，从余额就能算出"本轮没有诊断"。这一点和"无采纳则没有消融"一样。
• 诊 3 定了"不诊断"时，诊 4 不做。
• 实现：一个实验员任务，对象是本轮诊断。
• 核验：一个核验员任务，交逐个实验的结果。
• 修复：只修不通过的实验，次数上限 maxRepairs。用完仍不通过的实验从这次诊断里拿掉，记"证据不足：核验不通过"。一个都不剩时，写事件，不跑，不扣次。
• 拿掉实验时，诊断程序里对应的代码怎么处理，你定。要求是：跑的只是剩下的实验，而且核验员核过的代码不再改动。
• 诊断运行用 formalRun，用途写 diagnosis，对象是本轮诊断。
• 结算、写信念本之后，才开 ② 提案。

阶段编号照消融的写法按"第几次"排。

**"做完以哪条记录为准"**补进结构.md 第八部分 flow 一节的表。

规模

• flow 现在 1673 行，预计加 400–700 行，上限照结构.md 第七部分（3500）。

1.7 审阅

写完后另派一个全新上下文的子 Agent 审阅一轮，只看这几处：

• 诊断运行的登记、扣次和恢复；
• 选诊断实验和诊断结算的输入，是不是照 rules 的类型拼对了；
• 诊断预测冻结早于运行启动；
• 拿掉实验以后跑的是不是剩下的实验；
• 消融的数字是不是逐位不变；
• 正向、消融、基线运行定义是不是没变。

审阅只防 CLAUDE.md"罕见情况怎么办"里的三类情况，提了别的照列不改。

二、第二块：诊断这一段的提示词

2.1 范围

要写的

• 新的任务提示词：诊断解释与实验、诊断预测、诊断实现、诊断修复（如果修复能共用实现那份，就不另写）、诊断核验；
• 四种新提交的字段说明（vocab 的 description）。

要改的

• prompts/roles/researcher.md：加上诊断这项工作。只加诊断需要的几句，其余不动。
• prompts/roles/experimenter.md、verifier.md：加上诊断程序怎么写、怎么核。只加几句。
• prompts/tasks/proposal.md：加一句，用上本轮的诊断结果。

不改的

• 其余提示词；
• tasks/circle_packing/ 下除 TASK.md 里"诊断实验怎么拿到原始产物"那一段以外的内容。

2.2 诊断提示词要让模型做到的事

照 docs/调研/提示词.md 第三、四部分写：引导怎么想，不做必填的结构化清单。诊断这一段要讲清楚以下几点。例子只用和题目无关的领域。

1. **诊断问的是"剩下的空间在哪"，不是"上一步功劳怎么分"。**做法是在当前程序上只动一处，看分数怎么变：
   • 换成明显更强、不计时间的版本，看这一步后面还藏着多少；
   • 拿掉它，看它现在撑着多少；
   • 换一种做法；
   • 放宽一个限制。 参考 Ng《Machine Learning Yearning》第 44–45、53–57 章的"优化验证测试"和"按部件看上限"，原文是 reference-paper/human-practice/mly.txt。Platt 1964 的"强推断"（同一目录）讲的也是这件事：先列几种互相竞争的解释，再设计能排除其中一些的实验。
2. **好的诊断实验，不同解释对它的预测差得远。**大家都预测"涨不了多少"的实验，测了也不改变下一步。研究者之间意见不同的地方最值得测。
3. **每条诊断解释要写什么样的实测会推翻它。**写不出来，说明这条解释还不能被检验。
4. **以前否掉某条路线的理由，本身也是一条没测过的看法，**可以拿来设计诊断实验。
5. **诊断实验只动一处，**交出能判分的答案，用时要放得进分到的那份时间。
6. **实验员实现诊断实验时，照写法做，不顺手改进。**任务书 16 查过的"照规格实现"结论可以直接用。

2.3 怎么做

1. 读 docs/调研/提示词.md，以及上面提到的论文原文。
2. 派子 Agent 再查两样。子 Agent 只读、不写 md，结论直接回复。
   • 让模型提出互相竞争的解释，并设计能把它们分开的实验，有哪些写法实际有效：POPPER 的证伪实验设计、co-scientist 的假设与评审、AdaEvolve 停滞时的元指导。原文在 reference-paper/，参考实现的克隆在 /home/iomgaa/Projects/RivalBits/reference/。
   • 同类系统怎么写"诊断当前瓶颈"的提示。
3. 写。任务提示词里不写字段怎么填，那是字段说明的事。
4. 自查泄露：照任务书 17 第 1.2 节第 5 条，用填圆的关键词搜一遍改过的全部文件。关键词至少包括任务书 16、17 用过的那些，再加"联合""半径""LP""起点"。搜到就改掉，搜不到才算过。
5. **先提交，再跑。**提示词单独提交一次。之后的真实运行全部用这一版，看到运行结果以后不再改提示词。

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

3.1 跑什么

• 配置用 eval/diagnosis/research.json（诊断开、消融关），从头新跑 3 份完整研究，一直跑到余额用完、停在"导出还没写"。
• 3 份同时跑，同任务书 17 第 3.1 节。CPU 时间与墙钟时间之比照样列出。
• 3 份里挑 1 份，在一次诊断运行确认启动以后、出结果之前，杀一次控制进程再启动。检查三件事：
  • 恢复后没有重跑；
  • 只扣了一次；
  • 每个实验的结果都照常写进去，结算和后面的步骤照常走完。
• 中途出错，照任务书 17 第 3.1 节处理。
• 模型服务的内容审核拦下某份材料（任务书 17 的 E 那种情况）时，这份研究照方法停下，照实记，不改写模型交的文字，不换模型。

3.2 评估：研究质量

不设硬线，结果照实交给用户。

第 1 样：诊断解释和诊断实验的质量。每一轮的诊 1，派一个全新上下文的子 Agent，在看不到诊断结果的情况下读：诊断解释、诊断实验、诊断预测、当前基线代码与它的分数。回答：

• 解释说出了具体的瓶颈吗？写了什么实测会推翻它吗？
• 同一轮几位研究者的解释有没有真正不同？
• 每个实验是不是只动一处？是不是真能把几种解释分开？
• 有没有实验去测以前否掉过的路线的理由？

**第 2 样：选实验。**每轮列出：

• 合并后的实验、各实验的事前合并范围、各组合的信息价值、成本、净值；
• 选了哪几个，或者为什么不诊断。

回答：选中的是不是大家分歧最大的；有没有因为大家意见一致而不诊断，出现了几次（方法.md 第十二部分第 10 条）。

**第 3 样：诊断实现照写法没有、核验员判得对不对。**每次诊断，派一个全新上下文的子 Agent 读：实验原文、当前基线代码、诊断程序、位置表、concerns、核验结论。回答：

• 每个实验是不是只动了写的那一处，有没有偷偷改进别的地方；
• 核验员该判不通过却通过的、不该判却判了的。

**第 4 样：诊断有没有改变走向。**这是这次最要紧的一样。每份研究每一轮一行：

• 诊断推出的方向和它的实测收益；
• 本轮提案里有几条沿这个方向；提案正文有没有引用诊断结果；
• 选批选没选沿这个方向的候选；
• 正向实测，以及沿这个方向的候选比诊断实测高还是低（方法.md 第十二部分第 9 条）；
• 采纳了什么。

另列：诊断指出了方向、却没有人沿它提的轮次（第十二部分第 11 条）。

第 5 样：预测准不准、分不分得开。

• 诊 2 预测的落点四段和覆盖率，按人、合并分开报；
• 同一轮各实验合并中位数之间的差距，和任务书 17 里正向候选之间的差距（0.001–0.03）对比。

**第 6 样：整份研究的走向。**每份研究列：

• 每一轮：诊断做没做、几个实验；正向候选；采纳与分数；离已知最好还差多少；
• 分数随轮次的曲线。和任务书 17 的 B、D（没有诊断、消融开）并排，再并上参考项目 15-real-1、15-tight-2、16-real-1。
• 每个跑过的正向候选一行，同任务书 17 第 3.2 节第 6 样的表。

**第 7 样：程序账目。**每份研究列：

• 确认启动的正式运行数（基线、诊断、正向分开）和余额减少的次数，两者应相等；最后余额为 0；
• 每次诊断：选了几个实验，核验几次、修复几次、拿掉了几个，跑了几个；每个实验的用时和结局；
• 诊断预测冻结早于诊断运行确认启动；每轮最多一次诊断结算；
• 余额 < 2 的那一轮没有诊断记录；
• 消融关着：没有消融阶段和解释阶段，账本里有"按配置跳过"；
• 杀进程那一次的三条检查。

3.3 怎么算通过

程序部分必须过：

• npm run check、npm test 全过；
• 3 份研究都跑到余额为 0、停在"导出还没写"，阶段开关成对；
• 扣掉的次数等于确认启动的运行数；
• 杀进程那一次的三条检查都成立；
• 消融的数字逐位不变（1.2）；
• 正向、消融、基线的运行定义没变（1.4）。

**研究质量不设硬线，照实交给用户。**质量不好时，先查是不是 flow 或 materials 写错了：抽一次诊断，看研究者、实验员、核验员"模型调用开始"里存的材料，是否符合方法.md 第三部分和 4.3 诊断一段。材料错了就修，修完重跑；材料对，就照实报告，不再改提示词。

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

照任务书 12 第四部分的 7 条。这次新加的检验代码放 eval/diagnosis/，能复用 eval/full/、eval/lib/ 的就复用。运行目录、审阅结果放 /home/iomgaa/inforsi-eval/<日期-名字>/，不提交。

五、规模

模块	现在	这次
flow	1673	加 400–700，上限 3500
rules	1762	加 200–400，上限 2500
materials	1930	上限 2250（用户 2026-10-05 定）
vocab	1131	上限 1300（用户 2026-10-05 定）
其余	—	照结构.md 第七部分

写的过程中，哪个模块超过预计一倍，停下来检查。

六、文档

完成后更新：

• docs/结构.md 第八部分各模块新导出的函数、类型；flow 一节"做完以哪条记录为准"的表、"谁做、对哪个对象"的表、诊断的阶段编号；新加的 eval: 命令；
• WORK_LOG.md："已完成"补一条。"关键决定"不用你写，监督者核对时补。

不新建 md 文件。方法.md 不用改，有和它对不上的地方，写进报告。

七、验收与报告

做完后本地提交，然后在回复里交一份报告。报告写正文，不把日志全文附进去，日志放在证据目录，报告里给路径。

1. 提交号：提示词那次单独列；新增和修改的文件，分 prompts/、src/、tests/、eval/ 列；各模块行数。
2. 提示词：每份写了或改了什么、依据哪条原则或调研结论；泄露自查的关键词和结果；再调研派了哪些子 Agent、查到了什么。
3. npm run check、npm test 的结果，完整输出放证据目录。消融逐位不变、运行定义不变的对照结果。
4. 程序部分：3 份研究的研究目录、轮数、停下原因；杀进程那一次的三条检查。
5. 研究质量：第 3.2 节七样的表和结论。第 4 样单独写一段结论：诊断有没有改变走向。
6. 你和这份任务书、结构.md、方法.md 不一致的地方，以及为什么。
7. 规则不清楚的地方：哪里让你犹豫、哪里你是靠猜的。没有就写"没有"。没有真实证据的可能情况，在这里提一句就够，不写进 WORK_LOG。
8. 正式代码和检验代码分开的自查，逐条写"做到了"或"没做到、为什么"。