Skills 生态评测写到第四轮，写作、翻译、SEO、PPT、数据处理这些「内容创作与办公」的显学赛道都已经被拆过一遍。但办公大类里还有一条隐性赛道始终没人系统评过：知识入库——怎么把一本电子书、一场会议、一次调研，自动变成你个人知识库里能检索、能复用的资产。
本期换一个评测口径：不再泛浏览市场榜单，而是以一台真实开发机的装机清单为样本。这台机器上装着 500 余个 Skills，其中围绕「知识库进出」形成了一条完整的产业链：上游有电子书获取件（zlib-download），中游有入库件（zlib-to-notebooklm、notion-knowledge-capture、obsidian-cli），下游有出库再创作件（ebook-to-article、knowledge-to-slides、knowledge-to-course）。三个阵营——Google NotebookLM 系、Obsidian 系、Notion 系——各自凑齐了整条流水线。本文横向对比这三条线，并深拆最有趣的一条链路：从电子书到 NotebookLM 的全自动入库。
一个事先声明：本期素材以本机装机实况为主要观察对象（外部目录抓取受限），评分依据是装机集成形态、命名分工结构与链路完整度这些可验证特征；无法确证的细节会明确标注，不编造 Star 数与作者信息。
先看本机装机清单里「知识库」赛道的真实阵容，按阵营归类：
| 阵营 | 装机件 | 角色定位 |
|---|---|---|
| NotebookLM 系 | zlib-download | Z-Library 电子书下载 |
| NotebookLM 系 | zlib-to-notebooklm | 电子书直送 NotebookLM |
| NotebookLM 系 | notebooklm | NotebookLM 基础操作件 |
| NotebookLM 系 | notebooklm-skill-master | NotebookLM 深度操作件 |
| NotebookLM 系 | ebook-to-article | 电子书转文章（出库侧） |
| Obsidian 系 | obsidian-cli | 命令行操控 Obsidian 库 |
| Obsidian 系 | obsidian-markdown | Obsidian 方言 Markdown 写入 |
| Obsidian 系 | obsidian-bases | Obsidian 数据库视图（Bases） |
| Obsidian 系 | obsidian:json-canvas | 白板画布文件生成 |
| Notion 系 | notion-knowledge-capture | 知识捕获入库 |
| Notion 系 | notion-meeting-intelligence | 会议智能纪要 |
| Notion 系 | notion-research-documentation | 调研文档沉淀 |
| 出库通用件 | knowledge-to-slides | 知识库转幻灯片 |
| 出库通用件 | knowledge-to-course | 知识库转课程 |
这张表本身就是本期第一个发现：知识管理类 Skills 已经从「单点工具」进化成「流水线」。没有人再单独发布一个「保存笔记到 Notion」的 Skill——发布者打包的是「捕获→整理→沉淀→复用」的完整动线。
mindmap
root((知识库赛道<br/>装机实况))
NotebookLM系
电子书下载 zlib-download
直送入库 zlib-to-notebooklm
库内操作 双件套
出库 ebook-to-article
Obsidian系
命令行 obsidian-cli
方言写入 obsidian-markdown
数据库视图 obsidian-bases
白板 json-canvas
Notion系
知识捕获
会议纪要
调研沉淀
出库通用
转幻灯片
转课程
三个阵营里，NotebookLM 系的链路设计最激进，值得单独拆开看。它回答的问题是：能不能让 Claude 自己找书、自己下载、自己塞进 NotebookLM，再自己产出内容？
从装机件的命名分工可以还原出这条链的四段结构：
flowchart LR
A["需求: 一本书"] --> B["zlib-download"]
B --> C["本地电子书文件"]
C --> D["zlib-to-notebooklm"]
D --> E["NotebookLM 笔记本"]
E --> F["notebooklm 双件套"]
F --> G["问答/摘要/音频"]
G --> H["ebook-to-article"]
H --> I["成稿文章"]
第一段：获取。 zlib-download 负责从 Z-Library 拿到电子书文件。这一段的设计要点不在下载本身，而在「格式适配」——下游的 NotebookLM 只吃 PDF/EPUB/TXT 等少数格式，所以获取件必须保证产出的文件能被下一棒接住。
第二段：投递。 zlib-to-notebooklm 是整条链的灵魂件。它要解决一个 awkward 的问题：NotebookLM 没有开放给第三方直接写文件的公开 API（截至本文写作，Google 仅提供有限的实验室接口，此点未经官方渠道证实，以 Google 官方文档为准）。因此这类 Skill 的实现路径基本只有两条：浏览器自动化（Playwright 模拟真人上传），或者引导用户手动完成「最后一公里」而 Skill 负责之前的一切。从该件与本机 playwright、chrome-automation 件共存的形态推断，走的是前一条路——这也解释了为什么装机清单里自动化三件套（playwright、chrome-automation、agent-browser）总是和它一起出现。依赖自动化件的入库 Skill，本质上是一个「流程编排说明书」，而不是独立工具。
第三段：库内操作。 notebooklm 与 notebooklm-skill-master 双件并存是装机清单里典型的「重影」现象：基础件管触发与常规操作，master 件管深度功能（多笔记本管理、来源追问这类重操作）。这和之前拆过的 pptx 官方件与社区件并存是同一个模式——社区先做基础版跑通，再有人做加强版收编深度用户。
第四段：出库。 ebook-to-article 把库里消化完的内容拉出来变成文章。至此闭环：一本书从「想读」到「产出可发布的内容」，中间人类只出手一次——点一下授权上传。
把 zlib-to-notebooklm 这条链拆完，能提炼出三条对想写 Skill 的人有用的模式：
回到横向对比。三条入库流水线各有鲜明的工程哲学：
定位：把「读」外包给 Google 的检索增强引擎，Skill 只负责搬运。 亮点：链路最完整，从盗火（zlib-download）到出稿（ebook-to-article）一站到底；NotebookLM 本身的音频概览、引文追溯是三家里最省心的增值功能，Skill 层几乎零维护成本。 短板：最依赖外部服务的稳定性——Google 改一版界面，自动化路径就可能断；数据出境到第三方云，对隐私敏感的库是硬伤；zlib 段还有版权灰色地带，企业环境基本不可用（此为合规常识判断，非法律意见）。
定位：知识库就是一堆本地 Markdown 文件，Skill 直接读写文件系统。 亮点：四件套分工是三家里最讲究的——obsidian-cli 管库级操作（搜索、打开、标签），obsidian-markdown 专攻 Obsidian 方言（callout、双链、frontmatter 的写法细节），obsidian-bases 对接 2025 年新增的 Bases 数据库视图，obsidian:json-canvas 生成白板。「方言专门件」是 Obsidian 系最值得抄的设计：Markdown 谁都会写，但写得不合 Obsidian 方言，双链图谱就废了——把方言知识单独成件，等于给整条链配了个校对员。纯本地、纯文本文件，零锁定。 短板：入库前的「内容加工」要靠 Claude 裸做，没有 NotebookLM 那种现成的检索引擎兜底；多设备同步是用户自己的功课；四件之间没有强制的链路约定，新手容易装了不会连。
定位：知识入库即建库入表，所有内容都是结构化数据库行。 亮点：三件套按「场景」而非「功能」切分——捕获（knowledge-capture）、会议（meeting-intelligence）、调研（research-documentation），这是产品经理式的设计，用户按场景触发，命中率高；Notion API 成熟稳定，是三家里唯一走正规军 API 路线的，自动化最不易断。 短板：写入 Notion 数据库需要预先配好 schema，字段对不上就写歪——开箱即用度最差；会议件与 Notion 日历深度耦合，非 Notion 日历用户收益减半；结构化的代价是灵活性，随手记一条灵感都要过数据库这一关。
| 维度（权重） | NotebookLM 系 | Obsidian 系 | Notion 系 |
|---|---|---|---|
| 功能完整度 25% | ★★★★★ 链路四段全通 | ★★★★ 四件分工全但靠人连 | ★★★★ 场景三件齐 |
| 设计质量 25% | ★★★★ 命名即链路 | ★★★★★ 方言专门件是范本 | ★★★★ 场景切分聪明 |
| 实战效果 20% | ★★★★ 省心但怕改版 | ★★★★ 本地稳、图谱增值 | ★★★☆ schema 门槛折损 |
| 上手难度 15% | ★★★★ 双件重影需辨析 | ★★★☆ 四件要自己组线 | ★★★ 需先建库配表 |
| 社区活跃度 15% | ★★★☆ 依赖上游波动 | ★★★★ Obsidian 生态热度高 | ★★★★ Notion API 生态成熟 |
| 加权总分 | 4.20 | 4.30 | 3.95 |
评分说明：基于装机集成形态与设计结构的可观察特征打分，社区维度参考的是所属平台生态热度（Obsidian/Notion 均为千万级用户产品）而非单个 Skill 的下载数——后者本期无法核实，故从严取平台级证据。
横评不能只看入库。装机清单里 knowledge-to-slides 和 knowledge-to-course 两个通用出库件，代表了这条赛道的终局想象：知识库的资产价值 = 入库成本与出库频次的比值。
这两个件的设计共同点是把「复用场景」写死在触发词里：做幻灯片、做课程是两个高频、高价值的再创作动作，与其让用户说「帮我把库里那本书的内容整理一下」（模糊、易触发失败），不如让 Skill 名字自带场景。这呼应了之前拆过的触发工程结论：Skill 的竞争一半发生在被调用之前。
值得注意的空白：出库侧缺少「转推文/转短视频脚本」这类高频社交场景件——本机清单里内容转化类的活儿目前由 content-repurposer 等通用件兼着。知识库赛道在出库端的场景细分，还没跟上入库端的密度，这是新入场者的机会窗口。
按使用场景选型（本机装机实况佐证）：
给想入场的开发者：入库赛道三家已成型，正面攻山头的窗口已关。剩余机会在：① 出库端社交场景细分；② 跨阵营搬运（Obsidian ↔ Notion 双向同步件，本机清单里尚无专职件）；③ 中文方言件——三家的中文内容处理都是裸奔状态。
知识入库是内容创作与办公大类里被低估的赛道：三家平台阵营已完成从工具到流水线的进化，而评测的真正分野不在功能多少，在数据主权归属——NotebookLM 把智力外包给 Google，Obsidian 把文件留在本地，Notion 把结构押在数据库上。选哪条流水线，本质是选你愿意把知识资产托付给谁。下一轮（Round 5）将转向工作流自动化类的部署、CI 与多 Agent 协作评测。
[!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 等场景全覆盖。