298 lines
22 KiB
Markdown
298 lines
22 KiB
Markdown
# 任务书 14：flow 第 2 部分（开轮到选批）与这一段的提示词
|
||
|
||
这是 flow 四部分里的第 2 部分（`docs/结构.md` 第三部分"flow 分四部分写，各自验证"）。做完以后，研究能从第零轮走到第 1 轮选出本批：提案 → 判重合并 → 第一次预测 → 挑刺 → 回应与统一 → 冻结协议 → 第二次预测 → 选批，然后停下，原因写"实现还没写（任务书 15）"。
|
||
|
||
一份任务书里有三块，**按顺序做**：
|
||
|
||
1. **第一块：改提示词。** 这一段要用的提示词，监督者和用户都认为一定有问题。先读调研结论，可以再调研，拿参考项目的真实记录诊断，然后改。改完先提交，再做后面两块。
|
||
2. **第二块：写代码。** 写 `src/flow` 的 ①–⑧，加两处小修复。
|
||
3. **第三块：真实运行和评估。** 真实跑 3 次，按整体研究质量评估，和参考项目的高分运行盲评比较。
|
||
|
||
本任务书已由用户和监督者在 2026-10-03 一起确定。下面说的"监督者"，是在参考项目目录里和用户讨论设计的另一个会话。
|
||
|
||
## 开工前先读
|
||
|
||
- `CLAUDE.md`：全部。尤其是"测试"一节：flow 的验收看研究质量；正式代码和检验代码完全分开。
|
||
- `docs/方法.md`：
|
||
- 第三部分：角色与材料；
|
||
- 4.3 ①–⑧；
|
||
- 第五部分：每种提交；
|
||
- 6.3、6.4：合并与选批；
|
||
- 第九部分：中断与恢复。
|
||
- `docs/结构.md`：
|
||
- 第三部分：步骤清单，以及"flow 分四部分写，各自验证"；
|
||
- 第四部分：账本记录；
|
||
- 第八部分：flow、materials、submissions、jev、rules、config 各节。
|
||
- `docs/调研/提示词.md`：提示词怎么写的两次调研结论。第一块必读。
|
||
- `任务书/12-flow-1-骨架与第零轮.md`：第二部分（骨架怎么搭）、第四部分（正式代码和检验代码怎么分开）。两处这次照旧适用。
|
||
- `WORK_LOG.md`："关键决定"最后几条；"未完成"里"给 flow"的条目，第十部分列了哪几条归这次。
|
||
- 参考项目（只读，不要改）：
|
||
- `/home/iomgaa/Projects/RivalBits/src/controller/steps/research.ts`，里面有 `openRound`、`dedup`、`writeProtocols`、`predictInputs`、`writeSelection`。看它怎么做，不照搬结构。
|
||
|
||
## 一、第一块：改这一段的提示词
|
||
|
||
### 1.1 范围
|
||
|
||
可以改的：
|
||
- `prompts/roles/researcher.md`；
|
||
- `prompts/tasks/` 下的 `proposal.md`、`firstPrediction.md`、`critique.md`、`response.md`、`unification.md`、`secondPrediction.md`；
|
||
- `src/vocab/submissions.ts` 里这几种提交的**字段说明**（`description`），因为"现在交什么"是从字段说明生成的。只改措辞，不改字段的结构、类型、必填与否；vocab 上限 1150 行。
|
||
|
||
不改的：
|
||
- 第零轮那三份（entry、discussion、claim）：上一轮已经改过，事先定好不再调；
|
||
- 实验员、核验员、解释、收尾、消融的提示词：后面几部分再看；
|
||
- `tasks/circle_packing/` 下的任务文件，第二块第 2 条那一处除外。
|
||
|
||
### 1.2 怎么做
|
||
|
||
1. **读调研结论。** `docs/调研/提示词.md` 全文。
|
||
2. **可以再调研。** 针对这一段的几步可以派子 Agent 去查。参考项目的克隆在 `/home/iomgaa/Projects/RivalBits/reference/`。子 Agent 只读、不写 md，结论直接回复。值得查的方向：
|
||
- 提出改法时怎么让几个人不交出同一个改法的不同参数；
|
||
- 挑刺和审稿怎么写才能挑到实质问题：co-scientist 的反思和辩论、AI-Scientist 的审稿提示；
|
||
- 回应和反驳怎么写；
|
||
- 让模型给范围预测、而且给得准：`llm_forecasting`、`forecastbench`，以及 `papers/` 下的预测类论文。
|
||
3. **拿真实记录诊断。** 读参考项目高分运行第 1 轮里模型实际交了什么、被退回了什么、Jev 怎么判的：
|
||
- 账本在 `/home/iomgaa/rb-acceptance/{16-real-1,15-real-1,15-tight-2,14-real-1,12-real-2}/board.sqlite`，只读，用 `sqlite3 -readonly`；
|
||
- 提交在 `submissions` 表，按 `stages.phase` 区分；退回在 `audit` 表的 `submission-rejected`；
|
||
- 参考项目当时的提示词在它的 git 历史和 `prompts-used/` 下。新项目的提示词是以它为底稿改的。
|
||
|
||
列出你看到的毛病。每条写清四样：现象、证据位置（库名、表、序号）、提示词里是哪一句引起的、怎么改。
|
||
|
||
监督者已知的几条，你核实后可以直接用：
|
||
- 同一轮三个人常交出同一个改法的不同参数。12-real-2 第 2 轮三份都是"在当前最好解附近加扰动再优化"，只是幅度不同；16-real-1 第 2 轮 c2、c3 跑出逐位相同的分数。
|
||
- 一条后来证明有效的提案被三人都估成最低，没被选上（15-real-1 第 1 轮 c2）。
|
||
- 挑刺有时只说空话，没有对照代码。
|
||
- 研究者角色提示词 1.9 万字，每个任务都整份发。
|
||
4. **改。** 照 `docs/调研/提示词.md` 第三、四部分的原则写。同一段内容只放一处：角色提示词里的内容不在任务提示词里再写一遍，任务提示词里不写字段怎么填（那是字段说明的事）。
|
||
5. **自查泄露。** 照 `docs/调研/提示词.md` 第四部分最后一条：
|
||
- 改完用填圆的关键词搜一遍你改过的全部文件，搜到就改掉，搜不到才算过；
|
||
- 例子只用和题目无关的领域，不出现任何填圆的做法、数值或参考项目跑出来的具体经历。
|
||
6. **先提交，再写代码和跑。** 提示词改完单独提交一次。之后的真实运行全部用这一版，**看到运行结果以后不再改提示词**。这是事先定好的规则：结果不管好坏都照实收下，交给用户。
|
||
|
||
## 二、第二块：代码
|
||
|
||
### 2.1 管哪些步骤
|
||
|
||
config 的 `ROUND_STEPS` 从 `openRound` 到 `selectBatch`。走到 `implementation` 时停下，原因写"实现还没写（任务书 15）"。现在只走得到第 1 轮，但代码按"第 r 轮"写，不写死 1。
|
||
|
||
### 2.2 每一步以哪条记录为准算做完
|
||
|
||
接着 `docs/结构.md` 第八部分 flow 一节的那张表往下加：
|
||
|
||
| 步骤 | 看到哪条记录算做完 |
|
||
|---|---|
|
||
| `openRound`、`carryOverPool` | 不写记录。本轮名单和提案上限就是冻结的配置；留池候选由 materials 从记录算出（`Board.carried`） |
|
||
| `proposal`、`firstPrediction`、`critique`、`response`、`secondPrediction` | 这一轮这个阶段的关闭记录。阶段编号 `r<轮>-<阶段>` |
|
||
| `dedupe` | 本轮的判重合并决定（`decision`，种类 `dedup`） |
|
||
| `freezeProtocol` | 本轮每个新候选都有冻结协议记录（`protocol`）。全部候选在同一个事务里写 |
|
||
| `selectBatch` | 本轮的选批决定（`decision`，种类 `batch`） |
|
||
|
||
### 2.3 每个阶段谁做、对哪个对象
|
||
|
||
一个任务就是"一个人对一个对象"。同一阶段里，一个人的几个任务按先后跑，不同的人同时跑（照任务书 12 第 2.6 节）。一个任务做完，以"这个人对这个对象有一份被收下的提交"为准。阶段关闭要等所有任务都做完。
|
||
|
||
| 阶段 | 任务 | 对象 |
|
||
|---|---|---|
|
||
| 提案 | 每位研究者一个任务，一个会话里交 1 到 M 条 | 无 |
|
||
| 第一次预测 | 每位研究者 × 本轮每个新候选（含自己的） | 候选 |
|
||
| 挑刺 | 每位研究者 × 本轮每条**不是自己写的**原提案（监督者定，照参考项目：方法没写谁挑谁） | 原提案 |
|
||
| 回应与统一 | 每个新候选一个任务：只有一条原提案的，由作者交"回应"；几条合成的，由其中研究者编号最小的作者交"统一" | 候选 |
|
||
| 第二次预测 | 每位研究者 × 池里每个候选（新候选加留池候选） | 候选 |
|
||
|
||
"派不派、什么时候停下"的规则照任务书 12 第 2.3 节，只是从"一个人"细到"一个人对一个对象"。查这个任务最近一次调用时，"模型调用开始"里存的材料带着对象，可以用它。
|
||
|
||
**提交之后才知道的东西**（submissions 的 `known`）：
|
||
- 提案：本人在本阶段已经收下几条；
|
||
- 回应：作者那条原提案；
|
||
- 其余照 submissions 的 `KnownOf`。
|
||
|
||
提案和挑刺一人可以交几份，编号用 materials 的 `proposalId`、`critiqueId`，收下时由 flow 分配。
|
||
|
||
### 2.4 三个程序步骤
|
||
|
||
**判重合并（③）**：
|
||
- 本轮新提案两两问一次 Jev（jev 的 `judgeSameChange`），每条新提案也和每个留池候选问一次。
|
||
- 判为相同的连成一组：A 和 B 相同、B 和 C 相同，A、B、C 就是一个候选（监督者定，方法没写这种情况）。
|
||
- 一组里有提案和某个留池候选相同，整组并进那个留池候选（方法.md 4.3 ③）。一组同时连到两个留池候选，按内部错误停下：真实运行里没出现过。
|
||
- 新候选按组里编号最小的原提案排序，编号用 materials 的 `candidateId`。
|
||
- 写一条决定：
|
||
- 种类 `dedup`；
|
||
- 输入：每一对的 Jev 判断，原样存；
|
||
- 输出：materials 的 `DedupOutput`；
|
||
- 规则名写 `jevSameChange`，版本 1；参数写 Jev 模型名；种子 `null`。
|
||
|
||
**冻结协议（⑥ 之后）**：
|
||
- 回应阶段关闭后，对每个新候选：
|
||
1. 取它最后一份回应或统一；
|
||
2. 用 submissions 的 `protocolBody` 拼出协议主体；
|
||
3. 用 materials 的 `freezeProtocol` 补上候选编号、轮次、本批基线、合并了哪些原提案；
|
||
4. 写冻结协议记录。
|
||
- 一定在回应阶段关闭之后写（"给 flow"：materials 把这条记录的出现当作"已公开"，提前写会泄露）。
|
||
- 本批基线是哪个对象：materials 已经有 `Board.baselineOf`，导出来共用，不另写一份。
|
||
|
||
**选批（⑧）**：
|
||
- 输入照 rules 的 `BatchInput` 拼：
|
||
- 候选：池里每个候选，各人最后一份第二次预测的三个数；
|
||
- 本批基线分数：materials 已经有 `Board.baselineScore`，导出来共用；
|
||
- 方向、ε、λ、每批上限：取自冻结的配置和任务事实；
|
||
- 余额：用 rules 的 `runBalance` 从运行记录算；
|
||
- 种子：rules 的 `decisionSeed`，由研究编号、轮次、版本算（"给 flow"：同一轮选批、选格都用随机规则时，传不同的版本）。
|
||
- 用步骤清单里 `selectBatch` 那一步的规则，调 `runBatchRule`。
|
||
- 写一条决定：种类 `batch`，规则名和版本取 `runBatchRule` 交回的。
|
||
|
||
### 2.5 两处小修复（用户 2026-10-03 同意）
|
||
|
||
1. **讨论原文里的作废编号**：讨论和认领的材料里展示讨论原文时，原文引用的入口编号已经作废的，程序在它后面就地标"（已作废）"。上一轮 v2-3 有研究者引用了不在最终清单里的编号，读的人会糊涂。写在 materials 里（谁看到什么归 materials）。
|
||
2. **删掉 `tasks/circle_packing/baseline/SOURCES.md` 里"一个实测过的事实（参考项目里跑出来的）……"那一段**（第 21–23 行）。它把注意力引到半径函数上，研究者也引用过它。
|
||
|
||
### 2.6 不花钱的测试（`tests/`）
|
||
|
||
在 `tests/flow-next-step.test.ts` 里加"下一步做什么"的情形，至少覆盖：
|
||
- 第零轮做完 → 开提案阶段；
|
||
- 提案阶段一人交了两条、两人没交 → 只派没交的两人；
|
||
- 提案交齐关闭后 → 判重；
|
||
- 判重做完 → 开第一次预测，任务是每人 × 每个新候选；
|
||
- 挑刺阶段的任务里没有"挑自己的提案"；
|
||
- 合并而成的候选，回应阶段派给编号最小的作者交统一；
|
||
- 回应阶段关闭、还没有冻结协议 → 写冻结协议；
|
||
- 第二次预测关闭 → 选批；
|
||
- 选批做完 → 停下，原因"实现还没写"。
|
||
|
||
### 2.7 规模
|
||
|
||
- `src/flow` 这部分新增预期 500–800 行。总数超过 1700 行就停下来检查。
|
||
- materials 上限 1900 行，现在 1897 行，这次要导出两个已有的函数、加作废编号的标注。超过 1900 就在报告里写多在哪几处，监督者再和用户商量上限，不要为了压行数把代码挤在一起。
|
||
|
||
## 三、第三块：真实运行和评估
|
||
|
||
### 3.1 跑什么
|
||
|
||
- 用第一块改好的提示词，配置照 `eval/round-zero/research.json`（3 位研究者、M = 1、每批上限 2、运行次数 13）。
|
||
- 3 个新的研究编号，从头跑到第 1 轮选批后停下，跑 3 次。
|
||
- 一个接一个跑：上次同时跑时内存不够，进程被系统杀过。
|
||
- 3 次里挑 1 次，在第一次预测阶段中途杀一次控制进程再启动，检查：
|
||
- 被杀那次调用补了结束记录；
|
||
- 交过的任务没被重派，没交的被重派；
|
||
- 没有重复收下的提交；
|
||
- 阶段照常关闭，往下走完。
|
||
|
||
### 3.2 评估：整体研究质量
|
||
|
||
用户 2026-10-03 定：不只看某一个想法有没有出现，而是从整体看系统有没有正常、高质量地做研究。用户原话："你现在直接把我们要以 SOTA 方法做标杆，简化为要对着联合优化来，这是不是有一点狭义了"。
|
||
|
||
**对照组**：参考项目 5 次高分运行的第 1 轮，即 16-real-1、15-real-1、15-tight-2、14-real-1、12-real-2，从它们的账本里读（不回放，用户定）。注意：
|
||
- 12-real-2 那一版用的是投票，不是范围预测，"预测"那一项记"不适用"；
|
||
- 参考项目那几次的提示词里写着填圆的具体做法，所以在"方向"这一项上它们占了便宜。
|
||
|
||
**第 1 步：导出成同一种文本。**
|
||
- 我们的 3 次运行和参考项目的 5 次，每次导出一份纯文本，按同样的小标题排：
|
||
- 提案全文；
|
||
- 判重结果；
|
||
- 每条挑刺和它的回应；
|
||
- 冻结协议；
|
||
- 两次预测的三个数；
|
||
- 选批结果；
|
||
- 退回的次数和原因。
|
||
- 去掉能看出来历的东西：运行名、模型名、"16-real-1"这类字样；编号统一改写成"提案 1、候选 1"这种中性写法。字段名不同（"points"对"factors"）去不干净的，在给审阅者的说明里写"格式差异不代表好坏，忽略"。
|
||
- 8 份文本随机编成"运行 A–H"，对照表另存，审阅者看不到。
|
||
- 导出脚本放 `eval/round-one/`。
|
||
|
||
**第 2 步：盲评。**
|
||
- 派**两个**全新上下文的子 Agent 各自独立审阅，它们只读 8 份文本、`TASK.md` 和第 3.3 节的研究路径说明。
|
||
- 每个审阅者对每份文本，按下表 7 个方面各打 1–5 分，每个分数附原文引用作依据，结论直接回复给你，不写 md。
|
||
- 你把两份打分整理进报告，并按对照表还原成"我们的 3 次"和"参考的 5 次"。
|
||
|
||
| 方面 | 看什么 | 1 分 | 5 分 |
|
||
|---|---|---|---|
|
||
| 方向 | 提案在研究路径（第 3.3 节）上处在哪一步 | 都在死路上，或者原地打转 | 有提案沿着路径往前走了合理的一步，或者走了一条清单上没有、但讲得通的路 |
|
||
| 多样性与判重 | 同一轮的提案是不是不同类的做法；该合并的合了没有，不该合的有没有被合 | 几条是同一个改法换参数，判重也没拦 | 几条明显是不同的路，判重结果对 |
|
||
| 提案质量 | 照着能不能实现；机制有没有说清；因子划得对不对；关掉一个因子时怎么做有没有写；能不能被实测推翻 | 含糊、说不清为什么会好 | 换一个人照着写代码能写出同一个东西，什么结果算它错了也写清了 |
|
||
| 挑刺 | 有多少挑刺说中了实质问题（混杂、写不清、因子划分、保障会不会改分），有没有对照代码 | 空话、泛泛而谈 | 指出了具体问题，附代码依据 |
|
||
| 回应 | 作者有没有认真处理挑刺：改了，或者讲清不改的理由 | 回避、只说"同意"却不改 | 逐条处理，冻结协议里看得到改动 |
|
||
| 预测 | 范围合不合理；读了挑刺和回应以后，估计有没有变化、变得有没有道理 | 有荒谬的数（超过已知最好或远低于基线）、范围宽到什么都能包住，或两次一字不差 | 范围有依据，第二次的变化说得通 |
|
||
| 选批 | 选中的是不是大家认为最有希望的、在研究路径上合理的那几个 | 选中的明显不如没选的 | 选得合理 |
|
||
|
||
**第 3 步：用 Jev 判几个封闭的问题**（写在 `eval/` 里，不动 `src/jev/`；两个顺序都问的取平均；阈值未校准，大于 0.5 判"是"）：
|
||
1. **判重对不对**：本轮提案两两问"是不是同一个改法"（检验自己的问法，两个顺序都问），和程序的判重决定对照。列出两样：检验判"是"而程序没合的，检验判"否"而程序合了的。
|
||
2. **挑刺有没有被回应**：每条挑刺问"作者的回应有没有处理这条挑刺：改了协议，或者给了不改的具体理由"。
|
||
3. **提案对应研究路径的哪一步**：每条提案对 K1–K5 和 D1、D2 各问一次（第零轮的 `eval/round-zero/ideas.json`）。只做描述，不设通过线。
|
||
|
||
**第 4 步：数字和过程。**
|
||
- 每个阶段的模型调用次数、退回次数和原因（按提交种类分）、墙钟时间、token 用量；
|
||
- 有没有停下、交不出、卡住；
|
||
- 预测里超过已知最好（2.635983）或低于基线（0.9598）的数，逐条列出；
|
||
- 每个人对同一候选第一次和第二次预测的变化。
|
||
|
||
### 3.3 给审阅者的研究路径说明
|
||
|
||
写成 `eval/round-one/path.md`。这是给审阅子 Agent 读的输入文件，不是项目文档，放在 `eval/` 下。内容照下面写：
|
||
|
||
> 26 圆填圆，基线 0.9598（圆心按同心环写死、半径逐对缩放），已知最好 2.635983。同类系统和参考项目的高分运行，大多沿着这样一条路往上走：结构化的起点或多起点 → 把圆心和半径一起交给连续优化器 → 在当前最好解附近加扰动再优化，或退火式接受 → 最后修到严格合法。辅助手段有：固定圆心用线性规划求最优半径、只动贴紧的那几个圆。死路有：只做几何构造（圆心按手排的规则摆、不移动），各系统都卡在 2.2–2.54；只改半径的分法、不动圆心，上限受布局限制。这是常见的一条路，不是唯一正确的路：一条清单上没有、但讲得通的路，同样算往前走了。第 1 轮能走多远取决于起点，参考项目第 1 轮采纳的分数在 1.55 到 2.632 之间。
|
||
|
||
### 3.4 怎么算通过
|
||
|
||
**程序部分必须过**：
|
||
- `npm run check`、`npm test` 全过；
|
||
- 3 次运行都走到选批后停下，每轮每个阶段开关成对；
|
||
- 冻结协议都写在回应阶段关闭之后；
|
||
- 杀进程那一次的四条检查都成立。
|
||
|
||
**研究质量不设硬线，照实交给用户。** 报告里要有：
|
||
- 7 个方面，我们 3 次的平均分和参考 5 次的平均分（两个审阅者分开列）；
|
||
- 我们比参考低 1 分以上的方面，单独列出，附你读原文看到的原因；
|
||
- 第 3 步 Jev 的结果，第 4 步的数字。
|
||
|
||
质量不好时，先查是不是 flow 或 materials 写错了：抽一次运行，看每个阶段"模型调用开始"里存的材料，是否符合方法.md 第三部分和 4.3。材料错了就修，修完重跑 3 次。材料对，就照实报告，**不再改提示词**（第一块第 6 条）。
|
||
|
||
## 四、正式代码和检验代码分开
|
||
|
||
照任务书 12 第四部分的 7 条。这次新加的检验代码放在 `eval/round-one/`，共用的工具放 `eval/lib/`。导出的文本、审阅结果、运行目录都放 `/home/iomgaa/inforsi-eval/<日期-名字>/`，不提交。
|
||
|
||
## 五、文档
|
||
|
||
完成后更新：
|
||
- `docs/结构.md` 第八部分 flow 一节：
|
||
- "做完以哪条记录为准"的表，加上第 2.2 节的几行；
|
||
- 第 2.3 节"谁做、对哪个对象"的表；
|
||
- 判重怎么连组；
|
||
- 新加的 `eval:` 命令。
|
||
- `docs/结构.md` 第八部分 materials 一节：补上新导出的两个函数和作废编号的标注。
|
||
- `WORK_LOG.md`：
|
||
- "已完成"补一条；
|
||
- 删掉这次做到的"给 flow"条目；
|
||
- "关键决定"不用你写，监督者核对时补。
|
||
|
||
不新建 md 文件。`eval/round-one/path.md` 是检验的输入数据，不算项目文档。
|
||
|
||
## 六、"给 flow"的条目里归这次的
|
||
|
||
WORK_LOG"未完成"里的：
|
||
- 同一轮里选批和选格都用随机规则时，传不同的"版本"算种子。这次做选批这一半，选格留给第 4 部分。
|
||
- 冻结协议只在回应阶段关闭后写进账本。同一条里"解封只在本轮收尾阶段关闭后写"归第 4 部分，那半句留着。
|
||
|
||
## 七、审阅
|
||
|
||
这次改到了判重决定和选批决定，两处都是账本里"驱动实际动作的决定"（方法.md 第九部分）。写完后另派一个全新上下文的子 Agent 审阅一轮，只看第 2.4 节的三个程序步骤和恢复。审阅只防 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.4 节要求的表和单列项；
|
||
- 两个审阅者各自的打分和主要依据；
|
||
- Jev 结果；
|
||
- 数字和过程。
|
||
6. 我们 3 次运行第 1 轮的提案名称、判重结果、选中了哪几个，各一行。全文在运行目录里给出路径。
|
||
7. 你和这份任务书、结构.md、方法.md 不一致的地方，以及为什么。
|
||
8. **规则不清楚的地方**：哪里让你犹豫、哪里你是靠猜的。没有就写"没有"。没有真实证据的可能情况，在这里提一句就够，不写进 WORK_LOG。
|
||
9. 正式代码和检验代码分开的自查，逐条写"做到了"或"没做到、为什么"。
|