wandao

项目背景与痛点

知识库产品最大的护城河从来不是编辑器，而是数据锁定。一个人在语雀写了三年、在飞书文档沉淀了团队知识、在公众号攒了两百篇原创，真要搬家时会发现：文本本身复制粘贴就行，但目录树、图片、附件、公式、内链、代码块这些"结构性资产"会全部崩掉。手工搬运的结局通常是——几百个文件平铺在一个文件夹，图片全指向已经失效的防盗链地址，层级关系只存在于你的记忆里。

市面上不缺"单平台导出脚本"，语雀有、Notion 有、Obsidian 有。但它们基本是孤岛：每个脚本解决"从 A 出"，没人解决"从 A 进 B"以及"多对多"。wandao（万能导）切入的正是这个空白：把十几个主流知识库/内容平台当作端点，做一张全连接的转换网，并且强调保留目录结构、图片与项目格式。

核心技术揭秘

多平台互转这件事，最忌讳的实现方式是"每个源直接对每个目标写一套转换逻辑"。N 个平台意味着 N² 条转换路径，维护量随时间指数级爆炸。从 wandao 的功能矩阵反推，它大概率走的是Hub-and-Spoke 的中间表示（IR）路线：先把任意源平台的文档树抽成统一模型，再由统一模型渲染到任意目标平台，转换器数量从 N² 降到 2N。

这个 IR 至少要包含两层：一层是文档树（文件夹/文档节点、层级、排序、标题），另一层是内容 AST（段落、标题、表格、代码块、公式、图片、附件、内链）。只有把"结构"和"内容"分开建模，目录重建和正文转换才能解耦——前者决定落盘路径，后者决定文件内容。

数据流大致如下：

横向看，它的内部分层应该是这样的：

架构图不是重点，真正难的是三处工程细节：

其一，资源图（Asset Graph）。 图片绝不能边转边下载——那样并发不可控、重复引用会重复下载、失败一次整篇文档就脏了。正确做法是先扫描整棵文档树，把所有远程资源去重成一张图，用内容哈希命名（assets/<hash>.<ext>），并发池下载，失败进重试队列，最后统一改写引用路径。哈希命名还顺带解决了断点续传：文件已存在就跳过。

其二，双向保真。 Markdown → 富文本平台比反过来更难，因为目标平台很可能不支持 Markdown 的某些结构（嵌套表格、脚注、HTML 内联标签）。这里必须有一套降级策略，而不是硬塞。

其三，适配器的脆弱性。 语雀、飞书有稳定的 OpenAPI，公众号、知乎只能靠抓页面或逆向接口，一旦平台改版或 token 过期，适配器立刻失效。这类项目的长期成本几乎全部压在适配器的持续维护上。

功能亮点与差异

第一，双向且多对多。市面上多数工具只做"出"，wandao 做"进出"，这意味着同一份 IR 既能生成 Obsidian 库，也能回灌到语雀或飞书，对"多平台同步发布"的场景很有价值。

第二，目录结构保留是它区别于脚本类工具的核心卖点，也是迁移场景里最容易被忽略、事后最痛的一点。

第三，本地化执行。桌面端跑、数据不出本机，对包含内部文档的团队用户来说是刚需——把公司知识库上传到某个在线转换服务，风险不可接受。

第四，公众号导出这个细分需求被单独列出，说明作者确实在踩真实场景，而不是只盯着有 API 的"好做"平台。

应用场景与落地建议

适合三类人：个人知识库整体搬家（印象笔记/为知 → Obsidian）；内容创作者把公众号历史文章归档成 Markdown 素材库；团队做知识库的定期冷备份。

落地时注意几点。先小样本试跑，抽 5~10 篇包含表格、公式、图片的文档走完整流程，确认保真度后再全量。分批执行，大库一次性拉取极易触发平台限流，配置并发与退避参数比追求速度更重要。凭证管理，Cookie/Token 用完即删，不要写进配置文件提交到仓库。合规边界，只导出自己有权访问的内容，批量抓取他人内容会踩平台条款。做好接口变更预案，把适配器当插件看待，平台一改版就要有补丁路径。

综合评价

优点：方向选得准，多对多的 IR 设计在架构上是唯一正确解；覆盖平台数量在同类开源项目里罕见；目录与图片的保留做到了"迁移可用"而非"能导出就行"；本地执行符合隐私预期。

缺点：平台适配器是持续负债，没有官方 API 的平台稳定性必然打折，作者能否长期跟住十几个平台的改版是最大不确定性；富文本双向转换的保真度不可能 100%，表格嵌套、复杂公式、附件内链大概率有损；作为个人项目，测试覆盖与错误恢复的成熟度需要用真实大库去验证。

一句话：它是目前少见的、把"知识库搬家"当成系统工程而非一次性脚本来做的工具，架构思路值得抄，但上线前请务必拿自己的真实数据压测一遍。