prompts: 改解释/收尾/消融实现/消融核验四份任务提示词（任务书 17 第一块）

依据 /home/iomgaa/inforsi-eval/2026-10-04-task17/ 下的三份调研与两份真实记录诊断：

- explanation：给数前先回答"关掉后答案改从哪条路径出、那条路径值多少分"
  （诊断 P1：15-tight-2 r1、15-real-1 r2 范围被分支行为同向打穿）；
  主判断的错法答得出来就写成第二条对冲（P2：同模型同材料的相关错误）；
  "部分分得开"形态照实分开写（M6）；下一轮该做什么留给收尾（P3）。
- wrapUp：下一步改为"沿某个因子继续，或换一条更可能拿最高分的路线"
  （监督者 2026-10-04 定，方法.md 4.3 ⑱；诊断核实：收尾照着提率约 95%，
  旧方法非因子框定的收尾在饱和时自然产生换路线并被兑现）；
  新增贴近已知最好处境段（监督者 ② 核实成立：缺口量级、没出力的因子、
  "已知最好是参照不是上限"）；防撞车提醒（P5：15-real-1 r3 三条提案撞车）；
  先重读自己冻结的解释和范围再看实测（Curie 的对号顺序）。
- ablationImplementation：删掉与实验员角色提示词重复的三段（不跑正式实验、
  两个保留键写法、保障每格都带；监督者 ③ 核实属实，同一事三版措辞已漂移）；
  concerns 的具体例子换成抽象形状（诊断毛病 1：例子成了每份必答的锚）；
  补"关法走已有定义的做法，不新造"、共用代码段的行为归属判断法、
  连带关收窄为绕开跑不起来的最小集合（LLVM/git bisect/ParameterImportance
  的原则映射）；diff 参照物写明是完整代码冻结目录（与角色的"本次起点"
  口径冲突，角色那句随之限定）。
- ablationVerification：保障句删掉与角色重复的前提；补核验范围的另一侧
  （改动之外不归这一格核、不该关/连带没必要不是退回理由）；"看不清"
  改为先查完材料、仍核不了就如实填代码现状（诊断毛病 3：off 是布尔，
  没有"核不了"出口，不为它加字段）。
- vocab 字段说明同步：收尾的下一步口径、解释第二条的对冲情形、
  消融核验 where 里放总体核对说明（字段结构、类型、必填未动）。

泄露自查：填圆关键词（半径、圆心、线性规划、SLSQP、扰动、六角、布局、
摆法、结构起点、compute_max_radii、填圆、packing、circle、多起点、精修、
爬山、重启、圆、LP、2.6、26）搜改过的六份文件，零命中。
npm run check 通过，npm test 458 条通过。看到运行结果后不再改提示词。

prompts/tasks/wrapUp.md

@@ -1,9 +1,11 @@
 # 本轮收尾
 
-这一轮走完了：正向实验、采纳决定、消融（如果做了）都已公开。请写一段收尾：这一轮什么被支持、什么被挑战、下一步你想在哪个因子上继续。下一轮提案时，每位研究者都会在材料里读到全部人的收尾原文——你写的就是交给他们的接力棒，所以写给一个没参加这一轮、但要接着往下做的同事看。
+这一轮走完了：正向实验、采纳决定、消融（如果做了）都已公开。请写一段收尾：这一轮什么被支持、什么被挑战、下一步想往哪走——沿某个因子继续，或换一条更可能拿最高分的路线。下一轮提案时，每位研究者都会在材料里读到全部人的收尾原文——你写的就是交给他们的接力棒，所以写给一个没参加这一轮、但要接着往下做的同事看。
 
 ### 先读什么
 
+动笔之前，先重读你自己这一轮冻结时写的解释和范围，再看实测——先想起自己当时是怎么判的，再对号，才看得出偏差出在哪。
+
 材料"信念本"里，"按因子"一栏是程序从记录现算的：被采纳的改法每个因子关掉后分数变差多少、撑几成、测前大家的范围、实测落在哪、哪些解释被确认或否定，每次消融还有一句程序读出的结论（例如"p2 撑 70%，p1 只撑 5%，各管各"）。这些直接引用，不重算。"战绩"一栏写着各人的范围包没包住实测、偏高还是偏低，以及作者自评和大家合并的对照。
 
 几种状态要照它的意思读：
@@ -23,7 +25,9 @@
 
 把"改法有效"和"机制解释正确"当成两件事分开想：分数变好了只说明改法有效，不说明提案人给的原因是对的；原因被确认，要靠消融那一格的实测落在解释的范围里。不拿生成某个解释的那次运行，当作这个解释被支持的证据。提到结论时带上依据的运行编号或记录编号，别人才能核对。
 
-下一步写具体：在哪个因子上继续、为什么是它、大概想怎么改。好——"预热只撑了不到一成，换优化器撑了七成，而且离已知最好还差一截；下一轮在新基线上沿优化器这个因子继续，试它的学习率怎么随步数变"；坏——"继续优化"。这不是提案：下一轮要正式提才算。下一轮程序还会自己记下"按现有看法最该继续的因子"和下一轮实际变好了多少，用来事后核对，你不用替它算。
+如果现在的最好分数已经贴近任务给出的已知最好，把这一处境写出来，它会改变下一轮的判断：剩余的缺口有多大、采纳线随之降到了什么量级、还剩几次运行。缺口在哪一层，给出你的判断：是哪个因子其实没出力（预算或代码花在了撑不起分数的部分上），还是这条路线的空间本身用完了。另外记住：已知最好是别的人在别的条件下跑出来的参照，不是天花板——不要默认它就是上限。
+
+下一步写具体：沿哪个因子继续、为什么是它、大概想怎么改；或者换哪条路线、为什么它更可能拿高分。好——"预热只撑了不到一成，换优化器撑了七成，而且离已知最好还差一截；下一轮在新基线上沿优化器这个因子继续，试它的学习率怎么随步数变"；也好——"沿缓存预取的两轮都只挣到噪声带内的提升，这条路线的空间看起来用完了；下一轮换一条更可能拿高分的路线：把请求按大小分两类各走各的队列，而不是继续在预取参数上调"；坏——"继续优化"。你写的下一步，下一轮每位研究者都会原样读到，也可能照着提——几个人读同一份收尾，容易撞在同一个方向上。所以把只有你注意到的依据写具体（哪次运行的哪个读数）；值得走的方向不止一条时，都写出来，不指定哪条最好，方向由下一轮的人各自判断。这不是提案：下一轮要正式提才算。下一轮程序还会自己记下"按现有看法最该继续的因子"和下一轮实际变好了多少，用来事后核对，你不用替它算。
 
 如果你有第零轮认领的入口，顺带写一句你下一轮还走不走这条路、为什么（也可以写进你的私人笔记）。走不走都可以，入口只管起点。