本期是 Skills 生态拆解第 4 轮，方向内容创作与办公。先自证不是炒冷饭：本栏存档里内容管线已点亮十二格——写作（sepia 系）、人格、说服弹药、审美供给侧、PPT 三路线、图表五强、白板手绘、知识迁移、会议语音、知识写回、办公数据层、说服层，连素材进口端都在 09-01《素材入口类 Skill 横评》里拆过一次。但回看那期的名单会发现一个共同点：defuddle、youtube-transcript、summarize 全是「轻件」——它们运进上下文的是现成的文字。素材世界里还有另一半是重货：视频本体、电子书文件。搬运重货的两个下载器——video-downloader 与 zlib-download——从未在任何一期当过主拆对象，进入本栏视野的方式全是装机注册表和竞品注脚。本期把这两件拎出来首拆，配上 youtube-transcript 的存档分（09-01 期 4.50）做轻重对照，再把「重进料 → 轻加工 → 成品端」的全景管线补画完整。
mindmap
root((进料层))
重货下载器
video-downloader
zlib-download
轻货直取
youtube-transcript
defuddle
wikipedia-research
落盘加工
transcribe
ebook-to-article
zlib-to-notebooklm
下游成品端
book-to-short-videos
content-repurposer
拆书产线
先看一个装机侧的结构信号：本会话注册表里，进料层相关名字至少十一个——两个下载器、三个轻件（youtube-transcript、defuddle、wikipedia-research）、三个加工件（transcribe、ebook-to-article、zlib-to-notebooklm）、外加下游的 book-to-short-videos 与 content-repurposer。这条链上一期都没缺席过，唯独第一格从来没被单独看过一眼。
| 工位 / 技能 | 功能完整度 (25%) | 设计质量 (25%) | 实战效果 (20%) | 上手难度 (15%) | 生态活跃度 (15%) | 加权总分 |
|---|---|---|---|---|---|---|
| youtube-transcript（存档照印） | ★★★★★ | ★★★★ | ★★★★☆ | ★★★★★ | ★★★★ | 4.50 |
| video-downloader（黑箱估※） | ★★★★ | ★★★ | ★★★☆ | ★★★★ | ★★★ | 3.50 |
| zlib-download（黑箱估※） | ★★★☆ | ★★★ | ★★★ | ★★★★ | ★★ | 3.13 |
评分口径：youtube-transcript 一行为 09-01 期标准五维存档分，照印不复议；两件下载器为本期装机侧黑箱估分※——功能维度基于名字语义与已知依赖生态（yt-dlp、Z-Library 系脚本）推断，设计维度按本栏《起名即路由》确立的命名排他与场景承诺标准评分，活跃度按「榜单零曝光、装机常备」的隐形件口径压低。若与读者实测不符，应以上游正文为准修正。ebook-to-article 与 zlib-to-notebooklm 因 06-20、06-29 两期存档口径不同（变现/新星榜维度），不入加权表，只作定性对照。
定位：把视频本体下载到本地磁盘。08-27 期给过它一句精准的注脚——「下的是视频本体，重得多」——当时它是 youtube-transcript 的竞品注脚，本期把它扶正：它和 youtube-transcript 根本不是竞品，是同一管线的两个舱段。轻件取的是字幕文本（token 直接进上下文），重件取的是字节本体（文件落盘，占的是磁盘）。要写书评视频、要做二创切片、要离线剪辑，字幕是不够的，必须有人把原片搬回来。
亮点：功能完整度四星来自依赖底座——视频下载在 CLI 世界是被 yt-dlp 反复锤炼过的成熟工程，格式、画质、分段的坑早被填平，Skill 层只需要把调用纪律写清楚※。这也是本栏 09-01 期提炼的「CLI 说明书化」模式的延续：采集是确定性工程，SKILL.md 要写的不是「怎么下载」，而是「什么时候调 CLI、参数怎么给、文件落到哪」。重件比轻件把这套模式推得更极端——下载没有任何「智能」空间，纯粹是搬运。
短板：实战效果三星半的原因有二。其一，它产出的是文件而非 token，agent 要继续加工必须再接一件转写或抽帧工具，管线比轻件长一截；其二，平台服务条款是悬在所有视频下载器头上的剑——这决定了它永远拿不到榜单曝光（详见后文结构观察）。另外「video-downloader」这个名字只承诺了「视频」和「下载」，分辨率上限、平台覆盖面、是否含字幕文件，全部要靠正文或试错确认※。
一句话：管线第 0 站的搬运工，不出产知识，但决定下游有没有米下锅。
定位：电子书获取。它是本栏书稿线的最后一格空白：06-20《一书七变》拆了书变成什么（ebook-to-article 深度长文，功能近满分、社区短板），06-27《拆书即爆款》拆了书怎么被萃取，09-03《把书变成课》拆了教学重组端七件，09-11《视频工厂》拆了 book-to-short-videos「输入一本书、输出四件套」——四期文章的输入都写着「一本书」，但没有一期问过这本书从哪来。zlib-download 就是这个没人问的问题的答案：名字里 zlib 三个字母直指 Z-Library 系书源※。
亮点：与 video-downloader 同构——书源获取同样是 CLI 世界的成熟工程，Skill 层的增量在调用纪律与落盘约定※。设计质量给三星是因为「zlib-download」五个音节把书源、动作全部写死，触发上没有歧义；上手四星，装机即用。
短板：两处，一处技术一处合规。技术上，它的实战效果被源站可用性绑架——书源站点的域名漂移与访问波动是这类件的经典故障面（此为这类工具的共性推断※，非实测），实战三星是保守分。合规上必须说透：Z-Library 是阴影图书馆，版权状态因地而异。这不是它的「缺陷」，是它的存在方式——但也正因如此，它的使用边界必须由使用者自己画清：个人学习、已购内容的格式转换、公有领域书目是安全区；任何形式的再分发不是。企业环境与商用管线，这格应该空着，或换成公开书源（古登堡计划、Open Library）的等价件——这个「合规壳」工位目前装机端和市场端都是空白。
一句话：书稿四期文章共同缺席的那个问题，答案踩在灰色地带上。
把 09-01 期的轻件和本期两件重件放进同一张表，进料层的分工就清楚了：
| 轻件（youtube-transcript / defuddle） | 重件（video-downloader / zlib-download） | |
|---|---|---|
| 产物 | 纯文本，直接进上下文 | 文件，落盘 |
| 消耗 | token | 磁盘与带宽 |
| 加工链 | 到此即可用 | 必须再接转写/提取/转换件 |
| 可复用性 | 一次性消耗 | 原始资产，可反复加工 |
| 榜单可见性 | 存档有分、有曝光 | 零曝光，只以注脚形态存在 |
youtube-transcript 的 4.50 断层第一不是偶然：agent 时代的进料最优解是让字节在进上下文之前先变成 token——轻、快、对 token 友好，这三个词 08-27 期就写下了。但轻件有一个结构性短板：它丢掉了原始资产。字幕不等于视频，正文不等于网页。当下游要做的是切片、混剪、引用原片时间戳之外的视觉信息时，只有重件能供货。轻件是「读」，重件是「存」，成熟的进料配置是轻重各一、按需取用。
flowchart LR
subgraph G1["重货进料"]
A["video-downloader"] --> A2["磁盘视频文件"]
B["zlib-download"] --> B2["磁盘电子书"]
end
subgraph G2["轻货直取"]
C["youtube-transcript"] --> C2["字幕文本"]
D["defuddle"] --> D2["网页正文"]
end
A2 --> E["transcribe 转写"]
B2 --> F["ebook-to-article 长文"]
B2 --> G["zlib-to-notebooklm 喂料"]
C2 --> H["拆书与二创下游"]
E --> H
F --> H
G --> H
H --> I["成品 短视频 图文 课程"]
接线说明：G2 舱段的产物不需要中转，直接喂下游；G1 舱段的产物必须先经加工件（transcribe 转写、ebook-to-article 提纯、zlib-to-notebooklm 喂给 NotebookLM——后两件分别有 06-20 与 06-29 的存档分背书，前者功能近满分，后者 3.65 并被归入「语料喂料桥」）。09-11 期视频工厂那篇有个精彩的观察：三件主件互不调用，「共享的是上游产物格式，用文件约定解耦」。本期补的是这条观察的上游延长线——文件约定解耦的前提，是先有东西落成文件，而把东西落成文件的正是重件。
本栏已记录过两次「星数经济失灵」：09-10 期发现表格件「装机端常备编制、市场端零印刷位」，因为表格产出的验收权在打开 Excel 的用户手里，不能靠截图自带背书；09-07 期发现说服层「市场零曝光、装机重库存」，因为味道能截图、效果没法截图。本期是第三例，也是最好解释的一例：你无法晒一张「我下载成功了一个视频」的截图。搬运本身不产出任何可展示物，星榜的展示经济对它彻底失灵。于是这两件在全栏存档里的存在方式高度一致——不是主拆对象，是竞品注脚和命名标本。可它们又是装机注册表里的常驻编制。市场榜在读「谁值得炫耀」，装机表在读「谁离不开」：进料重货属于后者。
市场件检索（skills.sh 提供的 CLI）：
npx skills find video-downloader
npx skills find zlib-download
npx skills find youtube-transcript
装机确认：本会话注册表中 video-downloader、zlib-download 已在册（~/.claude/skills/ 目录可复核）。
文件型技能的最小骨架（以视频下载器为例）——注意它与轻件骨架的一个关键差异：
name: video-downloader
description: 下载视频本体到本地磁盘。当用户需要保存视频文件、离线
剪辑、取原片素材时使用；只要字幕文本时改用 youtube-transcript。
（正文：yt-dlp 调用参数、画质与格式选择、落盘目录约定、合规边界）
三个要点：其一，description 里写清与轻件的让位规则（「只要字幕时改用 X」）——同管线轻重件并存是触发歧义的高发位；其二，落盘目录约定是轻件不需要写而重件必须写的一段——轻件产物进上下文，重件产物进磁盘，没有目录约定的下载器会把用户的工程目录变成垃圾场；其三，正文里写明合规边界，给自己也给模型划出拒绝的空间。
进料层到本期才算画完：轻件把世界变成 token，重件把世界变成文件。前者赢得榜单和存档分，后者赢得磁盘和依赖——而星数经济对搬运失灵的第三例证明，一张装机注册表比十张星榜更接近生态的真相。对使用者，配置口诀是「一重一轻」：视频链 video-downloader 加 youtube-transcript，书链按需决定是否引入 zlib-download——引入之前先想清楚自己的合规红线。对作者，下载器给出了 SKILL.md 写作的一条新规范：产物落磁盘的技能，必须写落盘约定、让位规则与拒绝边界三段——写给人看的文档可以省，写给 agent 的文档里，这三段就是刹车。
~/.claude/skills/）— video-downloader、zlib-download、youtube-transcript、defuddle、transcribe、ebook-to-article、zlib-to-notebooklm、notebooklm、book-to-short-videos、content-repurposer 等件名字与家族结构的实证来源[!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 等场景全覆盖。