主题
08 - 自动迭代循环
把审稿、修复、重审做成状态机
目标
这一章不讨论“如何优雅地接受批评”，而是讨论：
收到审稿意见或内部 review 之后，怎样把问题分级、最小修复、重新评估，并决定是否继续推进？
本章的目标是：
- 把来自人类、智能体或外部 reviewer 的批评统一整理成问题清单
- 区分哪些问题是 claim 级、evidence 级、implementation 级、writing 级
- 为每一轮 review 输出一份最小修复计划，而不是无限加实验
- 把修复、补实验、重审和停止条件都写进
REVIEW_LOOP_LOG.md - 为 09-论文结构 和 11-写作与润色 提供稳定输入
本章回答的问题是：
这一轮 criticism 里，哪些必须修，哪些可以降表述，哪些说明这个方向该停？
完成标准
完成本章，不等于“我们讨论过 reviewer 意见”，而是至少做到：
- 你有一份经过人类复核的
REVIEW_LOOP_LOG.md - 每一轮 review 都有明确的 issues、fix plan、rerun summary 和 verdict
- 你能区分“提议修复”和“已经修复”
- 你知道本轮结束后是
ADVANCE、REVIEW_AGAIN、HOLD还是STOP - 你没有把 scope 扩张成一轮无边界补实验
输入与标准产物
输入
建议直接使用 04-07 章产物和当前草稿材料：
| 输入 | 作用 |
|---|---|
NOVELTY_REPORT.md | 回看 closest work、主差异点和风险 |
EXPERIMENT_PLAN.md | 回看原本承诺要证明什么 |
PILOT_LOG.csv | 回看首轮信号和中间决策 |
ANALYSIS_REPORT.md | 提供 claim 状态、异常和下一步建议 |
| 当前论文草稿 / 提纲 / 图表 | 让 reviewer 有可审对象 |
| 外部或内部 review 意见 | 作为问题输入 |
标准产物
| 产物 | 作用 | 后续会在哪用到 |
|---|---|---|
REVIEW_LOOP_LOG.md | 记录每轮审稿、问题分级、修复计划、重跑结果和最终 verdict | 09, 11, 12 |
这些 artifact 的统一命名、建议路径和状态定义见：附录 E
人类-智能体协作
| 阶段 | 智能体适合做什么 | 人必须负责什么 | 常见风险 |
|---|---|---|---|
| 问题整理 | 汇总多位 reviewer 的意见、去重、归类 | 判断哪些问题是实质问题 | 把表述问题和证据问题混为一谈 |
| 修复计划草拟 | 根据 issue table 生成最小 fix list | 决定本轮预算和 scope | 一轮修复里塞进太多“顺便做” |
| 补实验与改稿 | 执行明确修复项、改写段落、更新图表 | 判断修复是否真正解决批评 | 用更长篇幅掩盖没解决的问题 |
| 重审模拟 | 用相同 rubric 再审一轮 | 对最终 verdict 签字 | 自己给自己放水 |
本章默认的工作方式是：
智能体负责把批评和修复链条记录得清楚、执行得快；人类负责决定是否真的修到位。
自动迭代循环不是什么
这一章不是鼓励：
- reviewer 说什么就无限加什么
- 先承诺“会补”，但实际上不跑
- 通过更多文字掩盖证据空缺
- 明明主 claim 已经站不住，仍继续堆修复
自动迭代循环的真正目的，是：
用尽可能少的轮次识别并修复真正阻碍投稿或成文的问题。
工作流
Phase 0: 冻结本轮 review packet
每一轮 review 前，都要先冻结本轮被审对象：
- 当前摘要 / 引言 / 方法 / 实验段落
- 当前图表和表格
- 当前
ANALYSIS_REPORT.md - 当前想要主打的 claim 集合
否则 reviewer 反馈会针对不同版本，无法比较。
Phase 1: 统一收集 criticism
把问题来源统一写进一个 issue table，而不是散落在聊天记录、批注和脑内印象里。
建议至少包含：
| 字段 | 说明 |
|---|---|
issue_id | 问题编号 |
source | human / agent / external reviewer |
type | novelty / evidence / baseline / analysis / writing / figure / reproducibility |
severity | high / medium / low |
issue | 问题本身 |
affected_claim | 影响哪条 claim |
proposed_fix | 计划如何修 |
fix_status | planned / running / done / dropped |
Phase 2: 先分级，再修复
不是所有问题都该同等处理。建议先做四类划分：
| 类型 | 典型表现 | 常见动作 |
|---|---|---|
| Claim-level issue | claim 过强、novelty 不成立、定位不准 | 降 claim、重写定位、直接删除 |
| Evidence-level issue | baseline 不够、实验不足、分析不充分 | 补关键实验、补对比、重做分析 |
| Implementation-level issue | bug、评估错位、repro 不足 | 修链路、重跑、补日志 |
| Presentation-level issue | 结构混乱、图表不清、写作冗余 | 重组结构、改图、精简表述 |
原则是：
先修会影响 claim 成立与否的问题，再修表现层问题。
Phase 3: 设计最小修复集
每轮 review 后，不要把所有“也许有帮助”的实验都加进去。先问：
- 哪一个问题最可能导致被拒或被打回？
- 哪个修复动作成本最低但判定力最高？
- 哪些问题可以通过降表述而不是补实验解决？
- 哪些问题说明主线已经不值得继续？
建议把本轮 fix plan 限制为：
- 1-3 个必须修的高优先问题
- 0-2 个低成本补强项
- 明确不做的项及原因
Phase 4: 修复时把“计划”和“已完成”分开
最常见的问题是把“将补实验”写得像“已补实验”。
因此每个 issue 至少要区分：
| 字段 | 含义 |
|---|---|
proposed_fix | 打算怎么修 |
executed_fix | 实际完成了什么 |
evidence_of_fix | 哪张图、哪个表、哪份结果支持修复完成 |
如果没有 evidence_of_fix，就不应写成已修复。
Phase 5: 用同一 rubric 再审一轮
补完之后，不要直接默认“问题解决了”，而要用相同的标准重审：
- 这条 criticism 是否仍然成立
- 修复是否真正触达问题核心
- 是否引入了新的 weakest point
- 当前 claim 强度是否需要继续下调
这一轮最好仍然输出 issue table 更新和 round verdict。
一个补充的审稿-修复-重审闭环图（LaTeX/TikZ）
如果你想在本章放一张更强调“修复后再重审，而不是先承诺会修”的闭环图，可以直接使用下面的 LaTeX 代码：
使用时需要：
latex
\usepackage{tikz}
\usetikzlibrary{positioning,arrows.meta}Phase 6: 写成 REVIEW_LOOP_LOG.md
这一章的输出不是“大家都觉得差不多了”，而是一份可以交给后续章节继续消费的 round log。
REVIEW_LOOP_LOG.md 模板
markdown
# Review Loop Log
## Round R1
### Input Packet
- Draft version:
- Linked analysis report:
- Reviewed claims:
### Issue Table
| Issue ID | Source | Type | Severity | Affected Claim | Issue | Proposed Fix | Fix Status |
|----------|--------|------|----------|----------------|-------|--------------|-----------|
| I1 | external | evidence | high | C1 | ... | add baseline B | done |
| I2 | agent | writing | low | C2 | ... | rewrite intro para 2 | done |
### Executed Fixes
- ...
### Rerun Summary
- Added experiments:
- Updated figures:
- Updated claim status:
### Verdict
- Decision: REVIEW_AGAIN
- What is resolved:
- What remains:
- Stop condition if unresolved:常见 verdict
| Verdict | 含义 |
|---|---|
ADVANCE | 问题已降到可进入下游章节 |
REVIEW_AGAIN | 有明显进展，但还需再审一轮 |
HOLD | 当前轮不值得继续推进，先等待新结果或新方向 |
STOP | 主线已不成立，应终止本轮 |
工具接入建议
这一章更适合吸收 附录 D 里“审稿代理、状态持久化、最小修复”的经验：
| 工具 / 来源 | 更适合做什么 | 不要直接拿来做什么 |
|---|---|---|
| ARIS review / analyze 流程 | 组织多轮审稿和修复状态 | 自动宣布“已经可投” |
| The AI Scientist | 模拟 reviewer、汇总 round-level 结果差异 | 把自动审稿意见当最终标准 |
| AI-research-SKILLs | 提供 issue table、执行清单和状态机写法 | 替你决定哪些 criticism 真致命 |
这里强调的是从已有自动化科研系统里提炼的“review-fix-rerun”协议，而不是传统“多找人看看论文”的泛泛建议。
质量控制
1. 问题、修复、证据必须分开记录
不能把“有人提了问题”“计划修复”“修复完成”写成一回事。
2. reviewer 建议不等于必须执行
真正要修的是会影响 claim 成立和投稿判断的问题，而不是所有建议。
3. 修复必须有证据
如果某条 criticism 的 fix 没有新实验、新分析或新文本依据，就不要写成已解决。
4. 不要用更多内容掩盖没解决的问题
一段更长的叙事、更多图和更多表，不等于主问题解决了。
5. 必须有停止条件
如果连续几轮修复后，主线仍然被同一问题卡住，应考虑 HOLD 或 STOP。
常见错误
错误 1：reviewer 说什么就补什么
表现：scope 越修越大，最后变成新项目。
解决：先分级，只修最影响 go / no-go 的问题。
错误 2：把“会补”写成“已补”
表现：在 rebuttal 或草稿里提前承诺未完成实验。
解决：严格区分 proposed_fix 和 executed_fix。
错误 3：每轮 review 的标准都在变
表现：上一轮说解决了，这一轮又按新的尺子重打分。
解决：尽量复用同一 rubric，并把变化写进 log。
错误 4：只改写法，不改证据
表现：明明是 evidence gap，却只靠润色和重写段落应对。
解决：先区分问题类型，证据问题优先靠实验和分析修。
错误 5：没有 stop condition
表现：团队不断在弱主线上追加预算。
解决：为关键问题写下停止条件，无法通过就停。
检查清单
完成本章后，你应至少能回答：
| 问题 | 状态 |
|---|---|
| 我是否把所有 criticism 统一整理成 issue table 了？ | [] |
| 我是否区分了 claim、evidence、implementation 和 writing 问题？ | [] |
| 我是否只选择了本轮必须修的最小 fix set？ | [] |
| 我是否记录了哪些 fix 已执行、证据是什么？ | [] |
| 我是否给出了明确的 round verdict 和 stop condition？ | [] |
小结
自动迭代循环的核心不是“多审几轮”，而是：
- 把 criticism 结构化
- 做最小但可信的修复计划
- 把修复执行和证据记录清楚
- 用相同 rubric 重审
- 把每轮结果写入
REVIEW_LOOP_LOG.md
下一步：09-论文结构 - 把修复后的 claim 和 evidence 组织成可写论文
引用 ARIS：本章的多轮审稿、修复、重审思路主要来自 ARIS 的 review 和 analyze 流程。
扩展来源：这一版还吸收了 The AI Scientist 和 AI-research-SKILLs 中关于 reviewer simulation、状态持久化和最小修复集的可执行经验。完整来源见：附录 D