Slides Video

Slides-Video · 幻灯片驱动的口播视频

制作"一张 PPT 对应一段口播"的结构化视频。本 skill 沉淀的是制作方法和校对流程,不是某一次的视觉风格 —— 风格由用户决定、由下游 skill 实现。

---

Pre-flight · 依赖检查与 slides skill 选择

本 skill 是编排 + 方法层,自己不生成幻灯片 —— 它调用一个幻灯片生成 skill + video-planner。

不固定某一个 slides skill —— 从当前可用的里选

开工前先确定用哪个幻灯片 skill:

1. 识别候选 —— 会话里能产出单文件 HTML 横向翻页 deck 的 skill 就是候选。常见的有 magazine-web-ppt、guizang-ppt-skill、frontend-slides —— 但以本次会话实际列出的为准,不要假设某个一定在、也不要硬编码某一个。 2. 0 个可用 → 不要自己手写 deck 逻辑。告知用户当前没有可用的幻灯片生成 skill,并推荐安装一个再继续,例如:

• frontend-slides —— https://github.com/zarazhangrui/frontend-slides
• 也可让用户用 find-skills 搜索安装

装好后回到第 1 步重新识别。 3. 正好 1 个 → 直接用它,并在开工时告诉用户用的是哪个。 4. 多个可用 → 必须用 `AskUserQuestion` 跟用户确认选哪个(列出候选 + 各自风格特点),不要替用户拍板。

选定后,后文所有「调用 slides skill」都指这个选中的;video-planner 固定用于脚本与发布素材。任一必需依赖不可用就停下告知用户 —— 不要自己重写 deck / 脚本生成逻辑(那样会失去与生态的一致性)。

建议并行调用 personal-chinese-writing-style 确保语言风格跟作者一致。

---

适用场景

适合 —— 任何需要用 slides 搭配口播讲解的视频:

• 发布解读(新模型、新产品、新版本)
• 产品评测 / 技术讲解
• 论文 / 报告 / 行业数据拆解
• 多主体横向对比
• 趋势观察 / 现象评论

不适合 —— 纯教程(用通用 video-planner 够了)· 纯屏幕演示(slides 不是主体)· 短视频 / Shorts。

---

核心原则 · 本 skill 的方法学

这 4 条是贯穿整个工作流的方法原则。不涉及具体风格,只规定做事的方式。

1. PPT-脚本 1:1 同步

每张 PPT 页 = 一段脚本。录视频时翻页 = 切段。

• 脚本每段开头有切页标记:【PPT 切到 Slide N · 页名】
• 视频总时长 ≈ 页数 × 平均每页 30-50 秒
• 页数预算参考:
• 5-6 分钟 → 约 9 页
• 7-8 分钟 → 约 13-15 页
• 3-4 分钟 → 约 6-7 页

这个 1:1 约束是本 skill 相对通用 video-planner 的核心增量,不可妥协。

2. 语言面向目标受众,而非内部专家

无论受众是 AI 爱好者、开发者还是普通用户:

• 首次出现的术语必须用人话解释一句,不能裸用 jargon
• 用 类比 / 比喻 替代抽象名词(让观众能在头脑里形成图像)
• 每段结尾点出"对受众意味着什么" —— 把技术点翻译成受众能感受到的场景 / 价值
• 数字要带参照系 —— 不要堆"30%"、"1.6T"这类裸数,给参照("相当于 X"、"比上代 Y 倍")

谁是受众在 Step 1 跟用户对齐。不同受众,解释深度和比喻选择不同。

3. 叙事框架二选一

开工前必须决定:

• 单主角 —— 深度拆一个话题/产品 · 页面呈线性展开
• 多主角 —— 多个话题/产品同框对比 · 页面按"每主角独立幕"组织

这决定页面结构。不要含糊开写,中途很难改。

4. 生成后必做 QA 审核

PPT 生成完必须验证:

• 每页内容不溢出 foot 区域(overflow audit)
• 语言风格 / 术语密度 / 用户视角落脚是否到位(语言复审)

详见 references/overflow-audit.md。

修复原则 —— 改内容,不改模板。模板(CSS / 组件)是所选 slides skill 的维护范围,本 skill 不动它。

---

工作流程

每一步都指向 references/ 里对应的方法指引。

Step 1 · 需求澄清

问用户(已给的跳过):

1. 主题 —— 讲什么?(必填) 2. 叙事框架 —— 单主角 vs 多主角?(默认:单主角) 3. 目标时长 —— 大约几分钟?(默认 7-8 分钟) 4. 目标受众 —— AI 爱好者 / 开发者 / 普通用户 / ...?(默认:AI 爱好者) 5. 参考资料 —— 推文 / 论文 / 博客 / 源码仓库? 6. 视觉风格 —— 是否继承某个已有项目的风格?(给 URL / 项目路径) · 还是全新开始?

第 6 条很关键 —— 本 skill 不规定风格,风格由用户在这里指定。继承已有项目的话,在 Step 5 把相应配置原样传给所选 slides skill。

Step 2 · 资料研究

详见 references/research-method.md。核心:

• 用 WebFetch / WebSearch 拉推文、公告、报道
• 用 Read 读论文 PDF(支持 pages 参数提取特定页)
• 用 Explore agent / Grep / Glob 摸代码仓库
• 关键数据带来源记录 —— 每个跑分 / 价格 / 日期记下出处,方便 foot 行引用

Step 3 · 规划结构

详见 references/planning.md。先画页面节奏表、跟用户确认,再动笔。

规划产物:N 页 × 每页主题 + 主题 class(light/dark/hero light/hero dark) 的表格。

Step 4 · 创建输出目录

按项目惯例建:

{output-dir}/{YYYYMMDD}-{slug}/
├── ppt/
│   ├── index.html         # 由所选 slides skill 生成
│   └── images/            # (可选)插图
├── script.md              # 由 video-planner 生成,本 skill 加 1:1 标记
├── youtube.md
├── bilibili.md
└── x.md

Step 5 · 调用所选 slides skill 生成 PPT

用 Skill 工具调用 Pre-flight 选定的那个幻灯片 skill,传入 Step 1 和 Step 3 收集到的配置:

• 主题色(用户指定 / 继承参考项目)
• 页面节奏表
• 内容(按 Step 3 规划 + Step 2 研究)

本 skill 不规定主题色、不规定封面 / masthead 样式 —— 这些由用户选择和所选 slides skill 负责实现。不同 slides skill 的页面类型 / 模板约定不一样,按它自己的来。

Step 6 · 调用 video-planner 生成脚本 + 发布素材

用 Skill 工具调用,并应用本 skill 的方法增强:

• 在 script.md 每段开头加切页标记 【PPT 切到 Slide N · 页名】
• 在 script.md 顶部加 PPT 同步说明注释
• 每段结尾落到"对受众意味着什么"
• 其他细节见 references/script-method.md

发布素材(youtube/bilibili/x)的详细约定见 references/publishing-method.md。

Step 7 · QA 审核

详见 references/overflow-audit.md。

两类审核:

• overflow 审核 —— 用 chrome-devtools MCP 跑 JS 扫每页,≤ 5px 才算过
• 语言复审 —— 通读 script + PPT,检查术语密度、用户视角、比喻合理性

Step 8 · 迭代

用户反馈后的调整:

• 修改都用 Edit tool(surgical edit),不整文件 rewrite,方便用户看清每次改动
• 内容改写优先,模板不动
• 迭代后重新跑 Step 7 的 overflow 审核

Step 9 · 完成报告

简短清单:

视频制作完成,产物在 {目录}:
├── ppt/index.html         — N 页 PPT(全部 0 overflow)
├── script.md              — N 段口播(带切页标记)
├── youtube.md / bilibili.md / x.md — 发布素材

PPT 已在浏览器打开,可以开始录制。

---

工程注意事项

风格选择交给用户

本 skill 的原则是 方法固定 · 风格开放:

• 主题色、品牌名、masthead 文案、封面设计 —— 都由用户在 Step 1 决定或继承参考项目
• 本 skill 不规定具体视觉方案

如果用户想沿用之前某期视频的风格,在 Step 5 把该项目的 PPT 配置传给所选 slides skill(主题色、封面结构、品牌元素等)。注意:继承的风格最好出自同一个 slides skill,跨 skill 继承可能因模板体系不同而需要适配。

不要自动发布

只生成文件,不调用任何发布 API。用户手动发布。

复用个人推广信息

video-planner 会从 auto memory 的 video-promo.md 读取作者的固定推广块。本 skill 信任这个机制,不重新发明。

文件夹命名

统一 {YYYYMMDD}-{slug} 格式。日期默认取视频制作/发布日(不是产品发布日),除非用户指定。

---

Examples

已有的产出可以作为参考,但不应视为必须复制的风格 —— 下次的视频可以保留同一套风格(作为系列),也可以完全另起一套视觉:

• 单主角深度版参考 —— src/content/videos/20260424-deepseek-v4/
• 多主角对比版参考 —— src/content/videos/20260424-frontier-releases/

参考它们的 结构方法(页面节奏、1:1 同步、用户视角落脚、overflow 控制),而非具体视觉(主题色、品牌名、masthead 文案)。

---

Critical Rules

1. 显式调用所选 slides skill + `video-planner` —— 不自己重写 deck / 脚本生成逻辑;slides skill 不固定,从当前可用的里选,多个候选时用 AskUserQuestion 跟用户确认 2. 先规划后动手 —— Step 3 的页面节奏表必须跟用户确认 3. 1:1 同步不妥协 —— 每张 PPT 对应一段脚本,每段脚本开头带切页标记 4. 每段必须有受众视角 —— 技术点必须翻译成受众能感受的价值 5. 术语首次出现必解释 —— 不假设受众懂 6. 风格由用户决定 —— 本 skill 不钉死主题色 / 品牌名 / 具体页面设计 7. PPT 生成后必须 QA 审核 —— overflow ≤ 5px 才算完 8. 修内容,不改模板 —— overflow / 术语问题通过改内容解决,不改 CSS 9. 不自动发布 —— 只产文件,用户手动发

QA 审核方法 · PPT 溢出 + 语言复审

本文档规定生成完 PPT 和脚本之后的 QA 审核流程。这是纯方法,不涉及任何风格。

---

何时审核

• Step 7 · 生成完 PPT 和脚本之后必做
• 任何一次 slide 内容修改之后重做审核
• 用户反馈迭代之后重做审核

---

一 · PPT 溢出审核

工具

用 chrome-devtools MCP 做自动化审计。不可用时退化到 playwright MCP。

审核流程

1. 打开 PPT

mcp__chrome-devtools__new_page(url="file:///{abs-path}/ppt/index.html")

等加载完。

2. 跑 JS 审计脚本

() => {
  return Array.from(document.querySelectorAll('.slide')).map((s, i) => {
    const foot = s.querySelector('.foot');
    const footRect = foot.getBoundingClientRect();
    let max = 0;
    s.querySelectorAll('*').forEach(el => {
      if (el.closest('.foot') || el.closest('.chrome') || el === s) return;
      const r = el.getBoundingClientRect();
      if (r.height === 0 || r.width === 0 || el.children.length > 3) return;
      const o = r.bottom - footRect.top;
      if (o > max) max = o;
    });
    return {s: i+1, o: Math.round(max)};
  });
}

这段 JS 返回每张 slide 最大 overflow 像素值。

通过标准 —— 每页 `o ≤ 5`(抗锯齿误差范围)。

3. 视觉核查可疑页

对 o > 15 的 slide,截图人眼再看:

// 切到第 N 页
() => { document.querySelector('#deck').style.transform = 'translateX(-{N-1}00vw)'; }

mcp__chrome-devtools__take_screenshot(filePath="/tmp/slide-N.png")

Read 截图看是不是真的压到 foot 上了。

Hero 页特殊情况

Hero 页(封面 / 章节幕封 / 大引用等)因 min-height:82vh + align-content:center 的渲染特性,JS 检测值可能略偏高(5-15px 假阳性)。配合截图人眼核查 —— 视觉不压 foot 就 OK。

---

二 · 修复原则 · 改内容,不改模板

优先顺序:

1. 删冗余信息 —— 一行 meta-row 没必要? 删。callout 跟正文重复? 删。 2. 精简文字 —— 长副标写短,多段压一段。 3. 减项 —— 5 行表格改 4 行,6 张 stat 卡改 4 张。 4. 分页 —— 内容必要但一页装不下,拆成两页(页数预算 +1)。

不允许:

• ❌ 改模板 CSS(字号 / 间距 / padding) —— 那是所选 slides skill 的维护范围
• ❌ 加 overflow:hidden —— 会截断内容
• ❌ 改 min-height —— 会破坏节奏

常见溢出场景与修法

---

三 · 语言复审

PPT / script 的语言审核。跟 overflow 审核一起做。

审核维度

1. 术语首次出现是否有"人话"解释?

• 扫一遍 script,检查有没有"光秃秃"的技术术语没带解释
• 扫一遍 PPT 每页,检查 step-title / stat-label 等是否术语过密

2. 每段是否落到"对受众意味着什么"?

• 扫 script 每个 section,找"对你的影响"、"翻译成场景"这类句式
• 没找到的 section 标记出来,跟用户沟通是否需要加

3. 比喻是否合适?

• 每个比喻反问自己:比技术名词更直接吗?受众熟悉吗?
• 强扭的比喻(比本体还复杂)应该去掉,改直说

4. 数字是否有参照系?

• 扫 PPT 里的 stat-nb / big-num 旁边,看有没有 stat-note 给参照
• 扫 script 里的数字,看前后有没有"相当于 X"这类承接

复审产出

输出一份 checklist 给用户:

语言复审报告:

- [x] 术语解释:Slides 5/6 有术语 "mHC / CSA / HCA",script 已带人话解释 ✓
- [!] 用户视角:Slide 7 "训练稳定性三件套"段,script 未明确落"对用户意味着什么",建议补一句
- [x] 数字参照系:Slides 10 "Codeforces 3206" 已标"全球前 25 名真人选手" ✓
- [!] 过度行业体:script Section 3 有 "里程碑式发布",建议改成具体变化描述

用户同意后修改。

---

迭代原则

• 每次修改都用 Edit tool(surgical edit),不整文件 rewrite —— 方便 diff 查看
• 内容优先,模板不动
• 迭代后重跑 overflow 审核,确保修改没引入新 overflow
• 语言复审可以在用户侧提出后再跑(不强求每次都做)

---

完成标准

审核通过的输出:

// overflow audit
[{"s":1,"o":0},{"s":2,"o":0}, ..., {"s":N,"o":0}]

全部 o ≤ 5,且语言复审无遗留问题。然后向用户报告:

QA 审核通过:
- PPT overflow audit · 全部 ≤ 5px ✓
- 语言复审 · 所有 section 术语带解释 + 用户视角落点 ✓

可以开始录制。

结构规划方法

本文档沉淀 Step 3 的规划流程。规划是方法,不是具体的页面模板。

---

规划产物 · 节奏表

Step 3 必须产出一份表格跟用户确认:

主题 class / 页面类型 从所选 slides skill 的模板约定里选(例如 magazine-web-ppt 用 light / dark / hero light / hero dark;别的 slides skill 用它自己的页面类型词汇)。

页面角色是方法层面的,不涉及具体设计:

• 封面(开场仪式感)
• 开场引入(定位 / 时间线 / 关键数字)
• 正文展开(论点 / 证据 / 展开)
• 关键视觉(大字数据 / 大引用)
• 对比 / 综合(多主角框架用)
• 警示 / 转折(留悬念或反驳)
• 收尾(Takeaway / 索引)

跟用户对齐这份表,才进 Step 4。

---

页面预算

根据目标时长反推页数:

页数过少 → 每页负担重容易溢出;页数过多 → 节奏拖沓。

---

主题节奏硬规则(沿用所选 slides skill 的约定)

以下以 magazine-web-ppt 的页面类型为例;若选了别的 slides skill,换成它的强调页 / 章节页类型,规则精神一致:

• ❌ 禁止连续 3 页以上相同主题(light 堆叠或 dark 堆叠都不行)
• ❌ 禁止超过 8 页的 deck 没有至少 1 个 hero dark + 1 个 hero light
• ✅ 推荐每 3-4 页插入 1 个 hero 页(封面 / 章节幕封 / 关键数据 / 大引用)

规划完成后 grep 一次 class 标签,人工确认节奏合理。

---

单主角 · 页面角色分布

一个主角深度展开,页面按逻辑线性推进:

---

多主角 · 页面角色分布

多个主角对比,页面按"每主角独立幕"组织:

技巧 —— 让 A 幕和 B 幕的结构对称(都有定位 / 亮点 / 代价三页),用户能感到"公平对待",也便于视觉节奏(A 幕用 hero light 强调,B 幕用 hero dark 强调,形成对称)。

---

风格选择在哪一步

风格决策发生在 Step 1 需求澄清 那里,不在 Step 3 规划里:

• 主题色 / 品牌元素 / 封面设计风格 —— 用户决定(或继承已有项目)
• 规划时只关心结构和节奏,不关心视觉

到 Step 5 调用所选 slides skill 时把 Step 1 收集到的风格决策一起传下去。

---

规划常见错误

---

与用户确认的沟通模板

我按你的需求规划了 N 页的节奏表:

| # | 主题 | 角色 | 内容钩子 |
|---|---|---|---|
| 1 | hero dark | 封面 | {...} |
| 2 | light | 引入 | {...} |
| ... |

校验 ——
- hero 页分布:{每 X 页一个}
- light/dark 比例:{比例}
- 主题节奏符合规则:{是/否}

你看这个结构合适吗?有想加 / 想删的页面吗?

用户确认后才进 Step 4。

发布素材写作方法

本文档沉淀 youtube.md / bilibili.md / x.md 的通用方法。结构和原则,不是特定案例文案。

---

通用原则

所有平台素材包含:

1. 标题 + 标题备选(建议 3 个不同切入角度) 2. 描述(正文叙述) 3. 封面建议(引导封面设计)

个人推广信息 —— 从 auto memory 的 video-promo.md 读取,一字不改粘贴。video-planner skill 已实现这套机制,本 skill 不重写 —— 信任现有机制。

---

标题写作方法

标题要让受众 get 到"跟我有关"

避免纯技术学术标题,强调受众能感知的价值。

典型问题标题 —— 太学术、太术语密、太套话:

• "{产品名} Tech Report 拆解"
• "{版本号} 架构深度解读"
• "{功能} 技术全解"
• "重磅!{产品} 震撼发布"

更好的切入角度 —— 把"这视频对你有什么用"摆前面:

• 把核心变化说清:{产品} - {一句话的关键变化}
• 把受众利益摆前:{场景} - {对这类人意味着什么}
• 把悬念打出来:{现象}? - {给答案}

标题备选要覆盖不同切入角度

主标 + 3 个备选,每个侧重不同维度。作者发布时根据当天平台热点 / 流量感觉挑一个:

标题排版细节

这些属于作者的 typography 偏好,由 personal-chinese-writing-style skill 负责,本 skill 不重复规定。

---

YouTube 素材结构

# YouTube 发布素材

## 标题
{主标题}

## 标题备选
- {备选 1 · 不同切入}
- {备选 2 · 不同切入}
- {备选 3 · 不同切入}

## 描述

{主标题}

{从 video-promo.md 读取的"频道会员推广"块 · 如用户平台有 · 原样粘贴}

{社交链接块 · 从 video-promo.md 读取}

{正文 · 3-5 段}

参考链接:
- {官方 / 一手 URL}
- {第三方解读 URL}

## 封面建议

{2-4 句引导封面设计}

正文描述要点

• 字数 200-400,分段清晰
• 第一段:hook(最抓人的一个事实)
• 中段:关键信息、跑分、转折
• 结尾:"这期视频用 N 分钟讲 XX",引导点击

---

Bilibili 素材结构

与 YouTube 的关键差异:

• 开头通常需要赞助商卡片(如 video-promo.md 里配置了) —— 这是 B 站 UP 主的常见惯例
• 没有"频道会员"概念 —— 不放对应块
• 参考链接适当减少(2-3 条即可)
• B 站标题可以稍微不同调性 —— 允许更活泼一点

# Bilibili 发布素材

## 标题
{跟 YouTube 同一主标题 · 或作者决定换更 B 站调性的}

## 标题备选
{同 YouTube 或作者换}

## 描述

{主标题}

{从 video-promo.md 读取的 bilibili 段 · 通常开头一行赞助商}

{社交链接 · 从 video-promo.md 读取}

{正文 · 同 YouTube 内容 · 可微调语气}

参考链接:
- {2-3 条}

## 封面建议

{复用 YouTube 的封面建议}

---

X (Twitter) 素材结构

# X (Twitter) 推广文案

## 推文

{开头 2-3 句 hook}

[视频链接]

{3-5 条关键信息 bullet · 每条独立段落}

{收尾一句}

## 说明

- 链接位置说明(通常放在开头 2-3 句之后 · X 卡片预览效果最好)
- 可选的变通写法(更短版、替换链接等提示)
- 跟哪条推文互为引流(如适用)

X 推文要点

• 长度 500-700 字(利用 X Premium 长推空间)
• 链接位置 —— 开头 2-3 句之后(X 卡片预览会自动渲染)
• bullet 列表 —— 中间用 - XXX 列表,每条独立,便于扫读
• 留占位符 —— [视频链接] 让作者发布时自己填
• "说明"区 —— 给作者的备注,不是推文本身的一部分

---

模板对接 video-planner skill

本 skill 的发布素材写作大部分由 video-planner 生成,本 skill 做的增强有限:

• 从 `video-promo.md` 读推广信息 —— video-planner 已实现,信任它
• 标题朝"受众视角"倾斜 —— 可以通过给 video-planner 传提示来引导
• 封面建议呼应封面 slide —— 如果 Slide 1 的封面是本 skill 生成,封面建议可以引用其视觉要素(但不强制一致)

---

不要做的事

• ❌ 在 youtube.md / bilibili.md 的推广块里自己写推广文案(永远从 video-promo.md 读)
• ❌ 把 X 推文写成"视频简报" —— 要写成"钩子",让人想点开看
• ❌ 复制粘贴一个模板里的具体产品名 / 作者名 / 频道名(这些都是作者资产,由具体调用时填入)
• ❌ 自动发布任何内容

资料研究方法

本文档沉淀 Step 2 的研究流程与实践。方法,不是风格。

---

工具选择

---

信息收集原则

交叉验证

同一数据点从 ≥2 个来源核对。特别是:

• 跑分数据 —— 厂商官方 vs 第三方测试
• 价格 —— 厂商 API 页 vs 媒体报道
• 日期 —— 官方推文 vs 技术博客

交叉不一致的数据在视频里要么不用,要么明确标注分歧。

追源记录

每个要写进 PPT / script 的数据都要能答上"这个数字来自哪"。建议研究时建立记录:

- Codeforces 3206     - 论文 §5.3.2 Table 6
- 昇腾 950PR 2.87× H20 - 电子工程专辑 / IT之家 943029
- 发布日期 2026-04-24  - 官方推文 2047516922263285776

这些来源后面会用在 PPT 每页 foot 行(作为可追溯引用)和 script 里的"源"标注。

多语言资料

中文内容(如华为昇腾支持、国内产业信号)很多被海外媒体漏掉。如果主题有中国相关视角,必须查中文源(IT之家、电子工程专辑、新浪财经等)。

---

针对具体主题类型的研究路径

新模型 / 新产品发布

• 官方公告 + 官方推文(定位原话)
• 官方 API / Pricing 文档
• 跑分对比(官方 vs Simon Willison / Ethan Mollick / Artificial Analysis 等第三方)
• 竞品同档次对比

论文深度拆解

• PDF 按页分批 Read(前 10 页看动机 + 摘要,中间章节按需读,最后读 Conclusion)
• 提取:论文标题英文原文、核心创新、主要跑分、Limitations 章节的自我承认
• 重点读 Conclusion 和 Limitations —— 论文作者自己的价值判断是最好的剧透

多主角对比(如同日多场发布)

• 每家独立研究一轮,然后交叉建立对比矩阵(定价 / 跑分 / 战略定位)
• 注意事件时序 —— 谁先发谁后发、间隔多久、是否刻意撞档

行业 / 趋势观察

• 多家厂商的公开动作
• 资本市场信号(股价变动、产业链订单、投资人反应)
• 用户反馈(HN / X / 知乎 / B 站评论)

---

研究产物

研究完毕,在进入 Step 3 规划前,手头至少应该有:

1. 关键事实清单 —— 发布日期、产品名、版本号、核心数字 2. 定位原话 —— 厂商自己怎么说的(英文原句 + 中文翻译) 3. 跑分矩阵 —— 按领域(代码 / 数学 / 知识 / agent)组织 4. 来源索引 —— 每个数据对应的 URL / 章节 5. 叙事钩子候选 —— 这期视频可能的"最爆点"有哪些(价格翻倍?开源第一?撞档?)

这些素材决定 Step 3 规划里每一页放什么。

---

节制

研究会无底洞地进行下去。原则是 "够用就停" —— 预留够 13-15 页内容、叙事线索清晰即可。再深挖的细节放在 references/foot 行,不扩成新页。

脚本写作方法

本文档沉淀脚本写作的方法原则。方法,不是作者口头禅或固定句式。

---

核心结构 · PPT-Script 1:1

脚本的 section 数 = PPT 的 slide 数,严格对应。

每段开头必须有切页标记:

**【PPT 切到 Slide N · 页名】**

这个标记是本 skill 的核心约定:

• 录屏时作者一眼知道何时翻页
• 剪辑时可用作章节锚点
• 音频-视频对齐的参照

---

文件头部的同步说明

script.md 开头(frontmatter 之后)加一段:

---
title: "..."
date: "YYYY-MM-DD"
duration: "~X 分钟"
platform: "..."
---

# {标题}

> **PPT 同步说明**:每段口播对应一张 PPT 页。录屏时"翻到下一页"= "进入下一段"。PPT 地址:`./ppt/index.html` · 共 N 页。

> **写作说明** · {受众定位一行 · 如"面向 AI 爱好者,不是学术专家"}

## Section 1 - ...

"受众定位"那行提示作者自己:写的时候语言深度往哪个目标群体对齐。

---

语言方法

A. 术语处理

规则 —— 术语首次出现时,同句或邻句必须用"人话"解释。

反例:

V4 用了 mHC 替换 HC,让信号传播更稳定。

正例:

V4 的做法是给这个神经网络的每一层加了数学约束 —— 每层都不能把上层的信号放大,只能原样传下去或缩小。这样深层网络再堆高也不会崩。

写作时可以保留术语名(让有基础的观众对得上),但必须配一句"其实就是..."的人话版本。

B. 每段必须有"对受众意味着什么"落脚

每个 section 的技术段落后必须点出这件事对受众来说意味着什么。

常见句式(按语境选用,不要固定只用一种):

• "对你的影响是 —— ..."
• "翻译成你能感受到的场景 —— ..."
• "对{受众群体}来说的意义 —— ..."
• "这件事最终变成你能用到的能力是 —— ..."

写不出"意味着什么"的 section,要么简化,要么重新考虑这页有没有必要单独成页。

C. 比喻作为降低理解成本的工具

复杂技术概念用类比 / 比喻处理。本 skill 不规定具体比喻库 —— 由作者根据当期主题和受众选择。

好比喻的标准:

• 受众生活里熟悉的事物(不是另一个技术概念)
• 能呈现核心机制,不是只"像"个名字
• 用一次就够,不过度扩展(避免比喻比本体还复杂)

作者可以自己维护一个"用过的好比喻"列表作为资产,但本 skill 不在这里预置。

D. 数字要带参照系

裸数字对观众没信息量。每个数字都要加参照:

• "1.6 万亿参数" → "1.6 万亿参数 · 跟 ChatGPT 同级别"
• "Codeforces 3206 分" → "Codeforces 3206 · 相当于全球前 25 名真人选手"
• "省 70% 算力" → "省 70% 算力 · 相当于 API 价格能打下来一大截"

E. 避免"行业体"

删掉:

• "里程碑式"、"重新定义"、"XX 时代"、"令人瞩目"、"颠覆性"
• "打响了第一枪"、"吹响了号角"

换成:

• 具体变化是什么
• 跟上一代 / 同类对比差别
• 用户能多做什么事

---

Section 结构骨架

每段大致:

## Section N - {一个钩人的小标题}

**【PPT 切到 Slide N · 页名】**

{1-2 句开场,引入本段要讲什么}

{主体 2-4 段 · 展开说明 · 带类比 · 术语配人话}

**{受众视角落脚句}** —— {对受众意味着什么}

长度参考:60-90 秒一段(约 200-350 字)。

• 太短(< 60s) → 页面信息量可能不够,考虑合并
• 太长(> 120s) → 页面塞太多,考虑拆页

---

Hook 段 · 第一段的常见形态

第一段(Hook)通常需要承担两件事 —— 抓住注意力 + 设立定位。常见结构:

## Section 1 - Hook

**【PPT 切到 Slide 1 · 封面】**

{直接抛最抓人的点 · 1-2 句}

{作者自称 + 定位 · 告诉观众"我是谁、这期讲什么、不讲什么"}

{对这期长度 / 节奏的预告}

**【PPT 切到 Slide 2 · {下一页名}】**

{一两句过渡到 Slide 2}

注意 —— Hook 段可能覆盖 Slide 1 + Slide 2 开头一小部分,所以一段里可以有两个切页标记。这是合理的。

---

收尾段 · 不固定句式

收尾方式因视频调性而异。不要钉死固定结尾句 —— 作者有自己的口头禅就保留,没有就让语气自然。

常见收尾组件:

• 三句话总结(N 页内容压缩成 3 个 takeaway 论点)
• 延伸方向(这期没讲到的,后续要深入的)
• 收尾语(作者习惯用的结束语)

结尾语保持自然,不强求格式化。

---

品牌 / 个人元素处理

作者可能有:

• 自称(主播昵称)
• 固定口头禅(好了今天就聊到这里)
• 频道品牌(频道名 / 节目名)

这些是作者的个人资产,不是 slides-video 的 skill 属性。

处理方式:

• 第一次使用作者资产时,从用户那里收集(video-planner skill 会引导)
• 保存到 auto memory 的 video-promo.md
• 后续自动复用

本 skill 不硬编码任何作者特定元素。如果看到前版 references/ 里还有作者昵称 / 频道品牌类硬编码,应该清理掉。

---

不要做的事

• ❌ 假设受众懂术语就直接用
• ❌ 每段只讲技术不讲价值
• ❌ 用"里程碑 / 重新定义"这类套话
• ❌ 裸数字不给参照
• ❌ 钉死作者口头禅或频道品牌(留给作者资产层)
• ❌ 把脚本写成"课件" —— 要写成"口语"