655f5bb829
结构.md:私人笔记不属于阶段、以最后一条为准;消融结算按轮次唯一。WORK_LOG:更正一处把监督者措辞当成用户原话的记录;执行者列的待定项分派给 ledger 顺手改、materials、agents/runner。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
79 lines
9.1 KiB
Markdown
79 lines
9.1 KiB
Markdown
# 工作记录
|
||
|
||
只记当前状态。一个阶段完成后压缩成几行,细节看提交说明。
|
||
|
||
## 当前目标
|
||
|
||
搭好项目框架:CLAUDE.md、方法、结构都定下来以后,按模块从参考项目搬代码。
|
||
|
||
## 已完成
|
||
|
||
- CLAUDE.md:按官方写法写成(提交 3861fd8 及之后)。
|
||
- `docs/方法.md`:由参考项目的研究方案 v3、设计-15、设计-16 合成(f32c0bd)。之后按用户决定改过:消融只测信息价值选中的格(5e4f8c2);保障的定义借用"控制变量"和"重构"来说明(141494f)。
|
||
- `docs/结构.md`:13 个模块加 vocab、步骤清单、账本记录种类、可替换点、检查规则、粗估规模(6cf9f0c)。
|
||
- 任务书 01(工具链 + vocab):npm 包、TypeScript、`node --test`、dependency-cruiser 规则全写,临时违规实测 14 条都报错;vocab 1030 行,`npm run check` 通过,`npm test` 24 条通过。结构.md 第八部分补了 vocab 对外内容。
|
||
- 任务书 02(rules):src/rules 13 个文件、1761 行,`npm test` 192 条通过。预期值来源有三个:方法.md 的手算例;`tests/fixtures/rules/` 下不看实现写的 Python 脚本(重跑后 JSON 逐字节相同);参考项目 calc15、calc14b 里与现行方法一致的部分。审阅做了两轮,每轮都换一个全新上下文的子 Agent。结构.md 第八部分补了 rules 对外内容。
|
||
- 任务书 03(ledger):src/ledger 5 个文件、584 行,`npm test` 226 条通过(ledger 34 条)。一张只追加的表,两条禁改禁删触发器,8 处唯一约束(阶段开、阶段关、运行登记、确认启动或确认没启动、运行结果、模型调用开始、结束、消融结算),写入时只查四种拒收,提案的作者自评拆成封存另存。按第一版写过可见性和通用唯一键,按新版全部清掉了。全新上下文的审阅做了三轮。结构.md 第八部分补了 ledger 对外内容。
|
||
|
||
## 关键决定(用户原话见各提交说明)
|
||
|
||
- 项目改名 InfoRSI。参考项目 RivalBits 只读。
|
||
- "点"改称"因子","保障"保留。
|
||
- 不设轮数上限,只限运行次数。
|
||
- 第一次预测放在挑刺之前、看原始提案;第二次预测在冻结之后、看冻结协议。
|
||
- 子 Agent 调研时不写 md 文件,结论直接回报。
|
||
- 提交的字段定义放 vocab,submissions 只判收不收;vocab 只放两个函数(规范序列化、哈希)。用户原话:"我都同意"。
|
||
- vocab 上限改为 1100 行(多出来的主要是发给模型的字段说明)。用户原话:"同意 A,vocab 上限改为 1100 行。结构.md 由监督者改,你不用动。"
|
||
- 每份预测只对一个候选、每份挑刺只针对一个目标;入口、因子、实现条款的编号由程序按位置分配;实现提交不设代码字段(程序从工作目录冻结);运行结果用"没启动 / 正常退出 / 超时 / 被取消"一个字段表示启动与结束;四种 token 数都可记测不到。用户原话:"3、4、5、6:同意保留你的写法。方法.md 第五部分的表(入口编号、实现的代码字段)由监督者改。"
|
||
- 账本改为一张只追加的表,全部记录都不能改(ca2cd52)。用户原话:"同意全部只追加"。
|
||
- 谁能看什么归 materials(按任务定材料,第一条消息和查询工具是同一份材料的两种给法),ledger 只存;只在"只能一次"处加唯一约束;Jev 不单独成记录,记在它判断的那件事里(0b0cbb0)。用户原话:"给到派的材料有哪些"和"一开始灌进去还是主动等派去查"是分开的事情;Jev"本质只是一种可以代替程序的判别器"。
|
||
- 有自己编号、按定义只发生一次的记录加唯一约束,重复就报错;记录之间的前后顺序检查一律不加,flow 调 ledger 是模块之间的调用,不算边界(493ea6d)。这是监督者提的处理,用户回复"同意";CLAUDE.md"罕见情况怎么办"第 2 条随之写明边界。
|
||
- 计算时间不再是预算,只记录;预算只有运行次数(42347e4)。用户原话:"CPU 秒不当预算但是要记录"。
|
||
- 解释的每格三个数改为可选,关掉消融时不交。用户原话:"同意 A:解释的 cells 去掉 minItems,改为可选"。
|
||
- rules 的约定(方法.md 没写死的地方):入池 P < 0.5 严格;采纳和消融中发现都要严格大于采纳线;成本用 max(0, ĝ₀);没测的格附"含它的最好组合"的净值;战绩在分数原值上判;编号一律按自然序比较。用户原话:"1–8 都同意"。消融成分权重跟随 λ、分歧量不掺开放预留,由用户改进方法.md(a050771)。
|
||
- 三个数改为严格递增,去掉尖峰(bfb96ba)。用户原话:"凡是为'三个数相等''宽度为 0''开放预留缩成一个点'写的专门处理,全部删掉"。
|
||
- 答案路径、保障动手次数只记读到的原始内容或读不到的原因;在不在位置表里,由以后拿得到位置表的模块现算,不存。用户原话:"按'能现算的不存',tasks 只记读到的原始内容……对表由以后有位置表的模块现算,把这条记进 WORK_LOG。"
|
||
|
||
## 未完成
|
||
|
||
- `inbox/调研.md`:要迁进 `docs/调研/` 的调研结论。
|
||
- `docs/方法.md` 里还有 7 条标〔自定〕的规则,待用户过目。
|
||
- 留给 submissions 的跨字段规则(vocab 字段定义不管):
|
||
1. q1 < q5 < q9(严格递增,方法.md 第五部分,提交 bfb96ba):作者自评、两次预测、解释的每一格。
|
||
2. 因子数不超过上限,回应改过的因子清单同样适用。
|
||
3. 同一提案里两个因子不能延续同一个因子;延续的编号要在信念本里看得到。
|
||
4. 保障短名不能是 `main`,不能写成 `p<数字>`,同一清单里不重复。
|
||
5. 开着消融时每条解释必须交 `cells`,并恰好覆盖材料列出的格;关掉消融时不交。
|
||
6. 解释最多 M 条。
|
||
7. 志愿至少 min(N, 入口总数) 个、不重复、编号都在入口清单里。
|
||
8. 挑刺针对的因子编号在被挑提案的因子范围内。
|
||
9. 回应的逐条答复恰好覆盖针对本候选的全部挑刺;统一的 `sources` 恰好覆盖被合并的原提案。
|
||
10. `reused` 引用的指标存在且是假设专用指标;新登记的指标短名不重复。
|
||
11. 实现和修复:位置表覆盖每个因子和每条保障;代码位置起始行不大于结束行。
|
||
12. 核验:条款、因子、保障逐项全覆盖;没有归属的改动与材料列出的逐条对应。
|
||
13. 消融实现:写了 `cannotRun` 时 `alsoOff` 为空;`alsoOff` 不含本格要关的因子,且都在因子清单里。
|
||
14. 消融核验覆盖每个因子。
|
||
- 答案路径、保障名字"在不在位置表里"的对表,由以后拿得到位置表的模块现算(多半是 materials 或 flow)。
|
||
- 核验提交 `body` 的字段说明要补一句:同一行同时出现在因子和保障里时,在说明里写一句提醒(方法.md 4.3 ⑨)。写 submissions 时一并改。
|
||
- 给 config:每批上限必须 ≥ 1(为 0 时 R̂ 是无穷大,选格会卡住)。
|
||
- 给 flow:同一轮里选批和选格都用随机规则时,传不同的"版本"算种子,否则两次抽取用同一串随机数。
|
||
- 给 materials:被退回的提案原样存在退回记录里,作者自评没有拆成封存,所以不能把别人的退回记录给研究者看。方法.md 第三部分"作者自评从交上来那一刻起就封存"和"被退回的提交原样记"之间怎么处理,待用户定。
|
||
- 给 flow:确认启动前要先登记运行;模型调用要先开始再结束;阶段要先开再关;ledger 都不查。
|
||
- ledger 待顺手改(下一份涉及 ledger 的任务书带上):结算的唯一约束改按轮次(每轮最多一次消融,结构.md 第四部分已改),去掉 `ablation` 编号;私人笔记去掉版本号,以最后写入的一条为准(序号就是先后,版本号是程序推得出的栏目)。
|
||
- 给 materials:别人的"退回"记录不放进任何研究者的材料(退回的提案原样带着作者自评,不另拆封存)。
|
||
- 给 agents、runner:"整个环境的用量"(实验员会话的 CPU、内存等)写这两个模块时再定记录种类。
|
||
- 写 plugin 时实测:源码导入路径带 `.ts` 扩展名,Pi 加载插件能否接受。
|
||
|
||
## 工作方式(用户 2026-10-01 定)
|
||
|
||
每个模块分三步:
|
||
1. 参考项目的会话(监督者)先把这个模块讲给用户:放哪些东西、对外提供哪些函数、预期多少行、参考项目里对应的代码哪些保留哪些删掉。用户和监督者一起确定。
|
||
2. 监督者把确定的内容写成一份任务书,放在 `任务书/` 下,一个模块一份。
|
||
3. 用户在 InfoRSI 目录里另开一个新的 Agent 执行任务书;监督者只监督、核对,不直接写代码。
|
||
|
||
这样做有两个目的:一是检验 CLAUDE.md 和 docs 里的规则对一个全新的 Agent 是否真的起作用;二是让监督者和执行者的思路保持独立,方便发现跑偏。
|
||
|
||
## 下一步
|
||
|
||
任务书 03(ledger)已核对通过(716f4b8)。下一个模块待监督者与用户商定。
|