本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

• 我的帖子已经打上 开源推广 标签： 是


• 我的开源项目完整开源，无未开源部分： 是


• 我的开源项目已链接认可 LINUX DO 社区： 是


• 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是


• 以上选择我承诺是永久有效的，接受社区和佬友监督： 是

以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出

我写了一个论文阅读工具：Neuink

Neuink 是一个基于 MinerU 和 Sciverse 组织起来的开源论文阅读工作台。它不自研 PDF 解析模型、学术数据库或大语言模型，而是把现有服务接入一个本地优先、来源可追溯的阅读流程。

GitHub： GitHub - SugrSertraline/neuink: A local-first workspace for reading, annotating, searching, and building source-grounded knowledge from PDFs with AI assistance. · GitHub

一句话介绍

最近我写了一个论文阅读工具，叫 Neuink。它面向论文、技术报告、标准和书籍章节，保留原始 PDF，同时把 MinerU 的结构化解析结果用于片段定位、重排阅读、笔记、批注、来源链接、检索和 AI 协作，让阅读中形成的结论能够回到具体页面和原文片段。

为什么做 Neuink

现在已经有很多优秀的 PDF 解析、论文检索和大语言模型服务。Neuink 没有尝试重新实现这些基础能力，也不打算把自己包装成新的 OCR 模型或学术搜索引擎。

如果是计算机领域的开发者，像我之前也是直接使用 Codex、WorkBuddy 一类 Agent，给它安装一个 PDF 阅读 Skill，或者就直接把 Mineru 解析得到的markdown保存下来，再让它为文献建立索引、检索内容和整理笔记，很多工作就已经能够完成。但这种方式毕竟有一定的技术难度，我问了一些其他专业的同学，可能大部分也只是停留在扔文档-输出这一步。对其他专业的科研人员，或者不想维护这些技术细节的人来说，一套把解析、阅读、笔记、检索和 AI 交互放在一起的专业软件还是有必要的。它和小绿鲸等一体化阅读产品、Zotero 等文献管理工具并不是简单的替代关系：Zotero 更偏向文献收集、元数据和引用管理，小绿鲸等产品强调开箱即用的阅读体验，而 Neuink 更关注论文进入本地之后的精读、片段证据、学习笔记和后续研究。

它更像一个面向论文阅读的“组装厂”：

• MinerU 负责把 PDF 转换成带有文本、公式、表格、图片、页码和版面位置的结构化结果；


• Sciverse 提供可选的外部论文检索、正文和资源获取能力；


• Embedding 和语义关系能力仍在适配中；


• 用户配置的 LLM 提供问答、整理和翻译等语言能力；


• Neuink 负责把这些能力连接成一个可以阅读、记录、复核和长期保存的本地工作流。

Neuink 的重点不是“模型由谁训练”，而是这些能力进入真实阅读场景后如何协同：解析结果怎样与原始页面对应，笔记怎样保留来源，外部论文什么时候进入本地资料库，AI 提议的修改怎样交给用户确认。

从一份 PDF 到可追溯的阅读记录

一篇论文进入 Neuink 后，大致会经历下面的流程：

导入 PDF 或 MinerU 解析结果

  -> 归一化为 Neuink Source Segment

  -> 在原始 PDF 与 Reflow 中阅读

  -> 记录片段笔记、批注和 Markdown 笔记

  -> 用 Source Link 连接笔记与原文

  -> 在本地检索或把明确的上下文交给助手

  -> 从回答和笔记跳回原始页码复核

这里的核心不是把 PDF 转成一大段文本，而是得到一组可以定位的 Source Segment。每个片段可以包含页码、版面区域、文本、Markdown、内容类型和图片资源。段落、标题、列表、公式、表格和视觉内容因此不只是“解析输出”，还会成为后续阅读和引用的共同坐标。

Neuink 如何使用 MinerU

MinerU 是 Neuink 的可选 PDF 解析来源，不随 Neuink 仓库或主程序捆绑。Neuink 当前支持三种获得解析结果的方式：

1. 调用 MinerU Cloud；


2. 调用用户自行配置的兼容解析端点；


3. 导入 MinerU 客户端已经生成的完整结果 ZIP。

其中，第三种方式最能体现两个项目的分工：用户可以先在 MinerU 客户端完成解析，再把结果交给 Neuink 继续阅读和管理。

从 MinerU 客户端结果导入

首先在 MinerU 客户端中导入 PDF 并等待解析完成。解析完成后，打开该任务的结果文件夹。

将结果文件夹中的全部内容一起压缩为 ZIP，而不是只压缩某一个 JSON。结果通常包括：

• 原始 PDF；


• images 等资源目录；


• Content List、Middle JSON、Layout JSON 等解析文件；


• MinerU 输出的 Markdown 和其他派生文件。

随后回到 Neuink，在“新建条目”中选择“从 MinerU 客户端导入”，选择这个 ZIP 并创建条目。Neuink 会读取其中的 PDF、结构化 JSON 和图片资源，不会再次把文档提交给自动解析服务。

MinerU 客户端结果 ZIP

  -> 校验并提取 PDF、JSON 和图片

  -> 兼容不同 MinerU 输出结构

  -> 归一化为 Source Segment

  -> 保存到本地 Workspace

  -> 进入 PDF、Reflow、笔记、检索和助手流程

这种设计有两个目的：一是让已经使用 MinerU 客户端完成的解析结果可以直接复用；二是让 Neuink 后续的阅读能力依赖自己的稳定数据结构，而不是直接依赖某次 API 返回的临时字段。

当然我是直接本地部署的Mineru，大概20G显存左右，之前也使用七牛云先把资源传到云端然后在调用Mineru的API，后来还是删除了这个功能，只保留了配置URL和从Mineru解析后导入。

原始 PDF 与结构化片段一起阅读

Neuink 不会用重排文本替代原始 PDF。PDF 是最终证据，Reflow 和各种片段视图都是辅助阅读方式。

MinerU 结果归一化后，Neuink 可以在 PDF 页面上建立片段轨道和目录。点击标题或片段时，可以回到相应页面和区域；悬停时可以查看解析文本和翻译，同时保留原始版式用于复核。

结构化结果也可以用于标签推荐。推荐结果只是候选项，用户选择后才会保存到当前条目。

多种笔记与原文溯源

Neuink 对论文阅读中的不同记录方式做了专门适配，目前支持三类相互关联的笔记内容：

• 笔记：围绕某个解析片段记录即时理解；


• 批注：标记原文中的重点、问题和结论；


• 独立 Markdown 笔记：整理跨段落、跨页面甚至跨论文的完整学习笔记。

独立 Markdown 笔记支持标题、列表、引用、表格、图片和数学公式等内容。系统尤其适配了笔记与原文之间的溯源：关键论断可以插入 Source Link，保存条目、页码、片段标识和文本快照。用户可以从笔记预览来源、跳回 PDF，也可以查看当前原文片段被哪些笔记引用，让笔记依据和原文位置都更加清晰。

因此，Neuink 保存的不只是“我写了什么”，还包括“这句话依据了哪一页、哪一个原文片段”。

检索和 AI 助手如何参与

Neuink 的关键词搜索可以覆盖条目、标签、自定义字段、Markdown 笔记、片段笔记、PDF 页面和解析片段。Semantic、Hybrid 以及更进一步的关系检索目前仍属于实验能力，不能把它们当作已经完成的核心功能。

这里的 Agent 不是直接接入某个现成 Agent 产品，也不是类似 Tolaria 一类方案那样只调用本地大模型去修改内容。Agent 的任务路由、工具调用、上下文读取、证据记录、Verifier、Proposal 和写入约束是我在 Neuink 中自己实现的；真正负责推理的底层模型仍然来自用户配置的 LLM Profile。

助手读取的是用户明确添加的上下文，回答可以携带来源。如果它要修改笔记、标签或条目信息，会先生成 Proposal，由用户确认后再写入 Workspace，而不是让模型直接改动本地文件。

这一设计关注的不是“让 AI 自动替用户完成所有工作”，而是让 AI 的阅读范围、证据和写入目标保持可见。

Sciverse：从外部检索到本地文库

Sciverse 是 Neuink 可选调用的外部学术服务，不是 Neuink 自建的论文数据库。配置并启用后，助手可以按需搜索外部论文、读取远程正文，并查看论文元数据、参考文献、被引论文、相关工作和可用资源。

远程检索结果不会因为被助手看到就自动写入本地 Workspace。只有用户明确点击“保存到本地文库”后，Neuink 才会尝试导入：

• 如果 Sciverse 或开放获取地址提供 PDF，Neuink 会下载 PDF、创建本地条目，并进入后续解析流程；


• 如果暂时无法获取 PDF，可以降级保存元数据或远程正文；


• 远程证据在导入前保持 Sciverse 身份，不伪装成本地 entry_id 或 segment_uid。

这条边界很重要：外部搜索用于发现资料，本地文库用于长期管理资料，两者之间必须有一次清楚的用户决定。

现在还有不少问题

Neuink 目前更接近我为了科研工作搭建的实验性工具，还不是一个已经打磨完成的通用产品。

其中一个比较明显的问题是 Embedding 还没有真正适配好。虽然底层已经有本地 Provider、向量索引和 Semantic/Hybrid 的工程接口，但当前模型、文档片段和关系构建之间还没有形成稳定方案，因此底层图结构和语义关联的效果并不理想。现在更可靠的仍然是关键词检索、明确选择上下文和基于 Source Segment 的来源定位。

另一个问题是 Agent 仍在快速迭代。它的执行循环和工具系统是自己写的，因此可以针对 Neuink 的笔记、片段、Sciverse 和 Proposal 流程做约束，但任务路由、不同模型下的稳定性、长任务恢复和复杂研究流程都还有很多需要验证的地方。

总之还是有很多功能要更新和维护，希望大家能给我一些指导意见或者建议，让这个更好用，我自己最近一段时间一直在使用，可能符合我的习惯，但是不符合其他人的习惯，还是有很多要继续更新的地方吧。