播客主理人的 AI 工作流——从访谈转录到下期选题，我是怎么把重复劳动全部消灭的

播客主理人的 AI 工作流

——从访谈转录到下期选题，我是怎么把重复劳动全部消灭的

作者：一只阿木木 我相信：在 AI 时代，每个普通人都该拥有一个自动生长的知识系统。

先说一个我做播客第一年的真实状态

我的播客做了两年了，叫什么不重要，重要的是：它差点死在第 14 期。

不是没有选题，不是没有嘉宾，是累死的。

一期 60 分钟的播客，我的工作量大概是这样的：

text

录制前：
- 准备嘉宾背景资料：2–3 小时
- 拟访谈提纲：1–2 小时
录制后：
- 粗剪音频：3–4 小时
- 写文字稿（给聋哑社群）：2–3 小时
- 整理访谈精华 + 金句：1–2 小时
- 写公众号推文：2–3 小时
- 做小红书卡片：1 小时
- 下期选题研究：1–2 小时
合计：约 14–18 小时/期

14–18 小时，还是在没有意外的情况下。

如果嘉宾的观点和我预期不同，访谈提纲要临时调整；如果文字稿出现了一个我不熟悉的概念，要花额外时间核实；如果下期选题想和本期形成呼应，我要翻回所有之前的期数……

第 14 期之后，我认真思考了一件事：这里面有多少工作是真正需要我来做的，又有多少只是信息处理？

答案是：70% 是信息处理，只有 30% 是真正需要我的判断和声音。

信息处理的部分，可以交出去。

我现在的工作流长什么样

两年后，同样一期 60 分钟播客，我的工作量：

text

录制前：
- 准备嘉宾背景资料：20 分钟（AI 自动生成嘉宾 wiki 页，我做复核）
- 拟访谈提纲：30 分钟（基于嘉宾页 + 主题图谱，AI 给框架，我调整）
录制后：
- 粗剪音频：3 小时（这个没办法，还是要人工）
- 把转录文本 ingest 进 wiki：10 分钟
- 写公众号推文：45 分钟（基于 wiki 生成的精华，我改写）
- 做小红书卡片：20 分钟（金句已经自动提取，排版而已）
- 下期选题：15 分钟（wiki 里的知识图谱直接给建议）
合计：约 5–6 小时/期（减少了 65%）

更关键的是：省下来的时间，不是变成了休息，而是变成了更好的内容。

我花更多时间在嘉宾关系维护上，花更多时间在提纲的深度打磨上，花更多时间在录制本身的状态上。

这才是 AI 工具应该做的事——不是替你变懒，而是让你的注意力流向真正重要的地方。

整个工作流的架构

在讲具体操作之前，先把全貌展示出来：

text

┌─────────────────────────────────────────┐
│              播客知识库（Obsidian Vault）  │
│                                         │
│  wiki/entities/persons/   嘉宾图谱       │
│  wiki/entities/companies/ 相关机构       │
│  wiki/concepts/           议题图谱       │
│  wiki/episodes/           期数归档       │
│  wiki/synthesis/          跨期综合       │
└────────────┬────────────────────────────┘
             ↑ ingest                     ↓ query
┌────────────┴────────────┐   ┌───────────┴──────────┐
│      .raw/ 输入区        │   │      output/ 产出区    │
│  transcripts/  转录文本  │   │  outlines/  访谈提纲   │
│  guest-bios/   嘉宾资料  │   │  drafts/    推文草稿   │
│  references/   参考资料  │   │  topics/    选题建议   │
└─────────────────────────┘   └──────────────────────┘

核心逻辑：所有进来的内容进 .raw/，所有出去的内容来自 wiki/ 的 query。

第一模块：录制前——嘉宾研究从 2 小时压缩到 20 分钟

传统方式的问题

以前我研究嘉宾的方式：谷歌搜索 + 手动浏览 + 脑记或乱记笔记。

效率低有两个原因：

1. 重复劳动：很多嘉宾在同一个圈子里，他们的背景信息有大量重叠，但每次都要重新查
2. 无法积累：研究完就用，下次再遇到同圈子嘉宾，之前的研究消失了

现在的方式：/autoresearch + 人工复核

第一步： 把嘉宾已有的公开资料整理成一个文本文件，扔进 .raw/guest-bios/：

Markdown

# 嘉宾：王某某
## 基本信息来源
- 微信公众号：xxx（历史文章约 200 篇）
- 知乎主页：xxx（高赞回答）
- LinkedIn：xxx
- 相关媒体报道链接：xxx, xxx, xxx
## 本次邀请的议题
AI 时代的产品设计方法论
## 我希望了解的方向
- 他的核心方法论是什么？
- 他和主流观点的分歧在哪里？
- 他最有争议的观点是什么？

第二步： 告诉 Claude：

text

ingest guest-bios/wang-xx.md
/autoresearch 王某某 产品设计 方法论 2023-2026年主要观点

Claude 会自动搜索、综合，生成一个结构化的嘉宾 wiki 页面：

Markdown

---
address: c-000089
type: entity
subtype: person
title: "王某某"
created: 2026-05-15
role: [产品经理, 创业者, 播客嘉宾]
appears_in_episodes: []    # ingest 转录后自动填入
related_companies: [[某公司], [某产品]]
related_concepts: [[精益验证], [产品-市场契合度]]
---
# 王某某
> 产品设计师，关注 AI 时代的人机交互方法论，
> 曾任职于 XX，现为独立顾问。
## 核心立场
{3-4 句话总结他最核心的观点体系}
## 主要方法论
### 方法一：{名称}
{来源 + 解释 + 我的补充问题}
### 方法二：{名称}
{...}
## 有争议的观点
{标注他说过的、在业界引发讨论的观点}
> [!question] 值得在访谈中追问
> 他在 [来源] 中提到了 X，但这和他在 [来源] 中说的 Y 似乎有矛盾，
> 可以在访谈中直接问他。
## 与已有 wiki 的关联
- 和上期嘉宾 [[李某某]] 在 [[精益方法论]] 上有明显分歧
- 他引用过 [[特斯拉的产品哲学]]，可以深入问
## 可能的访谈角度
1. {角度一}
2. {角度二}
3. {角度三}

最有价值的部分："与已有 wiki 的关联"——因为之前的嘉宾已经在 wiki 里，系统会自动发现新嘉宾和历史嘉宾之间的关联，让你能设计出有传承感的访谈。

第三步： 我做人工复核（10–15 分钟）：

• 核实关键事实（防止 AI 混淆）
• 补充我个人知道的信息
• 标注我最想深挖的 2–3 个方向

第二模块：访谈提纲——基于知识图谱生成框架

有了嘉宾 wiki 页面之后，生成访谈提纲只需要一句话：

text

基于 wiki 里的王某某页面和本期议题"AI 时代的产品设计方法论"，
生成一个 60 分钟访谈的结构性提纲，
要有开场热身、核心议题、争议追问、结尾三个部分，
并标注每个问题背后的"我真正想知道的是什么"。

Claude 生成的提纲不是一张问题清单，而是有层次的对话设计：

Markdown

# 访谈提纲：王某某 × AI 时代产品设计
## 开场热身（0-8 分钟）
目标：建立信任，让嘉宾进入状态
Q1: 你最近在做的一个产品决策是什么？
（不用问大问题，从具体的事情开始）
Q2: 在你看来，AI 进入产品设计流程之后，
最大的变化是什么？
（用来定位他的整体认知框架）
---
## 核心议题一：方法论的核心（8-25 分钟）
核心问题：你的产品设计方法论和传统的"用户研究→需求文档→迭代"
有什么本质不同？
追问策略（基于 wiki 里的背景信息）：
- 他在公众号里提到了"反需求文档"的概念，如果他没主动提，在这里追问
- 他和业界主流观点有分歧，如果他描述自己的方法论，
  可以说"我了解到 XX 大厂是用 YY 方法，你怎么看？"
> [!note] 这个问题背后我真正想知道的
> 他是真的有独特方法论，还是用新概念包装了传统方法？
> 如果是后者，也可以直接问：
> "你的方法和精益创业有什么本质区别？"
---
## 核心议题二：争议追问（25-45 分钟）
> [!contradiction] wiki 里标注的矛盾
> 他在 [来源A] 中说"用户永远是对的"，
> 但在 [来源B] 中说"大多数用户调研是无效的"。
> 这是直接追问的好机会。
直接问法：
"你在不同场合说过两句好像矛盾的话……你能解释一下吗？"
---
## 结尾（45-60 分钟）
目标：给听众带走一个具体的行动
Q: 如果今天听播客的人只能做一件事来改变自己的产品工作方式，
你建议他做什么？
（用 wiki 里他推荐的方法来做引导，但让他用自己的话说出来）
---
## 备用问题（如果时间多余或某个话题聊完了）
- [问题列表]
## 绝对不要问的问题
- 不要问"你怎么看待 ChatGPT"（太泛）
- 不要问"你未来的计划是什么"（采访常见废话问题）

这个提纲最有价值的部分是："这个问题背后我真正想知道的" 和 "wiki 里标注的矛盾"——这两个来自 wiki 知识图谱的信息，让访谈从"问问题"升级为"真正的对话"。

第三模块：录制后——转录文本 ingest 是整个流程的核心

这是整个工作流最关键的一步，也是和传统播客工作流差距最大的地方。

获取转录文本

现在的转录工具很成熟，我用的是 Whisper（本地运行，隐私更好）。60 分钟音频，转录约 10 分钟，准确率约 92-95%。

转录完的文本，先做简单的格式化处理：

Bash

# 把 Whisper 输出的带时间戳的转录，格式化成对话格式
python3 scripts/format-transcript.py input.txt > .raw/transcripts/ep47-wang-xx.md

格式化后的转录文本大概长这样：

Markdown

---
episode: 47
guest: 王某某
date: 2026-05-10
topic: AI 时代的产品设计方法论
duration: 63 分钟
---
# 第 47 期：王某某 × AI 时代产品设计
**主播**：欢迎来到……（开场白）
**王某某**：谢谢邀请……
**主播**：我想先从一个具体问题开始……
**王某某**：对，这个问题其实……
[全文约 12,000 字]

执行 ingest

text

ingest transcripts/ep47-wang-xx.md

一次转录 ingest 通常会触动 8–15 个 wiki 页面。

具体来说，这次 ingest 会做这些事：

1. 更新嘉宾实体页

之前 autoresearch 生成的 wiki/entities/persons/王某某.md 会被更新：

• appears_in_episodes: [ep47]（标注他出现在哪期）
• 补充他在访谈中说的新观点（和之前公开资料里的对比）
• 如果他在访谈中改变或更新了之前的立场，自动标注

2. 生成/更新概念页

访谈里提到的所有概念，会被提取并生成或更新对应的 concept 页面。比如他在访谈中提到了"最小可行认知"这个我之前没听过的概念，系统会：

• 创建 wiki/concepts/最小可行认知.md
• 记录他的定义、使用场景、和已有概念的关系

3. 生成本期 episode 归档页

Markdown

---
address: c-000091
type: episode
episode_number: 47
title: "AI 时代的产品设计方法论"
guest: [[王某某]]
date: 2026-05-10
duration: 63min
key_concepts: [[精益验证], [最小可行认知], [反需求文档]]
---
# 第 47 期：AI 时代的产品设计方法论
## 核心金句
> "需求文档的问题不是它存在，而是它假设你在开始写之前就知道答案。"
> —— 王某某，第 47 期，23:15
> "AI 不会替代产品经理，但会替代那种没有判断力、只会翻译需求的产品经理。"
> —— 王某某，第 47 期，41:30
## 本期核心观点
1. {观点一}（时间戳：MM:SS）
2. {观点二}
3. {观点三}
## 值得深挖的引申议题
- {议题一}（可以作为下期选题）
- {议题二}
## 与其他期次的关联
- 与第 [[ep23-li-xx]] 期在 [[精益方法论]] 上形成对话
- 王某某的观点和第 [[ep31]] 期嘉宾的观点有明显矛盾，见 [[产品方法论争议]]

4. 自动提取金句

系统会从转录文本里识别出有潜力成为金句的句子——依据是：独立成句、有明确立场、长度适中（15–50 字）。

这些金句直接进入 wiki/episodes/ep47/quotes.md，我写小红书卡片时直接用。

第四模块：内容分发——从 wiki 到多平台

有了 episode 归档页和自动提取的金句，各平台内容的生产变成了这样：

公众号推文（45 分钟）

text

基于 wiki/episodes/ep47/ 的内容，
写一篇 1500 字的公众号推文，
用第一人称视角，突出我和嘉宾对话中最有共鸣的 2-3 个时刻，
结尾要给读者一个明确的行动建议。

Claude 生成草稿，我做两轮修改：

• 第一轮：加入我自己的声音和感受（这是 AI 无法替代的）
• 第二轮：语感打磨（平均 15–20 分钟）

小红书卡片（20 分钟）

直接从 wiki/episodes/ep47/quotes.md 里选 5 个金句，配上模板设计，发布。

选金句的时间：5 分钟（金句已经自动提取了） 做卡片的时间：15 分钟（套模板）

Newsletter（如果你有的话）

text

基于 ep47 的内容，结合 wiki 里和本期主题相关的历史期次，
写一个 500 字的 Newsletter 段落，
重点在于"这期内容和我们之前讨论过的 X 话题有什么新的联系"。

这个 Newsletter 的独特价值——跨期联系——只有知识图谱在，才能做到。

第五模块：选题系统——播客不再有"选题荒"

这是整个工作流里我最意外的收获。

我以前觉得"下期选题"是需要灵感的事，是要靠冥想、刷推特、和朋友吃饭才能有感觉的事。

现在，我每期录完之后直接 query：

text

基于目前 wiki 里的所有内容，
给我 5 个下期选题建议，每个选题说明：
1. 它和已有期次的关联（形成对话还是开拓新方向）
2. 适合的嘉宾类型
3. 这个选题现在做的时机判断（为什么是现在）

Claude 读取了整个 wiki 里 47 期的嘉宾、概念、议题之后，给出的建议不是随机的——它是基于你已经建立的知识图谱，找到那些被多次触及但还没有被正面讨论的概念，或者两位嘉宾之间有分歧但还没有被正面对话的议题。

实际案例：第 47 期 ingest 完后，系统给了我这样一个选题建议：

Markdown

## 选题建议 2：产品直觉 vs 数据驱动
**wiki 里的发现**：
在 ep12、ep23、ep41、ep47 这 4 期里，嘉宾们对"是否应该依赖数据做产品决策"
有明显分歧：ep12 的嘉宾强烈支持数据驱动，ep47 的王某某认为数据会杀死直觉。
这个分歧在 wiki 里被标注为 [[产品决策方法论争议]]，但从未被正面讨论过。
**适合的嘉宾类型**：
最好能找到在大数据公司工作过、后来又做过消费品牌的产品人，
能同时理解两种文化。
**时机判断**：
AI 生成大量数据的今天，这个讨论比以往任何时候都更紧迫。
**关联期次**：
可以在开场时直接播放 ep12 和 ep47 里两位嘉宾相互矛盾的片段，
制造"对话感"。

这个选题建议，是我自己翻遍所有期次记录都想不到的——因为那个矛盾在第 4 期和第 47 期之间，跨度太大，人脑根本记不住。

知识图谱记住了。

进阶：多主播模式的并发锁

如果你的播客有两位以上的主播，都在往同一个 wiki 里 ingest，需要注意：

Phase 2 是单写模式。不要从多个 Claude 会话并行运行 ingest。scripts/wiki-lock.sh 提供文件级的建议锁：一个写入者获取锁，另一个等待并在下一轮重试。

实际操作：

Bash

# 主播 A 在 ingest 时，主播 B 等待
# wiki-lock.sh 会自动处理，不用手动干预
# 但要告诉搭档：不要同时触发 ingest 命令

我们两人的协作方式：每人 ingest 自己负责的那半期（我负责第一段，搭档负责第二段），然后我做统一的 lint 和 synthesis 更新。

真实数据：做了 2 年播客，wiki 里现在有什么

text

wiki 总览（第 47 期之后）：
嘉宾实体页：47 个（每位嘉宾一页）
出现的公司/机构：83 个
核心议题概念页：156 个
跨期 synthesis 综合页：31 个
自动提取的金句库：412 条
被标注的嘉宾间分歧：19 处
从未被正面讨论的议题（潜在选题）：23 个

那 23 个"从未被正面讨论的议题"——是两年内容积累之后，知识图谱自动浮现的宝藏。

每一个，都是一期有深度的潜在节目。

给想开始的播客主理人：先做这一件事

不用一次性改变整个工作流。

先只做这一件事：把最近 3 期的转录文本 ingest 进去。

text

ingest transcripts/ep-latest-1.md
ingest transcripts/ep-latest-2.md
ingest transcripts/ep-latest-3.md

然后问：

text

what do you know about 我们播客里讨论最多的议题是什么？

你会看到你自己的节目，用一种你从来没有看到过的方式呈现出来。

那个时刻，你会理解为什么说知识是复利的。

最后

做播客这件事，本质上是在做一件非常奢侈的事：把聪明人的思想提炼出来，给更多人听。

但这件事的大部分时间，我们都花在了"提炼"之外的事情上——整理转录、查嘉宾背景、找上期说了什么、想下期聊什么……

这些事情，现在可以交出去了。

把时间还给真正的对话，还给真正的思考，还给真正的声音。

播客里最值钱的东西从来不是信息量，而是主播的判断力和真实的人味儿。

AI 负责信息，你负责人味儿。

这才是正确的分工。

👇 如果你想继续跟着做：

关注「一只阿木木」，我们在 AI 时代一起构建自己的知识系统。

本文基于 claude-obsidian 项目（GitHub: AgriciDaniel/claude-obsidian，MIT 协议开源）实测撰写。播客工作流数据来自作者两年真实使用记录。