三款海外开源新货，中文教程还是空白

导语： 这期不追“昨夜首发”的热闹，专门挖一类更值钱的信息差：海外热度已经起来、GitHub 仓库公开可查，但中文教程几乎空白的开源新工具。今天给你三个：让运营自己查数据库的 Vanna AI、直接改真实前端代码的 Onlook、IBM 出品的文档解析利器 Docling。三个都免费自部署，分别卡在数据、界面、文档三条流水线的咽喉位置。学会任何一个，都能省掉一类重复劳动或者一项外包费用。

编辑说明：本轮海外实时榜单抓取通道受限，本文选取的是仓库信息公开可查、可自行验证的项目。Star 数、最新版本号请以仓库 README 为准，文中不给未经核实的数字。

一、Vanna AI：把 ChatBI 的能力，开源版白送给你

仓库： github.com/vanna-ai/vanna ｜ 官网： vanna.ai ｜ 协议： MIT 开源，可私有化部署

它解决什么问题

每个公司都有一样的场景：运营、财务、老板想看数据，只能提工单等数据分析师写 SQL。排队半天，回来一句“口径不对”，再排队。市面上的 ChatBI 云产品按坐席收费，数据还得上传到别人家。

Vanna AI 的思路很简单：text-to-SQL 的开源实现。你用自然语言问“上个月华南区复购率最高的三个 SKU 是什么”，它生成 SQL，跑完直接出表格和图表。

它凭什么比一般的 text-to-SQL 准

大多数人不知道它的核心机关：RAG 训练层。Vanna 不是裸调大模型猜 SQL，而是让你把三类东西喂进它的向量库：

1. DDL——建表语句，让它知道每张表有哪些字段
2. 业务文档——“GMV 的口径是什么”“退款单算不算营收”
3. 历史问答对——之前人工确认过的正确 SQL

用得越多，喂得越多，生成准确率就越高。这是它和“把表结构贴给 ChatGPT”的本质区别：一个是一次性的，一个是可积累的公司数据资产。

怎么上手（五分钟版）

pip install vanna

Python 里几行代码：选一个 LLM（支持 OpenAI、也支持本地 Ollama 模型，数据不出内网），选一个向量库，把 DDL 和文档喂进去，然后 ask() 提问即可。官方仓库还附带现成的 Web 界面示例，不懂 Python 的同事也能用。

与国内方案对比

国内同类（Dify 的 text-to-SQL 插件、各云厂商智能问数）多为平台内功能，想深度定制口径管理不如 Vanna 灵活。

适用人群： 有一堆“帮跑个数”需求的小团队；想做内部数据自助工具的后端工程师；数据不能出内网的公司。

二、Onlook：设计师版 Cursor，改的是真实代码

仓库： github.com/onlook-dev/onlook ｜ 协议： 开源，免费自部署

它解决什么问题

前端协作有个经典死循环：设计师说“按钮往左挪 2 像素、这行文案改一下”，工程师放下手头活儿去改样式；或者工程师直接把 AI 生成的界面给设计师看，设计师只能说“再调调”，说不出具体怎么调。

Onlook 的定位一句话说清：所见即所得的可视化编辑器，但改的是项目里真实的 React 代码。

工作方式（这是关键认知差）

它不是 Figma 那种画布工具，也不是纯对话式造 App 的玩具。流程是这样的：

1. 把你正在开发的 React + Tailwind 项目连到 Onlook 桌面端
2. 它渲染出真实页面，设计师直接在页面上点选任何元素，拖拽改布局、改颜色、改文案
3. 每一次拖拽，Onlook 反向写回项目源代码，工程师在 Git 里看到的就是一次正常的代码改动
4. 卡住了或者要生成新组件，切到 AI 模式用自然语言补一刀

也就是说：设计师手里的“设计稿”，和工程师仓库里的“代码”，从头到尾是同一份东西。没有标注、没有切图、没有“按设计稿还原”这个环节了。

和两个容易混淆的东西划清界限

• vs Cursor/对话造 App：Cursor 是工程师用文字写代码；Onlook 是在跑起来的界面上直接动手，重点解决“不会写代码的人如何安全地改真实产品”，而不是从零生成一个项目。
• vs 国内设计工具（MasterGo、即时设计等）：那些是“画设计稿”，交付物还是图；Onlook 的交付物直接就是合并进主干的代码。

适用人群： 前端小团队（1 设计 + 1-3 工程师那种配置）；独立开发者想给设计师开个“自助改样式”的口子；接外包要频繁跟客户确认界面的工作室。

三、Docling：IBM 开源的文档解析机，RAG 的漏斗嘴

仓库： github.com/docling-project/docling ｜ 协议： MIT 开源

它解决什么问题

做过 RAG 或知识库的人都被 PDF 坑过：双栏排版的论文解析出来串行、表格变成一堆乱码字符、扫描件直接全军覆没。垃圾进垃圾出，检索层再怎么调优都白搭。文档解析这个环节，国内教程一般一句“用 PyMuPDF 提取文本”就带过去了，这正是质量塌方的地方。

Docling 是 IBM 研究院开源的文档解析库，专门啃这块硬骨头。

值得关注的几个点

1. 格式覆盖广：PDF、DOCX、PPTX、XLSX、图片、HTML 都能进，统一吐出 Markdown 或结构化 JSON
2. 表格还原是强项：识别表格结构后输出真正的表格语义，而不是一堆断裂文本——这对财报、研报类文档是刚需
3. 版面理解模型本地可跑：CPU 就能跑，机密文档不用出内网
4. 生态集成现成：官方提供 LangChain、LlamaIndex 等主流框架的接入包，解析完直接进你的 RAG 流水线

用法示例

pip install docling

from docling.document_converter import DocumentConverter

converter = DocumentConverter()
result = converter.convert("年报.pdf")
print(result.document.export_to_markdown())

三行代码，一份复杂版式的 PDF 就变成了干净的 Markdown，后面接向量库、接 LLM 都顺了。

适用人群： 搭企业知识库的工程师；要批量处理研报/合同/论文的人；做 Agent 需要让模型“读懂”文档的工具链作者。

四、三个工具串起来：一条完整流水线

单看是三个工具，串起来其实是一条“从原始资料到可用产品”的流水线：

flowchart TD
    A["PDF/合同/年报/网页"] -->|Docling 解析| B["干净的结构化数据"]
    B -->|入库存好| C["公司数据库"]
    C -->|自然语言提问| D["Vanna 生成 SQL"]
    D --> E["报表和图表"]
    F["Onlook 可视化编辑"] -->|拖拽与AI生成| G["前端界面"]
    E -->|数据接口| G
    B -->|对话知识库| H["内部问答助手"]

一个真实的小团队场景：用 Docling 把三年积累的行业研报拆成结构化数据入库存好；业务同事用 Vanna 自己查数，不用再排队等报表；产品界面要调整，设计师在 Onlook 里直接动手，工程师只管 review 代码。三个人干以前五个人的活。

信息差总结

行动指南

1. 今天：pip install docling，拿一份你最头疼的 PDF 试解析，五分钟内验证表格还原效果
2. 本周：把公司核心表的 DDL 和三条常用口径喂给 Vanna，让一位不懂 SQL 的同事试用一周，收集错误案例回喂
3. 有前端项目的：clone Onlook 仓库跑起来，连你的项目让设计师试改一个页面，观察 Git diff 是否干净
4. 进阶：三者都支持本地模型/本地运行，涉密环境先小范围 POC 再推广

参考来源

1. Vanna AI 仓库：https://github.com/vanna-ai/vanna （以 README 快速上手文档为准）
2. Vanna 官网：https://vanna.ai
3. Onlook 仓库：https://github.com/onlook-dev/onlook （以仓库文档为准）
4. Docling 仓库：https://github.com/docling-project/docling （IBM 开源，MIT 协议）

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护。 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。