Simon Willison 发布了 LiteParse for the web：一个跑在浏览器里的 PDF 文本提取工具。用户在本地打开 PDF，可选 OCR，输出文本和 JSON，也能选择渲染页面截图。文件不上传，处理留在浏览器里。
这不是“大模型读 PDF”。LiteParse 原本是 LlamaIndex 的开源 Node.js CLI，核心靠 PDF.js、Tesseract.js 和空间文本解析。Willison 做的是 fork 后移植成 Web 版，并用 Claude、Claude Code、Playwright、Vite、GitHub Actions 和 GitHub Pages 搭出初始发布。
LiteParse Web 版解决的是 PDF 的老毛病
LiteParse 的难点不在“识字”。难点在 PDF 这种格式太难伺候：多栏、页眉页脚、坐标碎片、字体信息、扫描件，经常把人类能读懂的页面拆成机器不好还原的文字块。
LiteParse 做的是 spatial text parsing，也就是按页面空间位置推断阅读顺序。遇到图片型文字，才调用 Tesseract.js 做 OCR。这个区别很重要：它不是用 AI 模型猜内容，而是用传统解析和启发式规则整理文本。
| 对比项 | 原 Node.js CLI | Web 版 | 直接影响 |
|---|---|---|---|
| 使用方式 | lit parse document.pdf | 浏览器打开 PDF | 不装 CLI 也能试 |
| 技术核心 | PDF.js、Tesseract.js、空间文本解析 | 基本沿用 | 不是大模型读 PDF |
| 数据路径 | 本地命令行 | 本地浏览器 | 文件不离开机器 |
| 输出结果 | 文本、结构化信息 | 文本、JSON、可选页面截图 | 更方便检查来源 |
| 部署方式 | npm CLI | Vite + GitHub Actions + GitHub Pages | 发布成本很低 |
对做 RAG 问答的人，这个工具最有价值的地方不是“提取出一段文字”。而是它能保留文本位置、页面尺寸、字体和坐标等结构信息。
答案后面只写“来源：第 12 页”，说服力已经不够。能把 PDF 对应区域裁出来、高亮出来，用户才更容易判断答案有没有凭据。PDF 问答真正卡人的地方，往往不是答不出来，而是答完以后没人敢信。
59 分钟不是神迹，是会选低爆炸半径
Willison 的流程很有工程味。
他先在 Claude 里研究 LiteParse 能不能跑在浏览器里。再切到 Claude Code，让它写 plan.md，然后按计划实现。中间要求 Playwright 做 red/green TDD，要求小步提交，指定使用 PDF.js 自己的渲染器，并用 Vite 本地预览。
发布也没有手搓服务器。GitHub Actions 跑测试，通过后部署到 GitHub Pages。一个静态 Web 应用就上线了。
关键细节是：他没有审查每一行 HTML/TypeScript。按严肃生产系统的标准，这很冒险。但这个项目的风险边界很小。
它没有后端。没有账号。没有支付。没有数据库。没有文件上传。解析失败，最坏也只是某个 PDF 不能用。
Safari 还真出过 readableStream 相关 bug。Willison 通过跨浏览器测试把它修掉。模型也可能偷懒，把功能写成 TODO 或假实现，所以他又用 OpenAI Codex 复核 Node CLI 和 Web 版的运行差异。
《孙子兵法》说，“胜兵先胜而后求战”。这里的“先胜”，不是模型变聪明了，而是工程师先把战场选窄了。
这才是案例的含金量。AI 代理没有被当成无所不能的工程师，而是被关进了一个输得起的笼子。
开发者和技术负责人该学的是边界清单
这个案例对开发者的启发很直接：很多 CLI 工具、内部脚本、文档转换器、数据查看器，都不必永远停在命令行里。核心能力已经在开源库里时，可以让 coding agent 先包一层可试用的 Web 壳。
开发者可以调整动作：少从脚手架开始磨，多把精力放在约束条件上。比如指定测试方式、浏览器兼容、输出格式、部署路径、失败提示。提示词不是许愿池，是工程任务单。
对技术负责人，重点不是“让 AI 写更多代码”。重点是建立可放权清单。
适合交给 agent 先冲一版的项目，大致有几个共同点：静态运行，无后端状态；不处理生产敏感数据；失败成本低；能自动测试；核心逻辑有现成库兜底。内部小工具、演示型前端、文档处理页面，属于这一类。
不该轻易放权的也很清楚：权限、支付、医疗、金融、生产数据、复杂后端状态、合规审计。这些地方不能靠“看起来能跑”过关。AI 代理可用，不等于可以替你背锅。
还要把这个项目的边界说死。LiteParse for the web 不是 LlamaIndex 官方浏览器版。Willison 只是 fork 了项目并开了 issue，尚未提交 PR，也没有被官方合并。
约 59 分钟也不是“生产级交付”的证明。它证明的是：在低风险场景里，懂工程的人能用 coding agent 很快把开源能力产品化。至于 OCR 性能、大文件体验、Safari 等兼容稳定性、LiteParse 团队是否接纳 Web 方向，还得继续看实际使用和维护成本。
真正的分水岭不在模型会不会写代码。分水岭在团队有没有能力判断：哪些任务可以让 agent 放手做，哪些地方必须人类盯死。