装机侧却是另一个世界。本会话注册表可直接核验：transcribe（转写）、speech（语音输出）、notion-meeting-intelligence（会议智能）、notion-knowledge-capture（知识捕获）四件齐装，外加 notebooklm 可做对照位。再拉宽一点看，语音/记录相邻件还有 youtube-transcript 和 notebooklm-skill-master，广义聚类能点到 7 件。还有一个此前没人注意的车皮现象：本机 Notion 系整装 4 件（knowledge-capture、meeting-intelligence、research-documentation、spec-to-implementation），Obsidian 系也整装 4 件（cli、markdown、mermaid、bases）——两大 PKM 各占一节车皮，但会议线的全部货物都装在 Notion 车皮上，Obsidian 四件里没有一件与会议相关。这个不对称是本文第一条硬观察：会议办公的沉淀路径，在装机环境里被单边绑定到了一个文档平台。
权重沿用本栏目固定口径：功能 25%、设计 25%、实战 20%、上手 15%（越高越容易）、社区 15%。
| Skill（装机） | 管线站位 | 功能 | 设计 | 实战 | 上手 | 社区 | 加权 |
|---|---|---|---|---|---|---|---|
| notion-meeting-intelligence | 会后·纪要与行动项 | ★★★★ | ★★★★ | ★★★ | ★★★ | ★★★ | 3.50 |
| notebooklm（对照位） | 会前·材料预习（名义） | ★★★★ | ★★★ | ★★★★ | ★★★ | ★★★ | 3.45 |
| transcribe | 会后·转写 | ★★★☆ | ★★★ | ★★★☆ | ★★★★★ | ★★ | 3.38 |
| notion-knowledge-capture | 会后·沉淀 | ★★★☆ | ★★★☆ | ★★★ | ★★★ | ★★★ | 3.25 |
| speech | 播报·TTS 输出 | ★★★ | ★★★ | ★★☆ | ★★★★ | ★★ | 2.90 |
评分说明：全部为装机侧黑箱估分。五件 SKILL.md 正文均未读取，功能/实战维度基于名字语义、生态绑定关系与同赛道已核验存档（xlsx、baoyu-translate、第二大脑一文）的对照推断；社区维度以生态背书与装机可见度为代理指标。若与读者实测不符，应以上游正文为准修正。
四件里唯一用「能力名词组合」命名的件。拆这个名字：meeting 圈定场景，intelligence 承诺的不只是纪要——按行业通行语义（名义推断），它至少应该覆盖要点归纳、决策点提取、行动项与责任人识别三件事。对照上期把书变成课一文提炼的「名字即规格」定律（arxiv-paper-to-wechat-article 用输入→输出三要素卡死触发），这件走的是另一条命名路线：不承诺输出格式，承诺输出智能。好处是场景弹性大，坏处是验收标准模糊——纪要写得好不好没有 goldie 那种平台硬规格可依，这正是它实战分只给三星的原因之一。
真正值得警惕的是它的绑定结构。会议线的中间站（转写）和输出站（TTS）都是无主通用件，唯独「会议智能」这一站装在 Notion 车皮上——意味着纪要的产生、存储、检索被整体锚进一个文档平台的数据模型。本站第二大脑一文（2026-05 存档）量过这笔账：Notion Skills 的 MCP 连接开销约为普通 Skill 的 4.6 倍。把这笔账平移到会议场景，结论不太舒服：一次会议纪要的边际成本，大头可能不在「理解录音」，而在「写回平台」。会议线最值钱的一站被平台生态攥住，这就是装机端显示的权力结构。短板如实列两条：强依赖 Notion 工作区与 MCP 链路的稳定性；纪要写入的是平台私有格式，换平台即断粮——对比 Obsidian 系全部走开放 Markdown 方言，这节的迁移成本结构性偏高。
transcribe（转写，加权 3.38）。 名字即功能的最简形态：音频进、文本出。它的加分在上手——转写是模型原生能力兜底的成熟任务，几乎零配置期望；它的短板在设计——名字里没有任何场景词、格式词、语言词，与 youtube-transcript 的边界、说话人分离能力、输出格式（srt/txt/md）全部要靠正文或试错才能确认（名义，未验证）。更要紧的是站位：它是文件转写件，不是会议实时字幕件——会议开完才有输入，会中现场它帮不上忙（此判断基于命名的保守推断）。
speech（TTS，加权 2.90）。 全表垫底，但垫底原因值得说透：它是通用介质件，不是会议件。会议场景对 TTS 的真实需求极窄（纪要播报、无障碍朗读），它的主战场在播客、旁白、视频配音——本站音频内容一期（2026-05 存档）已把 TTS 赛道单独拆过。把它放进会议线评分表是刻意为之，为的是暴露一个结构事实：会议线在装机环境里没有一件自己的端点件。耳朵借通用转写件，嘴借通用 TTS 件，唯独脑子被 Notion 垄断。对照 headcount 用部门路由解决 125+ 技能的检索问题，会议线缺的正是一个「meeting 路由器」——把录音、转写、纪要、行动项四个动作收进一个场景入口，按流程自动调度下面三件通用件。
notion-knowledge-capture（沉淀，加权 3.25）。 名字把「捕获」这个动作写进了场景：会议之后、纪要之前还有一道工序——把讨论中冒出的结论、待办、灵感从对话流里打捞进知识库。它与 meeting-intelligence 构成 Notion 车皮上的上下游双件：前者管「这次会说定的东西」，后者管「值得长期记住的东西」。被低估的原因是它看起来只是 meeting 件的子集，但组织行为学意义上的真实瓶颈恰恰在沉淀——纪要没人看，沉淀才有人用（此为一般性判断，非实测）。同样的绑定风险照抄第三节，不重复计分。
notebooklm（对照位，加权 3.45）。 放进会议线是因为它有一个从未被本栏目写过的反向用法：会前预习。NotebookLM 的本体能力是把文档变成对谈式音频概览（此为该产品公开形态，非本文实测），装进 Skill 层意味着开会前把 60 页背景材料灌进去、路上听完再进会议室。这个用法是本文的推断而非任何存档记载，但它把会议线唯一空着的会前端补上了一半——用的是别家车皮上的件。它的扣分在 Google 生态绑定与音频单向性：听完了，笔记还得手动落。
把五件按会议生命周期摆上流水线，空位一目了然：
flowchart LR
subgraph PRE["会前（半空）"]
A1["议程生成 ✗ 零装机零上榜"]
A2["材料预习 △ notebooklm<br/>反向用法为推断"]
end
subgraph MID["会中（空）"]
B1["实时字幕 ✗<br/>装机transcribe是文件件"]
end
subgraph POST["会后（满员）"]
C1["转写 transcribe"]
C2["纪要+行动项<br/>notion-meeting-intelligence"]
C3["沉淀 notion-knowledge-capture"]
C4["播报 speech（弱场景）"]
end
subgraph BACK["回写（空）"]
D1["行动项→日历/工单 ✗<br/>零装机零上榜"]
end
A2 --> B1 --> C1 --> C2 --> C3
C2 -.-> D1
C1 --> C4
两张空位券（会前议程、行动项回写）与一张半空券（实时字幕）为什么没人施工？本文给两个解释，都标为推断。其一，平台截胡：主流会议平台的自带 AI 纪要已成行业标配（常识层判断，本文未引用具体市占数据），会中段的独立工具窗口已被平台原生功能关死；其二，验收模糊：议程和待办回写都没有 goldie 式的硬规格，输出好坏难被星数奖励——本站变现半场一文的结论在此反向成立：规格越软的格位，市场越不给票。由此推出这条线在 Skill 生态里的正确形态：不做平台已经做掉的「纪要」，做平台不会做的「跨平台回写」——把 Notion 纪要里的行动项推回日历、issue、工单，这一步没有任何会议平台愿意替竞品做，也没有任何文档平台愿意替协作链下游做。
五件装机样本均无公开仓库可考（Notion 系与 transcribe/speech 的上游出处未经核实），不提供克隆命令，给验证与检索命令：
# 验证本机会议线装机（成本为零，30 秒）
ls ~/.claude/skills | grep -iE "meeting|transcribe|speech|notion"
# 市场侧检索（本轮未能联网验证返回结果，命令本身来自 Skills CLI 通行用法）
npx skills find meeting-minutes
npx skills find transcribe
# Notion 系技能依赖 MCP 连接，启用前先核对本机 MCP 配置与额度
# 参照本站存档：Notion 连接开销约为普通 Skill 的 4.6 倍，重装前先算账
把装机端五件摆上流水线，会议办公的完整地形第一次成形：中段（转写→纪要→沉淀）三站齐备且全部通车，会前半空，会中与回写两端零施工，而满员的中段里最值钱的一站被单边绑进了 Notion 车皮。市场零上榜与装机有货的落差，在这条线上比知识迁移线更极端——因为会议纪要的日常需求远比「把书变成课」大众。这不是生态的疏忽，是生态的理性：平台把最容易变现的中段做成了原生功能，Skill 层只剩软规格的边角。但对独立开发者而言，边角里有一张明确的图纸——跨平台回写，那个所有平台都不肯替别人做的动作。下一期值得回答的问题已经留好：如果把 transcribe、meeting-intelligence、knowledge-capture 三件串成一条「开会→行动」的无人管线，第一张多米诺骨牌该立在哪个回写终点——日历、issue，还是工单？
[!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 等场景全覆盖。