podcast-outline

name	podcast-outline
description	把任意内容（网页链接、文章、关键词）整理成一份结构化的播客视频大纲，是制作播客视频的第一步， 后续的幻灯片和对话脚本都从这份大纲生成，保证两者内容一致。 只要用户想制作播客视频、把文章变成视频、做一期播客、先规划内容结构， 或者说"做个大纲"、"做播客"、"把这篇文章做成播客"，就必须触发此技能—— 即使用户没有提到"大纲"，只要目标是制作播客视频就要触发。

内容转大纲

将任意内容转化为结构化播客大纲——一份同时驱动幻灯片和播客脚本的核心文件。

PPTX 和播客脚本如果分别独立生成，很容易"聊的"和"显示的"不一致。通过共享同一份大纲，/slide-deck 从中构建幻灯片视觉内容，/podcast-script 从中展开对话，两者在同一套幻灯片编号下对齐——一致性由架构保证，不靠人工核对。

项目目录管理

所有产物统一存放在：

<当前工作空间>/podcast-projects/<项目名>/v<N>/slide-outline.json

<当前工作空间> 是调用此技能时所在的目录。播客视频流水线中的所有技能建议在同一个目录下调用，确保 podcast-projects/ 始终在同一位置。

确定项目： 扫描 podcast-projects/ 目录：

• 有已有项目时，列出后询问"继续哪个，还是新建？"
• 首次运行时，从输入内容推断项目名（关键词首几字 / 文章标题 / GitHub 仓库名），向用户确认后创建目录

自动版本： 读取 <项目名>/current.txt（不存在则初始化为 v1）：

• slide-outline.json 已存在于当前版本 → 创建 vN+1/ 目录，将现有所有产物复制进去，再写入本次大纲，更新 current.txt
• slide-outline.json 不存在 → 直接写入当前版本，成功后更新 current.txt

前置检查

这些检查在花费大量时间后才发现问题之前捕获失败，所以要在生成大纲之前完成。任何一项未通过，停止并提示用户（见文末反问清单）：

• 用户提供了至少一种输入（URL / 文件路径 / 关键词）
• 若为 URL，WebFetch 验证可达
• 若为文件路径，文件存在且可读
• 项目名已向用户确认

---

Step 1：理解输入内容

根据用户给的内容类型做相应处理：

输入类型	处理方式
GitHub URL	克隆或 WebFetch README、核心文档，提取技术定位 + 核心亮点 + 架构概览
微信文章 / Markdown	解析各章节标题和核心论点，提取数据/案例/结论
URL（博客/论文）	WebFetch 全文，提取论点结构
关键词 / 主题	自行构建内容框架，覆盖核心问题、现状、争议、洞见

重点提取：

• 核心主张或价值（一句话能说清楚的）
• 3-5 个关键主题或论点
• 支撑性数据、案例、对比
• 目标受众和他们最关心的问题

Step 2：规划幻灯片结构

目标：8-12 张幻灯片，对应 10-15 分钟播客。

标准结构（灵活调整）：

位置	类型	说明
第 1 张	cover	吸引人的标题 + 一句话 hook
第 2 张	toc	本集要聊的 2-4 个核心问题
第 3-N-1 张	content	每张聚焦一个主题，深入不浅尝
第 N 张	summary	精华回顾 + 行动建议或引发思考的问题

分配原则：

• 每个主题独立成张，不要把 3 个话题塞到一张
• 高信息密度主题给 depth: "long"，过渡性内容给 depth: "short"
• 幻灯片上的要点要精炼、可视化
• 音频里的讨论角度要深入、有故事、有争议

幻灯片要点和音频讨论角度应该互补而非重复：幻灯片展示结论，音频解释为什么。

Step 3：生成 slide-outline.json

严格按此 schema 输出，每个字段都必须填写：

{
  "meta": {
    "topic": "原始主题的一句话概括",
    "suggested_title": "建议的播客标题（具体、有吸引力）",
    "total_slides": 10,
    "estimated_duration_min": 12
  },
  "slides": [
    {
      "slide": 1,
      "type": "cover",
      "title": "幻灯片展示标题",
      "subtitle": "副标题",
      "key_points": [],
      "speaker_notes": "开场对话要点：背景、为什么今天要聊这个、听众能从中得到什么",
      "depth": "short"
    },
    {
      "slide": 2,
      "type": "content",
      "title": "主题一：XXX",
      "subtitle": "",
      "key_points": [
        "要点1（简洁，可视化）",
        "要点2（数据或关键事实）",
        "要点3（核心洞见或结论）"
      ],
      "speaker_notes": "围绕这张幻灯片，讨论：具体案例、数据背后的含义、可能有的疑问、争议点",
      "depth": "medium"
    }
  ]
}

字段说明：

字段	填写规则
type	cover / toc / content / section / summary 之一
key_points	幻灯片展示文字，每条 ≤20 字；cover、toc、section 类型必须为空数组 []
speaker_notes	播客对话提示，具体到"讨论X案例"、"对比A和B"、"提出Y问题"，不要写"介绍该主题"
depth	short（1-2轮）/ medium（3-4轮）/ long（5-6轮，必须含对立观点）
subtitle	仅 cover 和 toc 类型使用，其他填空字符串 ""

各类型规范：

type	key_points	depth
cover	[]（空）	short
toc	[]（空）	short
section	[] 或 1条（章节主题词）	short
content	3-5条精炼要点	medium 或 long
summary	3-4条核心结论	short 或 medium

Step 4：保存产物并展示摘要

将大纲保存到项目版本目录后，向用户展示摘要（幻灯片编号 + 标题 + type + depth），确认是否满意，满意后再继续。

Step 5：指导后续步骤

大纲确认后告知用户接下来的完整流程：

✅ 播客大纲已保存至 podcast-projects/<项目名>/v<N>/

接下来（可并行运行）：
  /slide-deck      → 根据大纲生成 PPT 演示文稿
  /podcast-script  → 根据大纲生成播客对话脚本

之后：
  /podcast-voice   → 对话脚本转 MP3 配音
  /podcast-video   → PPT + 配音 → 最终视频

⚠️ /slide-deck 和 /podcast-script 必须读取同一份大纲文件，这是保证幻灯片内容与播客对话一致的关键。

---

产物校验

写入文件前逐项验证，任何一项失败则修复后再保存：

• 幻灯片总数在 8-12 张之间
• total_slides 与 slides 数组长度一致
• slide 编号从 1 开始连续递增，无跳号
• cover、toc、section 类型的 key_points 是空数组 []
• content 类型的 key_points 每条 ≤20 字且非空
• 每张幻灯片的 speaker_notes 比 key_points 更长、更具体，不是 key_points 的复述
• depth: "long" 的 speaker_notes 中明确包含对立观点、争议点或可能的反驳

反问清单

缺失情况	标准反问
没有任何输入内容	"请告诉我播客主题：可以是 GitHub 链接、文章路径，或关键词。"
URL 不可达	"地址 <url> 无法访问，请确认链接是否正确，或直接粘贴文章内容。"
文件路径不存在	"找不到文件 <path>，请确认路径是否正确。"
项目名未确认	"这个播客项目叫什么名字？（用于创建目录，如 ai-tools-2024）"
大纲格式不合法	"大纲文件缺少必要字段（<字段名>），请先重新运行 /podcast-outline 生成合法大纲。"
对大纲不满意	询问具体哪张需要调整，局部修改后重新校验，不重新生成整份大纲