播客学习笔记
总纲
本 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。
