拿一篇 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 下载论文时先确认版本而不是只点 PDFarXiv 每篇论文都有一个编号格式类似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 源码怎么选表格里我把两种输入格式的实际差异列一下。输入格式优点缺点适合场景PDF通用所有论文都有两栏排版干扰、公式识别困难、图表位置难还原快速阅读、没有源码的老论文LaTeX 源码章节、图表、公式结构清晰需要解压编译、宏包多、图片路径乱做结构优化、生成交互网页HTML 版本已经是网页结构提取方便部分论文没有需要做全文检索时优先考虑如果源码包解压后有很多.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放原始 PDFoutput放结构化结果和最终网页。这样跑批量的失败重试也方便哪一篇卡住了直接看对应目录里缺哪个文件。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 节又翻译成“注意机制”读起来非常像两个人协作翻的。解决办法是先做术语表。从论文标题、摘要、高频词中抽取候选词人工确认翻译然后统一写到某个配置文件里。下面是一个示例片段。英文术语建议中文翻译备注attention mechanism注意力机制不要写成“注意机制”fine-tuning微调不要写成“精调”backbone骨干网络视上下文可用“主干网络”embedding嵌入表示首次出现可写“嵌入embedding”baseline基线方法如果不确定保留英文翻译前把术语表作为 prompt 的一部分喂给模型能够明显减少飘移。4.2 按段落拆按 Section 重拼翻译的输入不是全文而是按结构优化后的段落。我习惯把每个 Section 作为一个任务单元而不是把整篇论文一次提交。这样有三个好处上下文长度可控不容易截断。某个 Section 翻译质量差时只需要重新翻译这一节。可以更容易地保留标题层级因为每次翻译都知道这是在处理哪个 section。处理顺序上我建议先翻译标题和摘要再翻译每节正文最后翻译图注和参考文献。不要先翻正文再翻图注因为图注经常需要和正文术语保持一致先定好术语才更稳。4.3 章节翻译的提示词示例如果使用在线翻译 API 或大模型接口可以做一个通用提示词模板。下面是我常用的简化版本。你是一名熟悉人工智能和计算机科学的中文技术编辑。 请把下面这段论文内容翻译成中文要求 1. 保持原有章节标题层级不要重写标题编号。 2. 翻译正文时不要生成额外解释。 3. 专业术语必须使用术语表里的翻译。 4. 公式、引文编号、图表编号保持原样。 术语表 - attention mechanism注意力机制 - fine-tuning微调 原文开始 [此处放入一段原文]注意提示词里不要放整篇论文只放当前需要翻译的 section。翻译 API 会有输出长度上限放太大会导致后半部分被截断必须分段。4.4 翻译后的检查清单每翻完一个 Section我会快速检查以下几个点。检查点常见问题处理方式中英文标点英文逗号、句号混入统一替换成中文标点但数学表达内的除外数字单位单位空格被删、大小写被改保持原文格式公式编号公式被翻译成中文检查公式块是否被当作普通文本图表标题图号丢失对比原 JSON 里的 caption参考文献编号乱跳只翻译标题部分作者名不翻译这里容易踩的坑是“看起来很通顺但细节丢了”。所以我每翻完一步都会用脚本跑一遍一致性检查比如统计中文字符占比、检查是否有残留的\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 langzh-CN head meta charsetUTF-8 / meta nameviewport contentwidthdevice-width, initial-scale1.0 / title中文论文阅读页/title script typetext/javascript srcstructure.json/script /head body aside idsidebar/aside main idcontent/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 项目后改造路径大概是创建项目选择微信小程序作为编译目标。准备论文列表数据可以放在本地 JSON 或远程接口。详情页用rich-text渲染富文本内容图表标题和段落可以做成组件。在 HBuilderX 里点击“运行到小程序模拟器”微信开发者工具会自动打开。在微信开发者工具里预览、调试、提交审核最后发布。这里不展开平台审核细节因为不同时期审核要求会有变化。你要记住的是不要把别人的论文原文、作者署名和授权信息去掉。6.3 小程序版本需要砍掉什么小程序的包体积有限不适合把整篇论文的图片全部打包进去。通常的做法是只保留论文文字和章节结构。图片放到远程静态服务器详情页按需加载。公式渲染在小程序里比较复杂可以先降级成图片或者直接显示 LaTeX 原文。搜索功能可以做本地过滤不需要数据库。如果单篇论文已经做成了网页小程序版先保证“能打开、能看章节、能看图注”就够了。不需要把网页所有交互都复制过去。7. 常见问题与排查顺序7.1 arXiv 打不开或下载失败时的处理顺序前面第 2.2 节已经讲过一部分这里补充一个更完整的排查链路。先看现象是完全打不开还是能打开但下载慢。再看浏览器换无痕模式、换浏览器、清缓存。再看 DNS使用系统默认 DNS 还是自定义 DNS是否有污染。再看网络范围同一网络下手机、电脑是否都打不开。如果只是官网不稳定可以等一小时后再试。如果本地网络确实无法访问境外学术站点按当地网络规范处理不要使用任何不合规手段。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 做一遍真机预览不要只看电脑上的开发者工具模拟结果。踩过几次之后我发现很多问题不是工具能力不够而是前置材料和中间数据没有处理干净。论文结构优化、翻译、网页发布这三步每一步都要有明确的输出和验收标准。先把单篇跑稳再做批量和小程序这条路线最省时间。