Video Planner

Video Planner & Publishing Materials

Help YouTubers/UP主 prepare video content: write structured scripts (口播稿), blog posts, platform-specific publishing materials, and an X (Twitter) promo tweet.

Output Structure

Each video gets a date-based directory under user's chosen location:

./videos/{YYYY-MM-DD}-{short-slug}/
├── script.md       # 视频口播稿
├── blog.md         # 博客文章
├── youtube.md      # YouTube 发布素材
├── bilibili.md     # Bilibili 发布素材
├── x.md            # X (Twitter) 推广文案
├── fact-check.md   # 技术事实审核表（技术类视频必出，见 Step 8）
└── cover.png       # 封面（可选，见 Step 10）

Interactive Workflow

Step 1: Gather Information

IMPORTANT: Before writing anything, collect sufficient context from the user. Ask the user:

请提供以下信息，帮我为你准备视频内容：

1. **视频主题**：这期视频讲什么？（必填）
2. **目标平台**：YouTube / Bilibili / 两者都有？（默认：两者）
3. **目标时长**：大约几分钟？（默认：10分钟）
4. **目标观众**：面向什么人群？（如：开发者、AI爱好者、初学者）
5. **关键要点**：你希望视频覆盖哪些要点？（可以是大纲、笔记、或链接）
6. **相关资料**：有没有参考文章、文档、代码仓库？（可选，我可以帮你研究）
已有部分信息的话，直接告诉我就好，缺的我会追问。

If the user provides partial info upfront, only ask for the missing pieces.

Step 2: Research (If Needed)

If the user provides reference URLs, docs, or repos:

• Use WebFetch to read reference articles/docs
• Use Read/Grep/Glob to explore code repos
• Use WebSearch to find supplementary information
• Summarize key points for script use

If the topic is about a specific technology/tool:

• Research its core features and selling points
• Find common pain points it solves
• Look for comparison angles with alternatives

Step 3: Create Directory

Create the date-based directory:

./videos/{YYYY-MM-DD}-{short-slug}/

Example: ./videos/2026-03-07-react-server-components/

The short-slug should be a brief, descriptive kebab-case label derived from the topic.

Step 4: Write Script (script.md)

Write a structured 口播稿 in the user's preferred language. The script is what the user reads aloud while recording, so two things matter as much as the content:

• 照着念友好（read-aloud first）：每一句都要是「能顺口念出来」的话，不是写出来给人读的文章。太书面、太像技术文档的句子会拖慢录制 - 写完后过一遍，把长定语、术语堆砌、嵌套从句改成短句口语（详见 references/script-guidelines.md 的「照着念友好」规则）。
• 屏上呈现推荐（screen-share cues）：作为 AI，你要逐段智能判断这段口播配什么画面最好 - 某个网页的某一段、某个应用 / 终端界面、一段代码、还是一张对比 / 速查卡 - 并写成 （屏幕：……） 备注。目的：用户照着口播稿念的同时，一眼知道该在屏幕上呈现什么。在脚本开头加一张「屏上呈现总则」总表（画面来源 + 逐段映射），正文每段再用内联 （屏幕：……） 落到具体内容。不是每段都要切画面 - 判断「需不需要」也是你的工作，纯口播段就标「纯口播」。

参考：

• templates/script.md - 输出格式模板（含「屏上呈现总则」表与内联屏幕备注）
• references/script-guidelines.md - 详细写作规则（含「照着念友好」「屏上呈现推荐」两条）
• references/examples-tutorial.md - 教程 / 配置类标准范本，配置 / how-to / setup 类视频开写前先读

Step 5: Write Blog Post (blog.md)

Repurpose the video content into a blog post to maximize content utilization. The blog should NOT be a transcript - it should be a standalone article that reads naturally.

• See templates/blog.md for the output format template
• See references/blog-guidelines.md for detailed writing rules
• IMPORTANT: Follow the personal-chinese-writing-style skill conventions

Step 6: Write Platform Descriptions (youtube.md & bilibili.md)

Generate separate publishing materials for each platform. The two platforms share the same core content but differ in structure and promo placement.

• See templates/youtube.md and templates/bilibili.md for output format templates
• See references/platform-differences.md for platform-specific rules and guidelines
• YouTube 章节：YouTube 描述里放章节时间戳（从 00:00 开始，按脚本结构估算），列表上方先放一行免责声明「时间戳为按脚本结构的估算，剪辑完成后按实际时长调整」。Bilibili 描述不放章节。
• 参考资料块：含外部链接（repo / 官网 / 文档）的视频，在 YouTube 描述末尾附一个「参考资料」块，列出链接，以及封面源文件路径（cover.html / cover.png）便于复用。

Step 7: Write X/Twitter Promo (x.md)

Generate a short promo tweet that the user can post alongside the video to drive traffic. Not a summary — a hook that makes people want to watch.

• See templates/x.md for the output format template
• IMPORTANT: Follow personal-chinese-writing-style skill's references/social-media-style.md rules (link position, bullet vs prose, tone)
• Leave [视频链接] as a placeholder — user fills in the real URL on publish

Step 8: Fact Audit (技术事实审核)

技术解读 / 评测 / 任何含技术事实点的视频必做，不可跳过。 在风格校对之前先把内容核实一遍 - 因为审核可能要删改成段内容。

• 逐条核验：把 script.md 和 blog.md 里的每一条技术陈述列出来，标来源、给核验结论。规则与来源分级见 references/fact-audit.md
• 结论三档：✅ 成立（有官方来源，可直接讲）/ ⚠️ 需屏上引用（非官方来源，保留但录制时屏上给可见证据）/ ❌ 删除（无来源或属推断，从脚本和博客移除）
• 绝不让模型的猜测 / 幻觉进稿：没有来源支撑的推断一律删，或改成「官方没披露，不猜」
• 闭源 / research preview 内容：脚本里要有披露句（「研究预览，部分细节未公开」）和边界句（「未披露的实现不猜」）；启用机制（环境变量 / 命令 / 菜单）对照当前官方文档核对；争议数字默认取官方
• 产物：把核验结果写成 fact-check.md 放进视频目录，便于复核追溯。格式见 templates/fact-check.md

Step 9: Apply personal-chinese-writing-style (统一风格校对)

After every file is written and fact-audited, run a dedicated polish pass over all generated Chinese text files. This is a required finishing step, not optional.

• Invoke the `personal-chinese-writing-style` skill and apply it to every generated file: script.md, blog.md, youtube.md, bilibili.md, x.md
• 口播稿不例外：script.md 虽然是用来「说」的，也要完整套用标点与风格规则 — 中文弯引号、半角破折号 " - "、ASCII 省略号 "......"、无标题编号、简洁标题，且不留全角/英文标点
• 额外做一遍「照着念」复核（口播稿专属，standalone-style 之外）：标点统一不等于好念。再过一遍 script.md，确保每句都顺口 - 把太书面 / 太技术文档化的句子（长定语、术语堆砌、嵌套从句、被动腔）改成短句口语；可以默念一遍，卡壳的地方就改。判断标准见 references/script-guidelines.md 的「照着念友好」。（屏幕：……） 屏上备注保留，不要被风格校对删掉。
• 保留口语化与自然语流：personal-chinese-writing-style 只做标点与语气的统一，不强加模板结构（不要把 script.md 改成 Hook/引言/正文/CTA 那种套路）
• x.md 仍以 personal-chinese-writing-style 的 references/social-media-style.md 为准（链接位置、bullet vs prose、语气）

Step 10: Generate Cover (封面，可选)

封面不是默认产物 - 先问用户要不要做封面，需要时再生成。

询问：

要不要顺手做一张封面？
- 视频缩略图（YouTube / Bilibili）→ 我用 `cover-design`（代码驱动的排版封面，文字清晰、适合缩略图）
- 文章头图（博客 / X Article）→ 我用 `cover-image`（AI 生成的插画风头图）

• 缩略图类需求 → 调用 cover-design skill
• 文章头图类需求 → 调用 cover-image skill
• 产物存进视频目录（如 cover.html / cover.png）

Step 11: Review & Iterate

完成后提示用户：

视频脚本和配套内容已准备好：

📂 {目录路径}/
├── script.md      — 口播稿（约 X 分钟）
├── blog.md        — 博客文章
├── youtube.md     — YouTube 发布素材
├── bilibili.md    — Bilibili 发布素材
├── x.md           — X (Twitter) 推广文案
├── fact-check.md  — 技术事实审核表（技术类视频）
└── cover.png      — 封面（如已生成）

请检查内容，如果需要调整，告诉我：
- 需要修改哪个部分？
- 风格/语气需要调整吗？
- 有要补充的要点吗？

Personal Promotion Info

Users should configure their promotion block. On first use, ask the user for their promotion links and save to auto memory for cross-session persistence.

When asking:

我注意到这是你第一次使用视频策划 skill。请提供你的个人推广信息，我会记住以便后续使用：

- 社交媒体链接（Twitter、Bilibili、YouTube 等）
- 知识星球/社群链接
- 联系方式
- 其他固定推广信息（如课程链接、赞助信息等）

Save to auto memory directory as video-promo.md (e.g. ~/.claude/projects/.../memory/video-promo.md). On subsequent uses, check if this file exists in the memory directory and read it directly — no need to ask again.

Examples

See references/examples.md for detailed examples of different usage scenarios.

Critical Rules

1. 先问后写 — 信息不足时必须追问，不要猜测用户意图 2. 照着念友好 — 口播稿是作者照着念的，每句都要顺口；太书面 / 太技术文档化的句子必须改成短句口语（见 Step 4、Step 9 与 references/script-guidelines.md 的「照着念友好」） 3. 屏上呈现推荐 — 逐段智能判断这段口播配什么画面（网页某段 / 应用 / 终端 / 代码 / 对比卡），写成内联 （屏幕：……） 备注，并在脚本开头给一张「屏上呈现总则」总表；纯口播段标「纯口播」（见 Step 4） 4. 脚本不加时间戳；章节只在 YouTube 描述 — script.md 章节标题不标时间戳（节奏由作者录制时掌控）；YouTube 描述放估算章节时间戳（从 00:00 起）并在列表上方加免责声明（剪辑后按实际时长调整）；Bilibili 描述不放章节 5. 不要自动发布 — 只生成文件，不执行任何发布操作 6. 保留用户风格 — 如果用户提供了之前的视频风格参考，尽量保持一致 7. 推广信息复用 — 首次询问后保存到 auto memory，后续自动填充 8. 日期目录 — 每期视频按当天日期创建独立目录 9. 技术内容先审后发 — 技术解读/评测等含技术事实的视频，发布前必须逐条事实审核（见 Step 8），无官方来源的点要么删、要么屏上给可见引用，绝不让模型的猜测/幻觉进稿，并出 fact-check.md 留档 10. 统一风格收尾 — 所有生成的中文文稿（含口播稿）在收尾时必须用 personal-chinese-writing-style 过一遍，见 Step 9，不可跳过 11. 封面按需生成 — 封面不是默认产物，先问用户；缩略图用 cover-design，文章头图用 cover-image（见 Step 10）

Blog Writing Guidelines

将视频脚本内容转化为独立博客文章，最大化内容复用。博客不是逐字稿转录，而是重新组织成适合阅读的文章。

IMPORTANT: Follow the personal-chinese-writing-style skill conventions for punctuation, formatting, and article structure.

写作规则

1. 不是逐字稿转录：把视频脚本当素材，重新组织成适合阅读的文章。口语化的表达要改成书面语。 2. 遵循 personal-chinese-writing-style：标题不编号、结构隐于文中、用散文过渡而非硬切、引号用中文弯引号 ""、破折号用 - 。 3. 补充细节：视频中靠画面展示的内容（录屏、对比截图），在文章里用代码块、表格或文字描述补足。 4. 独立可读：读者不需要看过视频也能完全理解文章内容。 5. 篇幅适当：一般是视频口播稿字数的 60%-80%，去掉寒暄和过渡性口语，保留干货。

Examples - 教程 / 配置类视频范本

这一份范本是用户认可的「教程 / 配置类视频」标准脚本 - 把 references/script-guidelines.md 里的 Hook 开篇结构、内嵌录制提示、节奏与判断、诚实承认约束这几条规则一次性展示出来。

写新的教程 / 配置类脚本前，先扫一眼这份范本里 Hook 段的结构、过渡句的语气、和制作备注的两种格式（括号 vs `>` blockquote）。

评论 / 拆解 / 发布解读类视频不完全适用这份范本 - 那种语境里 hook 可以是 punch line 开场（如「Karpathy 的 LLM Wiki 是什么 - 一个被严重低估的工具想法」），不必先做自我介绍。

---

重点看什么

阅读下面这份完整范本时，重点比对这几个段落：

1. Hook 段 - 第一句自我介绍 → 上期承接 → 受众点名（“对于注重数据隐私的朋友来说”）→ 完整句子描述方案 → 「无论是 X、还是 Y、还是 Z，都能满足需求」整齐排比 → 软过渡（“那现在我们就开始吧”） 2. 「为什么本地也能跑」段中部 - > 这里分享 Ollama 对 Anthropic 协议兼容的文档。 这种内嵌 blockquote 录制提示 3. 「装 Ollama 加拉模型」段 - 「大家根据自己的硬件配置来选择模型」「在演示中，我选 qwen2.5-coder:14b」这种平视引导式，不要写成「这里有个关键判断」式的工程裁判腔 4. 「装 Ollama 加拉模型」段 - 24GB 跑不动 30B + 64k 的诚实换算，把硬约束摆出来 5. 「跑一次真活」段 - （终端进入 ~/ollama-demo/，空目录） 这种括号制作备注，与上面 blockquote 形成两种格式的对比

---

完整范本

下面是 videos/20260514-claude-code-ollama/script-revised.md 的完整内容，保留作为该类视频的引用范本。

---

---
title: "给 Claude Code 配置基于 Ollama 的本地模型"
date: "2026-05-14"
duration: "~5-6 分钟"
platform: "YouTube / Bilibili"
---

# 给 Claude Code 配置基于 Ollama 的本地模型

> **录制说明**：
> - **Part 1（约 30s）**：Hook + 系列承接（上期 4 家云模型，本期完全本地）
> - **Part 2（约 30s）**：原理 - 还是 Anthropic 兼容端点，这次端点在 `localhost:11434`，token 字段是字面量 `"ollama"`
> - **Part 3（约 1 min）**：装 Ollama + 拉模型（pull 命令一笔带过，剪辑跳过等待）
> - **Part 4（约 45s）**：两条配置路径 - 手动 export 三行 / `ollama launch claude` 一行
> - **Part 5（约 1.5 min）**：fizzbuzz demo，真实展示本地模型 tool use
> - **Part 6（约 30s）**：64k 上下文这条硬约束
> - **Part 7（约 30s）**：本地 vs 云的边界
> - **Part 8（约 15s）**：收尾
>
> **录制前准备**：
> - `ollama pull qwen2.5-coder:14b` 已完成（约 5GB 下载，录前一晚跑完）
> - `ollama serve` 已用 `OLLAMA_CONTEXT_LENGTH=65536` 起好；如果环境变量这条路不通，改用 Modelfile 方案（脚本里给出兜底命令）
> - 空 demo 目录 `~/ollama-demo/` 备好，干净的 bun + TypeScript 环境
> - Claude Code 已装（`claude --version` 确认）
>
> **关键资料**：
> - 官方集成文档：https://docs.ollama.com/integrations/claude-code
> - Ollama 模型库：https://ollama.com/library
> - 上期视频：四家国产云模型接 Claude Code
>
> **录制机器**：MacBook Pro M3，24GB 统一内存。这是个有诚意要讲清楚的事实 - 24GB 跑不动 30B 本地模型 + 64k 上下文，所以 demo 用 14B 级。

## Hook

（终端开着，Ollama 已起）

大家好，我是小木头。在上期视频中，我们把 Claude Code 接到了 4 家国产云模型 - DeepSeek、GLM、Kimi、Qwen。今天这一期，我们给 Claude Code 配置本地模型。

对于注重数据隐私的朋友来说，本地模型是不错的选择。Ollama 让我们可以在本地环境上运行一个 Anthropic 兼容的端点，完全不依赖网络，不需要订阅，也没有账单。无论是处理敏感数据、在内网开发，还是出差时离线工作，都能满足需求。

我想，这应该是 Claude Code 用户会感兴趣的部署方案。那现在我们就开始吧。

## 为什么本地也能跑

Claude Code 启动时只看两个环境变量 - `ANTHROPIC_BASE_URL` 和 `ANTHROPIC_AUTH_TOKEN`。上期我们把 URL 指到阿里云、Moonshot 那些云服务；这期，**我们把 URL 指到你笔记本上**。

> 这里分享 Ollama 对 Anthropic 协议兼容的文档。

负责在本地暴露这个 Anthropic 兼容接口的，就是 Ollama。Ollama 默认监听 `http://localhost:11434`，做了一层 Anthropic 协议适配。

有一个细节 - **`ANTHROPIC_AUTH_TOKEN` 这里填字面量 `"ollama"` 这五个字母**。不是 API key，不需要注册。它只是个占位符，绕过 Claude Code 的非空校验。

## 装 Ollama 加拉模型

Ollama 装一次就行 - macOS 直接从 [ollama.com](https://ollama.com) 下载，或者：

brew install ollama

装完起 daemon：

ollama serve

然后拉模型。大家根据自己的硬件配置来选择模型 - 我录这期用的是 24GB 内存的 M3 MacBook Pro。**24GB 跑不动 30B 级别的本地模型 + 64k 上下文**。算一下 - 30B 模型 Q4 量化 ~18GB 权重，加上 KV cache 4-8GB，加上系统占用，直接溢出。

所以，在演示中，我选 `qwen2.5-coder:14b` - 9GB 权重，开 64k 上下文也只到 14-15GB，留足余量。如果你是 32GB 以上的 Mac，可以直接 `ollama pull qwen3-coder` 上 30B 级。

（录屏开始）

ollama pull qwen2.5-coder:14b

<!-- 剪辑：跳过下载等待，直接到完成 -->

拉完。

## 两条配置路径

接进 Claude Code 有两条路。

**路径 A - 手动 export 三个环境变量**。跟上期 4 家云模型形式完全一致：

export ANTHROPIC_BASE_URL=http://localhost:11434 export ANTHROPIC_AUTH_TOKEN=ollama export ANTHROPIC_MODEL=qwen2.5-coder:14b claude

> 这里分享 ollama launch claude 的文档 - https://docs.ollama.com/integrations/claude-code

**路径 B - 用 Ollama 新发的 `launch` 命令**，一行搞定：

ollama launch claude --model qwen2.5-coder:14b

这条命令自动设好上面那三个变量，然后直接启动 Claude Code。**强烈推荐路径 B** - 配置和启动绑在一起，不会出现“我 export 漏了哪一行”这种困扰。

## 跑一次真活

我直接进 demo 目录跑一下。

（终端进入 `~/ollama-demo/`，空目录）

cd ~/ollama-demo ollama launch claude --model qwen2.5-coder:14b

（Claude Code 起来）

给它一个真任务 - 不是“你好介绍一下你自己”那种摆设。本地小模型能不能做 agentic 编码，要看 tool use 稳不稳。

我让它写一个 fizzbuzz：

> 帮我写一个 `fizzbuzz.ts`，1 到 30，能被 3 整除打 fizz、5 打 buzz、15 打 fizzbuzz，写完用 `bun run fizzbuzz.ts` 跑一下验证输出。

（Claude Code 开始干活）

<!-- TODO: 录制时记录真实输出。期待行为：调用 Write 写文件 → 调用 Bash 跑 bun → 看到 30 行输出 → 总结。失败的话也照实展示，可能在 tool 调用格式上出错，或者输出多/少一行。 -->

这个任务考点很清楚 - **Write tool 写文件 + Bash tool 跑命令 + 一段薄逻辑**。14B 本地模型能扛下来，说明它在 Claude Code 这个 harness 下能做日常 coding。

## 64k 上下文这条硬约束

讲一个**录制前差点翻车的坑**。

Ollama 默认 context length 是 2048 或 4096，**Claude Code 第一句对话就会爆**。系统提示词加 tool schema 加用户问题，光这些就远超过这个长度。

官方文档明确写了 - **至少 64k**。两种设置方法。

**方法一 - 环境变量起 daemon**：

OLLAMA_CONTEXT_LENGTH=65536 ollama serve

**方法二 - 写一个自定义 Modelfile**：

cat > Modelfile <<EOF FROM qwen2.5-coder:14b PARAMETER num_ctx 65536 EOF ollama create qwen2.5-coder:14b-64k -f Modelfile

然后用 `qwen2.5-coder:14b-64k` 这个 tag 启动。我用的是方法一，简单。

## 本地 vs 云，什么时候选哪个

最后讲一下边界 - 本地不是云的替代品，是补充。

**走本地的场景**：

- **隐私敏感** - 客户代码、医疗数据、未发布产品，根本不想出网
- **内网开发** - 外网访问受限，云端 API 进不来
- **出差离线** - 飞机上、酒店烂网，本地完全不依赖网络

**走云的场景**：

- 日常 coding，要 Sonnet、Opus、Kimi K2.6、Qwen3-Coder Plus 这种顶配能力
- 大项目长上下文，本地 14B 扛不动

诚实讲 - **14B 本地模型的能力上限明显低于云端旗舰**。但在该用本地的场景里，它够用，而且永远在你手上。

## 收尾

回顾一下 - **Ollama 跑在 `localhost:11434`，token 写字面量 `"ollama"`，一条 `ollama launch claude --model X` 启动**。注意把 daemon 的 context length 调到 64k 以上，不然第一句话就爆。

官方文档和上期 4 家国产云模型的视频链接我放在描述里。今天的分享就到这里，感谢大家收看，我们下期再见。

Video Script Skill Examples

Example 1: User provides topic directly

User: 帮我写一期视频脚本，主题是用 Turborepo 管理 monorepo，面向前端开发者，大约6分钟

Claude: Confirms understanding, creates ./videos/2026-03-07-turborepo-monorepo/, generates script.md, blog.md, youtube.md, and bilibili.md.

script.md (excerpt):

---
title: "Turborepo：让你的 monorepo 构建快 10 倍"
date: "2026-03-07"
duration: "~6 分钟"
platform: "YouTube / Bilibili"
---

# Turborepo：让你的 monorepo 构建快 10 倍

## Hook（0:00 - 0:10）

我的项目有 12 个包，完整构建从 8 分钟降到了 45 秒。

大家好我是 xxx，今天来聊聊 Turborepo - 它是怎么做到这件事的，以及你的项目该不该用它。

## 为什么 monorepo 构建这么慢（0:10 - 1:00）

先说问题。你有一个 monorepo，里面放了前端应用、组件库、工具函数、后端服务。改了一行代码，CI 把所有包全构建一遍。

其实大部分包根本没变。问题出在构建工具不知道包之间的依赖关系，只能全量跑。

## Turborepo 的核心思路（1:00 - 2:30）

Turborepo 做的事情很简单 - 它分析包之间的依赖图，只构建真正受影响的包。

再加上远程缓存，同一份代码在 CI 上构建过一次，你本地 pull 下来就不用再跑了。

（展示 turbo run build 的输出对比：全量 vs 增量）

## 上手配置（2:30 - 4:30）

我们直接来操作。

（录屏开始）

<!-- TODO: 补充实际安装和 turbo.json 配置步骤 -->

首先在项目根目录安装 Turborepo......

然后是 turbo.json 的配置......

## 实际效果（4:30 - 5:30）

（展示构建时间对比截图）

<!-- TODO: 补充实际数据 -->

## 收尾（5:30 - 6:00）

Turborepo 不是银弹，小项目没必要上。但如果你的 monorepo 已经开始因为构建速度拖慢开发效率，它值得试一下。

好了今天的分享就到这里，感谢大家收看，我们下期再见。

youtube.md (excerpt):

# YouTube 发布素材

## 标题

Turborepo：让你的 monorepo 构建快 10 倍

## 标题备选

- monorepo 构建太慢？Turborepo 帮你解决
- 告别全量构建：Turborepo 实战

## 描述

#turborepo #monorepo #前端工程化 #vercel

{产品推广链接}

monorepo 项目构建越来越慢？Turborepo 通过依赖图分析和远程缓存，只构建真正变化的包。这期视频从原理到实操，带你快速上手。

本期内容：
- 为什么 monorepo 构建慢
- Turborepo 的核心思路：依赖图 + 远程缓存
- 从零上手配置
- 实际构建速度对比

相关链接：
- Turborepo: https://turbo.build/

---

{个人推广信息}

## 章节 (Chapters)

00:00 开头
00:10 为什么 monorepo 构建慢
01:00 Turborepo 核心思路
02:30 上手配置
04:30 实际效果
05:30 总结

## 封面建议

Turborepo logo + 构建速度对比（8min → 45s），背景用深色调，突出速度提升数字。

bilibili.md (excerpt):

# Bilibili 发布素材

## 标题

Turborepo：让你的 monorepo 构建快 10 倍

## 标题备选

- monorepo 构建太慢？Turborepo 帮你解决
- 告别全量构建：Turborepo 实战

## 描述

{赞助商广告}

monorepo 项目构建越来越慢？Turborepo 通过依赖图分析和远程缓存，只构建真正变化的包。这期视频从原理到实操，带你快速上手。

本期内容：
- 为什么 monorepo 构建慢
- Turborepo 的核心思路：依赖图 + 远程缓存
- 从零上手配置
- 实际构建速度对比

相关链接：
- Turborepo: https://turbo.build/

## 封面建议

Turborepo logo + 构建速度对比（8min → 45s），背景用深色调，突出速度提升数字。

Example 2: User provides reference material

User: 我想做一期关于 Cursor vs Windsurf 的对比视频，这是我的笔记 ./notes/cursor-vs-windsurf.md

Claude: Reads the notes file, researches both tools if needed, asks about target audience and length, then generates script, blog, youtube, and bilibili files.

Example 3: User only provides a vague idea

User: 想做一期视频聊聊 AI 编程

Claude:

好的，AI 编程是个很好的话题。让我了解更多细节：

1. 你想聊哪个方面？比如：
   - AI 编程工具对比（Cursor、Copilot、Claude Code 等）
   - AI 编程的工作流和最佳实践
   - AI 对程序员的影响和未来趋势
   - 某个具体工具的深度体验
2. 面向什么观众？开发者还是泛科技人群？
3. 大概多长时间？

Fact Audit · 技术内容事实审核

适用于技术解读 / 评测 / 任何含技术事实点的视频。目标：脚本和博客里的每一条技术陈述都能追溯到一个来源，不让模型的猜测或幻觉进稿。尤其针对闭源 / research preview 类内容 - 这类内容最容易把官方文档、第三方逆向、社区实测和个人推断混在一段话里且不标来源。

来源分级

给每条技术事实点标一个来源 tier：

审核规则

1. 逐条核验：把 script.md 和 blog.md 里的技术事实点逐条列出，每条标来源 tier + 出处，给一个核验结论。 2. 无官方来源的点：要么删掉，要么在屏上给可见引用（截图 / 链接卡），不能仅靠口播断言。 3. 闭源 / research preview：

• 脚本里要有一句披露 - 「这是研究预览，部分细节未公开」。
• 明确边界 - 「实现细节官方没披露的，我不在视频里猜」。

4. 争议数字默认取官方：同一事实出现多个数字时（如某重写「11 天」官方 vs「6 天」推文），默认用官方数字，除非用户明确要求呈现冲突。 5. 功能开关 / 启用机制按当前官方文档核对：环境变量、命令、菜单项这类「怎么开启」的内容，容易混进第三方写法（如某个 XXX=1 环境变量 vs 官方 /config 开关）。发布前对照当前官方文档确认。

产物：fact-check.md

审核结果落成一份 fact-check.md，放进视频目录，便于复核与追溯。格式见 templates/fact-check.md。

核验结论用三档：

• ✅ 成立 - 有官方来源，可直接讲。
• ⚠️ 需屏上引用 - 非官方来源，保留但录制时必须在屏上给可见证据。
• ❌ 删除 - 无来源 / 属推断，从脚本和博客里移除。

YouTube vs Bilibili Platform Differences

两个平台的视频描述共享核心内容（概述 + 要点 + 相关链接），但包装方式和固定素材块不同。所有固定素材块从 auto memory 的 video-promo.md 读取。

差异对照表

YouTube 描述结构（从上到下）

1. 一句话副标题 / slogan 2. YouTube 频道会员推广块（memory 固定文案） 3. 个人推广块（Substack / Twitter / Bilibili / 邮箱） 4. 可选产品推广（如与内容相关） 5. 视频内容概述段 6. 播放列表引用

之后是章节时间戳。

Bilibili 描述结构（从上到下）

1. 一句话副标题 / slogan 2. 赞助商广告（memory 固定文案，一行） 3. 知识星球链接（单独一行） 4. 视频内容概述段

Bilibili 的描述比 YouTube 简洁很多，不附完整的联系方式、播放列表或章节。

从 memory 读取内容

生成 youtube.md 和 bilibili.md 前，必须先读取 ~/.claude/projects/<project>/memory/video-promo.md，提取以下内容：

• YouTube 个人推广：Substack、Twitter、Bilibili、邮箱（全用）
• Bilibili 个人推广：知识星球（只用这一条社群链接）
• YouTube 频道会员推广块：整段原样放入 YouTube 描述
• YouTube 播放列表链接：按主题匹配选用
• Bilibili 赞助商广告：整条原样放入 Bilibili 描述第一行
• 可选推广（如 OpenClaw）：只在内容相关时插入

标题写作规则

1. 简洁有力：控制在 50 字符内（YouTube 推荐） 2. 包含关键词：便于搜索发现 3. 制造好奇/价值感：让人想点进来 4. 避免标题党：真实反映内容 5. 提供备选：至少给 2-3 个标题方案 6. 两平台可以不同：Bilibili 和 YouTube 的标题可以针对各自受众微调 7. 优先描述式动宾标题：教程 / 配置类视频用「给 X 配置 Y」「在 X 上做 Y」「用 X 实现 Y」这种动宾结构。避免两段式 punchy 标题（“X 跑在 Y 上 - Z 的零云配置”、“X 接 Y - 一次教完”），SEO 关键词稳定、降低标题党感。两段式 punchy 标题只在评论 / 拆解 / 发布解读类视频使用 - 那种语境里前半段是 hook、后半段是范围限定，能撑得起。

• 好（教程类）：「给 Claude Code 配置基于 Ollama 的本地模型」
• 好（评论类）：「Karpathy 的 LLM Wiki 是什么 - 一个被严重低估的工具想法」
• 避免（教程类）：「Claude Code 跑在你自己机器上 - Ollama + 本地模型零云配置」

描述写作规则

1. 前两行最重要（折叠前可见），放副标题 + 最吸睛的信息 2. 正文内容（概述）两平台共用 3. YouTube 描述更完整（含会员块、个人推广、播放列表、章节） 4. Bilibili 描述更简洁，赞助商信息必须在最前面

章节时间戳 (YouTube only)

1. 必须从 00:00 开始（YouTube 要求） 2. 根据脚本结构估算时间点 3. 章节名简洁，不超过 30 字符 4. 时间戳列表前面要放一个“章节”标签行，这样用户复制描述到 YouTube 时能自然地看到分组标题 5. 章节列表上方放一行免责声明 blockquote：> 时间戳为按脚本结构的估算，剪辑完成后按实际时长调整。 - 把「估算」摆明，避免用户误当作准确时间发出去 6. 注意：script.md 章节标题不标时间戳（节奏由作者录制时掌控）；时间戳只出现在 YouTube 描述里 7. Bilibili 描述不放章节

参考资料块 (YouTube)

含外部链接的视频，在 YouTube 描述末尾（章节之前）附一个「参考资料」块：

1. 列出本期引用的外部链接 - repo / 官网 / 文档，每条一行 2. 附封面源文件路径（videos/{date}-{slug}/cover.html + 渲染产物 cover.png），便于后续复用 / 重新渲染；有备选方向时附 cover-styles/ 3. Bilibili 只需放官网 / repo 一两条核心链接即可，不附封面源文件路径

Script Writing Guidelines

脚本结构原则

脚本应该像自然对话一样流畅，不要用“开场/引言/正文/总结/CTA”这种模板化结构。按内容逻辑分段，每段用描述性标题。

正面案例

写脚本前先扫一眼 references/examples-tutorial.md - 这是用户认可的「教程 / 配置类视频」标准范本，包含 Hook 开篇结构、内嵌录制提示、节奏与判断的具体写法。

写作规则

1. Hook 开篇结构：第一句话先做自我介绍 - “大家好，我是 {名字}”。紧跟一两句承接上期或引出本期主题。然后用一段「先点受众再讲技术」的引导（“对于注重 X 的朋友来说......”）解释这期为什么值得看。最后用“那现在我们就开始吧”类软过渡进入正文。不要把自我介绍埋到 hook 第三句之后、也不要写“今天 5 分钟讲清楚”这类时长承诺 - 让观众自己感受节奏。 2. 按内容分段，不按模板：章节标题是描述性的（“安装配置”、“登录演示”），不是编号式的（“要点一”、“第三章”）。不要在章节标题里标注时间戳 - 节奏由作者录制时掌控，估算的时间戳只会成为噪音。 3. 口语化：写出来的是要说的话，不是文章。用短句，用“先澄清一点”、“那为什么还要折腾”、“问题出在......上”这种口语表达。 4. 制作备注三种格式：

• 屏上呈现 / 操作类用括号 （屏幕：……） - 每段开头（或切画面处）写明这段该在屏幕上放什么：（屏幕：切到官网 {url}，从 #hero 慢滚）、（屏幕：终端跑 npx … 的输出）、（屏幕：编辑器里 SKILL.md 的 Color 段）、（屏幕：A vs B 对比卡）。纯操作动作也可用 （录屏开始）、（终端进入 ~/demo 目录）。
• 引用文档 / 卡片类（剪辑时要叠一张外部链接卡或截图）用内嵌 blockquote，写在对应口播句的紧下方 - 例如 > 这里分享 X 的官方文档 - https://...。blockquote 内联在段落里，剪辑时不会漏。
• 未确定的内容仍用 <!-- TODO: 补充... --> 标记（录前核对命令名 / 输出 / 数字也写这里）。

5. 结尾自然：不需要仪式感的“请点赞关注”。简短回顾，自然收束。 6. 时间把控：中文口播约 200-250 字/分钟，英文约 130-150 词/分钟。根据目标时长控制篇幅。 7. 节奏与排比：避免三连短句 staccato 堆叠开场（如 “零网络、零订阅、零账单。”）。把要点串成完整句子，多用「无论是 X，还是 Y，都......」整齐结构来枚举场景，而不是逗号串联的破碎枚举。例外 - 评论 / 拆解类视频可以适度提高 punch 密度；配置 / 教程类一律按这条来。 8. 判断保留，工程裁判腔收掉：不要用“关键判断”、“端点直接搬回你机器”、“这就是好 skill 的样子”这种锋利短语充当过场。改成“大家根据自己的配置选”、“在演示中我选 X”、“诚实讲 X” 这种平视引导式。带判断的句子本身保留（“永远在你手上”、“该用本地的场景里它够用”）- 收的是裁判腔，不是判断。 9. 诚实承认硬约束：碰到硬件、版本、上下文长度这类硬约束时，把限制和换算明摆出来（“24GB 跑不动 30B + 64k”），不要藏。这是教学视频比技术营销视频可信的关键差别。 10. 屏上呈现推荐（逐段判断该放什么画面）：口播稿不只是「说什么」，还要告诉作者「屏幕上放什么」。作为 AI，逐段智能判断这段口播配什么画面最有说服力，写成内联 （屏幕：……） 备注：

• 讲概念 → 切对应网页 / 官网板块慢滚当 B-roll；演操作 → 终端 / 应用界面；要让观众看到「写死的规则 / 关键实现」→ 一段代码 / 文件；做对比 / 小结 / 速查 → 叠一张卡（对比卡 / 速查卡 / 总览卡）。
• 在脚本开头给一张「屏上呈现总则」表：先列本期画面来源（A 网页 / B 终端 / C 代码 / D 叠加卡，按需增减），再给一张「段 → 主画面 → 具体放哪一段」的逐段映射。正文每段再用 （屏幕：……） 落到具体内容。
• 不是每段都要切画面 - 判断「需不需要」也是你的工作。纯口播段直接标「纯口播」，别硬塞画面；别让画面长时间停在一张静止图上。
• 引用具体网页锚点 / 命令 / 文件名时，提醒录前核对是否还在（写进 <!-- TODO -->），锚点 / 命令名变了别硬套。

11. 照着念友好（写完默念一遍）：口播稿是作者照着念的，不是写给人读的文章。每句都要顺口 - 写完过一遍，最好默念，卡壳的地方就改。

• 要改：长定语套长定语、术语堆砌、嵌套从句、被动腔、书面连接词（“此外”“综上所述”“基于上述”）、一句话塞三四个信息点。
• 改成：短句、主动语态、口语连接（“那”“所以”“你看”“说白了”）、一句话一个意思、把长链拆成两三句。
• 判断标准：这句话你能不能一口气顺当念出来？念到一半要回头看才懂的句子，就是太书面，必须拆。带判断、带细节的内容保留，收的是书面腔，不是信息量。

Bilibili 发布素材

标题

{主标题}

标题备选

• {备选标题1}
• {备选标题2}

描述

{一句话副标题 / slogan — 视频核心卖点}

{Bilibili 赞助商广告 — 从 auto memory 读取 "Bilibili 赞助商广告" 整条原样放入，置于描述第一行（正文内容之上）}

{社群链接 — 从 auto memory 读取 "加入我的知识星球" 这一条}

{视频内容概述，2-3 句话，说清楚本期要讲什么}

{官方 / 参考链接 — repo / 官网，每条一行；没有就删掉这一块}

Bilibili 描述不放章节时间戳，比 YouTube 简洁；不附完整联系方式与播放列表。

封面建议

{封面方向 — 可「同 YouTube」复用一套，再按 Bilibili 横版微调}

• Bilibili 横版封面：产品名 / 主标题字号更大，before/after 或核心反差更醒目，移动端列表缩略图里也能一眼认出。

{正文内容}

Fact Check · {视频标题}

逐条核验 script.md / blog.md 里的技术事实点。结论：✅ 成立 · ⚠️ 需屏上引用 · ❌ 删除。

规则见 references/fact-audit.md。

事实点核验表

争议项 / 待用户确认

• {如：某数字官方 11 天 vs 推文 6 天 - 已默认取官方 11 天，如需呈现冲突请告知}

闭源 / preview 披露检查

• [ ] 脚本含「研究预览，部分细节未公开」披露
• [ ] 脚本含「未披露的实现不猜」边界
• [ ] 启用机制（环境变量 / 命令 / 菜单）已对照当前官方文档

{视频标题}

屏上呈现总则（口播时该放什么）

这张表帮作者照着念的同时，一眼知道每段该在屏幕上呈现什么。逐段智能判断：这段口播配什么画面最有说服力 - 不是每段都要切画面，纯口播段就标「纯口播」。

本期的画面来源（按需增减）：

逐段映射：

Hook

（屏幕：{这段放什么 - 如「一个典型的 AI 生成落地页，全屏」}）

大家好，我是{名字}。{一两句话承接上期或引出本期主题}。

{先点受众再讲技术 - “对于 X 的朋友来说，{这期讲的方案}是不错的选择。{用一段完整句子说明它解决什么、不依赖什么}。无论是 A、还是 B，还是 C，都能满足需求。”}

{软过渡句 - 如 “我想，这应该是 {受众} 会感兴趣的方案。那现在我们就开始吧。”}

{第一部分描述性标题}

（屏幕：{这段放什么 - 如「切到官网 {url}，从顶部慢滚」}）

{内容}

{可选 - 引用卡。例如：> 这里分享 X 的官方文档 - https://...}

{第二部分描述性标题}

{内容}

（屏幕：{讲到对比 / 小结时叠一张卡，如「{A} vs {B} 对比卡」}）

{操作演示描述性标题}

我们现在直接来操作。

（屏幕：{终端 / 应用界面，说明视口与并排方式；操作类备注也可用 “（录屏开始）”}）

屏幕：

{要敲的命令 / 要展示的代码}

{操作步骤口播说明}

<!-- TODO: 补充实际操作截图 / 录前核对命令名与输出 -->

{收尾}

（屏幕：{总览卡 / 尾帧落在官网或 repo}）

{自然收束，回顾要点，给出行动建议}

好了今天的分享就到这里，感谢大家收看，我们下期再见。

X (Twitter) 推广文案

推文

{开头 1-2 句 hook — 抛出最吸引人的事实、数据或反差。引发兴趣，不剧透全部。}

[视频链接]

{可选的分点 bullets — 只在有多个值得并列陈述的事实/数字时使用。如果视频是叙事型/观点型，保持连续段落即可，不要硬套 bullet。}

• {要点 1，附具体数字}
• {要点 2}
• {要点 3}

{一句话收尾 — 点明视频时长和发布平台，让读者知道点击后的预期。}

说明

• 链接位置放在开头 1-2 句之后（X 卡片预览会正常渲染，放最前或最后都不行）
• 替换 [视频链接] 为实际 YouTube 或 B 站 URL
• 参考 personal-chinese-writing-style skill 的 social-media-style 章节决定语气和分点策略

YouTube 发布素材

标题

{主标题}

标题备选

• {备选标题1}
• {备选标题2}

描述

{一句话副标题 / slogan — 视频核心卖点}

{YouTube 会员推广块 — 从 auto memory 读取 "YouTube 频道会员推广块"，原样放入}

{个人推广块 — 从 auto memory 读取 "通用个人信息" 列表（知识星球、Twitter、Bilibili、邮箱）}

{可选产品推广 — 只有内容确实相关时才插入，如 OpenClaw 等}

{视频内容概述，2-3 句话，说清楚本期要讲什么}

{播放列表引用 — 从 auto memory 的 "播放列表链接" 中选择匹配本期主题的一条}

参考资料： {外部链接 — repo / 官网 / 文档，每条一行；没有就删掉这一块}

封面源文件：videos/{YYYY-MM-DD}-{slug}/cover.html（渲染产物 cover.png）{若有备选方向，附 cover-styles/}

时间戳为按脚本结构的估算，剪辑完成后按实际时长调整。

章节 00:00 {Hook / 引言 — 简短章节名} {MM:SS} {第一部分章节名} {MM:SS} {第二部分章节名} {MM:SS} {操作演示章节名}

封面建议

{这期视频的封面方向：一句话说清「是什么、什么品类、什么领域」三件事}

• 左半 / 主信息：{品类标签 + 产品名大字 + 中文钩子 + 可选命令条 / 关键字}
• 右半 / 视觉：{before → after 小样、对比、或最抓眼的画面元素，把版面填满}

色调与字体：{取自官网 / 品牌的主色与字体；注明小图（1280×720）下要看清的关键元素}