企业官网建设流程全解析

1. 先把投稿这件事的性质想明白

1.1 预印本平台不是“发论文的地方”，而是“打时间戳的地方”

很多人第一次接触 arXiv 投稿，脑子里默认它是“投稿系统”，于是把注意力全放在怎么把 PDF 弄上去。这个认知偏差会让你在后面的每一步都别扭。它的本质是一个带版本管理的公开档案库：你上传的东西会被永久保存、分配一个不可更改的编号、附带 v1/v2/v3 的版本历史，然后按天批量公开。它不做同行评审，不给你录用通知，也不保证你的内容一定被收录——中间还有一道人工与自动结合的内容审核。

理解这一点之后，很多设计就顺了。为什么提交后不能立刻改？因为公告是按天批量处理的，你的稿子在队列里。为什么摘要里不能塞一堆 LaTeX 命令？因为摘要会被拿去建索引、做检索、推送到邮件列表，纯文本才跑得通。为什么分类（category）选错了后果比想象中严重？因为它决定了你的稿子公告到哪些订阅列表，选错等于把文章扔进了没人看的角落，而改分类要走一轮额外流程。

我在帮身边人看稿子的时候，最常见的一类问题不是“编译不过”，而是“编译过了，但公告出来三天才发现分类填错、作者顺序标错、摘要首字母小写”。这类错误技术上零难度，改起来却要等一个版本周期。所以这篇东西我会把流程顺序倒过来讲：先讲清楚每个动作的后果，再讲怎么点那几下。

顺带说一句适用范围。这套流程对写机器学习、物理、数学、计算生物、经济计量的人几乎完全一样；如果你是做实验方向、稿子里有大量图片和补充材料，第 2、3 节的细节会更值钱；如果你是第一次投稿、账号还没“背书”，第 4.1 节请务必先读。

1.2 动手之前，有三件事必须先定下来

第一，内容能不能公开。这一点比技术细节重要一百倍。你要确认三件事：稿子没有投给明确禁止预印本的期刊或会议；稿子里没有合作方的保密数据、未公开的专利内容、需要走内部审批的实验结果；如果有多位作者，所有人都知情并同意。我见过最尴尬的情况是，一位同学把稿子传上去，两周后导师说“这个结果专利还没报”。技术上撤稿很容易，但公开记录和缓存不是你能完全控制的。

第二，版本策略。你要上传的是“准备投出去的完整稿”，还是“一个还在改的中间版本”？我的建议是前者。预印本的信用来自“我先把想法占住”，而不是“我先把半成品发出去”。中间版本一旦公开，后面正式投稿时审稿人搜到 v1，看到的是你还没打磨完的表述，这不是加分项。反过来，如果你确实需要抢时间窗口，那就明确接受“v1 会被看见”这个事实，把摘要和引言写到能独立成立。

第三，时间窗口。平台按工作日批量公告，超过当天的截单时刻就顺延到下一个工作日，节假日还会整体停摆。这意味着你算时间不能按“提交时刻 + 24 小时”，而要按“提交时刻 → 下一个公告日”。如果某个会议的投稿截止日卡得很死，你指望预印本先挂出来作为“已公开”的证据，那就必须提前至少两三个工作日动手，别在截止前两小时上传。

2. Overleaf 上的工程结构怎么搭才不返工

2.1 一个能一次编译通过的最小骨架

我强烈建议不要在 Overleaf 里“边写边建结构”。正确顺序是：先在本地或云端建一个扁平化的目录，把所有源文件放在同一层级或只有一层子目录，然后再开始写内容。原因很现实——大部分编译失败不是 LaTeX 语法问题，而是路径问题。子目录嵌套三层、图片放在figs/chapter3/final/v2/、文件名带空格或中文，这套结构在本地能跑，上传到云端编译环境后大概率报File not found。

我自己习惯的骨架是这样的，你可以直接照着建：

paper/ ├── main.tex # 主文件，唯一入口 ├── sections/ │ ├── intro.tex │ ├── method.tex │ └── experiments.tex ├── figs/ │ ├── framework.pdf │ └── curves.pdf ├── refs.bib └── refs.bbl # 关键：一定要一起带上

主文件的导言区保持在“任何标准发行版都能编译”的水平。下面这个是我常用的最小可用模板，注意我特意避开了那些云端编译环境不一定支持的包：

\documentclass[11pt]{article} \usepackage[margin=1in]{geometry} \usepackage{amsmath,amssymb,amsthm} \usepackage{graphicx} \usepackage{booktabs} \usepackage{hyperref} \usepackage{url} \usepackage{microtype} \graphicspath{{figs/}} \title{A Study on Something Reproducible} \author{A. Author \and B. Author} \date{\today} \begin{document} \maketitle \begin{abstract} 这里写摘要，纯文本，不要塞命令。 \end{abstract} \input{sections/intro} \input{sections/method} \input{sections/experiments} \bibliographystyle{plain} \bibliography{refs} \end{document}

这份模板看着朴素，但它有一个极大的好处：换任何一台机器、换任何一次编译，结果都一样。投稿阶段你要追求的是确定性，不是排版花活。

2.2 图片、字体、参考文献这三处最容易出问题

图片。首选矢量格式（PDF），因为它缩放不失真、文件小、云端编译稳定。如果是位图，300 dpi 起步，别用截图工具直接截一张图塞进去——那种图放大之后在审稿人屏幕上就是一团糊。还有一个隐蔽的坑：某些绘图工具导出的 PDF 内嵌了系统字体，而编译环境没有那个字体，PDF 能上传但排版会错位。解决办法是导出时选择“嵌入字体”或“转为轮廓”。

字体。这是云端编译环境最硬的约束。它跑的是 pdfLaTeX，不是 XeLaTeX 也不是 LuaLaTeX。也就是说，任何依赖fontspec、xeCJK、系统字体加载的写法，在这里都会直接失败。如果你需要中文，正确做法是把中文字体文件一并打包、用CJK宏包配合 pdfLaTeX，或者干脆把中文内容控制到最少。更省事的思路是：正文用英文，中文只在附录或图表注释里出现，并且提前做一次完整的云端编译验证。

参考文献。这是新手翻车率最高的一处。很多人习惯了本地“点一下编译，BibTeX 自动跑”，于是只上传.bib。一旦云端编译环境对 BibTeX 的调用顺序或版本有差异，结果就是满屏的[?]。我的做法是永远手动上传.bbl文件，让编译器直接读已经展开好的条目。这样即使云端不跑 BibTeX，参考文献也是完整的。

另外，.bib文件本身也要清理。如果你从 Zotero 或 EndNote 导出一个几百条的大库，里面有未发表草稿、有带内部备注的条目、有重复条目，全部打包上去，等于把一份混乱的素材库公开展示。正确做法是只保留被\cite实际引用的条目。

# 用 bibexport 或 bibtool 抽出真正被引用的条目 bibtool -x main.aux -o refs_clean.bib # 编译流程：pdflatex -> bibtex -> pdflatex -> pdflatex pdflatex -interaction=nonstopmode main.tex bibtex main pdflatex -interaction=nonstopmode main.tex pdflatex -interaction=nonstopmode main.tex

四次编译看着笨，但它能把交叉引用、参考文献、目录全部收敛。用latexmk -pdf main.tex更省事，它会自动判断需要跑几轮。

2.3 云端编译日志该怎么读

编译失败时，别急着改代码，先把日志从头看到尾。日志里真正有用的信息只有几行：

一个实操心得：日志里第一个报错才是真凶，后面几十行基本都是连锁反应。很多人从最后一行开始找，越找越乱。

3. 上传前的自检：把“编译通过”变成“提交无误”

3.1 一次彻底的目录清理

本地能编译，不代表压缩包里干净。你项目目录里大概率躺着.aux、.log、.out、.toc、.synctex.gz、.bbl的旧版本、main.pdf、备份文件main.tex~、还有早就不用的图片。这些文件一起打包，轻则让包体积膨胀，重则让编译器读到一个过期的.aux然后引用错乱。

我用一条命令做清理，每次提交前跑一遍：

# 在项目根目录执行，删掉所有中间产物 latexmk -C main.tex 2>/dev/null rm -f *.aux *.log *.out *.toc *.synctex.gz *.fls *.fdb_latexmk rm -f *~ .DS_Store find . -name "*.bak" -delete # 重新完整编译一次，确保 .bbl 是最新的 latexmk -pdf -interaction=nonstopmode main.tex

清理完再重新编译一遍，这一步别省。我踩过的坑是：删了.aux之后忘了重跑 BibTeX，.bbl还是上一版，结果上传后参考文献少了两条，公告出来才发现。

打包时用 zip，压缩包里顶层直接是main.tex，不要套一层文件夹。这一点很关键，很多“上传后找不到主文件”的报错就是因为多套了一层目录。如果你确实用了子目录，确保入口文件能被自动识别——最保险的办法是把主文件命名为main.tex或ms.tex这种约定俗成的名字。

3.2 那些比编译更容易填错的元数据

文件只是载体，真正决定“别人怎么找到你”的是元数据。下面这几项，我按重要程度排给你。

摘要这一项值得单独说。它不是“论文摘要的复制粘贴”。检索系统会对它做分词、去停用词，所以你要把领域关键词自然地放进去，而不是全堆在最后一句。另外，摘要里不要出现\cite{}、\ref{}、自定义宏，也不要写公式。我见过写$O(n\log n)$的，结果索引里显示成乱码。

分类选择这件事，我的经验是：去看你引用的那三五篇最相关的文章，它们公告在哪个分类，你就选哪个。别凭感觉。如果你的工作横跨两个领域，主分类选“投稿量适中、审稿人更可能看到”的那个，交叉分类补上另一个。数量上别贪，交叉分类多了会被当成“广撒网”，反而降低可信度。

另外还有一类字段容易被忽略：报告编号、期刊参考、DOI。如果你的稿子已经投出去了或者已接收，这些信息填上会让读者一眼看懂状态，避免有人误以为这是重复发表。没投就留空，别编。

4. 提交流程逐步拆解

4.1 账号、背书与“为什么我点不了提交”

流程从注册开始。填邮箱、机构、研究领域，然后你会进到一个提交入口页面。这里有个第一道门槛：背书机制。某些分类对新账号是限制的，你需要一位在该分类下有过投稿记录的人给你一个背书码，你填进去之后才能提交。

如果你的账号暂时提交不了，先别怀疑系统坏了。看一下分类选择页面有没有提示。如果是背书问题，正确做法是找合作者或者同领域熟人，让他们在个人后台生成一个码给你。这个过程本身不复杂，但要提前几天打招呼，别在截止前两小时发现缺码。

另外一个常见卡点是许可协议。平台会要求你选择一个发布许可并确认分发权限。这一步只有一次点击，但含义是：你授权平台永久保存并公开分发这份稿件。默认的非独占许可对绝大多数人够用；如果你希望他人能更方便地复用（比如允许演绎），可以考虑更开放的选项。不确定就选默认，别在这里纠结太久。

填完许可，进入文件上传页。这一步支持两种模式：上传单个.tex让系统自动生成 PDF，或上传一个 zip 自包含包。我建议永远用 zip，因为单文件模式隐藏了太多不确定性——图片怎么处理、参考文献跑不跑、宏包从哪来，你都没法控制。

4.2 文件上传、编译校验与 PDF 复核

上传之后系统会自动编译，产出预览 PDF。这个环节有三件事必须做。

第一，逐页翻一遍生成出来的 PDF，不是翻你本地的版本。云端编译的结果和本地可能有细微差别：字体替换导致的行距变化、图片缩放比例、表格跨页断开、参考文献格式差异。我遇到过最无语的一次是本地排版正常，云端因为某个包的版本差异把最后一页的参考文献全挤成了竖排单列，看起来像没排完。

第二，看编译日志。系统一般会提供日志入口，即使编译“成功”也要扫一眼有没有 warning。常见但不致命的 warning 包括 overfull hbox（文字超出边界）、字体替换、缺失字符。轻微的可以放过，但如果出现LaTeX Warning: There were undefined references，说明引用没收敛，必须回去重新编译、重新打包、重新上传。

第三，核对页面上的元数据。系统会尝试从.tex里自动抽取标题和作者，抽取结果经常是错的——多作者被合并成一个、LaTeX 命令混进标题、特殊字符变成问号。你要手动改回来，一个字一个字改。这一步花三分钟，能省掉后面一轮版本更新。

全部确认无误后点最终提交。提交后进入审核队列。这个阶段的稿子有两个可能：被正常公告，或者被退回要求修改（常见原因是分类不合适、内容不符合收录范围、格式问题、疑似重复）。被退回不是灾难，按提示改完重新提交即可，但要留意时间成本。

4.3 提交之后：版本、替换与撤回

稿子公告出来，你的编号就固定了。之后的所有修改都走替换流程：上传新文件、填写替换说明、等待公告。编号不变，版本号递增，旧版本依然可访问（这一点很多人不知道，以为替换会把旧版覆盖掉）。

替换说明要写清楚改了什么。别写“fixed some typos”这种含糊表述，写成“v2: 修正表 3 的数值单位，补充附录 B 的证明，更新参考文献 [12]”。读者和审稿人看到清晰的版本记录，信任度会高一截。

撤回是另一种操作，它会留下公开记录，说明“此稿已由作者撤回”，但编号和标题仍然可查。所以撤回不是“删除”。如果你的稿子有实质性问题需要彻底下架，走平台提供的正式渠道说明情况，而不是自己反复替换。

还有一个时间上的常识：公告日和提交日之间通常隔一个工作日。周末和节假日不公告。如果你在周五下午提交，大概率要等到下周一或周二。这不是系统慢，是批量处理的节奏。

5. 常见问题与排查实录

5.1 编译类问题：按这个顺序排查

下面这张表是我这些年帮人看稿子时整理出来的高频问题，按出现频率排序。用法是：先定位现象，再按“最可能原因”那列验证，最后执行处理动作。

再补两个不写在表里的经验。其一，别在最后一刻换模板。有人看中一个漂亮的会议模板，提交前一晚换上去，结果所有\ref断掉、图表位置全乱。模板要在写作初期就定。其二，大表格用图片。如果一个表有十几列，无论如何都排不进单栏，那就把它渲染成矢量图插进去。审稿人看得清比“可编辑”重要。

5.2 流程类问题：那些不属于技术范畴的坑

流程上的问题往往更让人抓狂，因为它不给你报错，只给你沉默。

“我提交了，为什么搜不到？”先看是否过了公告时间。公告是批量的，不是实时的。再看审核状态，如果还在等待审核，那就是还没放行。最后看分类——如果你的主分类很小众，检索默认排序可能把你排在很后面，用标题精确搜索能确认到底在不在库里。

“作者顺序标错了怎么办？”只能走替换，重新提交正确的作者列表并填写说明。这个操作不影响编号。所以我的建议是：提交前把作者列表打印出来，让所有作者逐个确认拼写和顺序，特别是姓名中间名缩写、姓氏大小写、是否有变音符号。变音符号在元数据里最容易丢。

“能不能先传一个版本占位，之后再更新内容？”技术上可以，实际上不建议。原因在第 1.2 节说过：v1 是公开可见的。如果一定要这样，至少把标题和摘要写到位，因为这两项决定了别人第一眼看到什么。

“稿子被退回了，会不会影响以后投稿？”单次退回不会留下污点，按提示修改再提交就行。真正需要注意的是重复提交同一份被判定不符合范围的内容，那才会被认为是在浪费审核资源。

“已经投给期刊了，还能传预印本吗？”这取决于期刊或会议的具体政策，你必须自己去查那份政策原文，不要听二手转述。有些明确允许，有些要求在特定时间之后，有些完全禁止。这一条没有通用答案。

“合作者在国外，署名单位怎么填？”单位名称要用完整、规范的官方英文写法，别用缩写或俗称。多个单位用上标编号对应。这一项填错的代价是后续所有引用你的文献都会显示错误单位。

5.3 几件我希望当初有人早点告诉我的事

第一件，把“提交”当成一次正式发布，而不是一次上传。上传只是动作，发布意味着这份东西会被索引、被引用、被检索、被长期保存。所以那些“反正后面能改”的想法，在预印本场景下要打个折扣——改是能改，但改的成本比你想的高，而且旧版本永远在。

第二件，给自己留一份“提交快照”。我在每次成功提交后，会把当时的 zip 包、生成的 PDF、日志、以及填过的所有元数据（标题、摘要、分类、作者列表）复制到一个带日期的文件夹里。理由很简单：半年后你要做替换，需要知道 v1 到底长什么样；或者有人质疑某个表述，你能立刻翻出原始版本。这件事花两分钟，价值极高。

第三件，摘要值得单独打磨三轮。第一轮写清楚做了什么，第二轮塞进领域关键词，第三轮删掉所有无法被纯文本承载的符号。很多人把摘要当成论文摘要的缩写版，其实它更像一条“检索广告”：读者在几百条每日公告里扫过去，只有标题和摘要的前两句会进入视线。

第四件，别在提交当天做任何有风险的操作。不要升级宏包、不要换编译器、不要重装环境、不要清理你不确定的文件。提交日只做两件事：编译、上传。所有优化留到下一个版本。

第五件，找一个没看过你稿子的人读一遍生成出来的 PDF。不是读内容，是读“能不能看懂这是什么”。预印本的读者大多数不会读全文，他们靠标题、摘要、第一张图、第一张表来判断要不要点进去。如果这四处有一处让人困惑，你的曝光就少了一半。

最后分享一个我自己一直在用的小检查：提交前把生成出来的 PDF 在手机上打开，缩到最小，看还能不能一眼分辨出结构。如果缩略状态下只剩一团灰色文字、看不出哪里有图哪里有表，说明你的版面密度太高，读者在列表页预览时也不会有兴趣点进来。这个检查方法很土，但比任何排版规范都直观。