科研入门Q&A

可以先理解成三件事：找值得问的问题，提出解释或解法，再把得到的新知识、做法和产品交给社区。课程和比赛通常已经给定了比较明确的任务，研究还需要你判断该问什么、怎样知道答案可靠。

科研不用上那么重的滤镜。它是你可以尝试的一种事情，做过之后再形成自己的判断。

读论文、写代码，和学长学姐讨论，关注前沿研究、report 和 blog，做规划、分析结果、写作和汇报。有时一天都在查一个错误，也有时讨论后发现，原来的问题需要换一种问法。

当然可以。好奇、想解决一个问题、保研、留学、工作，或者单纯想试试，都可以成为起点。动机以后也可能变。

如果是为了升学或工作，可以想得更具体一点：想申请什么项目、什么岗位，希望在那里学到什么、做什么？研究经历能让别人看到你怎样理解问题、设计实验、分析结果和与人合作。偏开发和应用的工作，也值得通过项目、实习去接触实际需求。

一开始可能只是觉得某个 demo 很有意思。真正做起项目，才发现把问题想清楚、亲手验证想法、和别人一起讨论推进，也很吸引人。兴趣未必是一开始就有的，也可以在一次次尝试中慢慢长出来。先找一个让你好奇的东西做做看，再判断自己还想往哪里探索。

从打基础、调研、确定 idea，到具体 solid 地推进，再到最后组织写作和 presentation，都需要你亲自经历一遍，体验其中的摩擦和困难。

有了 AI 和 Agent，读论文、写代码、跑实验、整理结果确实容易了不少。但研究的摩擦并不会消失：实验结果不符合预期，方向走偏了，忙了很久才发现一开始的问题没想清楚，或者做出来的东西没有想象中有价值。你仍然需要参与其中，理解发生了什么、发现问题、调整方向，判断下一步值得做什么。让 Agent 执行是一回事，能不能提供有价值的干预、把工作做扎实，是另一回事。

可以。有些学长学姐最初就是从复现 CV 小 demo、接触 YOLO 开始的，后来也会转向 LLM、Agent 或其他方向。

一个原本只在视频里见过的效果，变成了自己能运行、能修改的东西，就足够让人兴奋，也有了继续探索的入口。你可以留意：自己更喜欢把应用做出来，还是会追问模型为什么能做到、为什么有时失败，想继续设计实验弄清楚？

挑一个 MNIST 或 YOLO 小项目试试，再拿结果和问题找人聊。把东西做出来之后的感受，会帮助你决定下一步想深入哪里。

可以。尤其有了 AI 工具，现在更容易从一个感兴趣的问题出发，边做边补基础，而不是必须先学完数学、编程、LaTeX、机器学习和深度学习，等到某个年级才开始碰研究。

碰到真正妨碍理解和推进的知识时，再认真补上。学习和探索可以结合起来。

早开始，通常意味着有更多尝试和调整的时间；晚一点开始，也不意味着失去了参与研究的机会。关键还是你现在想弄清楚什么、愿意为它做哪些尝试。

从一个现在能接触到的问题开始。英语、数学和编程都能在做中提升；遇到它们实际影响推进的地方，就认真补。

学校与资源会影响机会，可以通过校内老师、学长、开源项目和公开交流慢慢找入口。你现在的条件，用来决定下一步怎么做，不必直接拿来判定自己有没有资格。

学习的价值，是让你能够上手研究，知道自己要做什么。不需要把 Python、数学、机器学习和深度学习全部学完，才有资格联系老师。

如果基础暂时不够，但你已经认真了解一个领域，知道大家在做什么，也想清楚了下一步怎么学、怎么补，就可以大大方方地联系。带着问题回来学，理解也会更深。

只是请教一个具体问题，准备可以轻一些；如果希望加入项目，就认真介绍自己的理解、已有尝试和基本干活能力。让对方知道你能从哪里开始，也知道你还需要什么指导。

联系身边的师兄和任课老师，也可以先在 AI 的帮助下尝试论文复现、做一个小 demo。选一个具体问题，尽量把相关论文读充分，弄清楚已有工作做了什么、还想做什么，再把自己的尝试放进去看。

简历暂时空，不妨先留下别人能看到的东西：一篇 blog、一份能跑的代码、一段对问题的分析，都有价值。让自己被看到，也让对方知道你在认真做事。

先选一个能看见结果的小项目。图像分类、一个简单的工具调用 Agent，或者读一段机器人示范数据，都可以。做完留下代码、结果和几个自己的问题，再找人交流。

第一个月不必追求做出一篇论文。先真正把一个东西跑起来、改过、想过，就能更具体地知道下一步要学什么。

小红书、知乎、B 站、新智元等媒体，GitHub 的 awesome 系列，都可以成为入口。关注身边的 AI 热点和前沿方向，也用好 AI 工具，让它帮你解释陌生概念、找相关资料。

看到感兴趣的演示或介绍，再顺着它去找原论文、代码和作者。

从它想完成的事情开始。它怎样进入实际生活？做得不好的地方是什么？还没落地，又卡在了哪一步？

再回论文，看作者提出什么问题，为什么出现，怎样解决，结果怎么样。每多读一篇，试着给你对这个领域的认识加一点具体内容。

做一做就会更清楚。先知道 demo 怎么实现，再看做成它的过程中有什么困难，有没有哪一部分让你好奇、想继续探索。

如果看完发现它只在很窄的条件下成立，那就先把它当作 demo。这个发现也能帮你认识真实问题。

兴趣、导师、资源和难度都会影响一个方向能不能做下去，但它们不一定有统一的排序。

兴趣决定你愿不愿意持续追问；导师和合作者会影响你能得到怎样的讨论和反馈；数据、算力、硬件则决定很多想法能否真正试起来。热门方向有更多工作可参考，也可能竞争激烈、变化很快。难度高不一定代表更值得做，门槛低也不意味着问题没有价值。

这些条件很难一开始就全部满足。可以先看眼下接触得到什么问题、有哪些支持和资源，做进去之后再调整判断。有些兴趣，也是探索过之后才发现的。

眼界放宽，才能逐渐对一个领域有整体认识：大家有什么 belief 和思潮，前沿热点是什么，卡点在哪里，还有哪些 gap，你又能给 community 带来什么。保持开放地学习，才不容易闭门造车，困在一个小圈子的信息里。

读文章、看项目和报告，都是在建立一张研究的关系网。留意范式怎样演变、change point 出现在哪里，一个需求或 gap 被什么做法解决，又留下了什么问题。

可以，包括跨学院、跨学校和海外。先确定自己为什么想联系，至少了解一点对方的工作，再看看有没有共同认识的人可以牵线。社群、小红书、cold email 都是可以尝试的办法。

不要为了认识而认识。一次有共鸣的交流、共同的朋友和研究话题，都很有价值；把想聊和想做的事情放在前面，不必本末倒置，专门研究“怎么认识人”。

小红书等社交媒体、科研交流群、学校和实验室官网，以及你感兴趣的论文作者，都可以找。作者主页通常有 email；沿主页和 Google Scholar 看研究与合作者，也能逐渐认识这个圈子。

可以留意作者和组员中有没有本科生或刚入门的 junior，这能提供一些线索；再看是否有学生项目、公开招募，或直接问是否愿意指导本科生。

不少学长学姐愿意和认真提问的本科生聊聊，分享一些建议。至于有没有时间带项目、眼下有没有合适任务，可以在交流中进一步了解。

有时可以先约一次交流，了解彼此的规划、安排和想做的事情。第一次联系可以是请教论文里的一个问题，也可以询问有没有适合本科生参与的任务。

如果目标是进组，就直接说明兴趣、时间和目前能做的事，让对方知道这次交流需要讨论什么。

介绍你是谁、来意是什么，对什么研究感兴趣，想针对什么问题做些什么，或者希望参与什么任务。简历有就附上，经历少也不用硬凑。

不需要一开始就有漂亮履历，具备基本的干活能力、能说清自己的尝试，也很有价值。初次联系不一定就是正式面试，也可能先聊聊彼此的方向，后续有没有面试或试做，再具体讨论。

“看了您的某项工作，我对这里的问题感兴趣，自己尝试了什么，希望了解有没有可以参与的任务”，已经是清楚的来意。

可能没有回复，或者婉拒；也可能正常回复、加微信交流。和学长学姐的初次交流未必有想象中那么可怕，也不一定是很难的考核。有时聊的其实是：项目能提供怎样的指导，你能帮忙做什么，你自己希望得到什么。

有的组会让你先读论文、试做，或安排正式面试，具体再看对方的要求。没有回复，可以隔一段时间礼貌跟进一次；被拒绝了，也可以从反馈里获取一些信号，再联系其他合适的人。不需要把一次回复当作对自己能力的总评。

准备一个简短自我介绍、一两个做过或看过的东西，以及想问的问题。一般会看你对领域的基本了解、做法和认知，也有一些交流会问基础知识。

很多交流也是双方在了解：项目能提供怎样的指导，你能承担什么，你自己希望得到什么。尽量想清楚自己想做什么，把任务、指导方式和时间安排聊明白。

不会的地方照实说；如果知道怎么继续查、准备怎么补，也可以一起讲。

可以先问对方希望你侧重读懂、汇报还是复现，什么时候再讨论。

第一遍把问题、方法、证据和没懂的地方讲清楚。再往下，要看这篇论文在整个研究方向里处于什么位置，你怎么理解这个方法，如果分析或改进，可以做些什么，后续工作又是怎么做的。

还可以往外联想：其他领域是不是也有类似的 insight，它们面对的问题和这里有什么相通之处？这些联系也是阅读能带给你的东西。

可以先问有没有旁听、短期试做或阶段任务。把工作内容、反馈方式、时间、资源和预期贡献说清楚，再判断是否适合。

涉及正式加入、成果使用和署名，开始合作时就谈，比快投稿时再补容易。

直接问：平时具体和谁讨论，多久同步一次，卡住了找谁，数据和算力如何使用，这段任务预期投入多少时间。

有的组主要由博士生或硕士生带，有的老师参与更多。按对方实际安排确认，也讲清楚你的课业和时间。

先看这段合作哪里不适合：是长期没有反馈，任务安排不清楚，还是你希望研究的东西和实际工作差得比较远？如果还能沟通，可以先和直接带你的学长学姐或老师聊聊，看看能不能调整。

有些合作确实会慢慢减少交流和任务，但如果已经承担了项目工作，最好主动把进度、代码和还没完成的事情交代清楚。特别是有人在等你的结果时，不要让别人一直猜这个项目还会不会继续。

决定退出也不必把关系弄僵。一次项目合作结束之后，仍然可以保持正常交流，未来也可能再次合作。

线性代数、概率论、信息论，以及 infra，都是值得逐渐建立的基础。它们能让你更深入地理解技术的原理、理论和细节，也能为你正在做的事情提供指导。微积分、优化、编程和计算机基础，也会在实际问题里反复用到。

比如预训练的超参数、后训练的数据配比、RL scaling、CV 和 DDPM，背后都有值得继续追问的东西。做 RL，理解 policy gradient 会经常用到概率与期望；看 CNN、Transformer 的架构，会碰到线性代数、张量运算和优化；真正把模型训练、部署起来，又离不开 infra。

现在还不认识这些名字也没关系。遇到具体问题时，再找对应材料，逐渐把它们和自己的工作联系起来。

不必等一个方向的论文都读完，才打开代码。 读到一个感兴趣、条件允许的项目，就可以把阅读和运行放在一起：用作者的示例看看模型输出，对照实现理解论文，再尝试改动其中一处。很多原本不知道为什么要学的知识，会在这时变成具体问题，回头补课程也更有着落。

先看它是否妨碍你理解当前步骤或判断结果。妨碍了就停下来补；暂时只影响深入推导，可以记下，先把整体走一遍。

之后再回来补时，用现在的任务检验自己的理解。别让“以后再学”永远停在笔记里。

有了 AI，学一个新概念、看一段代码、跑起一个 demo 都比以前容易得多。Agent 可以解释，也可以直接替你执行。但便利也带来了一个很实际的问题：听懂一段流畅的解释，很容易被误认为自己已经掌握了。

比如学 TRPO、PPO、GRPO，AI 可以很快告诉你：TRPO 使用 KL 约束，PPO 用 clip 限制策略更新，GRPO 用组内相对奖励构造优势估计。听懂这些概括，和真正理解它们为什么这样设计，差别很大。继续往下，你会碰到状态和动作怎样进入计算、policy 怎样采样、目标函数和优势怎样估计、约束怎样起作用，也会想看实际训练的稳定性和 scaling 是什么样。

Attention 也是一样。看懂一张架构图、听过解释之后，再去推公式、读实现、调整超参数，才会发现原来有很多细节没注意到。真正复现过、改过，看到它怎么 work、又会怎么失败，才更容易形成自己的 observation。

更重要的是不丢掉关键的信息：你能不能解释一次实际运行，预判某个改动的影响，再根据结果修正自己的判断？如果可以，理解就在逐渐变深。

AI 可以承担越来越多代码和资料整理工作，但它不会自动把经验和判断一起交给你。数学、模型、计算机系统和实验方法仍然重要，因为它们影响你能理解什么、能看出什么问题，以及出现意外时能不能自己作出判断。

除了技术基础，讨论、表达和合作也很重要。一个结果为什么可信，一项方法为什么这样设计，实验里哪里可能出错——这些问题需要你能够和其他人讲清楚，也听懂别人的质疑。

多问 AI，也多和真实的研究者交流。让工具帮你完成事情的同时，尽量弄明白它做了什么、为什么这样做。否则任务可能完成了，但下一次遇到相似问题，你还是不知道该从哪里下手。

第一次读论文，取决于你这次想获得什么：是迅速了解一个领域，还是先明白论文是个什么东西？经典论文能让你认识领域里的重要工作，也看到一项研究怎样呈现；想进入一个方向，可以先找综述，让 AI 帮你梳理线索，再回原文看；已有任务，就先读最相关或老师指定的文章。

比如 Agent，可以沿一条线索去读：从 LLM 本身的能力，到 CoT 和 prompt engineering，再到姚顺雨等人的 ReAct，看推理怎样和行动、工具、环境反馈结合起来。接着再看多 Agent、多模态 Agent、Agent RL，以及 harness 和 skill 如何组织执行、loop 和 self-evolve 怎样利用反馈。对 RSI 感兴趣，也可以继续查它具体讨论的自我改进是什么。

这些路线会交叉，不是一代替掉一代。真正值得串起来的是：各自遇到了什么问题，为什么提出这个做法，它和已有工作有什么联系？带着这些问题读，你才会逐渐有一个领域的 overview。

先看摘要、引言、关键图和结论，弄清做了什么、为什么做、怎么做，再检查实验怎样支持这些话。

顺着这个过程，你也会认识任务、数据、baseline 和指标。

先把主要句子与概念读通。让 AI 解释术语，对照原文，也可以找作者讲解、视频和别人的笔记。

公式可以分层读：先知道各个量代表什么、这一步要完成什么，再看推导。某个公式正好是你要复现或改动的核心时，就值得认真拆开。

第一遍能讲清问题、方法与主要证据，就已经有收获。若要复现或改进，还需要进入数据、实现、推导和评价细节。

你为了什么读，就决定这一遍需要读到哪里。遇到关键疑问，留着回头验证。

飞书、Notion、Zotero、Obsidian 都可以。工具选顺手的，笔记里留下自己的疑问和联系。

几篇文章之间，可以按同一个问题整理：它们分别改了什么，比较条件有什么不同，一篇的结论如何影响另一篇。读完再写几句自己的理解，比只收藏摘要更有用。

不必先独立想出一个漂亮 idea 才能参与。跟着做已有课题，可以学一项工作怎样推进，实验怎样检查，文章怎样组织，人怎样合作。

在阅读、使用和讨论里留意自己好奇的现象，想法常常从那里长出来。

研究方向是一片领域，比如 Agent、具身或 World Model。

研究问题是其中一个具体疑问，比如 Agent 做长任务为什么容易出错。idea 是你对原因或解法的猜测；方法是把猜测落实成可以运行、可以检查的做法。

先把问题说明白，后面的模块和实验才有共同指向。

这里面有经验，也有对领域背景的熟悉。可以和更有经验的人读同一篇文章，比较你们注意到了什么。他看到的细节可能是你原本根本没想过的。比起直接记住“这篇工作有问题”，更值得弄清楚他为什么注意到这里、依据是什么。

你自己觉得好奇的地方，也可以先查一查、跑一跑。能提出一个具体疑问，再验证它，比逼自己立刻批判整篇文章更容易开始。

是否有人做过，最基本的就是调研。看相近工作的 setting、motivation 和做法细节，不能只靠关键词判断是不是重复。

你自己觉得好奇的问题，值得先去探索。但如果希望它成为一项能让别人也有所收获的研究，就要进一步追问：它能带来什么新的知识或更一般的理解？前人已经回答了哪些部分，还有什么没有解释清楚？

能不能做，也取决于资源：验证这个问题需要哪些数据、工具、算力、时间和合作？可以先挑一个小实验摸清条件。

领域里已经公认踩过的坑，可以先了解别人为什么没走通，不一定要硬刚。如果自己的初步尝试没 work，先分清是实现的问题，还是想法在当前条件下没有效果，再探索为什么。

没 work 也是信息。如果继续分析之后，发现这一层也没有得到期待中的结果，这仍然是你在这些条件下观测到的结论。把条件、过程和观察留下来，它本身也可能是发现。

从这个意义上说，没有简单的“放弃”之说：停下这条尝试，不会让已经得到的信息消失。接下来可以缩小问题、换一种解释，或把精力放到别处。

从想回答的问题往回拆：你想说明什么，需要什么证据，哪些实验能提供这些证据，还缺什么数据和 baseline。

第一阶段通常可以先读最相关的几篇文章、跑通参照、弄清评价，然后选一个小问题验证。每天的任务写到能实际动手的程度。

你需要知道改动相对什么产生了作用。结合论文读代码，也会让数据、指标和实现细节变得具体。

跑通后，对照论文的设置与结果，检查数据划分、评测、随机性和是否泄漏。打开实际输出看一看，有些错误不会从一个总分里显出来。

先写清验证的问题、预期结果，以及不同结果会怎样改变你对问题的理解。先用小规模检查流程，再决定投入更大实验。

想判断一个因素的作用时，尽量控制其他条件；如果研究的是多个因素之间的关系，就按目的设计组合实验。每次改动都要能追溯。

先查实现、数据划分和评价过程，再查比较是否公平，包括资源、配置和调参投入。

多次运行，报告波动。提升小于单次波动时，当前证据可能还不够稳，不能直接断言没效果或有效。再用合适的消融和样本分析，检查你提出的解释是否站得住。

缩小问题范围，从数据、实现、环境和评测逐步检查。把已经试过的东西整理出来，找学长或原作者请教。

确实复现不出来的情况会遇到。把条件与差异记清楚，再决定继续排查还是换参照；也提醒自己将来留下足够完整的复现信息。

比如自己试了半天到一天，已经没有新思路，就可以问。问之前先搜过、问过 AI、看过报错和文档，把自己试过什么、现象是什么整理好。

你耗一周解决的事，学长可能一句话就能点破。有时候你一直在自己的思路里打转，看到的只是自己已经注意到的那些东西；有经验的人可能发现你忽略的条件，甚至指出一开始的问题就问错了。听别人怎样看问题，弄明白他为什么这样判断，本身也是积累经验的过程。

时间只是一个参照，不必等满一天才开口。影响合作或耗费大量资源的问题，更应该及时同步。

讲清四件事：我想做什么，试了什么，现在看到了什么，我猜哪里出了问题。附上必要的环境、关键日志或结果。

尽量把问题缩到别人能看懂的一小段。

讲这段时间做了什么、得到什么认识、接下来准备做什么。没有正结果，也可以讲排除了哪些可能、现在卡在哪里、需要什么帮助。

把一两个关键结果和原始记录带上。同步得清楚，比等到有漂亮数字再出现更利于合作。

可以当场问，也可以记下来会后问。“这个词我还没理解，能用这里的例子解释一下吗”很正常。

觉得结论不对时，说清自己的理解和证据：“按这个解释，我预期会看到 A，但实验是 B，我们能一起看看吗？”

开始合作时先谈：谁负责什么、各自投入多少、目标是什么、署名怎样按贡献讨论。中途任务和贡献变了，再同步更新。

有分歧先和当事人聊，必要时找共同的指导者协调。尽量留下清楚的书面约定。

读论文时，让它解释概念、公式和背景，再回原文看依据。写代码时，让它搭脚本、查报错，核心计算和评测要理解。做实验时，让它整理记录、作图、帮助分析。

找 idea 可以拿自己的问题与它讨论，查可能的相关工作、挑解释里的漏洞。写作则用来理顺结构和句子，同时确认每个论断对应自己的证据。

要原始记录。它说实验成功了，就看配置、日志、输出和统计；它说文章支持某个结论，就回到文章对应的位置。

一个方案听起来有道理，还要设计能区分它对不对的尝试。遇到不符预期的地方，保留疑问，不急着让 AI 再给一个圆满解释。

你能把事情讲给别人，能回答为什么这样选、指标在测什么、哪里可能出问题，也更容易在条件变化后调整方案。

即使 Agent 已经跑完实验、画好了图，你还需要理解结果意味着什么，哪些地方值得怀疑，下一步该验证什么。人的参与不只是检查 AI 有没有出错，也包括发现意外、重新判断问题、决定如何推进。执行可以交给 AI，但这些判断和调整，才会慢慢变成你自己的经验。

做完后回看一次：原来怎么想，实际发生了什么，哪个判断错了，下次会先查哪里。保留一个具体例子，过段时间再看。

第一次借助 AI 写论文仍然很痛苦，但如果因此更明白实验、写作和组织推进，下次你就有了自己的参照。

公开论文、开源代码和自己的笔记，通常比较容易处理；组里没发表的 idea、数据和草稿，别人的代码，以及涉及隐私或保密约定的材料，需要先确认使用权限、团队约定和所用服务的数据政策。

帮人审稿，要单独查会议当年的规定。例如 ICML 2026区分两种审稿政策，按分配给你的政策执行；其中允许的辅助也不等于把判断和评价交给 AI。

论文写作同样先看目标会议或期刊的要求。作者要对内容负责，不能把 AI 列为承担作者责任的人；是否需要声明、哪些用法允许，按具体规定办。参考文献要逐条核对，尤其留意幻觉引用。

所谓 solid，就是你想传达的观点和做法，有足够的、与主张相匹配的实验和分析支撑，能够组织成一篇文章。写作承担的是把这些观点、证据和做法传达给读者的作用，也包括 presentation。

不必等所有实验结束才动笔。早期就可以写问题、图和结果记录，帮助自己看清还缺什么。一段讲不清，可能是句子的问题，也可能是研究本身还有东西没想清。

看一项研究好不好，重要的是它给 community 带来了什么：有没有提出值得关注的问题，带来新的 insight 和知识，或者改变大家对已有问题的理解？

新方法是一种可能的贡献，指标更高也是一种证据，但它们都需要放回问题和实验条件里看。某个 benchmark 上涨点，不一定意味着已经弄清楚为什么变好；相反，有些工作不提出新模型，却能通过仔细的分析让大家重新认识一个现象。

发表在重要会议当然有意义，说明工作经过了相应渠道的筛选，也更容易被看到。但会议名气不能代替对研究本身的判断。至于升学、评奖和成果认定，则还需要按具体学校和项目的规则来。

SCI/SCIE 是文献索引体系，常说的“SCI 期刊”与它的收录有关；期刊分区是另一层评价，别把索引和分区混成同一个东西。

CCF A 类来自中国计算机学会的推荐目录，会议和期刊有 A、B、C 分类。国内保研、评奖可能参照它，具体看学校和项目的认定。

顶会是领域内对重要会议的习惯称呼。比如 NeurIPS、ICML、ICLR、CVPR、ACL，是 AI 不同方向里经常见到的会议名字。领域评价和 CCF 目录不完全是同一件事。

Workshop 是专题研讨和交流场合。是否正式归档、能否扩展后再投、接收什么类型的工作，要看具体规定。选题合适时，也可以借这样的机会交流和获得反馈。

预印本用于较早地公开和传播研究，arXiv 是常见入口。上传 arXiv 本身不等于通过同行评审；一篇预印本之后也可能正式发表，要看它的具体版本与发表信息。

先看看自己遇到这些问题时，和刚开始有什么不同。很多当初只会问别人的问题，现在你可能已经亲自经历过了，这就是进步。

例如，第一次读论文时，你可能只能看懂作者做了什么；后来再读，你开始注意到它为什么这样设计，实验是否真的支持结论，还有哪些地方没有解释清楚。以前遇到一个问题不知道从哪里下手，现在逐渐知道怎样分析、怎样判断；以前看别人做研究，只觉得他们提出了一个厉害的 idea，现在自己经历过调研、实验、失败和讨论，也开始理解一项工作究竟是怎么做出来的。

很多变化并不是你又掌握了多少技能，而是你开始看到以前看不到的东西，形成以前没有的判断。

这些变化不会因为暂时没有论文而消失。当然，如果一项工作没有完成，仍然值得弄清它停在了哪里、留下了什么，以及以后是否还有继续的可能。

先看看当前遇到的究竟是什么问题：是最初的假设不成立，实验一直无法支持判断，还是数据、算力、时间和协作条件发生了变化？这些情况需要的处理并不一样。

如果问题仍然值得研究，但现有条件做不了，可以先缩小范围，寻找更容易验证的一部分；如果已经反复检查，证据也不支持原来的想法，可以调整解释，甚至换一个问题。停下来并不会让已有的观察失去价值。

不管继续还是结束，都把做过的实验、失败的尝试、代码和还没解决的疑问留清楚。要是有人一起做，就把后续安排沟通好。决定不是凭一时的正负结果，而是看继续投入还能不能获得新的信息。