本专栏拆了四十多个主题，视频、部署、浏览器、调研、PPT 全都上了台，唯独有一层一直没人碰：声音层。音频进文本出的转录件、视频进字幕出的字幕件、文本进音频出的朗读件——这三件是装机目录里最新补齐的空工位。本轮早期挖掘的核心发现一句话：声音层是整个 Skills 生态里「薄封装、重依赖」的典型段位——SKILL.md 本身极薄，智能全在下游模型和上游命令行工具里，件与件的设计差距不在功能数量，而在失败面处理和输出落点约定。另需说明：本轮写作环境检索受限，不列 star 数与更新日期等无法当场核实的数字，评的是结构与设计；装机版原文请以各仓库为准。
先交代选题逻辑。回看已拆清单：进料端拆过下载器，出料端拆过视频工厂和 PPT 线，中间的浏览器、调研、部署、安全、办公各层都有横评。但「耳朵和嘴巴」这一层始终空白——直到最近装机目录里才陆续补进 transcribe、youtube-transcript、speech 三个名字，外加两个邻居件 notebooklm 和 zlib-to-notebooklm。
这符合新星首发的一贯规律：生态补层总是从「最疼的地方」开始。做内容的人要给视频上字幕，做研究的人要把播客变文字，做自动化的人想让 agent 跑完任务出声报信——三拨人三种疼，对应三个工位。这条线没有巨头件，没有全家桶，全是小而实用的单件，正是早期挖掘最值得下铲的地方。
评分口径：编辑部基于装机端结构观察与生态通行实现评估；「上手难度」星越多越容易装；「社区活跃度」以分发广度为代理指标，未核实精确数据。
| 维度（权重） | transcribe | youtube-transcript | speech |
|---|---|---|---|
| 功能完整度（25%） | ★★★★ | ★★★ | ★★★ |
| 设计质量（25%） | ★★★★ | ★★★ | ★★★ |
| 实战效果（20%） | ★★★★ | ★★★★ | ★★★ |
| 上手难度（15%，星多=易） | ★★★ | ★★★★★ | ★★★★ |
| 社区活跃度（15%） | ★★★ | ★★★★ | ★★★ |
| 加权印象 | 4.0 | 3.6 | 3.2 |
定位：本地音频进，带时间戳的文本出。会议录音、播客、课程音频，都是它的进料。
这类件的通行实现是 whisper 系——本地跑 faster-whisper，或走云端转写 API。它的 SKILL.md 通常只干三件事：探测音频参数（时长、格式、语言）、选模型档位、把输出落成 md 或 srt。真正的重活全在脚本里：长音频切片、并发转写、拼回时间轴。这是全赛道最典型的「薄 SKILL.md 厚脚本」结构——prompt 层负责决策，脚本层负责苦力，官方 pptx、docx 两件用的也是这套模具。
亮点：把「选哪个模型」这种决策收进了件里。小文件用小模型秒出，长音频自动切片再拼装——这一步靠纯提示词工程做不到，必须落脚本，所以它也是声音层里脚本含量最高的一件。
短板：依赖最重的一件。本地跑要 Python 环境加模型权重，从几百 MB 到几 GB 不等；走 API 要 key。装完不等于能用。更普遍的边界是说话人分离：多数版本不做 diarization，多人会议稿出来是一锅粥，你得自己认谁说了哪句。选购前先问自己一句：有没有 GPU？愿不愿意付 API？两个都没有，就先装下一件。
定位：给一个 YouTube 链接，拉回官方字幕或自动字幕，落成纯文本。
通行实现走 youtube-transcript-api 或 yt-dlp 的字幕导出，零模型、零权重、纯 HTTP 请求。对「把视频当资料源」的人——做简报的、做拆解的、要喂 NotebookLM 的——这是刚需件。
亮点：全赛道上手成本最低。没有 GPU 要求，没有 key 要求，装上就能跑，实战命中率也最高，因为大量目标视频本来就有字幕。
短板：命门在「有没有字幕」。纯演示、冷门语言、刚发布还没出自动字幕的视频，它直接空手而归；自动字幕还没有标点、不分说话人。要认清它的本质：它是取现成的，不是造新的——和 transcribe 是互补关系，不是替代关系。
设计观察：这类件的 SKILL.md 里最有价值的部分是错误分支文案。没拿到字幕时，写得好的版本会提示「该视频无字幕，建议改用 transcribe 本地转写」——两个件在文档里互相指路，这是装配线思维，说明作者脑子里有整条流水线，而不只是一个函数。
定位：反向工位。文本进，音频出。前三件都是「让 agent 听见」，只有它是「让 agent 开口」。
通行实现是 edge-tts 这类免费合成引擎（音色多、零成本），或接云端 TTS API；macOS 上也有人直接挂系统的 say 命令。用途比想象中广：长任务跑完语音播报结果、长文校对换耳朵过一遍、给视频草稿配临时配音。
亮点：它补上了自动化闭环的最后一厘米。之前拆自动化栈时留过一个断言——「件都强，线不通」；朗读件至少让线的终点能出声了。
短板：实战效果最依赖口味。音色、语速、断句全是主观分；中文多音字和断句的翻车率不低。多数版本没有 SSML 级的精细控制，长文本要切片合成再拼接，接缝处的停顿处理比较糙。
设计观察：好的朗读件会把输出落点定死——比如固定输出 mp3 到指定目录、文件名带时间戳；坏的版本让你在对话记录里捞临时文件路径。输出约定是这类件设计质量的试金石，比功能列表更能暴露作者的工程段位。
装机目录里还有两个邻居值得点名：notebooklm 和 zlib-to-notebooklm。后者把电子书喂给 NotebookLM，产出双人播客式的音频 Overview——这是声音层的第二条路径：transcribe 把已有音频变文本，它把已有文本变音频对话，互为逆过程。装机端把这几个件放在相邻位置，说明作者也意识到这是同一条线。对想搭「听书流水线」的人，这条邻居路径的上手成本更低，但内容可控性也更低——播客里聊什么，你说了不算。
这一节是给想自己动手写一件的读者的。声音层三件放在一起看，能提炼出四条可复用的写法。
声音层件的典型目录结构分三层：
transcribe/
├── SKILL.md # 上层面包：判断、决策、选工具
├── scripts/
│ └── transcribe.py # 中间是肉：切片、调用、拼接
└── references/
└── troubleshooting.md # 下层面包：依赖安装与故障排查
SKILL.md 只写「什么情况用什么模型、输出落到哪里」，重活全部下沉到 scripts。这个结构不是声音层发明，官方件的模具早就是这么开的——但声音层把它用得最彻底，因为它天然是「一个决策 + 一堆苦力」的形状。你写自己的件时，先问一个问题：我的 SKILL.md 里有没有一句「应该执行的命令」？有，就该下沉到脚本；SKILL.md 里只该有「什么时候执行、参数怎么定」。
转录件的边界场景清单，直接决定一件的档位：
好件把这份清单写进 SKILL.md 的常见问题节，坏件让你自己读 stderr。判断方法是装之前瞄一眼它的 SKILL.md：数一数「失败分支」的段落数。一个失败分支都不提的件，大概率只在作者自己的音频上跑通过。
md、srt/vtt、txt 三种落点，对应三种完全不同的下游：md 是喂给大模型做摘要的，srt 是上字幕的，txt 是进检索库的。一个件支持几种落点、每种落点的默认值选得对不对，暴露了作者对「这坨文本最后被谁消费」的理解深度。声音层最怕的不是转不出来，是转出来了但下游没法直接用——比如给 LLM 的稿子里塞满毫秒级时间戳，token 全浪费在坐标上。
声音层件的最大风险不是不能干，是乱触发。用户说「帮我看看这个视频」，不该惊动字幕件；说「把这段整理一下」，不该惊动转录件。description 里堆触发词人人会写，「何时不用」的否定条款才见功力。官方模板对 description 的要求本来就是两段式：做什么，加何时用——社区件普遍只写了前半句。你写自己的件，description 里至少留一句「如果不是 X 场景，不要用本件」。
flowchart LR
subgraph IN["进料"]
A["本地音频文件"]
B["YouTube 链接"]
C["写好的文稿"]
end
subgraph MID["声音层三工位"]
T["transcribe 转录件"]
Y["youtube-transcript 字幕件"]
S["speech 朗读件"]
end
subgraph OUT["出料"]
D["可检索文本"]
E["合成音频"]
end
A --> T
B --> Y
T --> D
Y --> D
C --> S
S --> E
D --> N["投喂 NotebookLM"]
注意图里的关键事实：三工位之间没有直接连线。字幕件空手而归时要靠文档里的错误文案把用户导向转录件——件与件的衔接目前靠约定，不靠机制。这也是整个 Skills 生态的通用现状：单件越来越强，线还是靠人脑拼。
用 skills CLI 先搜后装，名字以搜索结果为准：
# 搜索确认仓库
npx skills find transcribe
npx skills find youtube-transcript
npx skills find speech
# 安装（仓库名以 find 结果为准）
npx skills add youtube-transcript
手动路径：到 skillsmp.com 搜件名 → 进对应 GitHub 仓库 → 把整个件目录拷到 ~/.claude/skills/ 下即可。转录件装完先跑一段一分钟的小音频验环境，别拿两小时的会议录音当第一次测试。
说明：本轮写作环境检索权限受限，未附 star 数、更新日期等未能当场核实的数字；三件的逐行原文请以各自仓库为准，本文评的是赛道结构与设计模式。
[!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 等场景全覆盖。