348 lines
22 KiB
Markdown
348 lines
22 KiB
Markdown
# 任务书 18：诊断（每轮提案之前，在当前基线上做诊断实验）
|
||
|
||
做完以后，每一轮在提案之前多走一段诊断：
|
||
1. 研究者写诊断解释和诊断实验；
|
||
2. Jev 合并重复的实验，研究者对每个实验交三个数；
|
||
3. 程序用信息价值减成本，定这轮做不做、做哪几个实验；
|
||
4. 实验员把选中的实验写进一份诊断程序，核验员核对，然后跑一次正式运行；
|
||
5. 程序结算，结果放进本轮提案以及之后全部研究者任务的材料。
|
||
|
||
同时，消融改成默认关闭。
|
||
|
||
方法以 `docs/方法.md` 为准，这次改了这几处：第一部分、第二部分、4.3（开轮之后的"诊断"一段，以及 ② ⑨ ⑫）、第五部分、6.3、6.9–6.11、新增的 6.12、第七、九、十一、十二部分。`docs/结构.md` 第三部分的步骤清单、第四部分的账本表、"flow 分几部分"表的第 5 行也同步改了。
|
||
|
||
一份任务书里有三块，**按顺序做**：
|
||
|
||
1. **第一块：写代码。**
|
||
2. **第二块：写诊断这一段的提示词。**这一块单独提交，提交以后才跑第三块。
|
||
3. **第三块：真实运行和评估。**从头真实跑 3 份完整研究，按研究质量评估。
|
||
|
||
本任务书已由用户和监督者在 2026-10-05 一起确定。下面说的"监督者"，是在参考项目目录里和用户讨论设计的另一个会话。
|
||
|
||
## 开工前先读
|
||
|
||
- `CLAUDE.md`：全部。
|
||
- `docs/方法.md`：上面列的改动处全文，以及 6.7（诊断的数学规则大部分沿用它）、6.8、第三部分（材料顺序）。
|
||
- `docs/结构.md`：第二、三、四、五部分；第八部分 flow、rules、materials、submissions、tasks、runner、workspace、jev 各节。
|
||
- `docs/调研/提示词.md`：第二块必读。
|
||
- `任务书/17-flow-4-消融到收尾.md`：消融这一段的写法。诊断的实现、核验、修复、运行、结算，大体照着消融和正向的写法来。
|
||
- `WORK_LOG.md`："未完成"里的"B、D 两份完整研究的分析"和"文献精读"两条。这两条说明了为什么要加诊断。
|
||
- 论文原文在 `reference-paper/`（不进仓库）。第二块用得到的：`human-practice/mly.txt`（Ng）、`human-practice/platt1964.txt`、`ai-scientist/popper.pdf`、`ai-scientist/ai-coscientist.pdf`、`llm-search/AdaEvolve_2602.20133.txt`。
|
||
|
||
## 一、第一块：代码
|
||
|
||
### 1.1 配置与步骤清单
|
||
|
||
- `flow` 里加一个 `diagnosis`，写法同 `ablation`：
|
||
- `{ enabled: false }`；
|
||
- 或者 `{ enabled: true, perResearcher, maxExperiments }`：每人每轮诊断实验上限 A，现行值 2；一次诊断最多做几个实验 D，现行值 4（方法.md 6.11）。
|
||
- 两个都是方法参数。
|
||
- `ROUND_STEPS` 在 `carryOverPool` 和 `proposal` 之间加诊断的步骤。名字照现有的风格自己起，至少分开这几步：
|
||
1. 诊断解释与实验；
|
||
2. 判重合并；
|
||
3. 诊断预测；
|
||
4. 选诊断实验（决策点，带规则）；
|
||
5. 实现、核验、修复；
|
||
6. 诊断运行；
|
||
7. 诊断结算。
|
||
- 诊断关掉时，这几步都标"按配置跳过"。
|
||
- **消融关掉时，`explanation` 也跟着跳过**（方法.md 4.3 ⑫）。改 `steps.ts` 里那句注释，以及 schema 里 `ablation.enabled: false` 的说明。
|
||
- 选诊断实验的规则只有一条，就是"信息价值减成本"。照选格的做法登记进 rules 的登记表，步骤清单里带规则名和版本。不为它另造别的规则。
|
||
- 验收配置 `eval/round-zero/research.json` 不改。第三块用的配置放在 `eval/diagnosis/research.json`：照抄这份，改两处：诊断开（A = 2，D = 4），消融关。
|
||
|
||
### 1.2 rules：诊断的数学（方法.md 6.12）
|
||
|
||
**要算的东西**
|
||
- 成分模型；
|
||
- 方向收益 g_d(x) = x − b，外加一个收益为 0 的"都不走"；
|
||
- 信息价值；
|
||
- 价值减成本；
|
||
- 选实验，只比较装满的组合；
|
||
- 结算：每个实验的结局、确认与否定、世界比特、惊讶、诊断推出的方向。
|
||
|
||
**复用，不另抄一份公式**
|
||
- 6.7 的成分权重、权重更新、精确积分和部分格网格，现在写在 `value.ts` 里，是按"撑几成"刻度写的。把它抽成能接两种"实测 → 收益"换算的形式：
|
||
- 消融：撑几成乘 h；
|
||
- 诊断：x − b，再和 0 取大。
|
||
- 消融的数字必须**逐位不变**。拿现有的消融测试和 B、D 账本里的选格决定重算对照。
|
||
- 确认与否定、世界比特、惊讶，直接用 `ablation.ts`、`bits.ts` 现有的函数。
|
||
|
||
**和消融不同的地方**
|
||
- 有一个"都不走"的 0 选项：VOI 公式里两处都和 0 取大。
|
||
- 成本固定按 1 次运行算，ĝ₀ 取 max(0, ·)。
|
||
- R̂ = ⌈(余额 − 1) ÷ 每批上限⌉。
|
||
- 只比较装满的组合：实验数 ≤ D 时只有"全做"一个组合；超过 D 时，比较所有恰好 D 个的组合。
|
||
- 平票时按实验编号比。
|
||
|
||
**选实验的决定记录**要附上：全部组合的价值、成本、净值，选中的组合，以及每个没选中的实验的原因和净值。数字写到能离线重算的程度，同选格（方法.md 6.7、结构.md 第五部分第 2 条）。
|
||
|
||
**战绩和信息账**的 Phase 加一个 `diagnosis`，按人、按正向 / 诊断 / 消融分开报（方法.md 6.9、6.10）。
|
||
|
||
**测试**用独立算出的预期值，不复制实现的公式。至少覆盖：
|
||
- 两条解释对一个实验预测相反时信息价值为正，预测一样时信息价值为 0（只剩开放预留的部分）；
|
||
- 余额 < 2 时不诊断；
|
||
- 实验数超过 D 时只比较装满的组合；
|
||
- 证据不足的实验不判、不记账；
|
||
- 诊断推出的方向：全部实验收益不为正时，记"没有指出能涨分的方向"。
|
||
|
||
### 1.3 vocab、submissions、jev
|
||
|
||
**vocab：新加四种提交**（方法.md 第五部分表里"诊断"三行）：
|
||
- 诊断解释与实验；
|
||
- 诊断预测；
|
||
- 诊断实现（修复同一种）；
|
||
- 诊断核验。
|
||
|
||
字段说明照现有提交的写法：每样都有出口。
|
||
|
||
**submissions 收件时查：**
|
||
- 解释 1 至 M 条，实验 1 至 A 个；
|
||
- 诊断预测覆盖"自己每条解释 × 每个合并后的实验"，不多不少，三个数严格递增；
|
||
- 诊断实验登记的指标只能是"缺了只记缺失"；
|
||
- 诊断核验的逐个实验结果覆盖全部选中的实验。
|
||
|
||
**jev：**
|
||
- 诊断实验判重：新加一个问法，照 `dedup` 写，对象是"在当前基线上动一处的诊断实验"。阈值暂用 `dedup` 的 0.3，等真实数据再校准，照实写进注释。
|
||
- 诊断实验交上来时，查"改动了评测、自相矛盾、太含糊"：直接用 `freeze` 那三问。如果问法里的措辞只适合冻结协议，就照 `dedup` 的办法加一个变体，不改原问法。
|
||
- 诊断程序的代码改动：直接用 `diff` 那五问。
|
||
|
||
### 1.4 tasks、runner、workspace：一次运行跑几个实验
|
||
|
||
**运行方式**
|
||
- 一次诊断运行就是一个容器、一次登记、一次确认启动、一次扣次。runner 的现有规矩（限时、限核、断网、记资源、按容器名恢复）照旧。
|
||
- 总时限、核数照任务规定（填圆：120 秒、1 核）。容器里由任务的 harness 按顺序跑每个实验，每个实验分到"总时限 ÷ 实验数"。
|
||
- harness 记下每个实验实际用了多久、是不是超时。一个实验超时或跑崩，不影响后面的实验。
|
||
|
||
**每个实验从哪里出发**
|
||
- 从当前基线的代码，以及**产出当前基线的那次正式运行的原始产物**出发。
|
||
- 这份产物在运行目录里，用只读的方式交给每个实验。
|
||
- 怎么交（文件路径、参数还是环境变量），由 tasks 定，写进 `TASK.md` 给实验员看。
|
||
|
||
**判分**
|
||
- 每个实验交出的答案，用任务现有的校验器和合法化**单独判分**。
|
||
- 判分结果按实验分开记在这一次运行的结果里：分数、合法化、登记的指标、用时、结局。
|
||
- 资源用量记整次运行的。
|
||
|
||
**workspace**
|
||
- 诊断程序存成一个版本，记进冻结代码记录，同时附上每个实验的位置表。
|
||
- 实验员的工作目录从当前基线代码取出，再放进那份原始产物。
|
||
|
||
**改动范围**
|
||
- 改 tasks 和 runner 时，正向运行、消融运行、基线运行的行为一个字节都不能变。
|
||
- 用现有测试，加上任务书 17 的一次正向运行定义前后对照来证明。
|
||
|
||
### 1.5 ledger、materials
|
||
|
||
**ledger**
|
||
- 决定加一种：选诊断实验。
|
||
- 结算加一种：诊断结算，按轮次唯一。
|
||
- 写入时要拒绝"这次诊断运行已经确认启动，才冻结诊断预测"，照消融拒绝晚冻结解释的写法。
|
||
|
||
**materials：给谁看什么**（方法.md 第三部分、4.3 诊断一段）
|
||
|
||
- **诊 1**
|
||
- 当前基线的代码，产出它的那次运行的答案、分数、指标，信念本，上一轮收尾；
|
||
- 第 1 轮还要放第零轮的全部记录。
|
||
- **诊 2**
|
||
- 合并后的实验清单（标明作者），全部诊断解释，自己的解释；
|
||
- 看不到别人这一步交的数。
|
||
- **实现、修复**
|
||
- 选中的实验原文，当前基线代码，原始产物的路径；
|
||
- 修复时还要放核验意见。
|
||
- **核验**
|
||
- 选中的实验原文，以及"当前基线 → 诊断程序"的改动，加上位置表。
|
||
- **从 ② 提案开始，本轮之后全部研究者任务**
|
||
- 公共材料里加"本轮诊断结果"一节：每个实验做了什么、实测、用时、结局，每条解释确认或否定，诊断推出的方向；
|
||
- 本轮没诊断时，写原因。
|
||
- **实现正向候选的实验员**
|
||
- 本轮有诊断时，材料里给出诊断程序代码的位置（只读），注明"冻结协议引用诊断实验时作参考"。
|
||
- **信念本**
|
||
- 加"诊断历史"（方法.md 6.10 第 3 条）。
|
||
|
||
**规模**
|
||
- materials 现在 1930 行，上限 2250（第五部分）。
|
||
- 先把诊断材料写清楚，再看能不能和消融材料共用写法。
|
||
|
||
### 1.6 flow
|
||
|
||
**怎么走**
|
||
- 照步骤清单走。方法.md 4.3 诊断一段每一条都要落实。
|
||
- 余额 < 2 时，诊 1–诊 4 都不做：不开阶段，不写记录，从余额就能算出"本轮没有诊断"。这一点和"无采纳则没有消融"一样。
|
||
- 诊 3 定了"不诊断"时，诊 4 不做。
|
||
- 实现：一个实验员任务，对象是本轮诊断。
|
||
- 核验：一个核验员任务，交逐个实验的结果。
|
||
- 修复：只修不通过的实验，次数上限 `maxRepairs`。用完仍不通过的实验从这次诊断里拿掉，记"证据不足：核验不通过"。一个都不剩时，写事件，不跑，不扣次。
|
||
- 拿掉实验时，诊断程序里对应的代码怎么处理，你定。要求是：跑的只是剩下的实验，而且核验员核过的代码不再改动。
|
||
- 诊断运行用 `formalRun`，用途写 `diagnosis`，对象是本轮诊断。
|
||
- 结算、写信念本之后，才开 ② 提案。
|
||
|
||
**阶段编号**照消融的写法按"第几次"排。
|
||
|
||
**"做完以哪条记录为准"**补进结构.md 第八部分 flow 一节的表。
|
||
|
||
**规模**
|
||
- flow 现在 1673 行，预计加 400–700 行，上限照结构.md 第七部分（3500）。
|
||
|
||
### 1.7 审阅
|
||
|
||
写完后另派一个全新上下文的子 Agent 审阅一轮，只看这几处：
|
||
- 诊断运行的登记、扣次和恢复；
|
||
- 选诊断实验和诊断结算的输入，是不是照 rules 的类型拼对了；
|
||
- 诊断预测冻结早于运行启动；
|
||
- 拿掉实验以后跑的是不是剩下的实验；
|
||
- 消融的数字是不是逐位不变；
|
||
- 正向、消融、基线运行定义是不是没变。
|
||
|
||
审阅只防 CLAUDE.md"罕见情况怎么办"里的三类情况，提了别的照列不改。
|
||
|
||
## 二、第二块：诊断这一段的提示词
|
||
|
||
### 2.1 范围
|
||
|
||
**要写的**
|
||
- 新的任务提示词：诊断解释与实验、诊断预测、诊断实现、诊断修复（如果修复能共用实现那份，就不另写）、诊断核验；
|
||
- 四种新提交的字段说明（vocab 的 `description`）。
|
||
|
||
**要改的**
|
||
- `prompts/roles/researcher.md`：加上诊断这项工作。只加诊断需要的几句，其余不动。
|
||
- `prompts/roles/experimenter.md`、`verifier.md`：加上诊断程序怎么写、怎么核。只加几句。
|
||
- `prompts/tasks/proposal.md`：加一句，用上本轮的诊断结果。
|
||
|
||
**不改的**
|
||
- 其余提示词；
|
||
- `tasks/circle_packing/` 下除 `TASK.md` 里"诊断实验怎么拿到原始产物"那一段以外的内容。
|
||
|
||
### 2.2 诊断提示词要让模型做到的事
|
||
|
||
照 `docs/调研/提示词.md` 第三、四部分写：引导怎么想，不做必填的结构化清单。诊断这一段要讲清楚以下几点。例子只用和题目无关的领域。
|
||
|
||
1. **诊断问的是"剩下的空间在哪"，不是"上一步功劳怎么分"。**做法是在当前程序上只动一处，看分数怎么变：
|
||
- 换成明显更强、不计时间的版本，看这一步后面还藏着多少；
|
||
- 拿掉它，看它现在撑着多少；
|
||
- 换一种做法；
|
||
- 放宽一个限制。
|
||
参考 Ng《Machine Learning Yearning》第 44–45、53–57 章的"优化验证测试"和"按部件看上限"，原文是 `reference-paper/human-practice/mly.txt`。Platt 1964 的"强推断"（同一目录）讲的也是这件事：先列几种互相竞争的解释，再设计能排除其中一些的实验。
|
||
2. **好的诊断实验，不同解释对它的预测差得远。**大家都预测"涨不了多少"的实验，测了也不改变下一步。研究者之间意见不同的地方最值得测。
|
||
3. **每条诊断解释要写什么样的实测会推翻它。**写不出来，说明这条解释还不能被检验。
|
||
4. **以前否掉某条路线的理由，本身也是一条没测过的看法，**可以拿来设计诊断实验。
|
||
5. **诊断实验只动一处，**交出能判分的答案，用时要放得进分到的那份时间。
|
||
6. **实验员实现诊断实验时，照写法做，不顺手改进。**任务书 16 查过的"照规格实现"结论可以直接用。
|
||
|
||
### 2.3 怎么做
|
||
|
||
1. 读 `docs/调研/提示词.md`，以及上面提到的论文原文。
|
||
2. 派子 Agent 再查两样。子 Agent 只读、不写 md，结论直接回复。
|
||
- 让模型提出互相竞争的解释，并设计能把它们分开的实验，有哪些写法实际有效：POPPER 的证伪实验设计、co-scientist 的假设与评审、AdaEvolve 停滞时的元指导。原文在 `reference-paper/`，参考实现的克隆在 `/home/iomgaa/Projects/RivalBits/reference/`。
|
||
- 同类系统怎么写"诊断当前瓶颈"的提示。
|
||
3. 写。任务提示词里不写字段怎么填，那是字段说明的事。
|
||
4. **自查泄露**：照任务书 17 第 1.2 节第 5 条，用填圆的关键词搜一遍改过的全部文件。关键词至少包括任务书 16、17 用过的那些，再加"联合""半径""LP""起点"。搜到就改掉，搜不到才算过。
|
||
5. **先提交，再跑。**提示词单独提交一次。之后的真实运行全部用这一版，看到运行结果以后不再改提示词。
|
||
|
||
## 三、第三块：真实运行和评估
|
||
|
||
### 3.1 跑什么
|
||
|
||
- 配置用 `eval/diagnosis/research.json`（诊断开、消融关），从头新跑 3 份完整研究，一直跑到余额用完、停在"导出还没写"。
|
||
- 3 份同时跑，同任务书 17 第 3.1 节。CPU 时间与墙钟时间之比照样列出。
|
||
- 3 份里挑 1 份，在**一次诊断运行确认启动以后、出结果之前**，杀一次控制进程再启动。检查三件事：
|
||
- 恢复后没有重跑；
|
||
- 只扣了一次；
|
||
- 每个实验的结果都照常写进去，结算和后面的步骤照常走完。
|
||
- 中途出错，照任务书 17 第 3.1 节处理。
|
||
- 模型服务的内容审核拦下某份材料（任务书 17 的 E 那种情况）时，这份研究照方法停下，照实记，不改写模型交的文字，不换模型。
|
||
|
||
### 3.2 评估：研究质量
|
||
|
||
不设硬线，结果照实交给用户。
|
||
|
||
**第 1 样：诊断解释和诊断实验的质量。**每一轮的诊 1，派一个全新上下文的子 Agent，在**看不到诊断结果**的情况下读：诊断解释、诊断实验、诊断预测、当前基线代码与它的分数。回答：
|
||
- 解释说出了具体的瓶颈吗？写了什么实测会推翻它吗？
|
||
- 同一轮几位研究者的解释有没有真正不同？
|
||
- 每个实验是不是只动一处？是不是真能把几种解释分开？
|
||
- 有没有实验去测以前否掉过的路线的理由？
|
||
|
||
**第 2 样：选实验。**每轮列出：
|
||
- 合并后的实验、各实验的事前合并范围、各组合的信息价值、成本、净值；
|
||
- 选了哪几个，或者为什么不诊断。
|
||
|
||
回答：选中的是不是大家分歧最大的；有没有因为大家意见一致而不诊断，出现了几次（方法.md 第十二部分第 10 条）。
|
||
|
||
**第 3 样：诊断实现照写法没有、核验员判得对不对。**每次诊断，派一个全新上下文的子 Agent 读：实验原文、当前基线代码、诊断程序、位置表、`concerns`、核验结论。回答：
|
||
- 每个实验是不是只动了写的那一处，有没有偷偷改进别的地方；
|
||
- 核验员该判不通过却通过的、不该判却判了的。
|
||
|
||
**第 4 样：诊断有没有改变走向。**这是这次最要紧的一样。每份研究每一轮一行：
|
||
- 诊断推出的方向和它的实测收益；
|
||
- 本轮提案里有几条沿这个方向；提案正文有没有引用诊断结果；
|
||
- 选批选没选沿这个方向的候选；
|
||
- 正向实测，以及沿这个方向的候选比诊断实测高还是低（方法.md 第十二部分第 9 条）；
|
||
- 采纳了什么。
|
||
|
||
另列：诊断指出了方向、却没有人沿它提的轮次（第十二部分第 11 条）。
|
||
|
||
**第 5 样：预测准不准、分不分得开。**
|
||
- 诊 2 预测的落点四段和覆盖率，按人、合并分开报；
|
||
- 同一轮各实验合并中位数之间的差距，和任务书 17 里正向候选之间的差距（0.001–0.03）对比。
|
||
|
||
**第 6 样：整份研究的走向。**每份研究列：
|
||
- 每一轮：诊断做没做、几个实验；正向候选；采纳与分数；离已知最好还差多少；
|
||
- 分数随轮次的曲线。和任务书 17 的 B、D（没有诊断、消融开）并排，再并上参考项目 15-real-1、15-tight-2、16-real-1。
|
||
- 每个跑过的正向候选一行，同任务书 17 第 3.2 节第 6 样的表。
|
||
|
||
**第 7 样：程序账目。**每份研究列：
|
||
- 确认启动的正式运行数（基线、诊断、正向分开）和余额减少的次数，两者应相等；最后余额为 0；
|
||
- 每次诊断：选了几个实验，核验几次、修复几次、拿掉了几个，跑了几个；每个实验的用时和结局；
|
||
- 诊断预测冻结早于诊断运行确认启动；每轮最多一次诊断结算；
|
||
- 余额 < 2 的那一轮没有诊断记录；
|
||
- 消融关着：没有消融阶段和解释阶段，账本里有"按配置跳过"；
|
||
- 杀进程那一次的三条检查。
|
||
|
||
### 3.3 怎么算通过
|
||
|
||
**程序部分必须过：**
|
||
- `npm run check`、`npm test` 全过；
|
||
- 3 份研究都跑到余额为 0、停在"导出还没写"，阶段开关成对；
|
||
- 扣掉的次数等于确认启动的运行数；
|
||
- 杀进程那一次的三条检查都成立；
|
||
- 消融的数字逐位不变（1.2）；
|
||
- 正向、消融、基线的运行定义没变（1.4）。
|
||
|
||
**研究质量不设硬线，照实交给用户。**质量不好时，先查是不是 flow 或 materials 写错了：抽一次诊断，看研究者、实验员、核验员"模型调用开始"里存的材料，是否符合方法.md 第三部分和 4.3 诊断一段。材料错了就修，修完重跑；材料对，就照实报告，不再改提示词。
|
||
|
||
## 四、正式代码和检验代码分开
|
||
|
||
照任务书 12 第四部分的 7 条。这次新加的检验代码放 `eval/diagnosis/`，能复用 `eval/full/`、`eval/lib/` 的就复用。运行目录、审阅结果放 `/home/iomgaa/inforsi-eval/<日期-名字>/`，不提交。
|
||
|
||
## 五、规模
|
||
|
||
| 模块 | 现在 | 这次 |
|
||
|---|---|---|
|
||
| flow | 1673 | 加 400–700，上限 3500 |
|
||
| rules | 1762 | 加 200–400，上限 2500 |
|
||
| materials | 1930 | 上限 2250（用户 2026-10-05 定） |
|
||
| vocab | 1131 | 上限 1300（用户 2026-10-05 定） |
|
||
| 其余 | — | 照结构.md 第七部分 |
|
||
|
||
写的过程中，哪个模块超过预计一倍，停下来检查。
|
||
|
||
## 六、文档
|
||
|
||
完成后更新：
|
||
- `docs/结构.md` 第八部分各模块新导出的函数、类型；flow 一节"做完以哪条记录为准"的表、"谁做、对哪个对象"的表、诊断的阶段编号；新加的 `eval:` 命令；
|
||
- `WORK_LOG.md`："已完成"补一条。"关键决定"不用你写，监督者核对时补。
|
||
|
||
不新建 md 文件。方法.md 不用改，有和它对不上的地方，写进报告。
|
||
|
||
## 七、验收与报告
|
||
|
||
做完后本地提交，然后在回复里交一份报告。报告写正文，不把日志全文附进去，日志放在证据目录，报告里给路径。
|
||
|
||
1. 提交号：提示词那次单独列；新增和修改的文件，分 `prompts/`、`src/`、`tests/`、`eval/` 列；各模块行数。
|
||
2. 提示词：每份写了或改了什么、依据哪条原则或调研结论；泄露自查的关键词和结果；再调研派了哪些子 Agent、查到了什么。
|
||
3. `npm run check`、`npm test` 的结果，完整输出放证据目录。消融逐位不变、运行定义不变的对照结果。
|
||
4. 程序部分：3 份研究的研究目录、轮数、停下原因；杀进程那一次的三条检查。
|
||
5. 研究质量：第 3.2 节七样的表和结论。第 4 样单独写一段结论：诊断有没有改变走向。
|
||
6. 你和这份任务书、结构.md、方法.md 不一致的地方，以及为什么。
|
||
7. **规则不清楚的地方**：哪里让你犹豫、哪里你是靠猜的。没有就写"没有"。没有真实证据的可能情况，在这里提一句就够，不写进 WORK_LOG。
|
||
8. 正式代码和检验代码分开的自查，逐条写"做到了"或"没做到、为什么"。
|