本周精选已更新
AI Daily · 博客每日精选 归档
返回 2026-04-24
🛠 工具 / 开源

LiteParse for the Web：浏览器内提取 PDF 文本的新方案Extract PDF text in your browser with LiteParse for the web

simonwillison.net·2026-04-23

LlamaIndex 开源项目 LiteParse 原本是基于 Node.js 的 PDF 文本提取工具，现已被移植至浏览器环境，利用相同核心库实现在前端解析 PDF。它采用传统 PDF 解析技术而非 AI 模型，支持空间文本识别，无需服务器即可在客户端完成高精度文本提取。

阅读原文

Simon Willison

2026年4月23日

LlamaIndex 有一个非常出色的开源项目叫 LiteParse，它提供了一个 Node.js CLI 工具，用于从 PDF 中提取文本。我成功实现了一个完全在浏览器中运行的 LiteParse 版本，使用了与 LiteParse 在 Node.js 环境下运行时相同的绝大多数库。

空间文本解析

令人耳目一新的是，LiteParse 并不依赖 AI 模型来完成其工作：它采用的是传统的 PDF 解析方式，对于包含图像文本而非原始文本的 PDF 文件，会回退使用 Tesseract OCR（或其他可插拔的 OCR 引擎）。

LiteParse 解决的核心难题是：如何在 PDF 布局混乱不堪的情况下，仍能合理有序地提取文本。他们将此称为“空间文本解析”——通过一些非常巧妙的启发式算法来识别多栏布局等结构，并将文本按合理的线性顺序进行分组和返回。

LiteParse 文档描述了一种实现带边界框的视觉引用的模式。我非常欣赏这个想法：能够从 PDF 中回答问题，并附上裁剪后的高亮显示的图片，这似乎是提升 RAG 风格问答可信度的绝佳方式。

LiteParse 作为一个纯粹的 CLI 工具提供，设计初衷是用于由智能体调用。你可以这样运行它：

npm i -g @llamaindex/liteparse
lit parse document.pdf

我用 Claude 探索了它的能力，很快发现它完全没有必要局限于 CLI 应用：它基于 PDF.js 和 Tesseract.js 构建，这两个库我之前就在浏览器环境中用于类似场景。

LiteParse 没有纯浏览器版本唯一的原因就是，还没有人真正动手实现过……

隆重推出网页版 LiteParse

访问 https://simonw.github.io/liteparse/ 即可在浏览器中直接对任意 PDF 文件试用 LiteParse。效果如下：

该工具可选择是否启用 OCR，还可选择是否在页面下方额外显示每页的 PDF 图片。

使用 Claude Code 和 Opus 4.7 开发

这次开发的起点是我 iPhone 上的常规 Claude 应用。我想亲自体验一下 LiteParse，于是上传了我手机上随机找到的一个 PDF 文件，并附带了这个提示词：

克隆 https://github.com/run-llama/liteparse 并用它对这份文件进行测试

现在的常规 Claude 聊天可以直接从 GitHub 克隆代码，虽然它在容器内默认无法访问大部分互联网，但可以从 PyPI 和 npm 安装包。

我经常用这种方式在手机端尝试新的开源软件——这是一种不用打开笔记本电脑就能快速上手的好方法。

你可以查看我们完整的共享 Claude 对话记录。我问了几个关于工作原理的问题，然后接着问：

这个库能在浏览器里运行吗？能实现吗？

得到的回答足够详尽，让我确信值得认真尝试实现浏览器版本。于是我打开了笔记本电脑，切换到 Claude Code。

我在 GitHub 上 fork 了原仓库，克隆了本地副本，新建了一个 web 分支，并把 Claude 的最后回复粘贴到一个名为 notes.md 的新文件中。然后我对 Claude Code 说：

把它做成一个网页应用。index.html 加载时应渲染一个应用，让用户能在浏览器中打开 PDF，选择 OCR 或非 OCR 模式，并让这个功能运行起来。阅读 notes.md 了解这个问题的初步研究，然后写出 plan.md 详细描述你的实现方案

对于这类项目，我通常喜欢先制定一个计划。有时我会使用 Claude 的“规划模式”，但这次我希望将计划作为仓库中的一个文件保存下来，因此我直接要求它生成 plan.md 文件。

这也意味着我可以与 Claude 一起迭代优化这个计划。我发现 Claude 原本打算跳过在 PDF 中生成图片截图的步骤，并建议我们将“canvas-encode 交换”推迟到 v2 版本。我通过提示解决了这个问题：

更新计划，明确说明我们会执行 canvas-encode 交换，以确保截图功能正常工作

经过几次简短的后续提示后，我得到了一个足够完善的 plan.md 文件，准备开始实施。

我输入了以下提示：

构建它。

然后大部分时间我都让 Claude Code 自主运行，同时处理其他项目、完成 Duolingo 的学习任务，偶尔检查一下进度。

在开发过程中，我陆续添加了一些提示到队列中。这些提示目前在我的导出记录中没有显示，但发现通过在相关 ~/.claude/projects/ 文件夹中使用命令 rg queue-operation --no-filename | grep enqueue | jq -r '.content' 可以提取出来。

以下是关键的一些后续提示及备注：

  • 实现时请使用 Playwright 和红绿 TDD（测试驱动开发），也要为此做好规划——我在其他地方更详细地写过关于红绿 TDD 的内容。
  • 让我们使用 PDF.js 自身的渲染器（之前它一直在折腾 pdfium）
  • 最终的用户界面应该同时包含文本和格式化的 JSON 输出，两者都放在 textarea 中，并且都要有复制到剪贴板的按钮；同时界面应该是移动端友好的——我对 UI 的工作方式有了新的想法。
  • 沿途进行小规模的提交——见下文。
  • 确保 index.html 页面顶部包含指向 https://github.com/run-llama/liteparse 的回链——在这个项目中致谢依赖库非常重要！
  • “View on GitHub” 是糟糕的文案，因为那不是存放此 Web 应用的仓库，而是 LiteParse 基础库的仓库。
  • “运行 OCR”默认应为未选中状态。
  • 当我在浏览器中尝试解析 PDF 时看到 'Parse failed: undefined is not a function (near '...value of readableStream...')'——之前用 Playwright 在 Chrome 中测试时出现了这个问题，后来发现是 Safari 中的 bug。
  • ...哦，这确实是 Safari 的问题，但在 Chrome 中可以正常工作。
  • 点击“复制”后，文本应变为“已复制！”持续 1.5 秒。
  • [图片 #1] 请美化文件输入框，防止 Firefox 上长文件名导致布局错乱——事实上可以添加那种可拖放也可点击选择的区域，把截图拖进去查看小 UI 问题效果意外地好。
  • 调整拖放区域的文字垂直居中，现在稍微偏上一些。
  • 在 macOS 上的 Safari 中会出问题，但在 Chrome 和 Firefox 中都正常。在 Safari 中点击解析按钮后（OCR 未勾选）会出现 "Parse failed: undefined is not a function (near '...value of readableStream...')"，即使如此仍然无法在 Safari 中工作...
  • 现在在 Safari 中也能工作了——一旦我指出这个问题，Claude 很快就让 Playwright 在该浏览器中正常运行了。

    • 我开始习惯性地要求“沿途进行小规模提交”，因为这会让代码更容易理解或后期审查，而且我有一个未经证实的直觉认为这也有助于代理更高效地工作——这再次鼓励我们提前规划和一次只解决一个问题。

    在运行过程中，我决定如果能与正在进行的版本进行交互会很不错。我让 Claude Code 针对同一目录的另一个会话来获取如何运行的提示，它建议我用 npx vite。运行后启动了一个支持实时重载的开发服务器，这意味着我可以立即看到它对磁盘所做的每次更改的效果，并进一步请求调整和修复。

    接近尾声时，我决定可以发布了。我启动了一个新的 Claude Code 实例，并告诉它：

    查看 web/ 文件夹——为这个仓库设置 GitHub Actions，使得任何推送都会运行测试，如果测试通过，则构建并部署 Vite 应用到 GitHub Pages，使得 web/index.html 成为部署后的首页，并在 GitHub Pages 上正常工作。

    经过一些迭代后，这是使用 Vite 构建应用并将其结果部署到 https://simonw.github.io/liteparse/ 的 GitHub Actions 工作流。

    我喜欢 GitHub Pages 做这类事情，因为它可以快速配置（比如由 Claude 完成），将任意仓库变成零成本的已部署网页应用，并且支持任何必要的构建步骤。即使对于私有仓库也有效，只要你不在意唯一的安全保障是私密 URL。

    对于这类项目，总存在一个重大风险：模型可能会“作弊”——把关键功能标记为“TODO”然后假装实现，或者采取忽略最初需求的捷径。

    负责任的做法是审查所有代码……但这个项目本就不打算如此严谨，所以我转而使用 OpenAI Codex 搭配 GPT-5.5（我有预览权限），并让它：

    描述 node.js CLI 工具的运行方式与 web/ 版本运行方式的差异。

    它给出的答案足以让我确信 Claude 没有采取任何威胁项目的捷径。

    差不多就是这样。整个“构建它”阶段在 Claude Code 中总共花了 59 分钟。我使用了 claude-code-transcripts 工具导出完整对话的可读版本，你可以在此处查看（尽管缺少那些额外排队中的提示；这是我用来修复该问题的 issue）。

    这还算 vibe coding 吗？

    我对 vibe coding 的原始定义非常严格——vibe coding 并不是指你用了 AI 辅助写代码就算，而是指完全不审查也不关心所写代码的行为。

    按我自己的定义，这个 LiteParse for the web 项目已经达到了最纯粹的 vibe coding！我没有看过一行为此项目编写的 HTML 和 TypeScript 代码——事实上，在写这句话时我还得去确认它用的是 JavaScript 还是 TypeScript。

    然而不知为何，这次感觉不像我之前很多 vibe coding 项目那样纯粹：

  • 作为托管在 GitHub Pages 上的静态浏览器内网页应用，任何 bug 的影响范围几乎为零：要么对你的 PDF 有效，要么无效。
  • 没有任何私人数据被传输——所有处理都在你的浏览器中完成——因此无需安全审计。我在运行时瞥了一眼网络面板，发现解析 PDF 时没有发出额外的请求。
  • 尽管如此，以这种方式使用模型仍然需要大量的工程经验和知识。识别出将 LiteParse 直接移植到浏览器中运行对后续项目至关重要。

    • 最重要的是，我很高兴将我的声誉与这个项目联系起来，并推荐其他人尝试一下。与我大多数 vibe coded 工具不同的是，我不认为在这上面花费大量额外的工程时间会带来更有意义的初始版本。目前这样就很好！

    我没有向原始仓库提交 PR，因为我还没有和 LiteParse 团队讨论过。我已经提了一个 issue，如果他们希望我的 vibe coded 实现作为更正式项目的起点，他们随时可以拿去用。

    需要完整排版与评论请前往来源站点阅读。