我这篇文章从最初投稿到被Accept，前后走了一年多。中途被技术审查退回过一次，经历过两轮Major Revision和一轮Minor Revision，等系统状态栏终于变成Accept的时候，我连ScholarOne那个界面上的每个按钮都熟到可以闭眼操作。这篇记录就是把我这段完整经历摊开来讲——包括时间线、状态流转、审稿意见处理，以及那些最容易让人吃亏的细节。
先交代一下期刊。Probability in the Engineering and Informational Sciences，大家一般直接叫它PEIS，是剑桥大学出版社旗下的一本老牌期刊。它主打的是应用概率方向：排队论、可靠性建模、随机过程在工程和信息系统中的应用、通信网络性能分析，基本都归它管。如果你和我一样做的是偏理论但又贴着工程应用的概率问题，PEIS会是一个非常对口的选项。
这篇记录适合两类人看。一类是第一次投稿、对学术期刊流程还不熟的硕博生，另一类是正在考虑投欧洲系概率期刊、想了解PEIS真实审稿节奏的同行。下文里的所有经验都是从实际过程里总结出来的，很多细节你翻官网说明未必翻得到。
1. 投稿前的准备：选刊决策和稿件格式打磨
1.1 为什么最终选了PEIS
其实在正式投稿前，我在手边的几个期刊之间犹豫过一阵。做应用概率方向，通常绕不开几本期刊：Operations Research偏运筹优化，Queueing Systems更偏排队论的小圈子，而我当时的文章是随机建模在信息系统性能分析中的应用，牵头比较下来，PEIS的定位最符合——它不要求你做到纯数学那种极致严格性，重视的是概率方法在工程问题里的有效建模和分析。这对于很多"应用而优"的稿件来说，恰好是个合适的落点。
一个值得说的点是，PEIS的影响因子不算高，但在圈子里认可度很稳，而且它的审稿人群体基本是同行里真正懂行的人，很少出现外行审稿意见。我当时也考虑过投一个影响因子更高的期刊，但结合文章周期和毕业压力，最终还是选择了更对口、对方也更可能认真处理的PEIS。说到底，选刊不是选影响因子最大的，而是选最不会浪费你时间的。
1.2 模板和格式：看似简单，但最容易卡住你
投稿前，我在官网下载了当年的LaTeX模板。这个环节看起来没有技术含量，但反而是我最想提醒大家不要轻视的地方。PEIS对格式的要求包括：稿件主文件、高分辨率的图、独立的Title Page，以及投稿时需要的Cover Letter。我第一遍自己检查觉得没问题，后来被技术编辑退回，才发现还是有遗漏（这个放到下一章细说）。
关于LaTeX模板，我的建议只有一条：能用模板默认设置，就不要自己乱改。字体、单双栏、参考文献格式，都是模板写好的，改起来除了增加格式风险，没有任何收益。特别是参考文献，如果你用BibTeX，注意词条里的标题大小写，该加花括号保护的一定要加，否则遇到合成词、缩写字，排出来会很丑。
图上更容易踩坑。我投稿时有一张仿真对比图直接用Python画成了PNG，缩到300dpi看已经挺清晰，但技术编辑仍然打回要求换成矢量图（PDF或EPS）。原因是印刷排版时，位图一旦被缩放，清晰度就会下降。这里记住一个经验：凡是曲线图、示意图，一开始就用矢量格式导出来，别等到被退回再返工。
2. 提交系统的关卡：技术审查与状态流转
2.1 ScholarOne的提交流程与状态含义
PEIS的投稿系统用的是ScholarOne Manuscripts，这是投稿圈最常见的系统之一。登录后先要做的事是确认稿件类型（Research Article、Review Article等），然后依次填写标题、摘要、关键词，再上传文件。这里有一个细节我不止一次踩到：关键词部分不是随便填的，编辑分配审稿人的时候会参考它；填得越准确，文章越容易被送对口的审稿人手里，后续意见质量通常也更好。
我提交后，系统里的状态是这样流转的：
| 状态 | 含义 | 本次经历的大致周期 |
|---|---|---|
| Submitted | 稿件已提交成功 | 几小时内 |
| With Editor | 编辑正在决定是否送审 | 1~2周 |
| Under Review | 外审中 | 2~4个月较常见 |
| Required Reviews Completed | 所有审稿意见已返回，编辑综合中 | 数天到两周 |
| Decision in Process | 编辑在起草决定 | 数天 |
| Accept / Major Revision / Reject | 最终结果 | 以邮件为准 |
这个表是我根据自己这次投稿以及身边同门经验整理的，具体时效会因编辑和审稿人不同而有浮动，但总体节奏八九不离十。对于第一次投稿的人，看到Submitted之后没有立刻变Under Review先别慌，With Editor阶段花一两周都是正常的。
2.2 第一次技术审查被退回的全过程
我6月初提交的稿件，大概一周后收到邮件，标题写着"Returned for technical revision"。打开邮件一看，技术编辑列了三个问题：一是缺少作者贡献声明（CRediT statement）；二是缺少利益冲突声明；三是有一张图不符合分辨率要求，需要换矢量图。
当时第一反应是有点恼火——这些材料官网指南里都有，我提交时怎么就漏了。冷静下来才发现问题出在我太依赖系统自动检查了，ScholarOne并不检查这些"软性材料"，它们全靠投稿人自己对照checklist确认。被退回到技术上其实不亏，因为整个退回加重新提交只用了一周，不损失任何审稿时间。我重新导出了图，补上了两份声明，把文件顺序调整好，再次提交。
这里给大家一个非常实用的建议：提交前把剑桥那边的Submission Checklist逐条打印出来，对着打勾。第一次就通过技术审查的人非常多，被卡住的多半是小事，但小事也会消耗你几天时间和一次情绪。
3. 审稿期的等待：状态观察与合理催稿
3.1 从With Editor到Under Review的周期变化
重新提交后很快进入With Editor状态。编辑大约花了10天评估稿件，决定送外审，之后状态变为Under Review。当时看到状态变成Under Review，我心里其实松了口气——说明编辑认可这篇文章至少值得送审。这一步在PEIS这种期刊上并不是必然的，部分稿件会在编辑环节直接被拒，那样反而能省时间。
我这条线的大致时间线是这样的：6月5日初次提交；6月12日技术退回；6月13日重投；6月19日进入With Editor；7月中旬进入Under Review；11月上旬收到Major Revision。Under Review阶段整整持续了大概三个半月，中间没有任何状态变化。这期间我养成了一个习惯：每周六固定查一次系统，其余时间基本不看。过度刷新系统不会让审稿人快哪怕一天，只会在消耗自己的耐心。
3.2 什么时候催稿、怎么催稿
到了10月中旬，也就是Under Review已经约3个月的时候，我给编辑部发了一封询问邮件。催稿这件事很多人不敢做，怕被编辑讨厌。实际上，一封礼貌、简短、不带情绪的催稿邮件，编辑完全愿意回复。我的邮件大意是：稿件编号是多少、目前在Under Review阶段已约3个月，想确认审稿进度是否正常，如有需要补充的材料请告知。
让我意外的是，编辑第二天就回复了，说目前有一个审稿人已经交了意见，另一个还在审，让我再等等。这封回信本身就说明状态是正常的，也让接下来的等待没那么焦虑。如果你遇到审稿超过4-5个月都完全没有动静，我建议你发一封邮件询问；一般问一次就够了，频繁催促反而可能适得其反。
4. Major Revision的处理：意见分类与Response Letter
4.1 审稿意见先分类，再逐条消化
11月上旬，我收到系统通知，状态变为Major Revision。打开邮件看到PDF附件时，手确实有点抖。三个审稿人的意见，A4纸整整7页，乍一看会觉得全是问题，但冷静下来拆解后，真正必须回答的硬核问题其实没那么多。
我的处理习惯是：把意见分为三类。第一类是必须补做的内容，比如审稿人1指出定理3的证明里引理2的假设不够强，需要一个额外引理来构建完整的逻辑链；第二类是表述和结构问题，比如审稿人2认为3.2节的结果表述不够清晰，数值实验缺少可复现的参数说明；第三类是"建议项"，相当于审稿人给出了一些可以改但也可以不改的想法。比如审稿人3建议把文章的仿真部分扩展成更完整的案例研究——这确实是好事，但全文篇幅和精力有限，我选择做一个小号的补充仿真来回应。
我把分类结果发给了合作导师一起开会，先确定了硬核问题无论如何都要满足，再确定哪些"建议项"可以选择性回应。有一个细节：你永远不要试图在回复里对审稿人讲"这个问题不重要"这种话，哪怕你再觉得它不重要。正确的打开方式是先做一部分能做的，再把不能做的原因用数据和文献说清楚。
4.2 Response Letter的写作逻辑
Response Letter是整个修改过程中最关键的产物。它的格式我推荐点对点回复，即把每条审稿意见原样复制出来，标注成"Reviewer #1, Comment #1"，下面写你的回复。
回复一个意见的标准结构是：先感谢——"We appreciate this comment"；然后一句话说明你做了什么——"We have added a new lemma and revised the proof of Theorem 3 accordingly"；接着把修改后的正文内容粘贴进来，方便审稿人不用翻全文；最后如有必要，补一句"我们之所以没有完全采纳这个建议，是因为..."，并用文献支撑。
这里我踩过一个坑：修改稿里改了很多地方，但在Response Letter中没有逐一说明，导致第二轮审稿人问"我没看到3.2节改动在哪"。后来我学乖了，每一条回复中都包含两个要素：修改位置（x节x段）和修改后的原文片段。不要怕重复，审稿人一天看几篇稿件，你要让他不费力就找到改动点。
4.3 修改过程里容易翻车的细节
我这次犯的几个错，大家可以直接避开。第一，改完正文后忘记同步摘要里的结果描述，小标题里多了一个新术语，摘要却没提到；两轮修改以后摘要和正文对不上的现象很容易出现。第二，新增的参考文献编号没有更新到位，正文引用跳号。我第一次重投前就是没跑一遍完整编译，结果生成PDF里参考文献编号错位了，幸好提交前发现了。第三，图表版本没有同步更新。修改稿里我换了一版图，Response Letter也说换了，但上传时邮箱里留的还是旧图——这个错误如果不是导师提醒，可能就到审稿人手里去了。
修改稿的提交材料包括：一份高亮标记改动位置的手稿、一份干净的最终版手稿、一份Response Letter、一封Cover Letter。高亮修改处的方式我用的是蓝色文字标注新增内容，删掉的内容直接在Word里用删除线，LaTeX的话可以用\textcolor{blue}或diff样式。这样审稿人扫一眼就知道哪里动了，效率很高。
5. 第二轮修改与最终接收：最后的细节
5.1 Minor Revision：看起来轻松，但不能掉以轻心
第一次Major Revision提交后，大约6周左右收到了第二轮通知。这次是Minor Revision。打开意见一看，只剩审稿人3的几条小意见和一个编辑附加要求：补一段关于方法局限性的讨论。审稿人3的意见集中在参考文献和表述细节，没有实质性的方法问题，这让我松了口气，但同时也提醒我：Minor Revision并不意味着可以直接凑合，编辑通常是在确认你第一轮已经改得足够的背景下才给出这个级别，你需要在Response Letter里展示出"所有意见均已逐条处理"的清晰度。
这轮修改我没有动核心内容，主要调整了讨论部分的表述，补了局限性段落，然后把Response Letter写得像上一轮一样详细。大约两三周后，我再次提交。这次系统状态走得很快：Submitted → With Editor → Decision in Process → Accept。从第二轮提交到收到Accept通知，整两周。
5.2 Proof阶段的检查清单
Accept之后还有最后一个步骤：Proof。剑桥那边会发来文章校样，一般是PDF，让你在规定时间内（常见是3个工作日左右）确认。Proof阶段不能再改内容，只能改排版和文字错误，比如公式显示错误、图注错位、参考文献的页码和年份不对、作者单位拼写错误等。
校样时最该仔细核查的几处：所有作者姓名和邮箱拼写、基金资助信息编号、图表下面注释里有没有缺数字、公式是否被排版排坏。另外，校样PDF里即使只看到英文，也别忘了检查参考文献列表——我身边真的有人在校样阶段发现某篇参考文献的卷号写错了。确定无误后，在系统里确认，然后就是等在线发表。大概一周内会收到文章上线的链接。
整个流程走完，我最大的感受是：投学术期刊从来不是一锤子买卖，它更像一个项目管理的游戏。项目进度不完全由你控制，你唯一能控制的是自己每个环节的响应速度和精度。不要幻想一次投稿直接Accept，也不要把Major Revision当成世界末日——它只是说明这篇文章还有救，而且审稿人愿意花时间帮你把它改得更好。
最后分享一个小习惯：我在第二次返修时整理了一个"投稿状态备忘表"，每封邮件来了就记录日期、动作和截止时间。这个表在回写Response Letter、给导师汇报进展、以及以后总结经验时都极其有用。强烈推荐你也做一份，不用复杂的工具，一个在线表格就够了。
