research-pipeline

完整研究流程：从构想到实验，再到投稿

每次审稿人评审前，请遵循可选审稿人： 解析调用 → .aris/reviewer.json → 默认使用 Claude Code（Codex MCP） 并通过规范的辅助解析器调用 reviewer_route.py，保留此评审环节的等级、 新建上下文、源文件/图像输入和确定性门槛。 下方的 Codex 示例/固定配置仅适用于 backend=codex；其他路由使用各自的 首次调用/回复约定。保存路由和实际返回的身份； 不可用的选项标记为 REVIEW_UNAVAILABLE。根据实际 家族/完成状态/范围对接受情况分类。将调用方指定的审稿人/模型/推理强度覆盖项 传递给包含审稿环节的子流程。生成工作线程保持不变。

⏱ 外部节奏：仅作非评判性心跳。 夜间 /loop / CronCreate 心跳可以唤醒流程，检测停滞阶段（没有进展、进程已死、因某项资源已释放而受阻），并推动流程继续；但绝不能 判断工作是否良好（论文是否足够好、证明是否成立、论断是否有支撑）。 此类判断始终遵循各自技能的内部节奏，并最终交由跨模型陪审团。 心跳可以说“继续”，绝不能说“已经足够好”。 请参阅 shared-references/external-cadence.md （夜间流程规则，以及停滞检测与强制结构性转向）。心跳启动时，每次周期都要先更新运行状态，并将此运行 注册为监控程序的 loop 类型（以便无声退出会显示为 STALE）；完成后取消注册。监控程序仅负责检测，绝不宣告无问题。每次周期还要通过 iteration_log.py 辅助程序记录新发现的数量（按规范的 .aris/tools → tools → $ARIS_REPO/tools → $ARIS_REPO/tools via ~/.aris/repo 链解析路径，详见集成约定 §2；若无法解析，则警告并跳过）： python3 "$ITER_LOG" note <root> <run_id> <phase> <n>。若返回 pivot=structural（停滞 ≥ 2），推动流程时必须更改一项结构性约束，并选择一个 尚未尝试的方向；若返回 pivot=human（停滞 ≥ 4），则标记并提请关注。仅作计数， 绝不作质量判断。

端到端自主研究工作流，适用于：$ARGUMENTS

可选的形式化证明流程

在创建实验运行之前，将以定理为核心的 Lean 请求转交给 /lean-formalize，并报告实际证明 结果。若任务包含实证研究，则运行以下实验阶段。在混合项目中，对于用户请求的形式化证明，或形式验证能够显著助益的特定数学义务，应使用 Lean；将已验证的范围和剩余义务纳入研究摘要及适用的证明审计。常规数学仍使用现有理论技能。仅凭难度不足以要求必须使用 Lean，而形式化子引理也不能证明实证论断。

常量

• AUTO_PROCEED = true — 当为 true 时，每个选择检查点都仅供参考：报告选择结果，并在同一轮中继续。当为 false 时，要求用户明确确认，并在检查点处结束本轮。

• ARXIV_DOWNLOAD = false — 当为 true 时，/research-lit 会在文献调研期间下载相关性最高的 arXiv PDF。当为 false（默认值）时，仅通过 arXiv API 获取元数据。此设置会传递给 /idea-discovery → /research-lit。

• HUMAN_CHECKPOINT = false — 当为 true 时，自动评审循环（第 3 阶段）会在每轮评审后暂停，让你查看评分并提供自定义修改指示，然后再实施修正。当为 false（默认值）时，循环会完全自主运行。此设置会传递给 /auto-review-loop。

• REVIEWER_DIFFICULTY = medium — 评审者的对抗程度。medium（默认值）：标准 MCP 评审。hard：加入评审者记忆和辩论协议。nightmare：GPT 通过 codex exec 直接读取仓库，并结合记忆和辩论。此设置会传递给 /auto-review-loop。

• CODE_REVIEW = true — GPT-6-Astra xhigh 会在部署前评审实验代码，以便在浪费 GPU 运行时间前发现逻辑错误。设置为 false 可跳过。此设置会传递给 /experiment-bridge。

• BASE_REPO = false — 用作基础代码库的 GitHub 仓库 URL。设置后，/experiment-bridge 会先克隆该仓库，再在其基础上实现实验。当为 false（默认值）时，会从头编写代码或复用现有项目文件。此设置会传递给 /experiment-bridge。

• COMPACT = false — 当为 true 时，会生成精简摘要文件，供上下文较短的模型使用，并用于会话恢复。此设置会传递给 /idea-discovery 和 /experiment-bridge。

• AUTO_WRITE = false — 当为 true 时，第 4 阶段结束后自动调用工作流 3（/paper-writing）。只有在第 5 阶段开始时才需要 VENUE——未设置投稿场所时会延后论文撰写；这不会阻塞第 1 至第 4 阶段。当为 false（默认值）时，第 4 阶段会生成 NARRATIVE_REPORT.md 并停止——用户需手动调用 /paper-writing。

• VENUE = (unset) — 论文撰写的目标投稿场所；仅在第 5 阶段开始时绑定。可选项：ICLR、NeurIPS、ICML、CVPR、ACL、AAAI、ACM、IEEE_CONF、IEEE_JOURNAL。没有默认值：未设置投稿场所时会延后论文撰写；这不会阻塞第 1 至第 4 阶段，也不会猜测投稿场所。

• RENDER_HTML = true — 当为 true（默认值）时，第 4 阶段完成后通过 /render-html 自动将 NARRATIVE_REPORT.md 渲染为 HTML。使用 --no-review（这是交给 /paper-writing 的内部交接文档，而非面向评审者的最终材料——上游第 3 阶段的自动评审循环已通过跨模型评审检查相关论断）。设置为 false 可跳过，或传入 — render html: false。不会阻塞流程：如果 /render-html 失败或 Codex MCP 不可用，记录失败并继续——HTML 视图是锦上添花，并非第 4 阶段的前置条件。

• RESUMABLE = true — 当为 true（默认值）时，流水线会将每个阶段的状态记录到 .aris/runs/<run_id>.json，以便崩溃或中断的运行可通过 /research-pipeline — resume <run_id> 恢复，而不必重新开始。阶段状态会区分 done（执行器已完成写入）和 accepted（该阶段的跨模型门控／确定性验证器已通过）；恢复时会重新验证任何已完成但尚未接受的阶段。参见 shared-references/resumable-runs.md。

💡 通过参数覆盖，例如：/research-pipeline "topic" — AUTO_PROCEED: false, human checkpoint: true, difficulty: nightmare, code review: false, base repo: https://github.com/org/project, auto_write: true, venue: NeurIPS。

检查点执行规则

在阶段 1 之前，根据 $ARGUMENTS 解析一次 AUTO_PROCEED，并将解析后的值传递给嵌套工作流。

• AUTO_PROCEED=true 为非阻塞模式。 检查点是进度更新，而不是提问。说明结果和自动选择的下一步操作，然后在同一轮中继续执行。不要请求确认、要求用户输入、休眠、等待用户不回复，或在检查点结束本轮。
• AUTO_PROCEED=false 为阻塞模式。 提供选项并询问用户，然后结束本轮。只有收到明确回复后才能恢复。

绝不要将自动继续实现为“先询问，然后在没有回复时继续”。一旦本轮结束，用户保持沉默也无法让流程继续。用户仍可随时中断非阻塞运行。

此规则仅适用于由 AUTO_PROCEED 控制的选择检查点。如果用户明确启用了 Feishu 交互式关卡，该外部审批或回复属于有意设置的阻塞例外；应等待由用户控制的关卡，而不是将沉默视为超时。在 AUTO_PROCEED=true 时，Feishu 关闭或仅推送模式仍为非阻塞模式。

概述

此技能将整个研究生命周期串联成一个流水线：

/idea-discovery → /experiment-bridge → /auto-review-loop → /paper-writing (optional)
├── Workflow 1 ──┤├── Workflow 1.5 ──┤├── Workflow 2 ───┤ ├── Workflow 3 ──┤

它按顺序编排最多四个主要工作流。工作流 3（论文撰写）为可选项，由 AUTO_WRITE 控制。

可恢复运行（— resume <run_id>）

此流水线耗时较长，可能在运行中途失败；它通过 run_state.py 跟踪各阶段的状态，因此可以恢复运行，而不必从头开始（参见 shared-references/resumable-runs.md）。 如果 RESUMABLE = false，请跳过整个部分。

按照规范链解析辅助工具（integration-contract §2）： .aris/tools/run_state.py → tools/run_state.py → $ARIS_REPO/tools/run_state.py → 通过 ~/.aris/repo 指向的 $ARIS_REPO/tools/run_state.py （若无法解析，则警告并跳过——绝不阻塞流水线）。

阶段，依次为：idea-discovery, experiment-bridge, auto-review-loop, summary, paper-writing。

• **开始时：**如果传入了 — resume <run_id>，运行 run_state.py resume <root> <run_id>——它会输出第一个尚未 accepted 的阶段；从该阶段开始流水线（重新运行处于 running/failed 状态的阶段； 重新审查已 done 但尚未接受的阶段）。否则，根据方向标识和日期生成 <run_id>，并运行 run_state.py start <root> <run_id> --phases "idea-discovery,experiment-bridge,auto-review-loop,summary,paper-writing"。

• **每个阶段：**进入时运行 set <run_id> <phase> running；阶段产物写入后运行 set <run_id> <phase> done --artifact <path>。

• 只有在阶段门槛通过后才能将其标记为 accepted——绝不能仅凭执行者自行宣称通过（run_state.py accept 需要已记录的 verdict id 和审查者）：

  阶段	将其设为 accepted 的条件	记录为审查者
  idea-discovery	Gate 1 跨模型评审团 / 新颖性检查通过	codex-gpt-6-astra + 线程 ID
  experiment-bridge	实验确实已运行（任务已完成）——确定性条件	deterministic:experiment-bridge
  auto-review-loop	循环触发了肯定的 STOP（score>=6 AND verdict∈{ready,almost}——codex 的 verdict）	codex-gpt-6-astra + 最终审查追踪 ID
  summary	已写入 NARRATIVE_REPORT.md（若 RENDER_HTML，还需完成渲染）——确定性条件	deterministic:summary
  paper-writing	提交审核通过（verify_paper_audits.sh 退出码为 0）——确定性条件	deterministic:verify_paper_audits.sh

如果 AUTO_WRITE = false（默认值），paper-writing 不属于本次运行： 在 summary 被接受后，运行 set <run_id> paper-writing skipped，这样 resume 会报告 COMPLETE，而不是永远指向待处理阶段。将每个 accept 的 verdict_id 记录为持久句柄——codex 线程 / 追踪 ID，或确定性验证器报告的路径 / sha（例如 verify_paper_audits.sh 输出的 JSON）——而不只是审查者标签。

若阶段处于 done 状态（门槛未通过 / 结果不明确，或运行在通过门槛前崩溃），则会在下次恢复时重新验证——绝不会跳过接受该阶段的必要步骤。

夜间心跳：停滞检测 → 强制结构性转向

仅当无人值守的心跳正在驱动本次运行时（夜间 /loop / CronCreate）才执行。否则跳过。原则与理由： shared-references/external-cadence.md →“停滞检测与强制结构性转向”。这是一个 Type-A 信号——它统计发现并改变方向，绝不评判质量。

通过规范链（integration-contract §2）解析辅助工具；如果无法解析，则发出警告并跳过（绝不阻止运行）：

ITER_LOG=".aris/tools/iteration_log.py"
[ -f "$ITER_LOG" ] || ITER_LOG="tools/iteration_log.py"
[ -f "$ITER_LOG" ] || ITER_LOG="${ARIS_REPO:-}/tools/iteration_log.py"
[ -f "$ITER_LOG" ] || { [ -z "${ARIS_REPO:-}" ] && [ -f "$HOME/.aris/repo" ] && ARIS_REPO="$(cat "$HOME/.aris/repo" 2>/dev/null)"; } || true
[ -f "$ITER_LOG" ] || ITER_LOG="${ARIS_REPO:-}/tools/iteration_log.py"
[ -f "$ITER_LOG" ] || { echo "WARN: iteration_log.py not resolved; skipping stall detection" >&2; ITER_LOG=""; }

然后，在每个心跳周期，记录当前阶段产生了多少个具体的新发现，并读取返回的 pivot：

[ -n "$ITER_LOG" ] && python3 "$ITER_LOG" note "$ROOT" "$RUN_ID" "$STAGE" "$N_NEW_FINDINGS"
# → {"stale_count": N, "pivot": "none|structural|human"}

根据 pivot 采取行动：

• none — 继续。
• structural（停滞 ≥ 2）— 下一次提示必须改变结构性约束（框架 / 目标 / 数据 / 表征），而非战术参数，并选择与之前所有尝试都不同的方向。记录所选框架，以便后续周期避开它：python3 "$ITER_LOG" note "$ROOT" "$RUN_ID" "$STAGE" 0 --direction "<the new frame>"。
• human（停滞 ≥ 4）— 停止盲目提示；标记为需要人工关注（升级处理，不要悄然放弃）。

心跳可以说“继续 / 改变方向”，但绝不能说“已经够好”——所有质量评判仍须由跨模型评审团最终决定（acceptance-gate.md）。

流程

阶段 1：创意发现（工作流 1）

如果项目根目录中存在 RESEARCH_BRIEF.md，系统会自动将其作为详细上下文加载（替代单行提示词）。参见 templates/RESEARCH_BRIEF_TEMPLATE.md。

调用创意发现流程：

/idea-discovery "$ARGUMENTS" — AUTO_PROCEED: $AUTO_PROCEED

此流程内部依次运行：/research-lit → /idea-creator → /novelty-check → /research-review

输出： idea-stage/IDEA_REPORT.md，其中包含经过排序、验证和试点测试的创意。

🚦关卡 1 — 创意选择：

生成 idea-stage/IDEA_REPORT.md 后，展示排名靠前的创意。

**如果 AUTO_PROCEED=true（非阻塞）：**报告选择结果，并在同一轮中立即继续。不要将更新表述为问题：

📋 Idea Discovery complete. Top ideas:

1. [Idea 1 title] — Pilot: POSITIVE (+X%), Novelty: CONFIRMED
2. [Idea 2 title] — Pilot: WEAK POSITIVE (+Y%), Novelty: CONFIRMED
3. [Idea 3 title] — Pilot: NEGATIVE, eliminated

AUTO_PROCEED: selected Idea 1 — [title]. Continuing to Stage 2.

**如果 AUTO_PROCEED=false（阻塞）：**展示相同的排名，询问 推荐：创意 1。是否继续实施？，然后结束本轮。 用户可以：

• 批准创意 → 进入阶段 2。/experiment-bridge 会读取 /idea-discovery 已生成的 refine-logs/EXPERIMENT_PLAN.md。
• 请求修改（例如“合并创意 1 和 3”“进一步聚焦 X”）→ 根据用户反馈更新创意提示词，使用优化后的约束重新运行 /idea-discovery，然后再次展示。
• 拒绝所有创意 → 收集用户对缺失内容的反馈，调整研究方向后重新运行阶段 1。重复此过程，直到用户选定一个创意。
• 在此停止 → 将当前状态保存到 idea-stage/IDEA_REPORT.md，供将来参考。

⚠️ 当 AUTO_PROCEED=false 时，此关卡会等待用户确认。 当其为 true 时，展示结果后会自动继续。流程的其余部分（阶段 2–3）成本较高（GPU 时间 + 多轮评审），因此如果希望在投入 GPU 资源前设置最终评审检查点，请将 AUTO_PROCEED=false。

阶段 2：实验桥接（工作流 1.5）

选定想法后（自动选定或由用户选定），将实现和部署工作委派给 /experiment-bridge：

/experiment-bridge "$CHOSEN_IDEA_TITLE" — code review: $CODE_REVIEW, base repo: $BASE_REPO, compact: $COMPACT

💡 队列路由会自动完成：/experiment-bridge 的阶段 4 会根据任务数量为每个里程碑选择路由：≤5 个任务 → /run-experiment，≥10 个任务或存在教师→学生阶段依赖 → /experiment-queue（支持 OOM 重试、波次门控和崩溃安全状态）。无需手动覆盖。

此流程会执行以下操作（完全自主）：

1. 解析 refine-logs/EXPERIMENT_PLAN.md——提取里程碑、运行顺序和计算预算
2. 实现实验代码——将试点扩展到完整规模，并遵循现有代码库约定
3. 跨模型代码审查——在消耗任何 GPU 时间之前，由 GPT-6-Astra xhigh 审查实现，检查逻辑错误、指标不正确和对真实标注的误用
4. 合理性检查——先运行最小规模的实验以验证环境；自动调试失败（最多尝试 3 次，失败时回退到 /codex:rescue）
5. 部署完整实验——根据任务数量自动选择路由（≤5 个任务 → /run-experiment；≥10 个任务 → /experiment-queue，支持 OOM 重试、波次门控和崩溃安全状态）
6. 收集初步结果——解析输出、更新 refine-logs/EXPERIMENT_TRACKER.md，并在配置了 W&B 时运行 /training-check
7. 如果主要结果为正，通过 /ablation-planner 自动规划消融实验

输出：

• refine-logs/EXPERIMENT_RESULTS.md——按里程碑整理的结果
• refine-logs/EXPERIMENT_TRACKER.md——更新后的逐次运行状态
• EXPERIMENT_LOG.md（当 COMPACT=true 时）——便于会话恢复的日志

监控进度（实验运行期间）：

/monitor-experiment [server]

等待 /experiment-bridge 完成并提交交接摘要，然后再继续。

阶段 3：自动审查循环（工作流 2）

获得初步结果后，启动自主改进循环：

/auto-review-loop "$ARGUMENTS — [chosen idea title], difficulty: $REVIEWER_DIFFICULTY"

此流程会执行以下操作（最多 4 轮）：

1. GPT-6-Astra xhigh 审查工作成果（评分、弱点、最低限度的修正）
2. Claude Code 实施修正（代码更改、新实验、重新构建论述框架）
3. 部署修正并收集新结果
4. 重新审查 → 重复此流程，直到（评分 ≥ 6/10 且判定 ∈ {ready, almost}）或达到 4 轮

输出：review-stage/AUTO_REVIEW.md，包含完整审查历史和最终评估。

阶段 4：研究总结与写作交接

自动审查循环完成后，准备交接材料以撰写论文。

**步骤 1：**撰写最终研究状态报告（与之前相同）。

**步骤 2：**根据以下材料生成 NARRATIVE_REPORT.md：

• IDEA_REPORT.md（选定的想法、假设、新颖性论证）
• 仓库中的实现细节
• 实验配置和最终结果
• AUTO_REVIEW.md（审查历史、已修复的弱点、仍存的局限）

叙述报告必须包含：

• 问题陈述和核心主张
• 方法摘要
• 关键定量结果，以及每项主张的证据
• 图表清单（已有的图表，以及需要手动创建的图表）
• 局限性和待跟进事项

输出：NARRATIVE_REPORT.md + 研究流水线报告。

# Research Pipeline Report

**Direction**: $ARGUMENTS
**Chosen Idea**: [title]
**Date**: [start] → [end]
**Pipeline**: idea-discovery → experiment-bridge → auto-review-loop

## Journey Summary
- Ideas generated: X → filtered to Y → piloted Z → chose 1
- Implementation: [brief description of what was built]
- Experiments: [number of GPU experiments, total compute time]
- Review rounds: N/4, final score: X/10

## Writing Handoff
- NARRATIVE_REPORT.md: ✅ generated
- Venue: [VENUE or "not set — run /paper-writing manually"]
- Manual figures needed: [list or "none"]

## Remaining TODOs (if any)
- [items flagged by reviewer that weren't addressed]

阶段 5：论文撰写（工作流 3 — 可选）

如果 AUTO_WRITE=false（默认值），则跳过此阶段。 展示 /paper-writing 命令，供手动使用：

📝 Research complete. To write the paper:
/paper-writing "NARRATIVE_REPORT.md" — venue: <VENUE>, AUTO_PROCEED: $AUTO_PROCEED

如果 AUTO_WRITE=true：

🚦 关卡 2 — 撰写检查点：

📝 Research pipeline complete. Ready for Workflow 3.

- Venue: [VENUE]
- Input: NARRATIVE_REPORT.md
- Manual figures required: [list or none]
- Next step: /paper-writing "NARRATIVE_REPORT.md" — venue: [VENUE], AUTO_PROCEED: $AUTO_PROCEED

Proceeding with paper writing...

继续之前的检查（会场在此处确定——阶段 1-4 与会场无关）：

• 如果缺少 VENUE：当 AUTO_PROCEED=false 时，现在询问用户。当 AUTO_PROCEED=true 时，不要猜测，也不要等待——在报告和检查点中标注 “未指定会场——论文撰写已推迟”，将论文撰写阶段保留为待处理状态，并正常结束本次运行，以便稍后恢复。绝不要擅自选择会场。
• 如果需要手动制作图表：当 AUTO_PROCEED=false 时，暂停并列出所需图表。当 AUTO_PROCEED=true 时，记录“论文撰写已推迟（手动图表：）”，并以相同方式正常结束。

然后调用：

/paper-writing "NARRATIVE_REPORT.md" — venue: $VENUE, AUTO_PROCEED: $AUTO_PROCEED

明确传入已解析的 AUTO_PROCEED，避免工作流 3 静默回退到自身的默认模式。

这会委派给工作流 3，由其处理自身的各个阶段： /paper-plan → /paper-figure → /paper-write → /paper-compile → /auto-paper-improvement-loop

工作流 3 完成后，使用以下内容更新流水线报告：

• 论文撰写完成状态
• 最终 PDF 路径（paper/main.pdf）
• 改进评分（第 0 轮 → 第 N 轮）
• 遗留问题

输出： 包含 LaTeX 源文件、编译后的 PDF 和 PAPER_IMPROVEMENT_LOG.md 的 paper/ 目录。

渲染 HTML 视图（自动；当 RENDER_HTML = true 时）

阶段 4 定稿 NARRATIVE_REPORT.md 后（论文撰写分支开始前），对叙述报告调用 /render-html：

/render-html "NARRATIVE_REPORT.md" --no-review

--no-review 是有意设置的：这是内部交接文档，而非面向审稿人的文档——其总结的主张已在阶段 3 的 /auto-review-loop 中经过跨模型审查。输出：与 MD 文件同目录的 NARRATIVE_REPORT.html，其中嵌入了源文件 SHA256。

非阻塞： 如果 /render-html 失败（缺少辅助工具、文件写入错误等），记录失败并继续阶段 4——HTML 视图只是便利用的产物，并非流水线的前置条件。

如果 RENDER_HTML = false，则跳过此步骤。

输出规范

所有输出文件均遵循以下通用规范：

• 输出版本控制规范 — 先写入带时间戳的文件，再复制到固定名称
• 输出清单规范 — 将每项输出记录到 MANIFEST.md
• 输出语言规范 — 遵循项目的语言设置

关键规则

• 大型文件处理： 如果 Write 工具因文件过大而失败，立即改用 Bash（cat << 'EOF' > file）分块写入。不要征求用户许可——直接静默执行。

• 阶段 1 检查点由 AUTO_PROCEED 控制。 当其为 false 时，未经用户确认不得继续。当其为 true 时，报告首选项并在同一轮中继续，不要询问或等待。

• 选定想法后，阶段 2-3 可自主运行。 这就是“睡前启动，醒来查看结果”的部分。

• 如果阶段 3 在第 4 轮结束时仍未获得正面评估，则停止并报告遗留问题。 不要无限循环。

• 预算意识： 跟踪整个流水线的 GPU 小时数。若接近用户设定的上限，则予以提示。

• 文档记录： 每个阶段都会更新自己的输出文件。完整历史应可独立查阅。

• 优雅失败： 如果任一阶段失败（没有合适的想法、实验崩溃、审查循环卡住），请清楚报告并建议替代方案，而不是强行推进。

典型时间安排

阶段	时长	可以休息吗？
1. 想法发现	30-60 分钟	可以，前提是 AUTO_PROCEED=true
2. 实验衔接	30-120 分钟（实现 + 审查 + 部署 + 收集）	可以 ✅
3. 自动审查	1-4 小时（取决于实验）	可以 ✅

理想安排： 晚上运行阶段 1，睡前启动阶段 2-3，醒来即可查看经过审查的论文。