prompt: 按真实诊断收紧实现职责并保留实质核验

任务书16第一块：参考实现、审查及最小修复提示词源码，核对五份真实账本；明确忠实协议、辅助检查边界、局部语义核对，字段说明归于vocab。用户2026-10-04确认：核验代码每个可能交出最终答案的分支标签是否对应，不预测实际路径；修复沿用基线到上次提交材料，核验看基线到修复结果。独立审阅后清除任务与角色重复指令。提示词先冻结，真实结果出来后不再调整。

prompts/tasks/implementation.md

@@ -1,23 +1,5 @@
 # 实现冻结协议
 
-分派给你的是一个候选的冻结协议（全文在材料"本任务要处理的东西"里）。你的工作目录是本批基线代码的副本，基线就是这次的起点代码，它的冻结目录写在材料"基线代码"一节。把协议照原样写进工作目录：每个因子照它的做法实现，每条保障照写，协议正文里写的随机性和停止条件照做，每条实现条款都落实，材料"要实现的指标定义"里的每个指标都写好采集代码，`metrics.json` 里另写 `answer-path`、`safeguard-triggers` 两个保留键（写法见系统提示词"两个保留键"）。
+从本批基线实现这一个候选。工作目录是基线代码的副本，冻结目录见材料"基线代码"。
 
-协议说改什么你就改什么，说不许改什么你就不碰什么；协议没说的，保持基线原样。为什么只做协议要的改动、为什么不自己跑正式实验，见系统提示词"两条纪律"——这一步最容易在这两处出岔子。
-
-### 因子位置表
-
-写完以后，对着材料"要交的因子位置表"一节列出的因子和保障，写下每个因子、每条保障各在你代码的哪几行（行号是你交的代码里的行号）。这张表有两个读者：核验员拿它逐项对照，没落进任何因子或保障的改动会被单独列给他判是否越界；被采纳以后做消融的实验员拿它找"关掉这个因子要动哪几行"。所以宁可写准，不要写满：一处代码同时服务两个因子，两个因子都写上；同一行既属于某个因子、又属于某条保障，两边都照实写，不用二选一；为了接上某个因子而不得不改的辅助代码、写两个保留键的代码、既不是因子也不是保障的改动，写进 `unassigned`（不属于任何因子或保障的改动），附一句为什么。保障位置表里每条保障的短名照冻结协议保障清单里的写；冻结协议没有保障，保障位置表就交空数组。
-
-### 实现时发现的问题
-
-写的过程中你看出来某处会出问题——某条保障会挡掉评测本来会收的东西、某个兜底在常见情形下就会被用上、协议要求某个指标写 null 可它的档位是"缺了整次作废"——写进 `concerns`，说清是哪条、为什么。它会原样送到同一轮写解释的研究者和下一轮提案的研究者手上。照冻结原文实现照常做，不因为担心就改写法（系统提示词"实现时发现的问题"）。没有就写"无"。
-
-### 交之前
-
-用 `diff -ru <基线冻结目录> .` 看一遍全部改动，对着协议过一遍：每一段对得上哪个因子、哪条保障、哪条条款、哪个指标？对不上的删掉，临时脚本和输出文件也删掉。这一步是你自己核对，对应关系写进位置表就够了。
-
-照协议做不下去时，不要交一份自己改过的版本：不提交，在回复里写清卡在哪一句（见系统提示词"照做不了的时候"）。
-
-## 交什么
-
-因子位置表（`factorLocations`）、保障位置表（`safeguardLocations`）、不属于任何因子或保障的改动（`unassigned`）；实现时发现的问题（`concerns`，没有写"无"）；实现说明（`body`：位置表之外需要说明的事，没有写"无"）。核验员会拿这几张表对着你的代码逐项核。
+冻结协议全文在材料“本任务要处理的东西”里，引用指标的原登记定义在“要实现的指标定义”里。这次尤其注意因子、保障和条款之间的接入关系。

prompts/tasks/repair.md

@@ -1,20 +1,9 @@
 # 按退回意见修改实现
 
-你上一次交的实现被核验员退了回来。你的工作目录是上一次提交时冻结的那份代码的副本；起点代码没有变，正向候选的起点代码就是本批基线。材料给了三样东西：退回意见、核验员的逐项结果（记"没落实"、判"越界"的各项，带位置和依据）、你上一次提交相对起点代码的改动全文。核验员看的就是这份改动全文，你对照的也是它。
+从上一次提交继续修复这一个候选，不重做方案。工作目录是上次提交的副本；材料给出冻结协议、退回意见、上次位置表，以及上次提交相对本批基线的改动全文。
 
-冻结协议没有变，要改的是实现跟协议对不上的地方。先对照协议原文和改动全文，想清楚每条意见说得对不对——核验员也会看错：
+先对照协议原文和实际代码核实意见。问题属实，就修到造成偏差的根因及其必要关联处，其他行为保持不变；几条意见来自同一根因时，不必各加一个补丁。消除被指出的行为，而不是换种写法保留它。
 
-- 说得对：只改意见点名的地方。没被点名的部分核验员已经认过，原样保留。
-- 看错了代码（例如说某行被改了，改动全文里其实没改；或者说找不到某个因子，其实在别处）：不照改，在实现说明（`body`）里指出实际在哪几行。核验员写了"核不了：需要看什么"的，就把那几行指给他。
-- 跟协议原文冲突：以协议为准，不照意见改，在实现说明里引用协议原文说明为什么。
-- 意见指出的问题属实，可照改就会违反协议的另一条（例如指标要加采集代码，协议却不许在那里加）：不照意见改，也不保持原样交一份注定测不到的实现：不提交，在回复里写清是哪两句对不上。
+核验员也可能看错：意见与代码或冻结原文不符时，用原文和代码位置回应，不为迎合意见把实现改成另一套做法。对"核不了"的意见，找出能核清的依据。无法同时满足冻结要求时，按角色说明停止，不自行选边。
 
-退回意见说"加了协议外的提前退出"，就把它删掉，不要换一种写法保留同样的效果。也不借机改意见没提到、协议也没要求的地方（系统提示词"两条纪律"第二条）。
-
-两个保留键（`answer-path`、`safeguard-triggers`）照旧要写；核验员指出没写或取值不在因子编号、保障短名里的，照意见补。
-
-改完以后，因子位置表要跟着更新：行号变了的照新代码写，删掉的改动从表里拿掉。下一次核验看的仍是相对起点代码的全部改动，所以用 `diff -ru <起点代码冻结目录> .` 对着协议再过一遍，不只看这一次改的几行。
-
-## 交什么
-
-跟第一次实现一样的几项（因子位置表、保障位置表、不属于任何因子或保障的改动、实现时发现的问题、实现说明），在实现说明（`body`）里对每一条退回意见写回应：改在了哪，或者为什么不改。实现时发现的问题照这一次的实际写：上一次写过、现在仍然成立的照写，没有就写"无"。
+修复后的核验仍看本批基线到修复结果的全部改动。检查修复有没有引入新的偏差，不只看退回意见点名的几行。

prompts/tasks/verification.md

@@ -1,35 +1,17 @@
 # 核验实现
 
-分派给你的是一次还没跑的运行：一个候选的冻结协议，和实验员照它写出的代码。你核过以后，程序从你的逐项结果推出通过与否：通过，这次运行才会被放去跑正式实验；不通过，你写的位置和依据原样交给实验员修改。
+核对这一个候选当前版本是否落实冻结协议。材料给出协议全文、指标定义、实验员的位置表与说明、候选相对本批基线的改动全文，以及两份代码的冻结目录。修复后的再次核验也看这份完整的基线差异。只归责候选新引入的改动，不把基线原有写法算成它的问题。
 
-材料给了你：冻结协议全文；实验员交的因子位置表和保障位置表；这份代码相对起点代码（本批基线）的改动全文；两份代码的冻结目录（可以用 `read_source` 读）。只看这份实现新引入的改动，起点代码里原有的写法不算它的问题。
+本次对照条款、因子做法及设定、保障做法；随机性和停止条件以协议正文为准，可用的库以任务要点为准。
 
-### 逐项核
+## 辅助记录
 
-冻结协议里每条条款、每个因子、保障清单里的每条保障，各写一项：找没找到对应的实现、在哪几行、依据是什么。
+检查 `metrics.json` 的两个保留键：每条保障在 `safeguard-triggers` 中有计数，没动手记 0；`answer-path` 在每个可能交出最终答案的分支写对应标签，正常主流程为 `main`，因子分支为其编号，保障分支为其短名。只核代码中分支与标签是否对应，不预测正式运行实际会走哪个分支。
 
-- **条款**：协议要求的那件事，代码里做了没有，做得跟条款说的是不是一样。
-- **因子**：对着因子位置表，看那几行是不是照这个因子的做法写的；因子的设定值是不是协议写的那个。位置表只是线索，因子的代码不在表上写的地方而在别处，照实写在哪。
-- **保障**：照协议保障清单里的那一条写了没有；再看它在 `safeguard-triggers` 里有没有计数（每条保障短名都要有一个键，没动手写 0）。没有计数也记没落实，依据里写清缺的是计数。
+计数缺失记在对应保障上。答案路径没写、取值不合法或与该分支不对应，记在对应保障上；没有保障时，记在最相关的因子上。
 
-随机性和停止条件按协议正文核：代码里有没有协议没登记的随机数、读时钟、按时间或成绩提前退出。查跨文件的随机性和时间依赖要顺着调用读——程序收件时的检查是逐段单独判的，看不到跨文件的关系，这部分要你来看。这类问题出在某个因子的代码里，那个因子就记没落实，依据里写清是哪一句协议没登记它；出在没归属的改动里，就在那一处判越界。
+## 没有归属的改动
 
-代码导入的库要在材料"任务与本轮"一节里的"任务要点"列出的库里；不在的，正式实验会直接报错，记在用到它的那一项上。
+材料列出的每个未归属改动块都要核对。为落实条款或因子所需的接入代码、照登记定义采集指标或写辅助记录，本身不越界；没有归属不等于没有依据。读实验员的解释，但以代码为准。
 
-### 两个保留键
-
-`metrics.json` 里的 `answer-path` 要写，取值只能是 `main`、冻结协议里的因子编号（`p1`……）或保障短名。看写它的那段代码：每个可能交出答案的分支，写进去的是不是对应的那个取值（主流程写 `main`、兜底分支写那条保障的短名）。没写，或者某个分支写了一个不在这几样里的取值，记在对应那条保障一项上（没有保障时记在你判断最相关的那个因子一项上），依据里写清是哪个分支、写了什么。你核的是"代码有没有写、取值在不在范围里"，不核这次运行实际会走哪条路径——那要等正式实验。
-
-### 没归到任何因子或保障的改动
-
-材料最前面一节列出了改动全文里一行都没落进任何因子或保障的改动块。逐条判它是否越界：为了落实某条条款、某个因子而改的辅助代码，按协议采集要实现的指标的代码，都不越界，写一句理由（它服务哪个因子、哪条条款、哪个指标）；超出协议、碰了最终指标的测量或校验、或者做了协议没写的事（加提前退出、加缓存、换算法、调参数），判越界。实验员在 `unassigned`（不属于任何因子或保障的改动）里写过说明的，读他的说明，但以代码为准。
-
-指标的采集代码、写两个保留键的代码多半会出现在这一节。对着材料"要实现的指标定义"里的定义看：照定义算、写进结果文件的，不越界；算法跟定义不一样，或者测不到时写 0 或别的占位数，判越界并写清——测不到写 0，会让一次失败看起来像测到了。
-
-### 写给实验员
-
-不通过时，实验员只按你写的改，所以每一项的依据要让他能照着改：好——"`solver.py:88-95` 加了 `if best > target: break`，协议的停止条件只有迭代 500 次，这段要删"；坏——"实现不够忠实"。找到一处问题后继续核完，一次说全。
-
-## 交什么
-
-逐项结果（每条条款、每个因子、每条保障各一项；保障的短名照冻结协议的保障清单写）和对每一处没归属改动的判断（`unassigned`，材料说没有就交空数组）；说明（`body`）写逐项结果之外需要说明的事，同一行同时属于因子和保障时在这里写一句提醒，没有要补充的就写"无"。
+超出冻结协议的行为、改动最终指标的测量或校验、采集算法与登记定义不符、测不到却写 0 或其他占位数，都是偏差。问题位于因子或保障内时归到对应项；位于未归属改动内时判断该块是否越界。