process-arxiv-paper

name	process-arxiv-paper
description	处理指定的 arXiv 或类似 arXiv 的研究论文，尤其适用于中文请求。当用户给出论文标题、项目名、arXiv ID/URL/PDF/HTML 链接或已有论文目录，并表达整理、处理、收录、读一下、看一下、翻译、逐句翻译、论文库、arxiv source、源码对齐或源码伪代码等意图时使用。该工作流会保存 PDF/源码，编写忠实的逐句中文 Markdown 译文，记录 alphaxiv 上下文，查找关联代码，添加明确标注的源码辅助伪代码注释，并编写 uv/demo/evaluation 配置说明。不要用于简单的 PDF 下载/复制请求、通用文献综述、arXiv 搜索列表、投稿检查清单、无关的表格提取或无关的 GitHub/uv 重构。

处理 arXiv 论文

触发请求的解释

当用户用中文要求对一篇 arXiv 论文“整理一下”“处理一下”“读一下”或进行其他宽泛处理时，除非用户明确只要摘要或不要翻译，否则应将其视为请求执行本 skill 的完整工作流。忠实的逐句中文 Markdown 译文是必需交付物，而不是可选附加项。

硬性要求：对于任何中文论文处理请求，包括但不限于“整理”“收录”“处理”“读”“看”“分析”“梳理”“研究”“翻译”“总结一下这篇论文”，或仅在研究论文语境中给出论文标题/URL，默认交付物都必须包含全文忠实的逐句中文翻译。不得用摘要、提纲、“整理稿”、阅读笔记或选择性翻译代替完整的逐句翻译。只有当用户明确表示不要翻译、只要摘要或要求其他范围时，才可跳过或缩减翻译。如果用户同时要求“整理”和其他输出，应先完成完整的中文逐句翻译，或以其作为核心产物，再围绕它添加分析/笔记。

默认值

除非用户另有指定，否则使用以下路径：

• 论文产物：当前工作目录（用户调用任务时的 pwd）下的 ./<arxiv-prefix>[.<venue>].<short-name>。将当前工作目录视为论文工作区根目录，而不是本 skill 的安装目录。
• 源码仓库克隆：默认使用 ~/Downloads/<arxiv-prefix>[.<venue>].<short-name>。如果 ~/Downloads 不存在但 ~/downloads 存在，则改用 ~/downloads/<arxiv-prefix>[.<venue>].<short-name>。

推荐使用以下文件名：

• PDF：<arxiv-prefix>[.<venue>].<short-name>_<full-title>.pdf
• 中文译文：<arxiv-prefix>[.<venue>].<short-name>_zh.md，并在开头写入 alphaxiv URL，以及可用时的概述区块
• arXiv 源文件包：<arxiv-prefix>[.<venue>].<short-name>_source/
• 源码克隆目录：~/Downloads/<arxiv-prefix>[.<venue>].<short-name> 或 ~/downloads/<arxiv-prefix>[.<venue>].<short-name>

对于 2509.22009 和“GraphSearch”，如果不知道发表场所，则使用 2509.GraphSearch 作为前缀。按 macOS 文件名规则清理非法字符，并在 PDF 文件名中保留论文完整标题。

术语：“arXiv 源文件包”是指从 https://arxiv.org/e-print/<id> 下载的论文 LaTeX/源文件，保存在论文产物目录内的 <prefix>_source/ 中。“源码”是指论文关联的实现仓库，应放在 ~/Downloads 或 ~/downloads 下，而不是论文产物目录内。

前缀规则：

• 根据 arXiv ID 的年月生成 <arxiv-prefix>，例如 2407.12345 对应 2407，2509.22009 对应 2509。
• 根据论文标题、项目名或仓库名生成 <short-name>，使用简短易读的 PascalCase 标记，例如 GraphSearch、DiffusionForPlanning 或 AgentMemory。如果论文有公认的项目名/仓库名，优先使用它。
• 如果产物文件已经存在后才发现最终发表场所，应将添加 venue 的前缀视为一次重命名操作，而不是创建第二个论文工作区。
• 确保源码克隆目录解析后绝不与论文产物目录相同。如果默认克隆路径会发生冲突，使用 ~/Downloads/<prefix>-code，或在克隆前询问用户。

输出目录安全检查

下载或创建论文产物前，使用 pwd 检查当前工作目录，并判断它是否适合作为论文工作区根目录。

• 默认安全：用户选择的项目、笔记、研究、论文或类似工作目录；任何已经包含一个或多个已处理论文目录的目录。
• 已处理论文目录是指类似 arXiv 论文工作区的同级目录，例如名称匹配 <yymm>.<short-name> 或 <yymm>.<VENUE>.<short-name>，或包含 *_zh.md、*_source/、arXiv PDF 等生成文件的目录。
• 默认不安全：用户主目录（~）、文件系统根目录、系统/应用/配置目录；Desktop、Documents 或 Downloads 等宽泛容器目录（除非它们明显被用作论文工作区）；以及不包含类似已处理论文目录的无关源码仓库或应用项目。
• 如果当前目录不安全或用途不明确，且不包含类似的已处理论文目录，请用户确认或提供其他论文工作区目录，然后停止。用户确认前，不要下载 PDF、创建论文产物目录或克隆源码。
• 如果当前目录不安全或用途不明确，但已经包含类似的已处理论文目录，则继续执行，并将新论文产物保存为该目录下的同级目录。

已有工作与恢复行为

当用户要求继续、恢复、重命名、修复或完成一篇已经处理过的论文时，在修改任何内容前检查现有目录。

• 查找 <prefix>_zh.md、<prefix>_translation_progress.md、<prefix>_source/、已下载 PDF、配套笔记，以及具有相同前缀的源码克隆目录。
• 根据文件推断当前状态：已完成章节、待处理章节、使用的解析源、是否已有 alphaxiv 元数据，以及是否已有源码说明或 uv 指令。
• 默认从第一个未完成或可疑章节继续，而不是重新翻译已完成章节。如果现有译文质量明显有问题，应说明问题并修复受影响章节，不要静默覆盖整份文件。
• 用户要求在发现发表场所后重命名时，只有从可靠来源确认 venue 后才执行重命名。一起重命名生成的论文文件和源文件包目录；除非用户创建的笔记明显包含旧前缀的生成路径或标题，否则保留不动。
• 如果现有状态不明确，先写入或更新进度标记，再继续处理，以便下次能够安全恢复。

根据发表场所命名

• 查询 arXiv 论文是否已有最终或接收发表场所，例如会议、Workshop、期刊或期刊缩写。需要时检查 arXiv 元数据、PDF/源文件、项目页、作者主页、OpenReview/ACL Anthology/IEEE/ACM/Springer/ScienceDirect 页面及其他可靠学术索引。
• 如果找到 venue，在 arXiv 年月前缀后插入简短的 venue 标记：<yymm>.<VENUE>.<short-name>。例如会议使用 2509.ACL2026.GraphTemp，Pattern Recognition 期刊使用 2509.PR.GraphTemp。
• 对会议和 Workshop，优先使用规范缩写加年份，例如 ACL2026、ICLR2026、NeurIPS2026、COLM2025。对期刊，优先使用不带年份的标准缩写，例如 PR、TKDE、TNNLS，除非用户另有要求。
• 如果无法快速找到 venue，或只有未经证实的传闻，则省略 venue 标记，继续使用 <yymm>.<short-name>，并简要注明未找到最终发表场所。
• 在发现 venue 后重命名已有论文时，应重命名当前工作目录下的论文产物目录、~/Downloads 或 ~/downloads 下存在的源码克隆目录，以及文件名以旧前缀开头的文件。不要改写任意用户笔记，除非旧前缀出现在明显的生成路径或标题中。

工作流

1. 将论文解析到规范的 arXiv 摘要页。

   • 如果用户给出 arXiv URL 或 ID，将其规范化为 https://arxiv.org/abs/<id>。
   • 如果用户给出标题或项目名，搜索网页/arXiv，并通过标题、作者、摘要和项目/仓库链接验证匹配结果。如果仍有多个合理候选，不要猜测，应提出简短的澄清问题。
   • 如果用户只说“this paper”“这个 paper”“这个 repo”，或只给出本地仓库但信息不足以识别论文，在可用时检查附近的 README/项目元数据。如果仍无法可靠识别论文，应先索要 arXiv URL、标题或论文链接，再创建产物。
   • 记录 arXiv ID、完整标题、作者、摘要 URL、PDF URL、源文件包 URL、HTML URL，以及找到的最终/接收发表场所。

2. 下载并保存原始论文。

   • 从 https://arxiv.org/pdf/<id> 下载 PDF 到论文产物目录。
   • 尝试从 https://arxiv.org/e-print/<id> 下载 arXiv 源文件包，并保存到专用的 <prefix>_source/ 目录。如果包可用且包含 TeX/LaTeX 文件，应将其作为首选解析源。
   • 小心地将源文件包解压到该专用源目录。它可能是 .tar、.tar.gz、gzip 压缩的 TeX 文件，或其他 arXiv 支持的源文件载荷。不要将其解压到无关文件之上。
   • 在文件名中保留完整的 arXiv 标题。
   • 只有当现有 PDF 明确匹配同一 arXiv ID/标题时才复用。

3. 生成中文 Markdown 译文。

   • 如果 arXiv LaTeX 源文件包可用，优先将其作为主要解析源。解析主 .tex 文件、参考文献文件、引入的章节、图片路径、图注、表格、算法、公式、标签和交叉引用，使译文尽可能忠实地保留论文结构和图片信息。
   • 使用 LaTeX 源文件时，应充分解析常见 TeX 命令和引入文件，以重建阅读顺序。保留图片引用；如果源文件包包含图片资源，在 Markdown 中嵌入或链接这些本地图片。应从专用源目录复制或引用图片，不要虚构占位图。
   • 译文 Markdown 嵌入本地图片时，默认使用相对于 <prefix>_zh.md 的路径，例如 ![图 1](./<prefix>_source/figures/example.png) 或 ![图 1](./<prefix>_source/assets/example.png)。除非用户明确要求，否则不要在译文中写绝对文件系统路径。
   • 对于长论文，当当前运行环境和用户指令允许时，可使用获准的委派或子 Agent 分块翻译。主 Agent 仍负责准备干净的源文本分块、给出严格格式要求、审查返回的译文并合并到最终 Markdown。如果无法或不允许委派，则在本地逐节翻译，并明确遵守完整逐句翻译要求。
   • 如果 LaTeX 源文件不可用、不完整、其生成方式比渲染页面更难解析，或缺失关键可读内容，则使用 arXiv HTML 页面（https://arxiv.org/html/<id>）获取结构、标题、公式、表格、图片、图注、参考文献和链接。
   • 如果 LaTeX 源和 HTML 都不可用或不够完整，则使用最佳的本地 PDF 处理工具提取内容。仅使用 PDF 时，应在提取能力允许的范围内明确保留图注、图片引用、表格、公式、参考文献和章节顺序，并注明无法避免的图片/表格限制。
   • 将忠实的中文译文保存为论文产物目录中的 Markdown。译文必须是原论文的逐句中文翻译，而不是摘要、意译、重写、提纲、“整理稿”、阅读笔记或选择性摘录。
   • 按顺序翻译每个句子。每个源句子都必须有对应的中文句子或段落并保留其含义；不要把多个原始段落合并为高层摘要，不要省略“没那么重要”的句子，也不要用要点代替完整段落。
   • 译文文件应是主要中文产物，命名为 <prefix>_zh.md。如果单独的摘要/分析有帮助，将其保存为配套文件，或明确放在完整译文之后，绝不能用它代替完整译文。
   • 对长论文逐节翻译。完成当前章节后再进入下一章节，以保持与原文对齐并避免遗漏。
   • 按原顺序保留所有章节、小节、段落、图注、列表、表格、公式、引文和参考文献条目。不要删除、合并、重排或简化原始内容。
   • 翻译前规范化 LaTeX 换行。原始 LaTeX 中，单个换行通常只是源文件排版，而不是渲染后的段落分隔；应将空行（\n\n）或明确的结构命令视为真正的段落边界。将源文件中因换行而拆开的文本合并后，再发送给翻译子 Agent。
   • 在 Markdown 中保留渲染后的段落边界。不要仅因为 TeX 源文件换行就创建新段落。只有当原始渲染论文确实存在段落边界、列表项、图注、表格行、独立公式或章节/小节分隔时才另起段落。
   • 完整保留所有公式和表格。只要表格足够规则，最终译文中的表格就必须使用标准 Markdown 表格语法。普通论文表格不得输出 <table>、<thead>、<tbody>、<tr>、<td>、<th> 等原始 HTML 标签或游离的 HTML 标题。如果表格无法用普通 Markdown 表格忠实表达，应改写为清晰的 Markdown 原生结构，例如列表加对齐代码块，并明确说明限制。
   • 从最终 Markdown 中删除纯 LaTeX 记账命令和伪影。除非论文本身正在讨论某条字面命令，否则不要保留 \label{...}、\ref{...}、\eqref{...}、\tag{...}、\nonumber、\bibliographystyle、\bibliography 等仅用于源文件控制的标记。将交叉引用解析为可读文本，不要暴露原始 LaTeX 标签。
   • 应认真重建数学格式，而不是机械复制提取伪影。单个符号和短表达式使用行内公式，例如 $q$、$\mathcal{G}$ 或 $\pi_{\text{ref}}$。只有完整独立公式、对齐公式、分情况公式、优化目标或递推关系才使用块级公式。
   • 最终 Markdown 中绝不能使用 $code$、$c$ 或其他在数学定界符中嵌套反引号的形式。如果内容是数学，直接写成 $c$ 等普通公式；如果内容是代码或标识符，则只使用 code 等反引号形式，不要再包裹 $...$。
   • Markdown 数学硬性规则：最终 Markdown 中，行内公式必须使用 $...$，独立块级公式必须使用 $$ ... $$。绝不能使用 math ... 等围栏代码块表示公式。例如应写为： $$ R = \\operatorname{topK}(\\{(s_i, \\operatorname{overlap}(s_i, T)) \\mid s_i \\in S\\}) $$ 而不是数学围栏代码块。
   • 保留图片标题和图片引用。只要图片存在于 LaTeX 源文件包或 arXiv HTML 中，并且可以通过本地路径或稳定 URL 引用，就应包含实际图片。在译文 Markdown 中嵌入本地图片时，优先使用以译文文件所在目录为基准的相对路径，而不是绝对文件系统路径。只有在仅使用 PDF 或确实无法提取图片时才可省略嵌图；此时仍须保留图注并明确说明限制。
   • 不得改写论文中的任何主张。译者注或结合源码补充的内容必须明确标记为新增注释，例如 > 译注：...。
   • 对于长论文，在 <prefix>_translation_progress.md 中保留轻量级进度标记，或在译文草稿末尾添加明确标注的进度章节。记录已完成章节、待处理章节、使用的解析源和已知提取问题。最终译文完成后更新或删除该标记。这可以防止在上下文切换或中断后，将长论文的部分译文误认为已完成交付物。

4. 在译文页首写入 alphaxiv URL 或概述。

   • 使用 https://www.alphaxiv.org/zh/overview/<id>。
   • 在 <prefix>_zh.md 开头添加包含 alphaxiv URL 的简短元数据区块。
   • 如果网站提供可读取的概述内容，在元数据区块之后、靠近 <prefix>_zh.md 顶部的位置添加明确标注的 alphaxiv 概述章节。
   • 如果网站阻止抓取或无法访问概述，仍应在 <prefix>_zh.md 开头记录 alphaxiv URL，并简要注明无法获取概述。
   • 不要创建独立的 <prefix>_alphaxiv.md 或 <prefix>_alphaxiv.url 文件。

5. 当论文关联源码时，发现并克隆源码。

   • 检查 arXiv 摘要页、HTML 页、PDF 文本、作者/项目页，以及 Papers with Code/GitHub 链接。
   • 默认将仓库克隆到 ~/Downloads/<arxiv-prefix>[.<venue>].<short-name>；如果 ~/Downloads 不存在但小写的 ~/downloads 存在，则使用后者。不要把源码克隆到论文产物目录中。
   • 如果克隆目录已经存在，先检查；只有在安全且明确符合用户意图时才更新。绝不能覆盖用户更改。
   • 如果找不到源码仓库，在最终回复中明确说明。

6. 使用源码增强译文。

   • 阅读仓库 README、依赖文件、示例、脚本、配置和关键入口点。
   • 找出与论文对应的算法组成部分。
   • 先完成相关原文章节的忠实翻译。只有在原文段落翻译完成后，才能紧接相关段落、公式、算法或小节插入结合源码的伪代码说明。
   • 将每段插入的解释明确标记为非原文内容，例如 > 译注：下面是结合源码补充的伪代码解释。，然后使用普通的 text 或 python 围栏代码块放置伪代码。
   • 除非映射范围很广或不确定，否则应让伪代码紧邻其解释的原始概念，而不是全部放在末尾。不要打断句子或修改原始翻译段落；在翻译区块之后添加注释。
   • 不要为了迎合源码而修改译文，使论文表达其原本没有提出的内容。如果源码与论文不一致，应在译注中明确说明。
   • 如果子 Agent/委派可用，并且当前系统指令允许，则将源码解释和伪代码映射委派给子 Agent。否则在本地完成该分析。

7. 编写使用方法与 UV 启动说明。

   • 在中文 Markdown 译文或命名清晰的配套章节/文件中，总结如何使用 uv 运行项目。
   • 根据仓库实际情况，包含依赖配置、建议的 uv venv/uv sync/uv pip install -e . 命令、demo 或 evaluation 命令、所需数据集、模型/API 凭据、环境变量和预期输出。
   • 区分已确认的指令和推断的指令。如果仓库没有 pyproject.toml 或原生 uv 支持，应说明最安全的推断性 uv 工作流，不要假装它是官方说明。

8. 完成前验证产物。

   • 确认 PDF 和中文 Markdown 存在于论文产物目录中。
   • 确认论文产物目录与源码克隆目录是两个不同路径。
   • 确认使用了哪种解析源：arXiv LaTeX 源文件、arXiv HTML 或 PDF 提取。如果跳过 LaTeX 源文件，记录原因。如果省略图片，记录原因。
   • 确认中文 Markdown 是完整的逐句翻译，而不仅是摘要或结构化笔记。最终完成前，至少将摘要、引言、方法章节、实验/结果章节、限制/伦理章节（如有），以及参考文献/附录的处理与原文抽查对照。如果有任何章节仅被总结或遭到遗漏，继续翻译，不要报告工作流已经完成。
   • 确认没有过时的进度标记仍声称存在待处理章节。如果因为用户要求提前停止而有意保留不完整译文，应明确说明，不要将其描述为完整译文。
   • 确认中文 Markdown 中的段落边界与渲染后的论文一致，而不是跟随原始 LaTeX 的源码换行。
   • 确认 <prefix>_zh.md 以 alphaxiv URL 开头，并且没有创建独立的 alphaxiv 产物文件。
   • 确认源码克隆位置，或解释为何没有克隆仓库。
   • 在最终回复中报告保存的文件路径和所有未解决的注意事项。

工具说明

• 通过网页获取最新的 arXiv、alphaxiv 和仓库信息；这些来源可能发生变化。
• 优先使用结构化来源和官方页面：arXiv 摘要/源文件/HTML/PDF、论文关联仓库和官方项目页。翻译提取的优先顺序为：先用 arXiv LaTeX 源文件，其次用 arXiv HTML，最后才使用 PDF 处理工具。
• 对大型翻译按章节处理并增量保存。保持 Markdown 易读，不要试图精确复制每个 HTML 伪影。将章节委派给翻译子 Agent 时，发送规范化的段落块，而不是带有原始换行的 LaTeX 文本。
• 为 Markdown 输出规范化数学公式时，将块级公式转换为 $$ ... $$，行内表达式转换为 $...$。最终交付物中不要使用 info string 为 math 的围栏代码块。
• 表格应优先使用修正过表头的清晰 Markdown 表格，而不是忠实复制源文件中的 HTML。若提取结果包含畸形表头、重复标题行或错误列名，应在保存译文前修正，不要保留损坏的结构。
• 从最终 Markdown 中移除 \label{...} 等仅用于源文件的 LaTeX 伪影，绝不要在数学定界符内混入行内代码反引号，例如 $c$。
• 在生成的 Markdown 中，本地资源尤其是图片引用应优先使用可移植的相对链接。译文在论文产物目录中移动后，图片渲染仍应正常工作。
• 不要硬编码个人绝对路径作为论文产物或源码克隆路径。通过安全检查后，论文产物应位于当前工作目录下新建的已处理论文目录中；源码克隆应位于 ~/Downloads 或 ~/downloads。