docs: 新增任务书 17(flow 第 4 部分:消融到收尾,含这一段提示词);收尾的下一步可换路线;第 4 部分不回放、3 份同时跑

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
2026-10-04 12:27:05 -04:00
parent 162c14072f
commit 81212b48ad
4 changed files with 327 additions and 4 deletions
+322
View File
@@ -0,0 +1,322 @@
# 任务书 17:flow 第 4 部分(消融到收尾、一轮接一轮、研究结束)与这一段的提示词
这是 flow 四部分里的最后一部分(`docs/结构.md` 第三部分"flow 分四部分写,各自验证")。做完以后,一份研究能从采纳往下走:
1. 列消融格、研究者写解释、程序选格;
2. 实验员实现消融格、核验员核对,不通过就重做;
3. 正式运行选中的格、结算、定押的因子;
4. 研究者写收尾,轮末解封;
5. 开下一轮,一轮接一轮,直到运行次数用完。
余额用完后走到"导出"一步时停下,原因写"导出还没写"。
一份任务书里有三块,**按顺序做**:
1. **第一块:改提示词。**解释、收尾、消融实现、消融核验这一段的提示词。用户 2026-10-04 定:和任务书 16 一样,先诊断再改,改完先提交,再做后面两块。
2. **第二块:写代码。**写 `src/flow` 的 ⑬–⑱、轮末动作、下一轮和研究结束。
3. **第三块:真实运行和评估。**从头真实跑 3 份完整研究,按研究质量评估。
本任务书已由用户和监督者在 2026-10-04 一起确定。下面说的"监督者",是在参考项目目录里和用户讨论设计的另一个会话。
## 开工前先读
- `CLAUDE.md`:全部。尤其是"测试"一节:flow 的验收看研究质量;正式代码和检验代码完全分开。
- `docs/方法.md`:
- 第三部分:角色与材料;
- 4.3 ⑫–⑱、4.4;
- 第五部分:解释、收尾、消融实现、消融核验四种提交;
- 6.6 消融结算、6.7 选格、6.8 押的因子、6.9 信息账、6.10 信念本;
- 第七部分:预算、扣次、"什么时候开下一轮";
- 第九部分:中断与恢复。
- `docs/结构.md`:
- 第三部分:步骤清单,以及"flow 分四部分写,各自验证";
- 第四部分:账本记录;
- 第八部分:flow、materials、submissions、rules、workspace、runner 各节。
- `docs/调研/提示词.md`:提示词怎么写的调研结论。第一块必读。
- `任务书/16-flow-3-实现到采纳.md`:第 3 部分的写法,这次照着往下接。第一块的做法和它的第一块相同。
- 任务书 16 的产出:`/home/iomgaa/inforsi-eval/2026-10-04-task16/report.txt`(执行报告),以及同目录下的诊断、调研、审阅文件。第一块可以直接复用那次的调研结论,不必重查同一批参考实现。
- `WORK_LOG.md`:"关键决定"最后几条;"未完成"里"给 flow"的条目,第六部分列了哪几条归这次。
- 参考项目(只读,不要改):`/home/iomgaa/Projects/RivalBits/src/controller/` 下消融、解释、收尾、下一轮的部分。看它怎么做,不照搬结构。
## 一、第一块:改这一段的提示词
### 1.1 范围
可以改的:
- `prompts/tasks/explanation.md`、`wrapUp.md`、`ablationImplementation.md`、`ablationVerification.md`;
- `prompts/roles/experimenter.md`、`prompts/roles/verifier.md` 里**只讲消融的那几句**(任务书 16 刚改过,正向的部分不动);
- `src/vocab/submissions.ts` 里解释、收尾、消融实现、消融核验这四种提交的**字段说明**(`description`)。只改措辞,不改字段的结构、类型、必填与否;vocab 上限 1150 行。
不改的:
- `prompts/roles/researcher.md`:它同时管着提案,改了会影响第 2 轮的提案,而研究者那一段已经定好不再调;
- 研究者其余任务提示词(提案、预测、挑刺、回应等);
- 实验员、核验员提示词里正向的部分;
- `tasks/circle_packing/` 下的任务文件。
### 1.2 怎么做
1. **读调研结论。**`docs/调研/提示词.md` 全文,以及任务书 16 产出里的 `implementation-research.txt`、`verification-research.txt`、`historical-diagnosis.txt`。
2. **针对这一段再调研。**派子 Agent 去查。参考项目的克隆在 `/home/iomgaa/Projects/RivalBits/reference/`。子 Agent 只读、不写 md,结论直接回复。值得查的方向:
- 让模型对一组实验结果事前写出可检验的解释、事后对号:AI-Scientist 的实验分析与写作提示、co-scientist 的反思与评审步骤;
- 一轮结束后怎么把结果交给下一轮,让下一轮既用上已有发现、又不被锁在小步调参上:openevolve、aideml、ShinkaEvolve 等进化或搜索系统怎么写"上一轮的总结"和"下一步";
- 消融实现:只关一个部件、其余不动,怎么写才不多改也不漏改。任务书 16 查过的"照规格实现、不顺手改进"结论可以直接用。
3. **拿真实记录诊断。**读参考项目运行里研究者、实验员、核验员在这一段实际交了什么:
- 账本在 `/home/iomgaa/rb-acceptance/{16-real-1,15-real-1,15-tight-2,14-real-1,12-real-2}/board.sqlite`,只读,用 `sqlite3 -readonly`。任务书 16 已经复制过一份到 `/home/iomgaa/inforsi-eval/2026-10-04-task16-diagnosis/`,可以直接用那份;
- 提交在 `submissions` 表:阶段编号里带 `analysis` 的是解释,带 `update` 的是收尾,带 `ablate-implement`、`ablate-verify` 的是消融实现和消融核验(14-real-1、12-real-2 是旧方法的 `split`,可作参考);
- 参考项目每次运行当时用的提示词在 `/home/iomgaa/rb-acceptance/<运行>/prompts-used/` 下,会话原文在同一目录的 `sessions/` 下。新项目的提示词是以它为底稿改的。
- 收尾要和**下一轮的提案**对着读:收尾里写的"下一步",下一轮有没有人照着提、提成了什么样。
列出你看到的毛病,也列出做得好的地方,每条写清四样:现象、证据位置(库名、表、编号)、提示词里是哪一句引起的、怎么改。
监督者已知的三条,核实后可以直接用:
- **收尾和"冲分"冲突。**`wrapUp.md` 要每人写"下一步想在哪个因子上继续",样本也是"沿某个因子继续调"。收尾原文会整段放进下一轮的提案材料,而提案提示词现在要求"交最可能拿最高分的那条,哪怕换掉整道工序"(提交 ff5c8dd)。方法.md 4.3 ⑱ 已改为"下一步想往哪走:沿某个因子继续,或换一条更可能拿最高分的路线"(用户 2026-10-04 定)。提示词照这个改,并用参考项目的"收尾 → 下一轮提案"核实这句话实际起了什么作用。
- **第 1 轮之后已经贴近已知最好。**任务书 16 的三份第 1 轮采纳 2.6307–2.6343,已知最好是 2.635983。第 2 轮起研究者面对的是"离已知最好只差一点"。解释、收尾里现在没有一句帮他们想这种处境:还差的那一点可能在哪、哪些因子其实没出力、哪条结论只在某个设定下成立。写的时候不出现任何题目的具体数值或做法,用无关领域的例子说明这种处境。
- **消融两份任务提示词和角色提示词重复。**"不要自己跑正式实验""两个保留键怎么写""看不清照实写"等内容,任务书 16 改过的实验员、核验员角色提示词里已经有一份,措辞也变了。同一段内容只放一处:角色提示词里有的,任务提示词里删掉,只留本次任务特有的。
4. **改。**照 `docs/调研/提示词.md` 第三、四部分的原则写。任务提示词里不写字段怎么填(那是字段说明的事)。
5. **自查泄露。**照 `docs/调研/提示词.md` 第四部分最后一条:
- 改完用填圆的关键词搜一遍你改过的全部文件,搜到就改掉,搜不到才算过。关键词至少包括任务书 16 用过的 18 个,再加"消融""收尾"样本里可能出现的题目数值(例如 2.6、26);
- 例子只用和题目无关的领域,不出现任何填圆的做法、数值或参考项目跑出来的具体经历。
6. **先提交,再写代码和跑。**提示词改完单独提交一次。之后的真实运行全部用这一版,**看到运行结果以后不再改提示词**。结果不管好坏都照实收下,交给用户。
## 二、第二块:代码
### 2.1 管哪些步骤
config 的 `ROUND_STEPS` 从 `listCells` 到 `wrapUp`,加上轮末动作、开下一轮,以及 `STUDY_STEPS` 里"一轮接一轮直到余额用完"和 `export`:
- `listCells`、`explanation`、`selectCells`:列格、解释、选格;
- `ablationImplementation`、`ablationVerification`:消融实现、核验,不通过就重做;
- `ablationRun`:消融运行;
- `settle`:结算、押的因子、消融中发现;
- `wrapUp`:收尾,以及轮末解封;
- 余额用完后走到 `export`,停下,原因写"导出还没写"。
代码按"第 r 轮"写,不写死轮数。第 2 部分(开轮到选批)原来只在第 1 轮真实跑过,第 2 轮起的留池候选、信念本、"从第 2 轮起说明新观测"、判重时和留池候选比较,这次第一次真正走到。出问题按 CLAUDE.md 修。
`next-step.ts` 里 `roundsNext` 的 `step.id !== "listCells"` 是任务书 16 留下的临时写法(WORK_LOG"给 flow"),这次去掉,按步骤清单正常处理"按配置跳过"。
### 2.2 怎么走(方法.md 4.3 ⑫–⑱)
**什么时候有消融**
- 采纳了、而且被采纳的改法有 2 个以上因子,才走 ⑬–⑰。
- 没采纳,或被采纳的只有 1 个因子:⑬–⑰ 都不做,直接到收尾(方法.md 4.3 ⑫)。这几步不写记录,从采纳决定和冻结协议就算得出"这一轮没有消融"。
- 配置关掉消融时,步骤清单已经标了"按配置跳过",照现有的跳过写法记事件;解释照样写正文、不交三个数(方法.md 第十一部分)。验收用的配置开着消融,这种情况不专门造出来测。
**列格(⑬)**
- 用 rules 的 `listCells`,被采纳改法的每个因子一格。不写记录:格从冻结协议现算,格编号用 materials 的 `cellId`。
**解释(⑭)**
- 研究者阶段,每位研究者一个任务,没有对象;材料由 materials 现有的解释材料给。
- 解释阶段关闭即冻结。ledger 已经会拒绝"有格启动以后才冻结解释",flow 照顺序走就不会碰到。
**选格(⑮)**
- 输入照 rules 的 `CellRuleInput` 拼:基线、完整分数、方向、已知最好、ε、λ、因子、各条解释,加 `ComboParams`(余额、每批上限、`knowledgeUse`、`decay`)和种子。
- 种子用 `decisionSeed` 的**版本 2**(选批已用版本 1,WORK_LOG"给 flow")。
- 规则取步骤清单里 `selectCells` 那一步的,调 `runCellRule`。写一条决定,种类 `cells`。
- 没选中的格**不另写事件**:没测的原因和"含它的最好组合"都在这条决定里,materials 的信念本也是从这里读的。
**消融实现与核验(⑯)**
- 每个选中的格派一个实验员任务,对象是格;工作目录从被采纳的完整代码取出。不同格的实验员同时实现。
- 交上来后:
- 交了"这一格跑不起来"(`cannotRun`):`known.code` 传 null(WORK_LOG"给 flow"),这一格不核验、不运行、不扣次;
- 否则用 workspace 存成一个版本,用 tasks 的 `protectedChanges` 查不许改的文件,拼成 submissions 的 `AblationCode`。
- 实现阶段关闭后,每个交了代码的格派一个核验员任务。材料里的改动是"完整代码到这一格代码"。用 submissions 的 `ablationOutcome` 判通过没有。
- 不通过的格,在核验阶段关闭后退回原实验员重做,从他上一次交的这一格代码接着改(materials 的消融实现材料已经这样写)。重做完再核验,只核验重做过的格。
- 次数和正向修复用同一个上限 `config.maxRepairs`。用完仍不通过:用 materials 的 `cellNotRunEvent(格, 原因)` 写事件,不跑、不扣次,结算记"证据不足"。
- 阶段编号按"第几次"排:`r<轮>-ablationImplementation-1`、`r<轮>-ablationVerification-1`、`r<轮>-ablationImplementation-2`、`r<轮>-ablationVerification-2`……第几次从账本里数,不另存。
- 实验员报了"还要一起关的因子"(`alsoOff`)时,这一格实际关掉的是几个因子。几格实际关掉的因子完全相同时,用 rules 的 `sharedSettings` 判断沿用哪一格的结果,不重复跑(方法.md 6.6)。
- 实验员、核验员的编号:materials 现有的是按候选编号起的,消融格按格编号起,需要的话在 materials 补,和正向的写法一致。
**消融运行**
- 通过核验的格,用 flow 已有的 `formalRun` 跑,用途写 `ablation`,对象是格。
- 一份研究里的消融运行**一个接一个跑**,同正向。
- 完整代码和基线的分数直接取本批已有的运行结果,不重跑(方法.md 4.3 ⑯)。
**结算(⑰)**
- 选中的格全部有结果、"跑不起来"或"不跑"事件后结算。
- 输入照 rules 的 `SettleInput` 拼:每个因子一格,结局取"有效分数 / 证据不足 / 没测 / 跑不起来 / 一起关"之一;调 `settleAblation`,写一条结算记录。
- 押的因子用 rules 的 `chooseBet`,写一条决定,种类 `bet`。结算和押的因子在同一个事务里写。
- "消融中发现"已经在 `settleAblation` 的输出里,materials 的 `baselineOf` 会据此把那一格的代码当成下一轮的基线;flow 不另写采纳记录。确认这一点在真实运行里对得上:出现了就核对下一轮的基线;没出现就在报告里写"没出现",不专门造。
**收尾与轮末(⑱)**
- 研究者阶段,每位研究者一个任务,没有对象。
- 收尾阶段关闭**之后**,写轮末动作(WORK_LOG"给 flow"两条):
- 本轮选批选中的每个候选(跑过的、入选了却没跑成的)解封作者自评:写解封记录。解封只在收尾阶段关闭后写,提前写会泄露(materials 审阅时实测过)。
- "入选了却没跑成的候选离开候选池"不用写记录:materials 的 `Board.carried` 只留从没进过任何一批的候选,已经算对。
- 本轮全部解封写在同一个事务里。
**下一轮和研究结束**
- 收尾做完后,余额至少还有 1 次就开下一轮;余额为 0,一轮接一轮这一步做完,走到 `export`,停下,原因写"导出还没写"(方法.md 第七部分"什么时候开下一轮")。余额用 rules 的 `runBalance` 从运行记录算。
- 本轮正向批量 k = min(每批上限, 余额),选格最多"余额 − 1"格,这两条 rules 已经有,确认选批和选格用的余额是当时的余额。
- 方法.md 第七部分说的情况——最后一次正向用掉了全部余额、又采纳了多因子改法——各格记"没测:剩余次数不够"。真实运行碰到就核对;没碰到不专门造。
### 2.3 每一步以哪条记录为准算做完
接着 `docs/结构.md` 第八部分 flow 一节的那张表往下加:
| 步骤 | 看到哪条记录算做完 |
|---|---|
| `listCells` | 不写记录:从采纳决定和冻结协议现算 |
| `explanation` | 这一轮解释阶段的关闭记录;这一轮没有消融时不开这个阶段 |
| `selectCells` | 本轮的选格决定(`decision`,种类 `cells`) |
| `ablationImplementation`、`ablationVerification` | 每个选中的格都已结束这一段:交了"跑不起来",或最近一次核验通过,或重做次数用完、有"不跑"事件。中间每次实现、核验阶段各有开关记录 |
| `ablationRun` | 每个通过核验的格,最近一次消融运行有结果,而且不是"没启动" |
| `settle` | 本轮的结算记录(`settlement`),以及同一事务里的押的因子决定(`decision`,种类 `bet`) |
| `wrapUp` | 收尾阶段的关闭记录,以及本轮选中的每个候选都有解封记录 |
| 一轮接一轮 | 新一轮开始时余额为 0 |
| `export` | 现在不做:走到这里停下,原因"导出还没写" |
### 2.4 规模
flow 现在 1302 行,预计加 500–800 行,上限照结构.md 第七部分的 2000–3500。materials 只补格的角色编号(如果需要),不超过 1950 行。
## 三、第三块:真实运行和评估
### 3.1 跑什么
- 用第一块改好的提示词,配置照 `eval/round-zero/research.json`,只换研究编号。
- **从头新跑 3 份完整研究**,一直跑到余额用完、停在"导出还没写"。不接着跑任务书 16 的三份:提示词改了,恢复时提示词哈希核对会挡下。
- **3 份研究同时跑**(用户 2026-10-04 同意)。一份研究里的正式运行仍然一个接一个跑,所以同一时刻最多 3 个正式运行的容器,每个限 1 个核,机器有 16 个核。为了确认没有互相抢 CPU:
- 每次正式运行列出 CPU 时间和墙钟时间之比(运行结果里本来就记着);
- 记下运行期间机器的负载(沿用任务书 16 的 `machine.jsonl` 做法);
- 比值明显低于 1 的运行照实列出,查是否和机器负载对得上。不为此重跑。
- 任务书 16 的 `eval/forward/acceptance.ts` 要求"启动区间互不重叠",这次不适用;新的检验不加这一条。
- 估计每份 8–12 小时。监督者那边会同时离线调 Jev 做另一项检验,只调接口、不占 Docker,不影响这边。
- 3 份里挑 1 份,在**第一个消融运行确认启动以后、出结果之前**,杀一次控制进程再启动。检查:
- 恢复时按容器名找到这次运行,接着等它,没有重跑;
- 这次运行只扣了一次;
- 结果照常写进去,结算和后面的步骤照常走完。
- 中途出错先查原因:
- 是程序的毛病,按 CLAUDE.md 修了,从出错处续跑;修了什么写进报告。修了 flow 以后,已经写进账本的记录照原样用,不重算;
- 是服务一时调不通,接着跑(`node eval/lib/cli.ts --resume --dir <研究目录>`)。
### 3.2 评估:研究质量
不设硬线,结果照实交给用户。前五样看第 4 部分自己的研究质量,后两样看整份研究。
**第 1 样:解释的质量。**
- 每一条解释,派一个全新上下文的子 Agent,在**看不到消融结果**的情况下读:解释正文和三个数、被采纳改法的因子清单、本批运行结果、实验员的提醒。回答:
- 它说出了具体的机制吗?写了什么情况下不成立吗?
- 三个数和正文说的一致吗(正文说某因子撑大半,关它那一格的范围是否靠近基线)?
- 范围宽窄是否合理:宽到什么结果都包得住,还是窄到没有依据?
- 同一轮几位研究者的解释有没有真正不同?
- "我没有具体机制判断"用得是否诚实?
- 然后对上结算:每条解释在每格是确认还是否定;有没有"现有测法分不开"。
**第 2 样:选格。**
- 每次选格,列出:因子、各格事前合并范围、各组合的信息价值、成本、净值,选了哪几格、没选的原因。
- 回答:选中的格是不是大家分歧最大、或最可能改变下一步方向的格;有没有因为大家意见一致而一格都不测的情况(方法.md 第十二部分第 7 条),出现了几次。
**第 3 样:消融实现照要求没有、核验员判得对不对。**
- 每个跑过的格,派一个全新上下文的子 Agent。给它:冻结协议、完整代码、这一格的代码、位置表、`alsoOff` 和 `concerns`。回答:
- 是不是只关了指定的因子:有没有多关、少关;
- 保障是否原样保留,关掉的因子的指标是否写 null;
- 答案路径标签是否和关掉以后的分支对应。
- 同一个子 Agent 再看核验员每次的逐项结论:该判不通过却通过的、不该判不通过却判了的;有重做的,看重做是否只改了被指出的地方。
**第 4 样:消融结果说明了什么。**每格一行:
- 关掉的因子(及一起关的);
- 实测分数、撑几成;
- 这一格的答案出自 `main`、某个因子还是某条保障,保障动手了几次。答案出自保障的,这一格量到的可能是保障而不是关掉因子的效果,标出来;
- 合并范围和实测落在哪一段。
另列:配合关系标签、押的因子、有没有"关掉反而更好"或"消融中发现"。
**第 5 样:收尾和接力。**
- 每条收尾,派一个全新上下文的子 Agent 读:收尾原文、本轮的信念本和结算。回答:
- 有没有把"改法有效"说成"机制被证实";
- 有没有用生成某个解释的那次运行去支持这个解释;
- 结论有没有写清覆盖哪些设定;
- "下一步"是沿某个因子小步调整,还是换一条可能拿更高分的路线,理由是什么。
- 再对着下一轮的提案看:下一轮的提案用上了上一轮的哪些发现;是在已有因子上小步调参,还是提出了新的完整路线;离已知最好只差一点时,研究者怎么判断还能做什么。
**第 6 样:整份研究的走向。**每份研究列:
- 每一轮:正向候选、采纳了什么、采纳分数、离已知最好还差多少、有没有消融、测了几格;
- 分数随轮次的曲线,和参考项目 15-real-1、15-tight-2、16-real-1 的逐轮采纳分数并排(参考项目当时的提示词带填圆做法,这一项它们占了便宜)。
- 每个跑过的正向候选一行,接着任务书 16 第 3.2 节第 3 样的表:路线代号、合并的一成、一半、九成、作者自评(这次已解封,直接读解封记录)、实测、落点。这份数据监督者之后要用来检验 Jev。
**第 7 样:程序账目。**每份研究列:
- 确认启动的正式运行数(基线、正向、消融分开)和余额减少的次数,两者应相等;最后余额为 0;
- 每格核验了几次、重做了几次、最后跑没跑;"跑不起来"和"不跑"的格有没有扣次数、有没有写事件;
- 解释阶段关闭早于本轮任何一格的确认启动;每轮最多一条结算;
- 每轮的解封记录写在收尾阶段关闭之后,覆盖本轮选中的全部候选;
- 第 2 轮起的基线等于上一轮采纳的(或消融中发现的)代码;
- 轻量检查每次调用用了几次、有没有超过上限;
- CPU 时间与墙钟时间之比(3.1);
- 杀进程那一次的三条检查。
### 3.3 怎么算通过
**程序部分必须过**:
- `npm run check`、`npm test` 全过;
- 3 份研究都跑到余额为 0、停在"导出还没写",每个阶段开关成对;
- 扣掉的次数等于确认启动的运行数;
- 杀进程那一次的三条检查都成立。
**研究质量不设硬线,照实交给用户。**
质量不好时,先查是不是 flow 或 materials 写错了:抽一次运行,看研究者、实验员、核验员"模型调用开始"里存的材料,是否符合方法.md 第三部分和 4.3 ⑭–⑱。材料错了就修,修完重跑。材料对,就照实报告,**不再改提示词**(第一块第 6 条)。
## 四、正式代码和检验代码分开
照任务书 12 第四部分的 7 条。这次新加的检验代码放新目录 `eval/full/`,共用的工具放 `eval/lib/`,能复用 `eval/forward/` 的就复用。运行目录、审阅结果都放 `/home/iomgaa/inforsi-eval/<日期-名字>/`,不提交。
## 五、文档
完成后更新:
- `docs/结构.md` 第八部分 flow 一节:
- "做完以哪条记录为准"的表,加上第 2.3 节的几行;
- "谁做、对哪个对象"的表,加上解释、消融实现、消融核验、收尾;
- 消融阶段编号怎么排;轮末解封;研究结束;
- 三份研究同时跑、一份研究内一个接一个跑;
- 新加的 `eval:` 命令;
- 本节开头"现在走得到的只有第 1 轮"等过时的话改掉。
- `docs/结构.md` 第八部分 materials 一节:补上新导出的东西(如有)。
- `WORK_LOG.md`:
- "已完成"补一条;
- 删掉这次做到的"给 flow"条目;
- "关键决定"不用你写,监督者核对时补。
不新建 md 文件。
## 六、"给 flow"的条目里归这次的
`WORK_LOG.md`"未完成"里的:
- 选格用随机规则时,种子用版本 2。
- 步骤清单没有单列"轮末动作"(解封作者自评、入选未跑的候选出池),flow 要做这些。
- 解封只在本轮收尾阶段关闭后写。
- 消融格核验不通过、修复次数用完时写 `cellNotRunEvent(格, 原因)` 事件,结算记 insufficient;重做时把上一次这一格的提交取出来当工作目录。
- 消融实现交了 `cannotRun` 时 `known.code` 传 null,否则传存版本的结果。
- `next-step.ts` 里 `roundsNext` 的 `step.id !== "listCells"` 临时写法去掉。
## 七、审阅
这次写到了消融的扣次、选格和结算、轮末解封、研究结束,都是账本里"驱动实际动作的决定"(方法.md 第九部分)。写完后另派一个全新上下文的子 Agent 审阅一轮,只看:
- 消融的实现、核验、重做循环,"跑不起来"和"不跑";
- 消融运行的登记、扣次和恢复;
- 选格、结算、押的因子的输入是不是照 rules 的类型拼对了;
- 解封的时机;
- 开下一轮和研究结束的条件。
审阅只防 CLAUDE.md"罕见情况怎么办"里的三类情况,提了别的照列不改。
## 八、验收与报告
做完后本地提交,然后在回复里交一份报告。报告写正文,不把日志全文附进去,日志放在证据目录、报告里给路径。监督者会对着实际文件、账本和评估输出逐项核对:
1. 提交号:提示词那次单独列;新增和修改的文件,分 `prompts/`、`src/`、`tests/`、`eval/` 列;`src/flow` 和 materials 的总行数。
2. **提示词**:
- 诊断出的毛病和做得好的地方,按第 1.2 节第 3 条的四样写;监督者已知的三条,核实结果分别写;
- 每份提示词改了什么、依据哪条毛病或哪条原则;
- 泄露自查用的关键词和搜索结果;
- 再调研派了哪些子 Agent、查到了什么。
3. `npm run check`、`npm test` 的结果,完整输出放证据目录。
4. 程序部分:3 份研究的研究目录、轮数、停下原因;杀进程那一次的三条检查。
5. 研究质量:第 3.2 节七样的表和结论。
6. 每份研究每一轮一行:正向候选、采纳与分数、消融测了哪几格、每格撑几成、押的因子。
7. 你和这份任务书、结构.md、方法.md 不一致的地方,以及为什么。
8. **规则不清楚的地方**:哪里让你犹豫、哪里你是靠猜的。没有就写"没有"。没有真实证据的可能情况,在这里提一句就够,不写进 WORK_LOG。
9. 正式代码和检验代码分开的自查,逐条写"做到了"或"没做到、为什么"。