夜雨聆风
如果你经常让大模型帮你写代码，就会发现一个很现实的问题：真正影响结果的，往往不是模型会不会写代码，而是它能不能拿到准确、完整、没有过期的官方文档。
网上搜索当然可以解决一部分问题，但搜索结果可能混入旧版本说明、第三方教程、论坛回答和截断的代码示例。尤其是调用大模型 API、配置 SDK、使用最新模型参数时，拿错一页文档，后面生成的代码就可能从第一行开始走偏。
因此，我更倾向于把需要使用的官方文档先下载到 Obsidian，再把这些 Markdown 文件交给大模型编程工具读取。这样做的重点不是收藏，而是建立一份可靠的本地知识库，让模型直接面对官方内容，而不是每次都重新猜测应该搜索什么。
问题在于，各家大模型文档网站的组织方式完全不同。有人提供标准的 llms.txt，有人只维护 sitemap，还有网站使用 Sphinx、Docusaurus 或 Google DevSite 生成文档。过去如果想批量下载，通常需要针对每一家网站单独编写程序，处理目录发现、页面链接、相对地址、分页、图片和重复内容，维护成本很高。
现在，obsidian-clipper-wechat-feishu插件新增了“收藏整个说明文档”功能，目的就是把这件事从编程任务变成一个简单的收藏动作。
插件地址：https://github.com/destineylu/obsidian-clipper-wechat-feishu
它不是无边界地抓取网页
这个功能的关键，不是把当前网站所有链接都递归爬一遍，而是先寻找站点自己提供的官方索引。
扩展的发现层支持标准 llms.txt，包括 Mintlify 等平台生成的文档索引，也支持 sitemap、Sphinx、Docusaurus 和 Google DevSite。因此，Kimi、智谱、DeepSeek、Claude、Gemini 等主流大模型文档，只要站点提供了受支持的官方索引，就可以按同一套流程处理，不需要为每个域名单独编写下载器。
这点非常重要，因为页面清单必须来自官方索引，而不是普通网页里的任意链接。这样既能减少误抓营销页面、博客文章和登录页面，也能让最终保存下来的内容更接近网站真正维护的文档集合。例如需要编写调用falai的api来调用图片、视频生成程序，网站的说明文档无疑会给大模型减少难度及出错的机会，把它全部下载下来喂给大模型使用是最便捷的方法。
第一步：安装并启用桌面端配套插件
使用整套文档收藏，需要安装并启用桌面端 Clipper Attachment Bridge 配套插件。这个插件不会出现在 Obsidian 社区插件商店中，需要按照项目提供的方式安装。
启用后，它负责把浏览器扩展与当前运行的 Obsidian 连接起来，让扩展可以把提取到的 Markdown 内容写入本地 Vault。
这里有一个容易忽略的前提：浏览器扩展选择的 Vault，必须与 Obsidian 当前打开的 Vault 是同一个。如果连接成功但选错了 Vault，文件可能会被保存到另一个位置，后面用大模型读取时就会以为文档没有下载成功。
第二步：在 Web Clipper 中配置连接
打开 Web Clipper 的 设置 → General → 飞书 / Lark，填写桌面端配套插件地址和配对令牌。
默认地址通常是：
1 http://127.0.0.1:27125 填写完成后点击“测试连接”，确认扩展能够连接到桌面端 Companion，并再次确认扩展选中的 Vault 就是 Obsidian 当前打开的 Vault。
这一步不只是配置流程，它实际上决定了后面的批量写入是否能正常进行。如果按钮不出现、写入中断或者文件没有落到预期目录，优先检查配套插件是否启动、令牌是否匹配，以及 Vault 是否选对。
第三步：打开支持的文档页面
打开一个支持的文档页面，例如 Sphinx 文档，或者提供 llms.txt、sitemap 等官方索引的主流大模型文档站，然后打开 Web Clipper，等待页面提取完成。
提取完成后，在紫色 Add to Obsidian 按钮上方，会看到一个单独的 收藏整个说明文档 按钮。它和普通的当前页面剪藏不是一回事：普通剪藏只保存正在浏览的页面，而这个按钮会根据官方索引发现整个文档集合。
如果没有看到这个按钮，可以先刷新当前文档页面，再重新打开扩展。PDF、浏览器内部页面，以及没有受支持官方索引的普通网页，目前不支持整套文档收藏。
第四步：确认语言、数量和保存方式
点击“收藏整个说明文档”后，扩展会显示当前文档的标题、当前语言、预计页面数量和保存方式。确认这些信息没有问题，再选择要保存的 Vault 和文件夹。
按章节模式保存时，每个文档页面会生成一篇 Markdown，同时生成一个 00 - Documentation index.md 作为文档索引。这样做比把所有内容堆成一篇超长笔记更适合后续交给大模型使用，因为模型可以根据目录和文件名定位相关章节，也方便你单独更新某一页内容。
保存过程中，图片会保留官网远程链接，不会把大量图片文件全部复制到本地。模型卡片、功能卡片等网格内容，会转换为 Obsidian 可以渲染的自适应卡片块；页面中的相对链接，也会转换成完整的官网地址，避免离开原目录后链接失效。
同时，处理过程会清理 llms.txt 中重复的索引提示，以及空的标准元数据，让最后的 Markdown 更适合直接阅读和提供给编程模型。
新版 Companion 可以断点续传
整套文档收藏和单页剪藏最大的区别，是它可能需要写入几十甚至上百个文件。因此新版 Companion 采用分批写入并保存断点的方式，不会因为一次任务稍大就必须从头开始。
只有全部页面和文档索引都成功落盘后，任务才会被标记为完成。如果中途网络波动、Obsidian 关闭，或者配套插件暂时不可用，再次执行时会继续处理尚未完成的页面。
重复收藏同一套文档时，扩展只会覆盖这个文档集合此前生成的笔记，不会覆盖你后来新建的其他笔记，也不会自动删除官网已经下线的旧页面。这个策略比较适合长期维护文档库：官方新增的页面可以补进来，官方下线的内容仍然保留在你的本地历史中。
100 页以内还有一个备用方案
如果文档不超过 100 页，但 Companion 暂时不可用、尚未配对、连接到了其他 Vault，或者版本过旧，确认框会提供“合并为一篇 Markdown”模式。
这个模式适合临时把一套较小的文档交给大模型阅读，操作门槛比较低。但它不适合作为大型文档库的长期结构，因为所有章节会集中在一篇文件里，后续检索、更新和让模型按章节引用都会不如多篇笔记清晰。
超过 100 页的文档，则必须连接支持可恢复文档集合的新版 Companion，并按文件夹和多篇笔记保存。对于大模型编程来说，这种保存方式也更合理：你可以只把 API 认证、模型列表、错误码或 SDK 示例所在的文件交给模型，而不必每次加载整套文档。
这套方法真正解决的是什么
它解决的不是“我想把网页存进 Obsidian”这么简单的问题，而是“我想给大模型提供一套准确的编程参考资料”。
以前遇到不同的大模型平台，我往往需要先研究它的文档结构，再写脚本下载页面，最后还要处理各种特殊情况：有些站点的目录在 sitemap 里，有些站点依赖 JavaScript 渲染，有些站点的 Markdown 索引里会重复列出页面，还有些站点的相对链接离开原网站之后就无法使用。
现在，使用者不需要先理解每个平台的内部实现，也不用为了偶尔下载一次文档维护一套爬虫程序。只要站点提供受支持的官方索引，扩展就能用统一的发现方式找到页面，再按照统一的规则写入 Obsidian。
这对 AI 编程尤其有价值。你可以把某个模型平台的完整 API 文档下载下来，放进一个独立文件夹，然后在编程时明确告诉大模型：“请只参考这个文件夹中的官方文档，不要根据记忆猜测参数。”模型仍然可能犯错，但至少它面对的是一份可检查、可更新、来源明确的资料，而不是一组不确定的搜索结果。
写在最后
如果你只是想保存一篇文章，普通的 Web Clipper 已经足够；如果你要让大模型编程，尤其是调用不同平台的 API、SDK 和工具链，那么保存整套官方文档会更实用。
它把原本需要为每家网站单独写程序的工作，压缩成了配置 Companion、打开文档、点击一个按钮。对偶尔使用的人来说，这是节省时间；对长期使用 AI 编程的人来说，这更像是在 Obsidian 中建立一套可以持续更新的官方文档资料库。
如果你还不熟悉这个扩展此前对特殊平台内容的保存方式，可以先阅读下面两篇文章：
如果你平时已经在用大模型写代码，不妨先挑一个最常用的平台文档试一次。真正用过之后，你会发现，给模型准备一份准确的官方资料，往往比反复修改错误代码更省时间。