这篇文章是我应该在入学第一天就知道，但是一直到毕业才后知后觉意识到的一些东西的记录。如果你看到了这个，那么有很大概率这里写的大部分东西你都已经知道了。Anyway，希望这些过时的经验能对你在某些方面查缺补漏。
在做任何事情之前，首先要问自己三个问题：
做这件事的目的是什么？
事情的受众是谁？
最后要交付什么？
目的决定方向。它帮助我们判断哪些工作是必要的，哪些只是形式上的补充；哪些内容应该深入，哪些内容可以简化。目的不清楚时，人很容易陷入“做了很多事”，但不知道这些事是否真正有用。
受众决定表达方式和评价标准。同一件事，面对不同对象，重点、语言、细节程度和呈现形式都可能不同。想清楚受众，才能知道应该让对方理解什么、相信什么、使用什么，以及对方会用什么标准判断这件事是否完成得好。
交付物决定完成边界。它帮助我们把抽象任务落到具体结果上，明确最后应该留下什么、达到什么状态、让别人拿到之后能够做什么。交付物不明确时，事情就容易无限延伸，既难以推进，也难以收尾。
做事的过程中如果能想清楚这三个问题，就能更好的判断应该做什么、不做什么、做到什么程度，从而避免无用功，把精力放在真正有价值的部分。
Python里有一个著名的 import this:
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
它是一组代码设计的原则。好的代码应该看得懂、能判断、能修改、能复现。代码里的每个模块、每个函数、每个变量，都有自己的目的和功能，都要让其他人理解他为什么存在、负责什么、和其他部分是什么关系。
自己 coding 的能力在目前可能远没有之前那么重要了，AI 可以帮我们写很多代码，甚至快速生成一些看起来完整优美的项目。但这并不意味着人对 coding 的理解不重要了，反而意味着对人的要求变高了——如果你想提升自己的 coding 能力的话。
从我比较过时的视角来看，有 AI 的帮助你可以不用自己写每一行代码，但你要具备以下的能力：
知道自己要做什么
把模糊需求拆解成清晰任务/模块/功能
理解代码框架/原理
判断代码是否实现了目标
发现代码中的错误和风险
理解项目结构
项目维护、更新和多人/AI协作
coding 是一种直接训练人需求分析、总体架构、边界控制、意图表达能力的方式。有了好的 coding 能力，相似的思想也可以用在处理其他复杂任务上。
类似地，比如说你要搭个模型，模型的结构和你的任务是息息相关的。如果你的目标是尽可能高的性能，那么在数据的筛选上可以精益求精，同时模型的复杂度和非线性度可以提高。如果你的目标是做一个深度的可解释的模型，那么相应的就要牺牲一点性能，降低模型的复杂度和非线性，这样相对来说模型就更好解释一点。
在数据的筛选上，比如说你想要涵盖一些 MHD 不稳定性，那么可以随便放两道磁探针；如果你想要尤其找到某个位置特定的变化，或者某种特定的模式，可能要根据你的需求筛选几道合适的磁探针，而后根据你筛选的通道特点，用正确的结构去做特征提取之类的。这个多的不说了，核心就是按目的去做事情，有指向性的去做数据选择和模型设计，不是越多越全越复杂越好的。
我相信看到这篇文章的人，大多并不缺少工作量。你可能已经有了算法上的改进、具体的应用场景、大量的实验设计，以及还不错的结果。这些都是写好文章、达到毕业条件的必要条件，但并不充分。
因为你的所有工作，最终都必须通过某种形式展示给别人。别人不会自动理解你做了什么，也不会天然知道你的工作为什么重要。你需要把自己的工作组织成一种别人能理解、能评价、能认可的形式。
这一部分最关键的点在于受众。
不同受众的知识背景、评价标准和关注重点是不一样的。小同行对背景、问题和技术细节比较熟悉，也更容易理解你的工作难点，因此可以更多侧重场景设计、方法细节、实验设置和结果对比。而大同行，尤其是在交叉领域里，可能并不清楚你的具体背景和问题意义。如果前面的引导不够，即使后面讲了很多细节，读者也可能不知道你到底解决了什么问题、结果说明了什么、这项工作有什么意义。
因此，写作时不能只站在自己的角度罗列工作，而要站在读者的角度组织理解路径。你要先把问题讲清楚，再把方法讲清楚，最后让结果自然支撑你的结论。
在研究生阶段，基本上有几个场景是比较常见的：
Presentation 的核心是让听众在有限的时间内抓住主线，最重要的是节奏和重点：先让听众知道你要解决什么问题，为什么这个问题值得解决，再讲清楚你的基本思路/直觉、关键结果和最终结论。
做 Presentation 时，要始终记住听众的注意力是有限的。每一页 PPT 最好只服务于一个核心信息：这一页想让听众记住什么，就把它明确地写出来。图表不是装饰，而是用来支撑这个核心信息的证据；文字也不是越多越好，而是要帮助听众快速理解图表和结论。
因此，PPT 的每一页都应该能回答一个问题：这一页存在的目的是什么？听众看完或听完这一页，应该带走什么信息？PPT 结构上的每一部分、每一部分里的每一页，都应该有明确的逻辑关系。就像“契诃夫之枪”，每一个素材都应该有它的作用，前面埋下的伏笔要在后面得到呼应。
PPT 在制作上要尽量做到“图文并茂”，以简单清晰的图、表、流程图和结构图为主，配合少量必要文字。每一页都应该用比较醒目的方式标出关键结论，让听众即使没有完全听清讲解，也能大致知道这一页想表达什么。同时，基本的排版、美观和一致性也很重要，因为它们会影响听众对内容专业性的第一印象。
同一套工作可以根据 Presentation 的场合和时间进行不同层次的展开。5 分钟的汇报重点是讲清楚问题、方法直觉和结论；半小时的报告则可以展开背景、方法细节、实验设计和结果分析。要准备的是一套可以根据受众和时间裁剪的表达框架。
小论文的核心是把一个相对完整的问题写成一条相对清晰的证据链。要在小论文里回答：针对什么问题，提出了什么方法，为什么这个方法合理，实验结果如何证明其有效，这项工作相比现有工作有什么价值。
写小论文时，我非常推荐在初稿阶段参考 Nature 系列文章的写法。当然，这里不是说格式上必须完全照搬某个期刊，而是参考它对文章表达的约束：摘要要短，主图要少，正文要集中，Methods 可以展开，但主线必须清楚。
可以给自己设置一些限制：
摘要控制在 150-200 词
全文章节分：Introduction, Methods, Results, Conclusion/Discussion
全文除 Methods 字数不超过 5000 词
全文主要图表不超过 10 个，每一个图表都服务于一个明确的方法/结果/结论
补充材料可以写一点细节，但正文能够独立讲清楚故事
这些限制很大程度上会强迫你在写作过程中做一些必要的取舍和精炼语言/结果/结论，最终给出一个精炼、清晰的主线，读者也更容易看懂你的核心贡献。
在写论文的全过程中，可以提早、反复强调论文的核心思想/直觉/结论。在摘要、Introduction、Results、Conclusion里，都体现论文的主要结论。尤其是Results，讲故事的时候甚至可以不按照“实验设计——实验结果——结论分析”这样的线性逻辑，读者很可能没有耐心等你把所有细节铺完再理解结论，因此可以把核心结论适当前置，作为实验结果和分析的起点，再用后面的实验和图表去支撑它。有了一个预设，读者也更容易自己跳进图表里去找对应的支撑。
接下来一个很关键的是审稿人意见。审稿意见一定要认真回应，但不一定每一条都要无条件照做。比较稳妥的方式是：能改的尽量改，不能改或不适合改的，要解释清楚原因，并给出合理依据。回复审稿人时，态度要尊重，逻辑要明确，最好逐条回应，不要回避问题。我的个人风格是能顺着改就尽量顺着改，包括补实验；但这不代表所有意见都必须机械接受，关键是让审稿人看到你认真理解并处理了他的关切。
相比小论文，大论文是对研究生阶段所开展工作的高度凝练总结，需要把已有工作组织成一个完整的研究体系。与小论文不同，小论文更多强调一个具体问题的创新和验证，而大论文更加强调整体逻辑、章节关系、研究脉络和工作量呈现。它要让读者看到：研究对象是什么，主要挑战是什么，几项工作分别解决了什么问题，工作之间有什么逻辑关系，最后共同支撑什么结论。
大论文在掌握套路之后会好写很多。尤其对交叉领域来说，评审专家有概率是大同行。在工作量足够、成果比较丰富的情况下，他们未必会对每个技术细节追问得很深，但会对文章的结构、逻辑、表述和规范性要求比较严格。你需要向他们证明：你不仅做了足够的工作，也接受过基本的科研写作训练，能够把几年工作组织成一篇逻辑清楚、结构完整、表述规范的学位论文。这一部分因为我吃的亏比较多，所以篇幅会略长一些。
2.3.1 标题
标题里要能体现研究对象、核心问题和主要方法，不要太大，也不要太空。标题太大，后面正文很难支撑；标题太小，又显得工作格局不够。一个比较稳妥的标题应该让读者在看到标题时，大致知道你研究的是什么对象，面对什么问题，采用什么技术路线。一种常见的大论文标题可以是：基于<方法>的<研究对象> <问题>研究。
其中，<方法>对应你的主要技术路线，<研究对象>对应你的具体应用对象或研究场景，<问题>对应你真正想解决的核心问题。需要注意的是，标题里的每一个词都最好能在正文里被充分支撑。如果标题里写了某个方法，正文就要体现这个方法为什么是核心；如果标题里写了某个对象，正文就要围绕这个对象展开；如果标题里写了某个问题，全文就要持续回答这个问题。否则标题和正文就会脱节。
2.3.2 摘要
大论文的摘要是一个非常精炼、格式化的部分。但如果不知道基本套路，不是很容易写好。总的来说，摘要要做到让大同行能看懂，小同行觉得没乱写，评审专家能快速抓住贡献。按我毕业时的评审反馈和修改经验来看，一个比较稳妥的博士论文摘要可以按下面的方式组织。
摘要全文 1000-1200 字（约到第二页的 1/3-1/2，如果超过 1/2 则过长）
摘要尽量不要出现“本文”、“本工作”
第一段讲清楚研究背景和意义，约 7–8 行，同时自然引出本文的主要工作；
第二至第五段分别概括主要工作和贡献，不建议直接使用“1、2、3、4”编号，而可以使用“首先、其次、再次、最后”等表达串联
每一段主要工作可以参考以下句式：“针对 <问题>，提出 <方法> / 建立 <模型> / 设计 <框架>，实现 <量化指标>，获得 <结论或意义>。”
最后一段总结全文工作及其意义，回到论文的总问题，说明几项工作共同支撑了什么结论。
摘要的核心是把全文的研究逻辑讲清楚。第一段负责交代背景和总问题，中间几段负责说明各项工作如何分别解决问题，最后一段负责收束全文贡献。读者看完摘要后，应该大致知道这篇论文研究什么、为什么重要、做了哪些工作、取得了什么结果、形成了什么结论。
需要格外注意的是两点：背景和量化指标。
第一是背景。摘要里的背景不需要从盘古开天地开始论证研究背景和课题来源，否则会显得冗余，而且抓不住重点。更好的方式是从大同行更容易理解的角度切入，用简洁、具体、可感知的信息说明课题的意义和必要性。以破裂预测为例，没必要从磁约束聚变、托卡马克、破裂的三大危害、破裂缓解等一整套背景逐层引出。这些内容我们自己很熟悉，但对大同行来说可能反而看得云里雾里。可以更直接地从量化的经济损失、装置安全或运行风险等角度说明破裂的危害，再引出破裂预测的必要性。
第二是量化指标。量化指标能够有力地帮助大同行在不了解具体背景的情况下，大致判断工作的意义和效果。一类量化指标可以放在背景里，用来说明问题本身为什么重要；另一类量化指标可以放在各项工作中，用来说明你的方法相比类似场景下的已有工作，或者相比自己的 baseline，取得了多少提升。
2.3.3 目录
目录是最容易被忽视的部分，但实际上在评审过程中非常关键。我自己的论文在院审阶段就卡在过“目录不适宜”这个问题上。
评审专家在通读大论文之前，通常会先看题目、摘要、目录和全文格式。目录是论文整体结构的外显。它决定了读者对全文框架、研究内容和逻辑关系的第一印象。一个目录如果看起来混乱、重复、空泛，即使正文里有工作，也会让评审专家觉得论文组织能力不够。
这里有几个比较容易踩雷的点：
某一章/节标题和论文标题大面积重复
章/节标题不能体现核心方法
章/节标题缺乏逻辑递进，看不出章/节之间的联系
章内每节内容与章标题对不上，如章标题是“A、B与C”，实际上小节的内容只写了“A、B”或小节顺序是“A、C与B”
标题风格不统一
比较稳妥的做法是：每一章标题都要能体现这一章解决的核心问题和采用的主要方法；每一节标题都要服务于章标题，并且能体现本节在本章中的作用。章与章之间最好能形成递进关系，节与节之间最好能形成清楚的展开顺序。
检查目录时，可以逐级问自己几个问题：这章在全文里承担什么任务？这一节为什么放在这一章下面？这一节和前后节是什么关系？如果只看目录，读者能不能大致理解我的研究主线？
好的目录应该让人不看正文，也能大致看出论文的研究对象、技术路线、章节关系和工作重点。
2.3.4 绪论
绪论是全文的引入，主要完成几件事：说明研究背景与意义，梳理相关研究现状，总结现有研究存在的问题，并自然引出本文的研究内容和技术路线。绪论写得好不好，很大程度上决定了读者是否能理解后面几章为什么要这么展开。
需要注意以下几点。
首先，研究背景与意义要控制篇幅，尽量不要超过 5 页。背景部分的作用是说明问题为什么重要，而不是把领域知识从头讲一遍。写得太长会显得冗余，也会冲淡后面真正重要的研究问题。对于交叉领域，背景尤其要从大同行能理解的角度切入，用简洁、具体、必要的信息建立研究意义。
其次，相关研究综述应该占第一章的主要篇幅，但切忌简单堆叠文献。综述不是把已有工作按时间顺序列一遍，而是要围绕本文研究问题进行组织。可以先列举若干相关研究，说明该方向已经发展到什么程度；再选取几项代表性工作进行较详细分析，指出它们解决了什么问题、采用了什么思路、仍然存在哪些不足；最后再进行总结归纳，为后面提出本文问题做铺垫。
再次，存在的问题应该从现有研究中自然总结出来，而不是凭空提出。最好做到“问题”和“研究内容”一一对应：前面指出的每一个关键问题，后文都应该有相应章节或工作去回应。同时，几个存在的问题之间也要有逻辑关系，不能只是并列罗列。它们可以是递进关系、层次关系，也可以是同一个总问题下的几个子问题，但一定要让读者看出为什么本文需要开展后续几项工作。
最后，全文逻辑关系框图非常非常非常重要。这张图不是装饰，而是帮助评审专家快速理解整篇论文主线的工具。框图里最好包含：研究背景、关键问题及其逻辑关系、主要工作及其核心方法、各项工作之间的递进关系，以及最终形成的成果，例如算法、模型、框架或系统。对于交叉领域的大论文，这张图尤其重要，因为它能帮助大同行在不完全熟悉技术细节的情况下，快速把握你的研究对象、问题链条和工作结构。
写绪论时，可以始终记住一个目标：让读者在读完第一章后，知道这篇论文为什么要做、前人做到哪里、还差什么、本文准备怎么解决，以及后面几章为什么这样安排。
2.3.5 创新点
创新点基本上可以参考摘要的写法，“针对 <问题>，提出 <方法> / 建立 <模型> / 设计 <框架>，实现 <量化指标>，获得 <结论或意义>。”
创新点的数量不宜过多，一般 3 条左右比较合适。每一条创新点都应该能在正文中找到对应章节和实验支撑。反过来说，如果某条创新点在正文里没有充分展开，或者没有结果支撑，就不适合写成创新点。
创新点难写，是因为它要同时满足几个要求：要足够精炼，不能写成一大段工作总结；要有一定宏观性，不能只是某个实验细节；要踏实，不能写成空泛口号；还要具体，能让评审专家看出来到底新在哪里、解决了什么问题、有什么结果支撑。
我自己的创新点写得不算好，所以这里没有太多可以照搬的经验。更实际的建议是：创新点一定要尽早和导师、同门或熟悉领域的人反复讨论。因为自己很容易陷入具体工作细节里，觉得每一点都重要；但评审专家真正需要看到的是，这篇论文相对于已有工作，形成了哪些清楚、可验证、能被正文支撑的新贡献。
2.3.6 图表和格式
这个也许可以算是103的家学渊源😂，众所周知103的格式问题很大，我在这里尽量写一些我注意到的格式要求：
模板尽量不要用实验室传承的，可能有问题或者不是最新的，去研究生院学位申请专区下载
下载的模板里有一些基本说明和全文中可能会出现的样式，写的时候按样式处理
模板页眉页脚颜色如果不是红色的话改成标准色红色（正数第二个）
英文字符、数字前后没有标点符号的前提下需要空一格
带百分号的数字不空格
表的初稿按照模板样式调整，如果专家有格式意见，征求教务意见后做适当调整
图的字体与正文保持一致，中文宋体，英文 Times New Roman
图中尽可能不要出现英文
图的分辨率要清晰，放大后不模糊，尽量用矢量图
在 PPT 里调整后导出的图片，可能存在透明边框，可以加一个纯白背景覆盖所有框
图的字号最大不要超过正文字号，最小不要小于正文字号的小一号
图表（图注、表注）不跨页
图表出现在首次引用位置附近
图的坐标轴、单位、图例、颜色含义要完整
公式的解释（其中，a 表示...）等与公式存在逻辑关系的文字不另起一段（无首行缩进）
图表使用交叉引用
参考文献严格按照模板给出的样式，再不济也要通篇保持一致
最后切记，格式问题不要靠最后统一抢救。从初稿开始就用模板样式、自动目录、交叉引用和统一的图表规范，否则后面会非常痛苦。
专利其实要说的不多，写一个技术交底书，然后等专利中心老师给你打几个小时电话就ok了。要注意的是在专利公开之前你的成果不要以任何形式被检索到，arxiv也不行。
专利中心的网址：http://ips.hust.edu.cn，需要教职账号登录。
打杂是搞科研不得不品鉴的一环。既然不可避免，就尽量用少的时间把不得不做的杂事处理掉。这里主要写两类比较常见的事情：报销和服务器运维。
报销的本质，是把已经产生的垫付或支出，按照财务要求报掉。这个过程中通常会涉及几类人：经费使用人、经费负责人、经办人、所里负责审核和流转材料的人，以及学校财务处。
一般流程是：产生支出之后，先确认使用哪一笔经费报销；然后按照这类支出的要求准备材料；材料准备好后交给负责审核和流转的人；后续如果财务或审核人员提出补充要求，再按要求补材料。
报销之所以容易让人没头没脑，主要是因为一开始没想清楚它的目的和交付物。其实可以简单理解为：我们要向审核人员和财务证明，这笔支出是合规、必要、真实的。所有材料，本质上都是围绕这三个点展开。
以最常见的差旅报销为例。假设我们先去 A 地开会，又去 B 地交流，最后返回武汉，那么通常会涉及几类支出：交通费、住宿费、会议注册费和差旅补助。对应需要准备的材料大致如下。
通用业务支出表：这是所里内部存档和审批用的材料，主要用于说明支出事项、使用经费，以及经费负责人是否同意使用这笔经费。
交通费：核心是证明行程闭环。最基本的要求是行程逻辑完整，比如武汉—A 地—B 地—武汉，而不是出现解释不清的断点。
住宿费：如果行程跨天，通常会产生住宿费用，因此需要住宿发票。如果因为会议安排、接待安排或跨夜交通等原因没有住宿发票，至少要有接待人和联系方式。
会议注册费：需要证明会议确实存在，注册费标准是多少，食宿是否自理。这类信息一般来自会议通知、缴费通知或会议官网。
差补：能不能报补助、报哪些补助，要看会议通知和单位财务口径。比如会议通知写“食宿自理”和只写“住宿自理”，对应的补助可能不一样，具体要按当时要求确认。
支付记录：最好使用银行卡流水或支付凭证，能看出支付时间、金额和付款账户。尽量避免使用微信零钱、花呗、余额宝等不好解释资金流向的方式。
这些材料归根结底都是为了证明：这笔支出确实发生了，和这次出行或业务有关，金额和项目是合理的，票据和支付记录能对应上。
有几个常见坑需要注意。火车票可以用 12306 的电子发票。酒店如果前台能直接开发票，通常就不需要平台订单；但如果通过携程等平台订交通或住宿，平台开的发票项目可能是“代订服务”之类，而不是交通或住宿本身，所以往往还需要订单来证明实际发生了什么服务。还有一种情况是，支付记录里的商家名称和发票上的公司名称不一致，这时可能需要对方开具说明，证明二者是同一主体或存在对应关系。
其他类型的报销也大差不差，核心都是证明支出合规、必要、真实。具体要求肯定会随经费类型、财务口径和审核人员要求变化，来回补材料也很正常。能做的就是一开始尽量把逻辑想清楚，把材料准备全，减少后面反复折腾。
服务器运维，有 AI 的帮助后，很多具体命令和排错步骤都可以边查边做，所以没有太多必要逐条写操作教程。真正重要的是一些底层原则：
改之前先备份：重要配置文件先复制一份，例如加上日期后缀；重要数据不要在没有备份的情况下直接移动、删除或重命名。
一次只改一个关键变量：不要同时改网络、服务、权限和环境变量。否则出问题时很难判断到底是哪一步导致的。
保留回滚路径：改配置前先想清楚，如果失败了怎么恢复。比如原配置文件在哪里，服务如何重启，网络断了有没有本地操作或其他入口。
记录关键操作：尤其是改网络、挂载、系统服务、驱动和数据库时，最好简单记录改了什么、为什么改、改之前是什么状态、改之后怎么验证。
不要迷信 AI 给出的命令：AI 可以帮你生成方案，但你要知道这条命令大概在做什么，影响范围是什么，失败后会发生什么。
涉及多人使用时要提前沟通：如果服务器上有人在跑任务，不要随便重启、改驱动、改 CUDA、改磁盘挂载或清理空间。
不要随手 rm -rf：删除前先 ls、确认路径、确认变量是否为空，必要时先移动到临时目录，观察一段时间后再删。
服务要有状态检查：改完之后不要只看“命令没报错”，还要确认服务是否真的起来了，端口是否正常，日志是否有异常，别人是否能正常访问。
最后再回到最开始的三个问题：目的是什么，受众是谁，最后要交付什么。很多事情看起来很杂，但只要想清楚这三个问题，就不至于完全被任务推着走。科研、写作、代码、报销、运维，本质上都是把事情做清楚，做好，合理的交给下一个人。希望这篇过时的东西能对你的研究生生涯起到一点帮助。
薛凤鸣
2026年6月24日于103
本文章使用limfx的vscode插件快速发布