企业官网建设流程全解析

拿一篇 arXiv 论文做结构化翻译并发布成中文交互网页，这件事的价值不在“能翻译”，而在“能读、能搜、能跳、能分享”。我最近用 DeMinds 这条流程把一篇英文论文从 PDF 提取、章节解析、术语翻译，做到了可以在手机浏览器里打开的中文网页，整个过程走下来最大的感受是：真正花时间的不是翻译接口，而是论文结构怎么从 PDF 变成干净数据。这篇文章适合研究生、科研助理、想搭论文阅读器的开发者，也适合正在做论文知识库的人。下面按我实际落地时的顺序拆一遍：先讲输入准备，再讲结构优化，然后是翻译和网页发布，最后把常见问题一起说完。

1. 先想清楚：这条流程要产出什么，适合谁用

1.1 真正缺的不是翻译，而是可定位的阅读结构

很多人拿到一篇英文论文，第一反应是整篇复制到翻译工具里。结果往往是：标题翻译了，图表标题没翻译；正文段落乱了，公式变成乱码；参考文献数量看着不对，想回看某个 Section 还要手动滚动很久。问题不是翻译质量差，而是输入材料的结构没有被提前处理。

所以 DeMinds 这类流程的第一步，不是翻译，而是“结构优化”。所谓结构优化，就是把一篇论文从不可编辑的 PDF，变成一份带章节层级、图表编号、公式引用、参考文献映射的中间数据。有了这份数据，翻译才能在正确的段落里工作，网页才能生成目录和锚点，后续做小程序、做知识库、做批量阅读也才有基础。

我建议你先明确一个目标：做出来的中文页面，至少应该支持三件事。

• 按章节跳转：侧边栏点一下，能到对应标题。
• 按关键词搜索：在页面里能搜到某个术语出现在哪里。
• 图表和公式可定位：图注、表注、公式编号不丢，能对应回原文位置。

如果这三个做不到，那它只是一个长网页，不是交互网页。

1.2 为什么选择 arXiv 作为起点

arXiv 是学术预印本平台，机器学习和相关领域的论文更新非常快，很多工作还没正式发表，就已经有预印本。它的好处是开放获取，没有付费墙，任何人都能下载 PDF 或 LaTeX 源码。缺点也很明显：版本不一定是最终版，排版样式不统一，部分老论文只有扫描版 PDF。

选择 arXiv 作为起点，主要因为输入可获取、可合法处理。下载、解析和翻译，只要不使用原文的署名和许可信息，并且不用于商业侵权，通常可以接受。但要注意：预印本不等于期刊正式发表版。你在网页上标注 arXiv 编号和版本日期，既是尊重来源，也方便别人核对。

1.3 DeMinds 在我这里的定位：一条从原文到网页的流水线

DeMinds 这个名字，可以直接理解成“论文理解与发布”的流程方案。它不是一个必须安装的单一软件，而是一条流水线：原文下载 → 结构解析 → 数据清洗 → 术语翻译 → 页面渲染 → 部署发布。

用这个思路做的好处是，每个环节都可以单独替换。比如结构解析可以用正则和版面分析，也可以用更强的文档解析模型；翻译可以调用在线 API，也可以跑本地模型；页面渲染可以输出静态 HTML，也可以接小程序。下面每一章，我都按这个思路拆开讲。

2. 从 arXiv 拿论文：入口、版本和输入材料准备

2.1 下载论文时先确认版本，而不是只点 PDF

arXiv 每篇论文都有一个编号，格式类似2401.01234，表示年份、月份和当月序号。访问地址一般是：

https://arxiv.org/abs/2401.01234

/abs/页面是摘要页，里面有标题、作者、摘要和版本历史。页面右侧的 Download 区域，通常会有 PDF 入口；如果这篇论文提供了 HTML 版本，也可以直接看到网页版。另一个更重要的入口是 “Other Formats”，里面通常有 LaTeX 源码包，也就是e-print.source。

我的建议是：不要一上来就下载 PDF。如果目标是做结构优化和中英文对照，优先下载 LaTeX 源码。因为 PDF 是渲染结果，版式和页眉页脚混在一起，提取章节树会很麻烦；而 LaTeX 源码本身就是结构化文本，section、subsection、figure、table、bibliographystyle这些标记都是现成的。

下载时可以给文件加上版本号：

2401.01234v1.pdf 2401.01234v1_source.tar.gz

版本号很重要。作者可能提交过 v1、v2、v3，不同版本图表和结论有差异。你做的页面最好标注清楚是基于哪个版本翻译的，避免读者拿最新版本来对比时产生误解。

2.2 打不开或下载失败时的排查顺序

如果手机或电脑上访问 arXiv 经常打不开，先不要急着怀疑网络策略。我一般按这个顺序排查。

• 先看是否为临时故障：arXiv 服务器负载高、机房网络波动，都会导致首页能打开但下载卡住。
• 再换浏览器或清缓存：浏览器插件冲突、缓存了旧的错误页面，也会让页面一直转圈。
• 检查 DNS 解析：可以尝试换一个公共 DNS 后重新访问。
• 确认本地网络是否符合访问条件：部分地区或部分校园网络对境外学术站点有访问策略，此时应该按照当地网络规范确认，不能使用任何不合规的加速工具。

如果手机端打不开，最稳妥的办法是先换到电脑端下载，再把 PDF 或网页发送到手机。或者等访问恢复后再下载。不要反复点刷新，那样很容易触发限流。

另外，如果只下载部分文件，不要重复整包下载。先看本地目录是否已经有.part文件或未解压的压缩包，能续传就续传，不能续传就重新下载整个源码包，并确认压缩包完整性。

2.3 PDF 与 LaTeX 源码怎么选

表格里我把两种输入格式的实际差异列一下。

如果源码包解压后有很多.tex文件，先找到主文件，通常是main.tex或论文标题同名文件。主文件里会通过\input{}、\include{}引入其他子文件。不要只处理一个文件，否则章节会被截断。

2.4 文件命名与本地目录规范

这一步看起来不起眼，但批量处理论文时特别重要。我习惯按下面的目录结构放：

papers/ project_name/ source/ main.tex figures/ input/ original.pdf metadata.json output/ structure.json translation.json web/

每个项目单独一个文件夹，source放源码，input放原始 PDF，output放结构化结果和最终网页。这样跑批量的失败重试也方便：哪一篇卡住了，直接看对应目录里缺哪个文件。

3. 用 DeMinds 做结构优化：把论文变成机器可读的数据

3.1 结构解析要拆成四个动作

直接对着 PDF 做结构解析，容易把摘要和作者信息混在一起。DeMinds 这套流程里，我一般把解析拆成四个独立动作，每个动作都有单独的输出。

第一，版面清洗。把页眉、页脚、页码、作者邮箱、基金项目等非正文内容去掉。PDF 提取经常把左右两栏文字混成一行，这一步必须在切分段落前处理。

第二，标题层级识别。把 Title、Abstract、Section、Subsection、Subsubsection 分别抽取。LaTeX 源码里可以直接正则匹配\section{...}；如果是 PDF，就要靠字体大小、行宽和编号模式来判断，准确性会打折。

第三，图表抽取。图片文件从figures/目录复制出来，图注从\caption{}里提取。表格如果是 LaTeX 的tabular，可以转成 Markdown 或 JSON 数组；如果是 PDF 扫描表格，自动提取误差很大，建议先保留原样。

第四，引用和参考文献抽取。正文里的\cite{}标记，需要映射到参考文献列表。很多论文使用 BibTeX 管理，可以直接解析.bib文件。

一个常见的中间数据结构是这样：

{ "arxiv_id": "2401.01234v2", "title": "原文标题", "abstract": "摘要段落文本", "sections": [ { "id": "sec-intro", "level": 1, "title": "Introduction", "content": ["第一段", "第二段"], "figures": [], "tables": [], "references": [] } ], "references": [ { "key": "vaswani2017attention", "text": "Vaswani, A., et al. Attention is all you need. NeurIPS 2017." } ] }

这份 JSON 不需要严格遵循某个固定 schema，但一定要保证每个 section 都有唯一 id。后面生成网页锚点，靠的就是这个 id。

3.2 为什么不能直接把 PDF 丢给翻译模型

很多人试过把 PDF 整个上传给翻译模型，结果经常是：开头前言翻得还行，到后面段落内容开始缺失，公式被翻译成奇怪的中文，参考文献编号全部错乱。核心原因是翻译模型对输入长度有上下文限制，同时 PDF 混合了文本、排版控制和图片，模型不是在做“翻译前的阅读”，而是在猜测哪些内容需要保留。

另外一个更隐蔽的问题是段落断裂。PDF 为了排版会把一个段落拆到不同的页，源码里也可能因为注释和换行导致句子被切开。如果不先做段落合并，翻译时就会产生大量半截句子，术语上下文不一致。

所以流程必须是：先结构化，再翻译。

3.3 图表、公式与参考文献的保留方式

图表说明要单独处理。图注不是正文，翻译时也应该单独翻译，不要混在段落里。比如原文图注是 “Illustration of the proposed framework”，翻译后是“图 3：所提出框架的示意图”。这里必须保留图号和 caption label。

公式不要翻译。LaTeX 公式里的变量名、函数名、编号应该原样保留。如果公式过长，可以用图片形式加载，或者交给支持 LaTeX 渲染的组件显示。

参考文献在网页里建议做成中英对照。英文原文保留，翻译成中文时可以只翻译“作者姓名和机构”之外的内容，比如文章标题。作者名不要翻译成中文，保持原名更利于查证。

3.4 结构优化阶段的验收标准

结构优化不是跑一次就结束。我每次会做下面几个核对：

• 章节数量是否与原文一致。
• 每个 section 的标题是否完整，有没有混入图注。
• 图片数量是否与原文一致，图片文件是否真实存在于本地目录。
• 公式编号是否连续。
• 参考文献条数是否能对上文中的引用标记。

只要有一个不一致，就不要进入翻译环节。否则翻译完再改结构，等于所有内容重新翻译一遍，成本很高。

4. 中文翻译：术语一致、段落完整、格式不丢

4.1 翻译前先定术语表

论文翻译最容易出现的问题不是语法，而是术语前后不一致。比如第 2 节把 “attention mechanism” 翻译成“注意力机制”，第 5 节又翻译成“注意机制”，读起来非常像两个人协作翻的。

解决办法是先做术语表。从论文标题、摘要、高频词中抽取候选词，人工确认翻译，然后统一写到某个配置文件里。

下面是一个示例片段。

翻译前把术语表作为 prompt 的一部分喂给模型，能够明显减少飘移。

4.2 按段落拆，按 Section 重拼

翻译的输入不是全文，而是按结构优化后的段落。我习惯把每个 Section 作为一个任务单元，而不是把整篇论文一次提交。

这样有三个好处：

• 上下文长度可控，不容易截断。
• 某个 Section 翻译质量差时，只需要重新翻译这一节。
• 可以更容易地保留标题层级，因为每次翻译都知道这是在处理哪个 section。

处理顺序上，我建议先翻译标题和摘要，再翻译每节正文，最后翻译图注和参考文献。不要先翻正文再翻图注，因为图注经常需要和正文术语保持一致，先定好术语才更稳。

4.3 章节翻译的提示词示例

如果使用在线翻译 API 或大模型接口，可以做一个通用提示词模板。下面是我常用的简化版本。

你是一名熟悉人工智能和计算机科学的中文技术编辑。 请把下面这段论文内容翻译成中文，要求： 1. 保持原有章节标题层级，不要重写标题编号。 2. 翻译正文时不要生成额外解释。 3. 专业术语必须使用术语表里的翻译。 4. 公式、引文编号、图表编号保持原样。 术语表： - attention mechanism：注意力机制 - fine-tuning：微调 原文开始： [此处放入一段原文]

注意，提示词里不要放整篇论文，只放当前需要翻译的 section。翻译 API 会有输出长度上限，放太大会导致后半部分被截断，必须分段。

4.4 翻译后的检查清单

每翻完一个 Section，我会快速检查以下几个点。

这里容易踩的坑是“看起来很通顺，但细节丢了”。所以我每翻完一步都会用脚本跑一遍一致性检查，比如统计中文字符占比、检查是否有残留的\cite{}标记。没有问题，才继续下一步。

5. 从结构数据到中文交互网页

5.1 技术方案怎么选

如果你只是处理单篇论文，最简单的方案是生成一个静态 HTML 页面。把结构 JSON 放进一个<script>标签里，用前端框架或原生 JS 渲染即可。不需要启动后端服务，也不需要数据库。

如果你打算维护一个论文库，比如几十篇论文，再考虑用静态站点生成器，比如 VitePress、VuePress，或者直接写个批量构建脚本。不要在单篇场景里引入太重的框架，否则后续维护成本很高。

我自己更推荐“先做单页，再考虑站点”。单篇页面验证的是：数据完整性、渲染逻辑、搜索逻辑、移动端适配。如果单篇都做不顺，做多篇只会更乱。

5.2 中文页面需要哪些模块

一个合格的中文交互页面，建议至少包含以下几个区域：

• 顶部信息栏：论文标题、作者、arXiv ID、版本、原论文链接。
• 侧边栏目录：从 sections 数组生成，点击跳转到对应锚点。
• 摘要区：中英对照，方便快速看内容。
• 正文区：每节正文下方可以放“原段落”折叠区域。
• 图表区：图片下方放中文图注，点击可看原图。
• 公式渲染：用 KaTeX 或 MathJax 渲染 LaTeX 公式。
• 搜索框：在页面内搜索关键词，命中后定位到对应段落。
• 参考文献区：按编号列出中英对照。

公式渲染可以放在 build 阶段做，也可以让浏览器实时渲染。如果论文里公式很多，建议用 KaTeX，加载速度更快一些。

5.3 一个最小渲染示例

这里给一个非常小的渲染思路，你可以按实际框架替换。

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>中文论文阅读页</title> <script type="text/javascript" src="structure.json"></script> </head> <body> <aside id="sidebar"></aside> <main id="content"></main> <script> const data = window.__PAPER__; // 1. 生成侧边栏目录 data.sections.forEach((section) => { const link = document.createElement('a'); link.href = '#' + section.id; link.textContent = section.title; document.getElementById('sidebar').appendChild(link); }); // 2. 渲染正文段落 data.sections.forEach((section) => { const wrapper = document.createElement('section'); wrapper.id = section.id; const h = document.createElement('h2'); h.textContent = section.title; wrapper.appendChild(h); section.content.forEach((paragraph) => { const p = document.createElement('p'); p.textContent = paragraph.zh; wrapper.appendChild(p); }); document.getElementById('content').appendChild(wrapper); }); </script> </body> </html>

这段代码只是示意，实际项目里你应该把渲染、搜索、公式渲染拆成独立函数。先跑通单篇，再考虑抽象成模板。

5.4 部署与移动端适配

页面构建完成后，可以选择多种部署方式。最简单的就是把 HTML、CSS、JS 和图片目录放到任意静态服务器上。常见选择是 GitHub Pages、Gitee Pages，或者你的个人服务器。如果你不想用外网，本地用 Nginx 或者 Python 自带的 HTTP 服务也能访问：

python3 -m http.server 8080

浏览器打开http://localhost:8080就能预览。

移动端适配要重点检查三点：viewport 是否设置，侧边栏是否会在窄屏挡住内容，表格和长公式是否有横向滚动。手机上访问 arXiv 原文往往排版错乱，所以这一步做好的中文网页，在手机上价值更明显。

6. 进阶：把论文阅读器做成小程序并发布

6.1 为什么值得做小程序版

如果你已经把一个或多个论文页面做成了网页，接下来可以考虑套一个小程序壳子。小程序在手机上打开更快，分享给同学或同事也方便，而且可以把论文列表和阅读记录都放在一个入口里。这个热词对应的“HBuilderX 开发微信小程序”路线，本质就是把网页逻辑迁移到小程序视图层。

但要注意：小程序不是每个页面都要重写一遍。理想做法是做一个论文列表页 + 一个详情页。列表页展示所有论文标题和 arXiv ID，详情页加载结构化 JSON，再渲染章节、图表和正文。

6.2 HBuilderX 做小程序的基本改造路径

使用 HBuilderX 或同类 IDE 创建 uni-app 项目后，改造路径大概是：

1. 创建项目，选择微信小程序作为编译目标。
2. 准备论文列表数据，可以放在本地 JSON 或远程接口。
3. 详情页用rich-text渲染富文本内容，图表标题和段落可以做成组件。
4. 在 HBuilderX 里点击“运行到小程序模拟器”，微信开发者工具会自动打开。
5. 在微信开发者工具里预览、调试、提交审核，最后发布。

这里不展开平台审核细节，因为不同时期审核要求会有变化。你要记住的是：不要把别人的论文原文、作者署名和授权信息去掉。

6.3 小程序版本需要砍掉什么

小程序的包体积有限，不适合把整篇论文的图片全部打包进去。通常的做法是：

• 只保留论文文字和章节结构。
• 图片放到远程静态服务器，详情页按需加载。
• 公式渲染在小程序里比较复杂，可以先降级成图片，或者直接显示 LaTeX 原文。
• 搜索功能可以做本地过滤，不需要数据库。

如果单篇论文已经做成了网页，小程序版先保证“能打开、能看章节、能看图注”就够了。不需要把网页所有交互都复制过去。

7. 常见问题与排查顺序

7.1 arXiv 打不开或下载失败时的处理顺序

前面第 2.2 节已经讲过一部分，这里补充一个更完整的排查链路。

1. 先看现象：是完全打不开，还是能打开但下载慢。
2. 再看浏览器：换无痕模式、换浏览器、清缓存。
3. 再看 DNS：使用系统默认 DNS 还是自定义 DNS，是否有污染。
4. 再看网络范围：同一网络下手机、电脑是否都打不开。
5. 如果只是官网不稳定，可以等一小时后再试。
6. 如果本地网络确实无法访问境外学术站点，按当地网络规范处理，不要使用任何不合规手段。

7.2 “背书问题”在论文阅读里通常指什么

这个词在某些场景里含义模糊。结合论文阅读流程，通常指两件事。

第一是版本核对。如果你引用的论文是 arXiv 预印本，而不是期刊正式版，别人可能会质疑你引用的版本不是最终版。解决办法是：在网页和引用列表里同时给出 arXiv ID、版本号和正式发表信息（如果有）。

第二是来源验证。作者信息、机构信息、DOI 是否真实。可以在 arXiv 版本历史里查提交记录，在作者主页或学术数据库中交叉验证。不要直接照抄某个人转载的 PDF，那可能不是原始版本。

所以“背书问题”本质上不是技术问题，而是引用规范问题。在发布页面时加上来源信息，基本就能解决。

7.3 中文页面出现乱码、公式丢失、图表不显示

如果翻译后生成的中文页面出现乱码，先看结构数据是否完整。在浏览器里打开structure.json，如果 JSON 里就有乱码，说明问题出在翻译或编码转换阶段；如果 JSON 正常，问题出在渲染层。

公式丢失通常是因为渲染组件没有加载成功。检查网络里是否有 KaTeX/MathJax 的 CDN 文件，以及公式块是否被正确标记为 raw。图表不显示，先确认图片路径是不是相对路径，图片文件是否存在。本地预览正常但部署到服务器后不显示，大概率是路径大小写问题。

7.4 手机端排版错乱

手机端最容易出现三个问题：侧边栏不收起、表格超过屏幕宽度、公式缩放异常。

最通用的处理方式是给页面加上响应式 CSS：窄屏时把侧边栏隐藏成抽屉导航，表格容器设置overflow-x: auto，公式设置为可滚动。测试时可以先用微信内置浏览器或手机 Chrome 做一遍真机预览，不要只看电脑上的开发者工具模拟结果。

踩过几次之后我发现，很多问题不是工具能力不够，而是前置材料和中间数据没有处理干净。论文结构优化、翻译、网页发布，这三步每一步都要有明确的输出和验收标准。先把单篇跑稳，再做批量和小程序，这条路线最省时间。