AI时代的科研工作流总结

用 related_work 保存相关工作#

视频建议先建立 related_work/，集中保存与研究问题有关的论文。检索工具可以帮助寻找材料，但最终要落到自己能阅读、核对和再次定位的文件上。

检索时既要找当前问题的直接相关工作，也要理解近年的主要方法及更早的关键工作，核对它们的实验设置。这样后续复现和讨论才有依据，而不会只围绕模型即时生成的解释展开。

PDF 和 LaTeX 各有用途#

视频作者的经验是，同时保留论文 PDF 和能够获得的 LaTeX 源文件：

这里需要把经验和保证分开。并非所有论文都有公开的 LaTeX 源文件，有源文件也不意味着 AI 一定理解正确。遇到关键公式、实验数字或结论时，仍然要回到论文核对。

文献库的价值，是让研究讨论能够追溯到具体论文，而不是只留下一个看起来完整的总结。

先复现，再讨论改进#

视频建议建立独立的复现目录，选择近年重要、最好有开源代码的方法，先把它们跑通。复现过程可以帮助理解论文里不容易直接看出来的细节。

值得观察的不只是最后的指标，还包括：

• 结果可视化与论文展示是否一致。
• 实验设计和实际实现之间是否存在差异。
• 训练曲线中有没有异常或值得追问的现象。
• 数据处理方式、失败样例和方法适用条件是什么。

这些观察不一定立即成为新论文的创新点，但能把讨论从“我觉得可以改”推进到“我看到这里有一个具体问题”。复现也不能只以程序没有报错为完成标准，需要理解运行结果意味着什么。

在 brainstorm.md 中记录思路的来路#

有了文献和复现结果，再与 AI 进行头脑风暴。视频用 brainstorm.md 保存这部分讨论，让问题、假说和方法之间的关系可以回看。

我理解这里最重要的是记录推导过程：观察到了什么，为什么认为它值得研究，准备怎样解释或改进，而不只是保存最后一段漂亮的方案。

先有清晰的问题、假说和方法，再进入实验代码阶段。如果这些还没有想明白，AI 写出的代码越多，后面可能越难判断它究竟在解决什么。

建立 experiment 后，持续检查方向#

视频在明确研究思路之后建立 experiment/，开始让 AI 协助实现实验。这里强调反复核查：代码是否符合原来的想法，主要结构是否合理，有没有擅自把任务推进到另一个方向。

这也对应我使用 Codex 时遇到的问题。有时它把一个具体任务扩展成很多层分析，又不断加入术语；文字越来越多，我却越来越难确认它是否还在处理原来的问题。

看不懂实现和解释时，应当先要求它讲清楚，再决定是否继续推进。能运行的代码只是一个起点，研究者还需要理解主要步骤和判断依据。

每一版结果都要留下记录#

实验版本需要清楚命名，并保留相应代码和输出。视频用 results.md 总结每一版的方法与效果，让后续迭代能回答：这一版改了什么，结果如何，下一步为什么这么做。

如果只保存最新的一张图或一个指标，就容易忘记结果对应哪一版代码，也很难比较前后改动。

用 evaluation.md 固定测评规则#

evaluation.md 的作用，是记录统一的训练、测试和测评流程，包括使用哪些数据、哪些指标、哪些可视化和样例输出。

不同版本应当尽量在同一套测评规则下比较。如果每轮都随意改变测试数据、指标或展示方式，结果的差异就不一定来自方法本身。

当确实需要修改测评规则时，应当记录变动，并说明哪些旧结果还能直接比较，哪些需要重新测试。

DataSet 保存数据，dataset.md 解释数据#

视频中，AI 可以辅助下载数据、预处理、配置环境，以及查看表现不好的案例。这些能力仍然需要核查，尤其不能因为下载命令成功就认定数据完整、处理正确。

随着项目扩大，需要用 DataSet/ 保存数据资源，并在 dataset.md 中说明：现在有哪些数据，如何处理，文件和版本怎样命名。否则很容易在后续实验中忘记已有资源，或者重复执行同一批处理。

对于长时间下载任务，视频还强调要明确完成条件，并考虑网络失败后的重试和续传。把“把这些数据全部下载完成”说清楚，比只发出一次下载指令更容易验收。

handoff.md 记录当前进度#

视频建议在项目根目录建立 handoff.md，记录本轮完成了什么、目前到了哪里、下一步准备做什么。换会话或让另一个 Agent 接手时，先让它阅读交接记录。

这需要在自己的协作流程里明确安排，不能假定所有工具都会自动读取。交接文件也需要随工作更新，过期的记录可能比没有记录更容易让后续工作走偏。

重要进度应该留在项目里，而不只留在聊天记录中。

先整理文件，再继续堆实验#

我现在最需要解决的，是科研文件夹安排不够结构化。可以先把现有项目按文献、复现、自有实验和数据整理，再补上项目说明与交接记录。

具体整理时，我准备额外记录实验运行命令、环境、随机种子，以及结果对应的代码版本。不同版本的输出保留在独立目录里，数据处理过程也写清楚。这样以后追问某个结果时，能够找到它的来路。

把“说清楚”写进协作规则#

针对 Codex 过度思考、扩展任务和添加难懂术语的问题，我准备在项目的 AGENTS.md 里加入下面的约定：

1
先用简单语言说明当前问题和本次准备完成的具体任务。
2
每次围绕已确定的目标推进，说明这一步为什么需要做。
3
需要扩大任务范围或改变研究假说时，先说明理由。
4
优先使用项目已有的术语；必须引入新概念时，解释含义。
5
不要自造缩写或给普通操作起难懂的名字。
6
结论要对应到论文、数据或实验结果；猜测单独标明。
7
完成后记录修改、验证结果和下一步，并更新交接文件。

这段规则可以帮助我更快检查输出，也提醒我自己：如果无法解释一段代码或一个结论，就不能仅凭 AI 的肯定语气把它当作已经理解的内容。

用小步实验建立可回看的记录#

每轮开始前，先写清楚这次要验证的问题；运行后，核对实现、比较结果，把结果和未解决的问题记下来，最后更新交接。

我希望逐渐做到：打开文件夹，就能找到研究目标、已有依据、实验结果和当前进度；读完 AI 的解释，也能用自己的话说明它做了什么。

这个视频给我的启发，是把 AI 带来的便利落到可理解、可核查、可接续的日常工作上。对目前的我来说，先整理文件夹、约束表达方式，再逐步完善实验和测评记录，是值得开始的事情。

视频引用来源：Bilibili 原视频（BV1a5Mo6BEoN）。