播客学习笔记

总纲

本 skill 把一期 AI 访谈播客整理成“用约 1/4 时间就能 get 到嘉宾观点”的学习笔记。AI 领域前沿常无定论，嘉宾所讲是个人观点而非定论。LLM 的本分是忠实整理和转述嘉宾观点：不评判、不补充对立观点、不发挥己见。补充仅限无争议的基础概念扫盲。

对内容绝对忠实：不改原意，保留限定词，明确标注“事实 / 嘉宾观点 / 预测 / 存疑”。对呈现精心整理：结构清晰，好读，重点突出，能快速扫描，也能回到原文核对。

最终学习笔记的正文默认就是嘉宾观点的整理，不要反复写“嘉宾认为”“嘉宾说”“在嘉宾眼里”。只有内容来自 show notes、主持人、agent 基础概念补充、预测/暴论、转写存疑或来源不一致时，才显式标注来源或性质。

默认产物是 Obsidian/Notion 兼容的朴素 Markdown。只有用户明确需要时，才从 Markdown 轻量导出 PDF。不要做展示型 show notes、视觉文章、dashboard、报告、落地页或交互式 HTML。

架构

坚持双模型分工：

• 转写模型：音频 -> 文字稿。跑批、大量长期处理、重视免费和隐私时，推荐本地 FunASR（scripts/transcribe_funasr.py，优先带说话人分离）。单次/低频、希望省配置时间、可接受付费时，推荐云 ASR：通义 / DashScope、飞书等，使用 scripts/transcribe_cloud_asr.py 规范化结果。
• 写笔记模型：文字稿 -> 学习笔记。使用用户当前配置的 LLM/agent 环境完成。

不要把转写和写笔记焊死。如果 source/transcript.md 已存在，重写笔记、改风格、加深内容、重做术语表或自测题时都复用它。除非用户明确要求，或 transcript 缓存缺失/明显过期，否则不要重跑转写。

选择转写方案时先判断使用场景：

• 跑批/多期播客/长期使用：推荐本地 FunASR，一次配置后批量免费复用。
• 单次或少量播客：推荐通义/飞书等云转写服务，或用户提供已有文字稿/API 结果。
• 对专名准确率要求高：优先使用播客官方文字稿、飞书/通义等带编辑能力的文字稿，或用 show notes 辅助纠错。
• 本地 FunASR 未配置时：不要卡死；提示用户可改走云转写或直接上传文字稿。

输入与前置准备

支持三条输入路径，并统一汇合到 source/transcript.md：

• 音频 URL 或音频文件 -> 已配置 ASR -> source/transcript.md。
• .md / .txt 文字稿 -> 复制/规范化为 source/transcript.md，跳过转写。
• 小宇宙单集页 -> 运行 scripts/download_xiaoyuzhou_episode.py，提取音频到 source/audio.m4a，提取 show notes 和元数据到 source/show-notes.md，再按音频路径转写。

source/show-notes.md 只作为辅助元数据：标题、原始链接、发布时间、音频时长、节目简介、官方时间轴、嘉宾信息、正确专名线索。它不能替代 transcript，也不能覆盖 transcript 里的实际发言。若 show notes 与 transcript 冲突，标注“来源不一致”，默认以 transcript 作为事实底座。

工作区结构

在每期播客的工作目录里创建并使用以下结构：

source/
  audio.m4a
  show-notes.md
  transcript.md               # 原始/最终采用文字稿，Phase 1 的输入
  clean-transcript.md         # Phase 1 产物：清洗后的干净稿
  extraction-notes.md         # Phase 1 产物：纠错与存疑记录，不是 Phase 1 输入
  asr/
    funasr/
      transcript.md
      raw.json
      extraction-notes.md
    tongyi/
      transcript.md
      raw.json
      extraction-notes.md
extraction/
  question-skeleton.md        # Phase 2 产物：实质问题骨架 + 必须覆盖清单
  chunk-index.md
  chunks/
    chunk-001.md
    chunk-002.md
notes/
  notes.md
  notes.pdf
review/
  final-review.md
  repair-log.md
feedback-log.md

所有重要决策都要落盘，不能只依赖聊天上下文。若不确定某个决定是否已经确认，先回读对应文件。

流程

Phase 1：全文清洗

输入是 source/transcript.md、source/show-notes.md 元数据和 references/ai-term-corrections.md。注意：source/extraction-notes.md 是本阶段产出，不是输入；不要引用一个还不存在的文件。

目标是在切块前先把整篇 transcript 洗成稳定事实底座，产出：

source/clean-transcript.md
source/extraction-notes.md

重点修“危险专名错误”：专名被转成另一个正常词，句子读着通顺但语义全变，例如 skill -> scale、agent -> AG、prompt -> promote、ChatGPT -> 拆 GPT、Claude -> cloud。这类错误不容易露馅，必须用 AI 专名误转写对照表主动排查，而不是被动等待上下文暴露。

清洗规则：

• 用 show notes 的正确标题、嘉宾名、产品名、时间轴和专名线索纠正 transcript。
• 读取 references/ai-term-corrections.md，主动排查常见 AI 专名误转写。
• 修明显标点、断句、重复 header、坏空行和说话人切错。
• 保留时间戳和说话人标签；没有时间戳就不要编造。
• 对上下文强支持的专名错误可直接修正，并在 source/extraction-notes.md 记录。
• 拿不准的地方标“存疑”，不要硬改，不要臆造缺失内容。
• 保持口语事实，不做书面化改写，不消灭嘉宾表达里的限定词。

source/extraction-notes.md 应记录：采用的 transcript 版本、show notes 元数据、已修正专名、说话人映射、仍存疑的专名/句子/说话人切分。

Phase 2：提问题骨架 + 切块

输入是 source/clean-transcript.md 和 source/show-notes.md。从干净稿提取主持人的实质性提问，形成“问题骨架”，同时作为后续防遗漏的“必须覆盖清单”。实质提问是切块的强信号，但不是铁律；agent 需要结合嘉宾回答的连续性、主题是否真正转换、追问是否仍服务同一问题来判断切点。

产出：

extraction/question-skeleton.md
extraction/chunk-index.md
extraction/chunks/chunk-001.md
...

区分两类主持人发言：

• 实质提问：引出新话题、要求嘉宾解释概念/机制/判断/例子的发问。它可以作为问答单元切点。
• 附和、追问、过渡：如“对对对”“嗯”“那这样呢”“刚才说到”等，不单独作为切点，并入所在问答单元。

不要机械地“凡主持人开口就切”。这会切碎对话，也会斩断嘉宾的长回答。

切块规则：

• 优先按问答单元切块，而不是按固定字数或 show notes 每个时间戳硬切；但不要因为主持人提出了一个短追问就强行另起 chunk。
• 一块通常包含一个实质问题、必要的追问/附和、嘉宾完整回答。
• 对长回答可保留为同一 chunk，除非嘉宾明确进入新主题。
• 如果一个主题跨多个实质问题反复展开，Phase 2 可以分成多个问答 chunk；Phase 4 必须再把它们归拢到同一学习主题。
• question-skeleton.md 要列出每个实质问题、对应时间范围、所属 chunk、必须覆盖的核心内容。

Phase 3：逐块精读

逐块读取 extraction/chunks/*.md，抽取嘉宾观点、论证、限定词、具体例子和专名存疑。每块文件只做抽取和标注，不写成最终笔记。

每块必须包含：

• 主持人的实质问题。
• 嘉宾的核心回答。
• 嘉宾观点与事实陈述的区分。
• 关键限定词、前提、适用范围。
• 具体例子、类比、数字、工具/公司/产品/论文名。
• 专名存疑和转写断裂。
• 可用于最终笔记或自测的问题。

有框架、分类、成体系的内容必须完整抽取。例如“memory 三分类”“Harness 三层”“模型/上下文/工具优先级”。不要因为 chunk 靠后或内容复杂就草草带过。

Phase 4：重排整合

抛开问答顺序，按学习主题重组成 notes/notes.md。最终笔记主体是转述形式，不是逐块拼接，也不是主持人问答实录。Phase 2 的问答切块只是消化原料的办法，不能决定最终笔记结构。

写作前读取 references/note-template.md。合成时必须：

• 把散落在不同问答里的同主题内容归拢到同一节讲透。
• 对照 extraction/question-skeleton.md 的“必须覆盖清单”，确认每个实质问题对应的核心内容都进入笔记。
• 没有现成主题容器的核心内容要新开一节，不要因为不合当前结构就漏掉，例如 memory 三分类、PM 是否该懂 Harness 等。
• 只忠实转述嘉宾观点，不评判、不补充反方观点、不发挥己见。基础概念扫盲可以少量补充，但不能伪装成嘉宾原话。
• 正文默认以嘉宾观点展开，避免反复出现“嘉宾认为/嘉宾说/在嘉宾眼里”等归因套话；预测、存疑、show notes 来源、主持人观点或 agent 补充才显式标注。
• 遵循“有骨架的 prose”：解释用 prose 讲透，并列/分层/对比用结构呈现。
• 关键结论和关键定义挂 [mm:ss] 或 [hh:mm:ss] 锚点；若干净稿无时间戳，则不编造。
• 每节有可见的“带走点”，但不要机械写“学习要点：”固定尾巴。
• 避免两个极端：全 bullet 的机械档案；全散文、不可扫描的文章。

末尾另设可选的“经典 Q&A”模块：精选 2-4 段最有代表性、例子最生动的问答，以对话原貌保留主持人问 + 嘉宾答。它是最后的点缀，不影响前面按学习逻辑重排的主体。不要把整篇笔记写成 Q&A。

Phase 5：质检与修复

终审时读取 references/review-and-retrospective.md，并把质检结果写入 review/final-review.md。质检不是形式步骤，必须拿干净稿和问题骨架清单逐段核对。

核心检查：

• 用 extraction/question-skeleton.md 逐项核查：每个实质问题、每段核心回答是否已经进入 notes/notes.md。
• 用 source/clean-transcript.md 对照笔记逐段查遗漏。发现漏掉核心内容，先补回笔记。
• 查专名有没有漏改，尤其是正常词形的危险误转写。
• 查嘉宾限定词有没有被简化成绝对结论。
• 查是否把嘉宾观点写成事实，或加入 LLM 自己的评判/反方观点。
• 查有框架/分类/成体系内容是否完整，如 memory 三分类、Harness 三层、上下文机制等。
• 查关键结论时间戳是否来自干净稿，不能编造。
• 查“经典 Q&A”是否只是精选点缀，而非替代主体。

如果质检发现 fail 项，先修复 notes/notes.md，再汇报。只要做了修复，就写 review/repair-log.md。“只汇报不修复”不符合本 skill。

复盘模式

当用户说“复盘这个 skill”“review this skill”或类似表达时，进入复盘模式。读取过往 feedback-log.md，找出出现 3 次以上的问题类型，并提出对 SKILL.md 或 reference 的修改建议。用户明确确认前，不要自动修改 skill 文件。

每次完整运行结束后，向 feedback-log.md 追加：日期、播客标识、质检失败类型、实际修复项、需要观察的反复模式。

引用文件

• 第一次处理音频、配置本地 FunASR、运行 scripts/transcribe_funasr.py 做说话人分离转写，或解释用户应提供什么输入时，读取 references/funasr-local.md。
• 用户想用通义、飞书、讯飞、Deepgram 等云转写 API，或已经有云服务导出的 JSON/TXT/Markdown 结果时，读取 references/cloud-asr.md，并优先使用 scripts/transcribe_cloud_asr.py 规范化为 source/transcript.md。
• 处理小宇宙单集页、下载音频或提取 show notes 时，读取 references/xiaoyuzhou-source.md，并优先使用 scripts/download_xiaoyuzhou_episode.py。
• Phase 1 全文清洗前读取 references/ai-term-corrections.md。
• 写 notes/notes.md 前读取 references/note-template.md。
• 终审、修复或复盘模式前读取 references/review-and-retrospective.md。