过去一段时间，我一直在调整自己的科研流程。

最开始我只是把 ChatGPT 当成写作和查资料工具。后来发现，真正拖慢科研项目的，往往不是某个问题不会，而是中间过程太容易散：论文读了但没有沉淀成实验计划，实验跑了但日志不全，结果有了但写论文时又找不到它支撑哪一句话。

所以我现在更关心一件事：怎么让科研过程尽量不断线。

What changed

我现在不再把工具分开用，而是让它们围绕同一套材料工作。

Deep Research 负责把文献和 baseline 整理出来，Codex 负责靠近实验环境去跑代码，heartbeat 负责长实验期间的定期检查，论文写作 skill 负责从 repo、结果和引用里长出初稿。中间最重要的不是某个工具，而是 experiment contract、run report 和 evidence table 这些文件。

我现在大致这样做：

  • 前期用 ChatGPT Deep Research 做文献调研，重点不是“写综述”，而是整理论文表、baseline 表和实验风险。
  • 调研结束后写一页 experiment contract，把研究问题、实验矩阵、smoke test、停止条件说清楚。
  • 实验放到远程 GPU 服务器上跑，通过本机代理、反向隧道和容器代理环境变量解决服务器联网问题。
  • 在服务器容器或宿主机里安装 Codex，让它读 repo、配环境、跑 smoke test、启动实验、整理日志。
  • 长实验用 heartbeat 模式巡检，每隔几个小时看一次日志、GPU、checkpoint 和指标。
  • 写论文前先做 evidence table，把每个强结论和具体实验结果对上。
  • 最后用本机里的论文写作 skill，从 repo、实验结果、图表和引用出发生成初稿。

这篇文章不是想说“科研可以完全交给工具”。我的感受刚好相反：工具越能干，越要把边界写清楚。它可以帮你执行、整理和起草，但研究问题、实验协议和论文里的强结论，还是得自己负责。

AI research workflow loop
我现在使用的科研流程：文献调研先变成实验说明，再进入远程执行、定期巡检、证据整理和论文写作。

一、我现在最想解决的是“科研上下文丢失”

一个机器学习项目经常不是被单个难点卡住，而是被很多小断点拖住。

比如：

  • 文献调研做完了，但没有变成 baseline 矩阵。
  • baseline 找到了，但没有记录代码地址、许可证、训练成本和预期指标。
  • 实验能跑了，但 seed、config、commit、日志路径没有固定。
  • 训练结束了，但结果散在 tmux、csv、wandb 页面和临时截图里。
  • 论文写到 Introduction，才发现 claim 和实验结果对不上。

这些事情单独看都不大，但累积起来会让项目很难收束。

所以我现在会把科研项目拆成四层。

文献层 论文表、方法谱系、baseline 候选、引用候选。
执行层 环境、脚本、配置、smoke test、完整实验矩阵。
证据层 run report、metrics、figures、evidence table。
写作层 outline、draft、references、figure captions、补实验清单。

工具不是直接替我从第一层跳到第四层。它们更像在每一层之间搬运和整理材料。
真正让流程变稳的，是每一层都有明确的文件和检查点。

二、Deep Research 的结果，必须能继续往实验走

我现在用 Deep Research，不会只问：

1
帮我总结一下某某方向。

这种问法通常会得到一篇顺滑但不太能落地的综述。对科研项目来说，更有价值的是让调研结果直接服务后面的实验和论文写作。

根据 OpenAI 的帮助中心，Deep Research 可以选择数据来源、先生成 research plan、运行中跟踪进度并调整方向，最后输出带 citations 或 source links 的结构化报告。对我来说，这意味着它不只是“回答问题”，而是可以作为前期材料整理工具。

我现在的 prompt 会更具体：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
请围绕 [研究问题] 做一次 Deep Research。

这次调研不是为了泛泛综述，而是为了后续复现实验、设计 baseline 和写论文。

请输出：

1. 核心论文表
   - title / year / venue / paper url / code url
   - datasets / metrics / main claim
   - reproduction risk

2. 方法谱系
   - 按技术路线分类，不要只按时间排序
   - 每条路线解决了什么问题，又引入了什么问题

3. baseline 候选矩阵
   - 哪些方法适合作主 baseline
   - 哪些代码质量高
   - 哪些训练成本低
   - 哪些重要但不适合复现

4. 实验设计建议
   - 推荐数据集
   - 推荐指标
   - 推荐 ablation
   - 推荐 seed 数
   - 高风险失败点

5. related work 的段落结构
   - 哪些引用是主干引用
   - 哪些只是背景引用
   - 每段应该讲什么问题

调研结束后，我会把输出拆成几个文件，而不是只留一个很长的报告。

文件作用为什么要单独留下来
paper_table.csv记录论文、代码、数据集、指标、主要结论。后面写 related work 和查引用时，不需要重新翻聊天记录。
baseline_matrix.csv比较 baseline 的复现成本、代码质量和实验价值。避免只因为某篇论文有名，就把它放进主实验。
experiment_contract.md把调研结果转成可执行实验说明。这是从“读到了什么”走向“要验证什么”的关键文件。

我现在最看重的是第三个文件。调研报告回答的是“这个方向发生了什么”，实验说明回答的是“我接下来到底要验证什么”。

三、实验说明写不好，后面很容易跑偏

我以前经常犯的一个错，是太快让工具进入执行状态。比如直接说：

1
帮我复现这篇论文。

这句话看起来明确，其实很开放。它没有说：

  • 复现到什么程度算过关。
  • 哪个数据集是主线，哪个只是 sanity check。
  • 指标差多少是实现误差，差多少说明复现失败。
  • 如果环境冲突，允许修到什么程度。
  • 如果代码跑起来但结果异常，要不要继续花 GPU。
  • 哪些地方必须等我回来判断。

所以我现在会先写 experiment_contract.md。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
# Experiment Contract

## Research Question
这组实验到底想回答什么问题？

## Hypothesis
如果判断正确，应该观察到什么现象？

## Main Claim
未来论文里最想证明的一句话是什么？

## Datasets
使用哪些数据集？
下载方式、预处理方式、评价协议是什么？

## Baselines
主 baseline 是哪些？
每个 baseline 的代码来源、配置、预期指标和复现风险是什么？

## Metrics
主指标是什么？
哪些指标只是诊断，不进入主要 claim？

## Smoke Test
最小可运行实验是什么？
跑多长时间？
通过标准是什么？

## Full Run
完整实验矩阵是什么？
需要多少 GPU、多少时间、多少 seed？

## Stop Conditions
什么情况下继续？
什么情况下暂停？
什么情况下必须等人类决策？

## Logging Rules
每次实验必须记录：
- git commit
- environment fingerprint
- config
- seed
- command
- log path
- checkpoint path
- result path

这份说明不需要很长，但要具体。
它最重要的作用，是防止“实验跑起来了，但其实已经偏离原来的问题”。

我现在的经验

自动化实验最怕的不是报错。报错至少会停下来。真正危险的是训练脚本一直在跑，但数据、指标或协议已经悄悄变了。

四、服务器里的 Codex，要先读项目，再动项目

我的实验主要放在远程 GPU 服务器上跑。本机负责调研、编辑和判断，服务器负责训练、评测和长时间运行。

这里有一个很现实的问题：实验服务器的外部网络通常不稳定。GitHub、Hugging Face、Python 包、API、论文页面，都可能因为网络问题卡住。

我现在比较稳定的做法是：

1
2
3
4
5
Mac 本机代理
  -> SSH 反向隧道 / 端口转发
  -> 服务器宿主机端口
  -> Docker 容器代理环境变量
  -> 容器里的 Codex / pip / git / curl / Python requests

脱敏后的命令形态大概是这样：

1
2
3
4
5
ssh -N -T \
  -p <ssh_port> \
  -i ~/.ssh/<key_name> \
  -R 127.0.0.1:<remote_proxy_port>:127.0.0.1:<local_proxy_port> \
  <user>@<server_host>

容器里再统一 source 一个代理脚本：

1
2
3
4
5
export HTTP_PROXY=http://<docker_host_ip>:<host_forward_port>
export HTTPS_PROXY=$HTTP_PROXY
export http_proxy=$HTTP_PROXY
export https_proxy=$HTTP_PROXY
export NO_PROXY=localhost,127.0.0.1,.local

这一步最好写成脚本，而不是每次手动敲。
网络链路只存在于脑子里时，下一次断了就很难恢复。

我会先让 Codex 做 repo 勘察

Codex 进入服务器后，我不会立刻让它改代码或开训练。我会先让它读项目：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
你现在是这个项目的实验执行员。

请先阅读：
- README
- requirements / environment 文件
- configs
- scripts
- train / eval 入口
- 最近的 logs / results

不要立刻改代码。

先输出：
1. 项目结构理解
2. 训练入口
3. 评估入口
4. 依赖和环境风险
5. smoke test 方案
6. 完整实验矩阵建议

这一步很重要。科研 repo 往往没有产品代码那么规整，很多约定藏在路径、脚本名和 README 的一句话里。
Codex 如果没读懂项目，很容易把环境问题误判成算法问题，或者为了修一个路径问题改动核心逻辑。

五、full run 之前，我一定会先跑 smoke test

现在我不太愿意直接开完整训练。
完整训练之前，我会让 Codex 先做一个很小的 smoke test。

1
2
3
4
5
6
7
8
请先运行 smoke test：

1. 使用最小数据子集
2. 训练 1 到 2 个 epoch 或只跑固定少量 batch
3. 确认 loss 能正常变化
4. 确认 eval pipeline 能输出指标
5. 确认 checkpoint、log、result csv 都能生成
6. 不要启动 full run，直到 smoke test 报告通过

smoke test 不证明方法有效，只证明管线没有明显问题。
但这一步很值，因为很多错误越早发现越便宜。

cheap to catch 数据路径错、依赖缺失、CUDA 版本不匹配、日志没写、评估脚本断。
expensive to catch 训练三天后才发现评价协议错、seed 没记录、checkpoint 没保存。

如果 smoke test 失败，我会要求 Codex 只做最小修复。
这个阶段不适合重构，也不适合“顺手优化”模型代码。

六、heartbeat 的价值，是让实验别悄悄坏掉

长实验最难受的地方，是你不可能一直盯着它，但它又可能随时出问题。

我现在会让 Codex 进入 heartbeat 模式，每隔几个小时检查一次：

  • GPU 是否还在跑
  • 训练进程是否还活着
  • 磁盘空间是否够
  • 最新日志有没有 NaN、OOM、报错、卡住
  • checkpoint 是否按预期生成
  • metrics 是否明显异常

我会让它把每次检查归成几类：

状态含义允许动作
running训练正常进行，日志和指标没有明显异常。只更新 heartbeat 记录。
suspicious仍在运行，但 loss、指标或资源状态可疑。标记问题，收集证据，不直接写结论。
failed任务已经失败，能看到明确错误。只允许一次低风险修复和重启。
converged实验完成或已收敛。整理结果，更新 run report 和 summary 表。
blocked需要改变实验目标、协议或核心方法。暂停，等我判断。

如果用 Codex 的非交互模式，codex exec 可以接到 cron、systemd timer 或其他定时任务里。OpenAI 官方文档也把 codex exec 作为自动化入口来描述，并提醒自动化场景要妥善管理凭证。

一个最小的 heartbeat 命令可以像这样：

1
2
3
4
5
codex exec "
进入当前 repo，执行 heartbeat 检查。
请读取 logs、results、checkpoints，并更新 heartbeat_report.md。
不要启动新实验，除非 experiment_contract.md 明确允许。
"

这一步不是为了让流程看起来“全自动”。
它的价值更朴素：实验出问题时，尽量早点知道；实验没问题时，留下可回看的记录。

七、实验结果要先变成证据，再变成论文语言

我现在最看重的中间文件之一，是 evidence_table.md。

论文写作有一个很常见的问题：Introduction 里写得很强，Experiments 里支撑得不够。工具写作会放大这个问题，因为它很擅长把普通结果写得很顺。

所以我会先整理一张表：

1
2
3
4
5
| Claim | Evidence | Experiment ID | Dataset | Metric | Figure/Table | Status |
|------|----------|---------------|---------|--------|--------------|--------|
| 模块 B 提升低样本稳定性 | 3 seed 方差更小 | exp_012 | CIFAR-10 | Acc std | Fig. 3 | verified |
| 方法训练更高效 | 同等精度下 epoch 更少 | exp_021 | ImageNet | wall time | Table 2 | needs rerun |
| 消融 C 是主要贡献 | 移除 C 后性能下降 | exp_018 | xxx | F1 | Table 4 | verified |

这张表会直接约束后面的写作：

  • Abstract 里的强 claim，必须能在表里找到证据。
  • Introduction 的 contribution，必须能在 Experiments 对应到实验。
  • 找不到证据的 claim，要么降级，要么补实验，要么删掉。
  • needs rerun 的结果不能写成确定结论。
一个很实用的写作规则

先写 evidence table，再写 Abstract。不要先把故事写漂亮，再回头找实验支撑。这样很容易不自觉地夸大结果。

八、论文写作 skill 要从 repo 出发

我本机里装了几个和写作相关的 Codex skill。最常用的是：

  • 20-ml-paper-writing
  • research-paper-writing
  • paper-figure-polish
  • systematic-debugging
  • verification-before-completion

其中 20-ml-paper-writing 里有一条我非常认同的规则：不要凭记忆生成 citation。BibTeX 必须通过程序化方式获取和验证。

这条规则很重要。引用错误不是小问题，尤其是论文写作里，作者、年份、venue、DOI、结论归属都不能乱来。

我现在让写作 skill 工作时，会尽量给它完整上下文：

1
2
3
4
5
6
7
8
9
10
11
12
repo/
  README.md
  configs/
  scripts/
  logs/
  results/
  figures/
  research/literature/
  experiments/run_report.md
  experiments/heartbeat_report.md
  experiments/evidence_table.md
  references/

我会让它先输出：

1
2
3
4
5
6
7
8
9
1. 论文主线
2. 三个 contribution
3. Abstract 草稿
4. Introduction 结构
5. Method 结构
6. Experiments 结构
7. Related Work 结构
8. 需要补验证的 citations
9. 需要补跑或重跑的实验

这个过程的重点不是让它一次写完，而是让它先把“故事”和“证据”对齐。
如果它写出的 contribution 找不到实验支撑，我会先改 contribution，而不是强行把文字写得更好。

九、图表分两种：数据图和概念图

我现在会把图分得很清楚。

第一类是数据图，比如：

  • benchmark bar chart
  • ablation table
  • convergence curve
  • robustness curve
  • sensitivity analysis

这类图必须从真实数据生成：

1
2
3
4
5
raw logs / csv / json
  -> pandas 清洗
  -> matplotlib / seaborn / plotly
  -> 导出 svg / pdf
  -> paper-figure-polish 检查

这部分不能让图像模型“画一个差不多的”。

第二类是概念图，比如：

  • pipeline figure
  • method overview
  • teaser figure
  • 公众号封面

这类图可以先用 ChatGPT Images 生成草图，再做局部编辑。OpenAI 的 ChatGPT Images 帮助中心已经把它描述成可以创建和编辑图片的工作流。以前我会用 NanoBananaPro2，再通过 EditBanana 转成可编辑图；现在我更倾向于先在 ChatGPT 里把构图和风格试出来，再去 Figma、Illustrator 或 EditBanana 里修文字和矢量细节。

我的原则很简单：

  • 数据图必须可复现。
  • 概念图可以先快速试，但最终要可编辑。
  • 论文图不要只追求好看，caption 和证据关系更重要。

十、我会补上的外部工具

如果只用 ChatGPT 和 Codex，已经能跑起一套流程。
但项目稍微变复杂以后，我建议补几类工具。

工具我会用它做什么适合什么时候上
uv管理 Python 环境和依赖，把环境初始化写成脚本。服务器、容器、临时复现环境频繁切换时。
MLflow / W&B记录参数、代码版本、metrics、输出文件和实验对比。实验矩阵开始变多，只靠本地日志容易乱时。
OpenAlex / Semantic Scholar API拉取论文、作者、venue、citation 等结构化信息。需要维护长期 paper table 或验证引用时。
Snakemake把数据处理、训练、评测、画图做成可重放流程。项目不再是单个 train.py，而是多阶段实验时。

这些工具不是一开始都要上。
我的判断标准很简单：当某件事已经重复三次，并且出错会影响论文结论，就值得把它工具化。

十一、最后压成一套 SOP

如果把整套流程压成一份简化版 SOP，我会这样写：

阶段 1：调研

  • 用 Deep Research 做带来源的调研。
  • 导出 paper_table.csv 和 baseline_matrix.csv。
  • 标出主 baseline、可选 baseline 和高风险 baseline。

阶段 2：实验说明

  • 写 experiment_contract.md。
  • 明确 smoke test、full run、stop rules。
  • 明确每次实验要记录哪些信息。

阶段 3：远程执行

  • 打通本机代理到远程服务器和容器。
  • 让 Codex 先读 repo，再跑 smoke test。
  • smoke test 通过后再开 full run。

阶段 4：巡检

  • 用 heartbeat 定期检查进程、日志、磁盘、checkpoint、metrics。
  • 只允许低风险修复。
  • 需要改变研究方向或实验协议时，暂停等人判断。

阶段 5：证据整理

  • 每个实验写 run_report.md。
  • 主要结果进入 summary 表。
  • 所有强 claim 都进入 evidence_table.md。

阶段 6：写作

  • 从 repo、结果、图表、引用出发写初稿。
  • citation 先验证再写进 bib。
  • 数据图从真实数据生成，概念图可以先用图像工具打草稿。

十二、我不会放松的几条原则

工具越能干，边界越要清楚。

研究问题自己定 工具可以帮我扫文献和找 gap，但什么问题值得做，还是要自己判断。
实验协议自己过 baseline、公平性、数据泄漏、评价口径不能完全交给工具。
强 claim 自己负责 论文里的结论不是句子问题，而是责任问题。
引用必须能回查 看起来像真的 citation 不能直接用，验证不了就标出来。
权限要收紧 能重启任务，不等于能改研究目标；能修环境，不等于能改核心方法。
记录比记忆可靠 实验命令、日志、结果和结论都要落文件，不要只留在聊天记录里。

我现在想要的不是“一键发论文”。更现实一点说，我只是希望把那些重复、脆弱、容易丢上下文的工作整理顺一点，把更多时间留给问题本身。

参考与延伸阅读