# 三款海外开源新货，中文教程还是空白 **导语：** 这期不追“昨夜首发”的热闹，专门挖一类更值钱的信息差：海外热度已经起来、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”的本质区别：一个是一次性的，一个是可积累的公司数据资产。 ### 怎么上手（五分钟版） ```bash pip install vanna ``` Python 里几行代码：选一个 LLM（支持 OpenAI、也支持本地 Ollama 模型，数据不出内网），选一个向量库，把 DDL 和文档喂进去，然后 `ask()` 提问即可。官方仓库还附带现成的 Web 界面示例，不懂 Python 的同事也能用。 ### 与国内方案对比 | 维度 | Vanna AI | 国内云厂商 ChatBI | |---|---|---| | 数据位置 | 完全本地，LLM 也可本地 | 需接入云服务 | | 费用 | MIT 免费自部署 | 按坐席/用量收费 | | 口径沉淀 | 问答对自积累，越用越准 | 配置在厂商平台，迁移难 | | 定制自由度 | 任意改源码 | 黑盒 | 国内同类（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 流水线 ### 用法示例 ```bash pip install docling ``` ```python from docling.document_converter import DocumentConverter converter = DocumentConverter() result = converter.convert("年报.pdf") print(result.document.export_to_markdown()) ``` 三行代码，一份复杂版式的 PDF 就变成了干净的 Markdown，后面接向量库、接 LLM 都顺了。 **适用人群：** 搭企业知识库的工程师；要批量处理研报/合同/论文的人；做 Agent 需要让模型“读懂”文档的工具链作者。 --- ## 四、三个工具串起来：一条完整流水线 单看是三个工具，串起来其实是一条“从原始资料到可用产品”的流水线： ```mermaid 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 代码。三个人干以前五个人的活。 --- ## 信息差总结 | 你以为的 | 实际情况 | |---|---| | 查数据必须等分析师写 SQL | Vanna 开源免费，运营自己问，口径越喂越准 | | 设计稿和代码永远是两张皮 | Onlook 让设计师直接改真实 React 代码 | | PDF 解析就是提取纯文本 | Docling 能还原图表结构，这才是 RAG 质量的分水岭 | | 好用的 AI 数据工具都要付费上云 | 三个全部开源，都能私有化部署 | ## 行动指南 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 等场景全覆盖。