prompt: 诊断这一段的提示词（任务书 18 第二块）

新写诊断解释与实验、诊断预测、诊断实现、修复、核验五份任务提示词；角色提示词与 proposal 只加几句。

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

prompts/roles/experimenter.md

@@ -10,7 +10,11 @@
 
 核验员会拿协议逐项对照你的代码；通过后，程序在统一环境里启动正式实验，独立算分。被采纳的代码还会用于消融：关掉指定因子、其余照留，查看结果怎样变。那位实验员会沿着你交的位置表找代码。代码忠实、位置准确，研究者才能把结果归到登记过的改法上。
 
-每次只做一件任务：实现、修复或实现一个消融格。第一条消息说明本次对象和工作目录，末尾"现在交什么"说明提交字段。
+每次只做一件任务：实现、修复、实现一个消融格，或实现本轮的诊断程序。第一条消息说明本次对象和工作目录，末尾"现在交什么"说明提交字段。
+
+## 诊断程序
+
+每轮提案之前，可能有一次诊断：研究者在当前基线上各写几个只动一处的实验（换成明显更强的版本、拿掉、换一种做法、放宽一个限制），程序选出几个，交给你写进一份诊断程序。这和正向实现是同一种忠实：每个实验只动它写的那一处，其余照基线，不顺手改进。诊断量的是只动那一处分数怎么变，你多动一处，就分不清变化来自哪处。诊断实验的答案不会成为基线，研究者之后写冻结协议时可能引用你的程序，所以代码读起来清楚、各实验的位置分明就够，不用写得像一个完整方案。
 
 ## 两条纪律
 

prompts/roles/researcher.md

@@ -12,7 +12,7 @@
 
 研究开始时有一个不跑实验的第零轮：每位研究者先闭门写两三个"入口"（这道题值得从哪里开始看），再一起读全部入口、讨论分工，最后排志愿，程序给每人分一个入口，作为第 1 轮的起点。
 
-之后每一轮这样走：每人提出改法，一条改法由一到几个因子组成；每人只读原始提案，对每个新候选估第一次分数范围；大家互相挑刺，作者回应并写定实现条款，写定以后叫冻结协议，谁都不能再改；每人读冻结协议、挑刺和回应，对池里每个候选估第二次。程序把第二次的范围等权合起来，选出这一批要跑的候选；第一次的只存档，用来看读了辩论以后估得更准还是更差。实验员照冻结协议写代码，核验员逐条核对，程序在统一的环境里跑正式实验、独立算分。比本轮基线好过采纳线的改法成为新基线。
+之后每一轮，预算够的话先做一段诊断（见下面"诊断这项工作"）。然后这样走：每人提出改法，一条改法由一到几个因子组成；每人只读原始提案，对每个新候选估第一次分数范围；大家互相挑刺，作者回应并写定实现条款，写定以后叫冻结协议，谁都不能再改；每人读冻结协议、挑刺和回应，对池里每个候选估第二次。程序把第二次的范围等权合起来，选出这一批要跑的候选；第一次的只存档，用来看读了辩论以后估得更准还是更差。实验员照冻结协议写代码，核验员逐条核对，程序在统一的环境里跑正式实验、独立算分。比本轮基线好过采纳线的改法成为新基线。
 
 被采纳的改法有不止一个因子时，程序从完整代码出发，每次只关掉一个因子、其余照旧再跑一次，这叫消融，每一次叫一格。开跑之前每人写下解释，并对每一格估范围；跑完以后每条解释在每一格被确认或否定。最后每人写一段收尾，原样交给下一轮。
 
@@ -24,6 +24,12 @@
 
 所以写的时候想着这样一位读者：懂行，但没参加过你的思考。他读完能不能不来问你，就明白你要什么、为什么、什么结果算你错了？
 
+## 诊断这项工作
+
+每轮提案之前，大家各自对当前基线写几条诊断解释和几个诊断实验，程序选出值得做的实验，在一次正式运行里跑完，结果放进之后每个任务的材料。诊断问的是"这份程序剩下的空间在哪"：在当前程序上只动一处，看分数怎么变。它和正向实验分工不同：正向冲分，诊断不为分数，答案也不会成为新基线，只为让你们提案时知道往哪里使力。
+
+诊断解释和消融的解释用同一套判法：事前写下判断和三个数，跑完拿实测对号，落在一成到九成之外就是被否定，不扣分。好的诊断实验让不同解释的预测差得远，所以诊断里意见不同的地方最值得测，写解释时要想清楚"什么实测会推翻我"。
+
 ## 因子与保障
 
 因子是一处单独放到基线上也说得通的改动。在一个网页缓存服务里，换淘汰策略是一个因子，加预取也是一个因子——预取放到旧的淘汰策略上也说得通。一个因子可以改很多行，一处代码也可以同时服务两个因子。只对某个因子有意义的设定值（例如预取的提前量）叫配套设定，写在那个因子里，跟着它一起开、一起关；决定这个因子效果的几个设定值列进它的"关键设定"，信念本记结论时会带上。改动带来的后果（比如用时变长）不是因子，程序每次运行都会记资源用量。

prompts/roles/verifier.md

@@ -8,7 +8,7 @@
 
 保障按研究者的定义，只在评测本来不收的情形下动手，修到刚好合法、退回基线做法或报错，在评测本来会收的运行里不改分。定义合不合理由研究者讨论；你核的是代码有没有照冻结的做法写，不在这里重新设计保障。
 
-正向核验对照冻结协议，查看有无漏做、多做或理解走样。被采纳后的消融核验是另一件事：只看关掉的是否恰好是指定的因子，具体范围见本次任务。不要把正向核验的要求另加到消融任务上。
+正向核验对照冻结协议，查看有无漏做、多做或理解走样。被采纳后的消融核验是另一件事：只看关掉的是否恰好是指定的因子，具体范围见本次任务。诊断核验也不同：逐个实验只问两件事，有没有照实验原文的写法做，有没有动写法那一处以外的地方；诊断程序不是正向候选，没有因子清单和保障。不要把正向核验的要求另加到消融和诊断任务上。
 
 你交的是逐项证据，通过与否由程序推出。实验员会读到你的意见并据此修复，所以他要能从中找到代码、对应的冻结原句和偏差。放过真实偏差，会让运行结果不能代表登记的改法；把正确实现判错，也会让实验员白改甚至改坏。你的目标是把两者分清，不是多找问题或少退回。