§0 写作起因 & TL;DR
写这篇文章的起因很简单：我在 Twitter 上看到一个帖子，标题是"全网最完整 AI 科研终极指南"。点进去被浪费了人生的 5 分钟。
作者显然就是把几篇文章丢给 ai，自动化的生产出一篇垃圾。流程图画得花里胡哨，工具列表也罗列得无比齐全，从文献检索到论文生成一条龙，看完让人觉得 AI 做科研这件事已经被彻底解决了。但凡真正用 AI 跑过一整套深度学习实验的人，都知道这篇东西有多离谱：它把科研最难、最脏、最痛苦的那部分，直接用漂亮的方框和箭头抹平了，就好像这个世界有一条通往成功的路，没有任何分叉和转折，AI 就在那条路上一直往前走。
既然这种文章都有人点赞、有人收藏、有人转发，那我干脆也写一篇，把我自己踩过的坑、踩出来的经验，原原本本分享出来。
我是 TOP10 的 CS PhD 在读，发过 CVPR、ICCV、ICML、NeurIPS 等顶会，也担任过基本上所有主流顶会的审稿人。我有能力判断 AI 产出的东西到底有没有基本科研质量。
我用的主力模型是 Claude Opus 4.6、GPT-5.4 xHigh，以及 Gemini 3.1 Pro。我强烈不建议任何人拿低智能模型去做任何形式的科研探索，那纯粹是在浪费生命。
我目前订阅了 Claude Max 20x、两个 ChatGPT Pro、五个 GPT Plus、Gemini 家庭组 Ultra，还有 Super Grok。每个月 Claude 的额度基本能烧完，其中一大半都砸在了 research 上。这些订阅不是为了炫富，而是想证明：我真的把这套 workflow 从零搭起来、反复迭代过 N 次、真实跑通过，而不是看两篇教程就跑来分享。
Paper2Code、Sakana AI 的 The AI Scientist、Oh My Research、Hermes research skill，以及市面上能找到的各种"自动化科研框架"，我基本都 clone 下来对比过。结论很残酷：这些通用库对你真正发出一篇有价值的工作，几乎没有任何帮助。
注意，我不是说 AI 做科研没用，而是说"开箱即用的 agent system"没用。你必须根据自己的领域、自己的方向，去定制一套真正属于自己的 workflow。如果你连调试系统、控制上下文的能力都没有，指望一个现成的 agent 就能产出高质量科研成果，那基本是做梦。制造垃圾的话，其实连 agent 都不需要，一篇迭代过十几次的垃圾并不比 GPT 一键直出的垃圾高贵到哪里去。
至于什么"AI 互相 review""多元模型投票""多轮 loop 改论文"……这些听起来很高级、拍脑袋想出来的"科研 skill"，在我看来大多是伪需求。你自己丢给 Claude 两个小时就能迭代出三版，比 clone 那些别人的 skill 高效得多。
但这篇文章也不是什么"AI 科研终极指南"，我没有能力写出任何形式的指南，除了深度学习我什么都不会，因此所有经验完全针对深度学习的科研工作流。其实深度学习我也不怎么会，这只是我个人在使用过程中的一些经验和教训，写出来希望能对你有帮助，哪怕只有一点点。
最后，在我不断迭代这套系统，写这篇文章的过程中，有一个认知越来越清晰：
Context Is All You Need
被污染的上下文会崩溃式地影响模型的能力。AI 一直修不好一个 bug，不一定是它没有这个能力，而是它的上下文已经被彻底带偏了。后面这篇文章里你会看到的所有设计、所有踩坑、所有我最终选择的方案，背后其实都只在做一件事：管住每一个 session 的上下文。
§1 什么叫 AI 做科研
在开始聊具体流程之前，我必须先把一件事讲清楚：我所说的"AI 做科研"，到底指的是什么。
如今网上大量所谓的"AI 科研教程"，本质上只是在教你如何让 AI 生成一篇"看起来像论文"的东西。流程跑通，PDF 输出，排版精美，再让几个 agent 互相 review 一番，表面上无可挑剔。但那根本不是科研。
我认为，AI 真正参与科研，至少要守住以下底线：
整个过程不允许任何形式的造假。所有结论必须有明确出处；提出的 idea 与最终实现的 method 能够完全一一对应；实验的每一个结果，都是由真实代码训练得出的直接产物，任何人按照论文中的方法描述，都能复现代码、跑出一致的结果。
做不到这些，你用 AI 产出的就不是科研成果，而是学术垃圾。而且是带着 AI 高精滤镜、看起来更精致、但污染性更强的垃圾。
我把这一点放在最前面，正是因为后面你将看到的整个 workflow 设计，核心目的从来都不是"让 AI 写得更好看"，而是在严格确保：它提出的 idea 是真正被验证过的，实验是真正跑出来的，论文是真正可复现的。
这件事比大多数人想象的要难得多。但我认为它值得去做。因为它指向一个更长远的愿景：未来显卡资源的分配，应该分成三个方面：一部分用于训练更强大的基础模型，一部分用于日常 inference，还有一部分，应该交给每一个具体领域，让 AI 去探索那个领域的智力巅峰，不断推动学科向前。
而这个愿景能够成立的唯一前提是：AI 做出的科研，必须是真实的。
如果连结果的真实性都无法保证，那整条路从根子上就走不通。
§2 流程概览
我全程使用多个模型协作。Claude、GPT、Gemini 各有明显优势，让它们交叉 review，其实就是一种形式的 ensemble。Ensemble 基本在任何场景下都能无痛提点。尤其是这几家模型是完全不同知识不同方式分别训出来的，知识覆盖范围、思考模式以及幻觉倾向也不尽相同，利用他们各自强大的地方以及交叉 review 在整个 workflow 非常重要。具体模型之间怎么调用、怎么交互，后面单独一个 section 讲。
一篇深度学习论文从零到投稿，流程大概是这样：文献调研，确定 baseline，复现 baseline，提出 idea，实现 idea，跑实验，分析结果，写论文。
这个流程不是一条直线走到底的。从"提出 idea"到"分析结果"这几步是循环的，idea 实现了发现不 work，跳回去重新想；结果有苗头但方法有问题，跳回去重新改。一篇论文定稿之前，这个循环往往会重复多轮。甚至，这些 idea 本身也不重要，重要的是在这个 idea 实验中的探索，以及拿到结果的分析，这些才是真正有价值的能帮到你的东西。一个 idea 直接拿到一个好的实验结果并不是最好的科研，这个 idea 也不属于你，真正经过探索拿到的结果才输于你。(From Saining Xie)
§3 文献调研
文献调研这件事，只要接了正确的工具，Agent 一定是比人强的，因为他的窗口知识量以及阅读速度比人强大太多了，它能在很短的时间里扫过大量论文，覆盖面远超你自己一篇一篇翻。但怎么让它搜到真正相关的东西，还是值得展开讨论一下。
我最早试了好几条路线。第一个想法是把能接的 MCP 全接上，arXiv、Hugging Face、Web Search，认为知识源越多覆盖面应该越大。但事实上基本很难搜到有价值的相关文章，我自己找到的相关论文都比这种方式找到的好。第二个想法是接 Zotero，因为 Zotero 里存的是我自己读过的论文，想让它把这些当作第一信息源，优先从我已有的知识库里找。Zotero 那条路回头想想就是个蠢主意，你自己读过的论文首先基数就在那里摆着，完全不足以充当 idea 来源，此外他们没有任何理由应该拥有更高的权重，该搜到什么不该搜到什么，应该由研究问题本身决定，而不是由你的阅读历史决定。
后来我把文献调研单独交给了一个 scout agent，底层用 Gemini CLI。原因很简单，Gemini 的搜索能力是目前所有模型里最强的。在交付搜索任务的时候，不需要你自己去拆关键词，Claude 在分派任务时天然就会把需求转化成结构化的描述交给 Gemini，Gemini 也会很自然的把结构化的需求拆解成多角度的搜索。这个是我在他们交互的过程中 thinking 的过程中看到的。另外我在搜索流程里加了一个约束：让 Gemini 重点关注中了顶会以及附带有开源代码的工作。因为后续不管是 review idea 还是选 baseline，论文的收录会议级别和有没有代码都是值得作为一个因子来调整我们的判断。
论文搜索到以后怎么进入模型的上下文也是值得展开讨论的。不管是 Claude 还是 GPT，你把一篇 PDF 丢进去，很多时候它不会真的从头读到尾。它会略读来回答你的问题，只有当你追问、而它发现自己答不上来的时候，才会回去再读一遍。而且一篇论文动辄三四十页，全塞进上下文窗口，不光浪费 token，还会稀释真正重要的信息。上下文里无关内容越多，模型注意力越分散。
所以我目前的做法是：如果能拿到 LaTeX 源文件或者 Markdown，就直接喂原文，不走 PDF。arXiv 上大部分论文都能拿到源文件，这条路是通的。Markdown 的好处是可以按需读，需要摘要就喂摘要，需要方法就喂方法那一章，不用一次性把整篇论文塞进去。在调研阶段，其实只需要读摘要和 introduction 就够了，你只是在判断这篇论文跟你的方向有没有关系，不需要在这个阶段就去看实验细节。
最后想强调一点，很多人觉得文献调研不重要，让 AI 自己想 idea 就好了。这恰恰是最大的误区。文献调研的本质是在给大模型构建一个领域专家级别的上下文。你拥有一个深耕某个方向的专家上下文，还是一个什么都知道一点但什么都不深的通用上下文，想出来的 idea 质量差距是巨大的。巧妇难为无米之炊，如果调研阶段搜到的论文就是一堆不相关的东西，那基于这些东西想出来的 idea，看着头头是道，但经不起任何推敲。
§4 确定 Baseline
Paper2Code 尝试过在没有 baseline 的情况下直接从论文生成代码，效果自然很不理想。这也符合真实的科研现状，极少数科研是从零开始写一套全新的代码，绝大部分都是基于某个 baseline 展开的。因此在开始讨论 idea 之前，一定要先确定好我们要做的 setting 和 baseline。
§5 复现 Baseline
复现 baseline 是整个 workflow 里最容易被低估的一步。
很多人以为复现只是为了"验证别人论文"，其实不是。复现的真正价值，是为你后续所有实验建立一个可靠的锚点，你的 idea 到底有没有提升，必须放在同一个框架下才能看得清清楚楚。
我最开始觉得有开源代码复现应该是一件不太困难的事，但是实际真正去做会发现他成功率并不高，很多时候即使成功也不是按照你期望的方式成功。
出错的方式包括但不限于：pip 装到一半报错，进程直接卡死，主线程不轮询一直等待。另外 Claude 有一个让人崩溃的操作，调用 bash 等各种工具都要调 sleep 等，一个几秒钟就能解决的错误，硬生生耗掉半小时。数据集下载也是一样，第一秒可能就因为网络波动挂了，但模型根本不知道，继续在那儿假装一切正常。另外我有好几台服务器，很多常用数据集其实早就下好了，路径也清清楚楚写在文档里，可 AI 压根不会主动去读那个文件，每次都从零开始重新下载，即使我明确写了数据集 GPU 使用文档并且放在 CLAUDE.md 的索引路径要求下载数据集/环境等之前必须读。
后来我尝试加监控：要求每一步必须实时反馈进度，卡住必须立刻报警，下完必须做指纹校验确认版本正确。但即使这样，在国内服务器、代理、网络不稳定的加持下，至今依然没有一次能做到完全稳健。他只会背着你偷偷继续 sleep 然后等你问他为什么没有根据 instruction 的时候和你说抱歉。
还有两个容易被忽略的点。
第一，复现这种任务不要在主线程里跑。在主线程跑一方面会把安装报错、下载日志这些东西全部灌进上下文，污染后续的对话质量；另一方面你会被卡在前台干等，明明可以并行处理的事情变成了串行阻塞。交给 sub-agent 或者 exec 去做，主线程只负责收结果。
第二，远程服务器上跑任何东西，一定要用 tmux，不要裸 SSH。SSH 断一次连接，整个进程就没了，之前所有的等待全部白费。
最终我得出的最现实结论是：最稳、最省心的做法，还是你自己先把环境搭好、数据下好，或者是 human in the loop 地看着它正确做完，再开一个新的 session 把干净的路径直接甩给模型。避免这种无休止的上下文污染和隐形时间黑洞。
§6 提出 Idea
有了 baseline 和足够的文献积累以后，下一步是提出 idea。
我最早的做法是直接让 Claude 基于调研结果去想 idea。但是显然以 Claude 的智力很难提出有 novelty 的 idea，此外它一个人既搜又想又评，上下文里混着调研笔记、论文摘要、它自己之前被否掉的想法，越到后面想出来的东西越飘，而且它会不自觉地往自己之前的思路上靠，跳不出去。在实现的过程中也会由于各种 idea 的混淆出现各种幻觉。
后来我改成让 Gemini 来做发散，因为这几个大模型的使用过程中比较明显的体感是，Claude 是几家模型中智力最低的，而 Gemini 虽然幻觉严重，但是我个人使用中经常能发现他提出一些让我有点吃惊的开脑洞的 idea，而且他的搜索能力和知识量应该是大于其他两家模型的，因此我考虑让他来广泛的提出 idea。Gemini 拿到的上下文只有文献调研的结果和 baseline 信息，它不知道之前有过什么讨论、什么想法被否过，所以能从一个干净的起点去想。一次生成大概 10 个 idea，每个 idea 带一段简要描述。
10 个 idea 出来以后，交给 Codex 做独立 review。因为 review 这件事需要的是严格的智力判断，Codex 在上下文确定的情况下给出判断是比较令人放心的。而且关键在于上下文隔离：每一个 idea 是单独评估的，Codex 拿到的上下文只有 follow 的那篇 baseline paper 加上当前这一个 idea 的描述，它看不到其他 9 个 idea，也看不到 Gemini 生成时的讨论过程。这样至少能保证评审过程是公平的，不会因为看到了别的 idea 而产生偏好。
review 的维度包括：novelty 够不够、技术上是否可行、跟 baseline 的兼容性怎么样、实现复杂度是否可控、以及预期能带来多大的提升。每个 idea 评审完以后会生成一个 idea card，包含各维度的评分和 Codex 的判断理由，同时给出一个明确的判定：go、revise 还是 kill。最后根据 ranking 选出得分最高的。
选出来以后，交给 Claude 拍板。Claude 作为主 architect，不是直接选了就走，还要回头看 Codex 的意见，如果 Codex 给的是 revise，Claude 需要判断是否采纳修改建议，把 idea 调整到位再继续推进。
确定以后，这个 idea 再交给 Gemini 做一次针对性的文献调研，专门搜这个方向上有没有已经做过的工作、有没有可以打磨润色的空间。通过这一轮验证的 idea，才正式进入实现阶段。
这个过程我试过很多策略，包括让 Gemini review、让 Claude 和 Codex 互相 review。最后放弃了所有"互相 review"的方案。原因很简单：只要让两个模型互相审，它们永远能告诉你"还能怎么改进"、"还可以从哪个角度优化"。这个过程没有终局。一定要有一个角色来做最终决定，而不是让它们无休止地互相照应。
而且这样的流程下，最终选出来的 idea，一定是三个模型共同认可当前上下文中综合情况更适合的 idea。
Research Contract
但在真正进入实现之前，还有一件必须做的事：写 research contract。
在动手写任何代码之前，先把所有预期写清楚：hypothesis 是什么，什么结果算成功，什么结果算失败，每个 ablation 预期会看到什么。失败信号要独立写，不是"没达到成功"的反面。
为什么要这么较真？因为如果你不在实验之前把这些确定，模型一定会在结果出来以后帮你合理化。跑出来的数差了一点，它会告诉你"虽然主指标没达标，但从另一个角度看这个结果其实揭示了一些有趣的现象"。做科研最忌讳的就是先看到结果再编故事。
contract 写好以后，后面所有角色都以它为唯一的尺子。写代码的要严格对照里面的超参、metric、数据 split 来实现，有偏差不能自己决定，必须回来问。评审结果的时候先读 contract 再看结果，逐条判定每个信号是达标还是没达标。写论文的时候，每一条 claim 必须能对应回 contract 里的某个信号和对应的实验数据。
而且 contract 一旦写好，实验开始以后不能改。如果确实需要修正，产出一个 v2，写清楚改了什么、为什么改。不允许事后调整 success signal 去配合结果。
未完待续……