我制作了 Feishu2MD 的桌面应用，帮助你快速批量导出飞书文档

作为一款生产力工具，飞书文档的批量导出问题一直困扰着不少用户。好在社区里有现成的解决方案，比如基于 Go 语言实现的 Feishu2MD CLI 工具，它本身支持单文档、文件夹以及知识库的下载。今天要聊的，是一个基于它改造而来的桌面端版本，有图形界面，操作起来更直观一些。 其实飞书官方也有一套 Lark CLI，功能更全面，API 支持也更丰富，但看起来目前只能单个文件导出，做不到批量处理文件夹或知识库。如果说目标只是批量导出 Markdown，那 Feishu2MD 这条路径已经足够成熟好用。至于图片本地化、链接替换这些细节，官方 CLI 是否已经覆盖，我还没去验证。 说到底，做这个桌面端版本，最初的出发点就是给现有的 CLI 套一个图形界面，顺便塞进去一些我自己实际会用到的功能。虽然飞书未来可能会调整接口权限或文档结构，让这套东西失效，但现在用着还是挺顺手的。 # 主要优化点 与原版 CLI 相比，最直观的区别当然是图形界面 vs 命令行——对于不习惯敲命令的朋友来说，友好度不是一个量级。下面说说几个追加的特性。 ## 文档链接的智能识别 原版 CLI 里，下载单文档、文件夹、知识库需要用不同的命令；现在统一成了一个输入框，不管什么链接丢进去，程序会自动识别并路由到正确的处理逻辑。 还额外支持了知识库分享链接（即 `wiki/space` 格式）。原版 CLI 要下载知识库，得填设置页面的链接（`wiki/settings`），这其实不太符合直觉。现在两种链接都能识别，底层做了自动替换。 ## 文件名作为 H1 处理 提供了一个选项，可以选择是否把飞书文档的文件名作为一级标题插入正文最顶部。默认开启。考虑到有些同学已经在正文里加了一个 H1 Heading，取消勾选可以避免标题重复。 ## 文件重命名 原版 CLI 下载的文件名通常是一串由 URL 获取的文档 Token，本地保存后完全不知道内容是什么。现在增加了将文件名重命名为真实文档标题的选项，并且会自动把非法字符替换为下划线。 文档间的相互链接（Markdown 文件互相引用），虽然做了两遍扫描，但目前还没有完整测试过，如果使用中遇到问题欢迎反馈。 ## 图片存放路径 支持修改存放图片的本地文件夹名称，默认是 `static`，可以按习惯改成 `pic`、`image` 或 `assets` 等。图片文件夹会放在 Markdown 文件的同级目录下，方便后续迁移。 同时，Markdown 中的图片路径也改成了相对路径。原版 CLI 用的是绝对路径，移动文件后图片就失效了；相对路径没有这个问题。 ## 默认保存文件夹 桌面端版本会在指定位置下创建带时间戳的文件夹来保存导出结果。服务端因为浏览器下载的限制，会把所有内容打包成一个 ZIP 包再下载（保存位置遵循浏览器设置）。 # 安装和使用 可以从 GitHub Release 下载 Windows 和 Mac 版本的安装包。下载后只需要配置好飞书应用凭证，其他什么都不用做，直接就能用。 目前还没有签名，系统可能会提示不安全，安装时跳过警告即可。不放心的话，也可以把代码拉下来让 AI 检查后在本地构建，具体可以查看 README 中的说明。 如果需要在服务器部署或使用本地网页版，同样可以参照 README。服务器版和桌面版的下载核心机制和 UI 界面是通用的，支持通过 ENV 注入飞书应用凭证，防止滥用。 使用前需要准备飞书应用的凭证，步骤如下： ### 1. 获取应用凭证 登录飞书开发者后台，创建一个企业自建应用。应用名称和应用描述随便填，自己分得清就行。 在「权限管理」页面，搜索并开通以下**应用身份**权限（注意：是「应用身份」，不是「用户身份」）： - `docx:document:readonly` - `docs:document.media:download` - `drive:drive:readonly` - `wiki:wiki:readonly` 可以直接复制上面这串权限字符串进行搜索。整段复制到输入框后，对应的权限就会显示出来，全选开通即可。 创建版本并发布后，在「凭证与基础信息」中找到 **APP ID** 和 **APP SECRET**，填入 App 设置中。 ### 2. 配置文档权限 确保你要导出的飞书文档、文件夹或知识库已经开启了「互联网上获得链接的人可阅读」权限。 导出整个知识库时，请点击「分享知识库」→「将知识库发布到互联网」，复制该分享链接（而非单篇文章链接）。正确示例： `https://domain.feishu.cn/wiki/space/xxxxxxxx` ### 3. 开始导出 复制文档、文件夹或知识库的 URL，填入首页的输入框，点击「导出为 Markdown」就可以了。 Voilà，就这么简单。 # 开发碎碎念 说实话，我从来没做过桌面端 App，虽然只是通过 Tauri 打包了一下，整个过程中还是学到了不少有意思的东西。 最开始只是在 Google AI Studio 上随口说了一句，想给 Feishu2MD 做个 Web Wrapper，这样不管在哪都能用。结果它很快就生成了雏形，虽然最初只能导出单个文档还有 bug，但慢慢调试下来已经相当不错了。后来想干脆搞个桌面端，考虑到这个项目是用 Google AI Studio 起的头，就决定用 Google 自家的 Antigra vity 继续做下去。 平心而论，虽然 Antigra vity 号称是第一个用 Agent Manager 形式的 IDE，但我觉得它很难用……不过既然有 Google AI Pro 订阅，不用白不用嘛。 发现 Antigra vity 里的模型配额是这样的：Gemini 3.1 Pro High 和 Pro Low 是一个池子，Gemini 3 Flash 是一个池子，其他家的模型（如 Claude Opus 和 Sonnet）又是另一个池子。Google AI Pro 每月还有 1000 点 AI credits，本来以为只能在 Flow 里做视频用，后来发现其实跟 Antigra vity 是共用的。当 5 小时配额和周配额用完后，可以选择继续用这些点数。 看起来好像还不错？但我真的觉得 Google 做产品很乱。有阵子 Antigra vity 里面不管用什么模型都显示服务器忙，连 Flash 模型都忙，也不知道在干嘛。当时 Gemini CLI 也有问题，一直说我没有权限使用，但提示的是我正用着一个不属于我的 Google Cloud Project……退出重新登录也没用。当时好像很多人都有这个问题。 总之那段时间所有东西都用不了，只有 AI Studio 能用。AI Studio 倒是又更新了不少小功能，还单独把 Flow 拎出来做了个 Flow Music（虽然好像是原有产品改名），甚至还能做音乐 Playground（类似 Web App）。每次看到它更新我都在想：能不能先把坏了的东西修好？现在倒是都好了，都能用了。 Antigra vity 也只有 Plan 和 Fast 模式。Plan 就是先规划再执行，Fast 直接执行。但有时候感觉 Plan 和 Fast 也没啥区别，它也没给我真的 Plan……被其他工具惯坏了，我挺希望能有开箱即用的 Debug 模式，不用自己配置。 关于发布 Release 版本，因为不想每次都自己打包再手动上传，所以 AI 帮我写了一个 workflow 文件。现在的流程是：打上版本 tag 后 push 到 GitHub，自动触发 GitHub Actions，自动运行打包任务，完成后创建一个 Release Draft，我看没问题就可以点击公开。 最初调试的时候那些 Action Jobs 都失败了。怎么办呢，我可不会改。想着给它配好了 GitHub MCP 也开了 Actions 读取权限，那就让它自己排查错误吧。但就是修不好。后来烦了，直接把 Error Message 贴给它，一下子就修好了…… 所以到底是我哪里没做对，还是 GitHub Actions 本身就比较难搞？不过既然已经跑通了，暂时也不会去碰其他的 Release，这个问题就先放着吧。 Anyways，祝大家使用愉快！