福桃九分饱做教学视频这事，我最深的感受是：真正耗时间的从来不是对着镜头说话，而是前期那套反复重复的设计流程——定主题、拆知识点、写逐字稿、排分镜、统一口语风格、配字幕分段。以前每做一期新课，我都得把这些步骤重来一遍，哪怕有 AI 帮忙，每次也要把背景、要求、输出格式重新交代一次，换来的结果还不稳定。后来我把整套流程固化成了一个 Claude Skill，让 Claude 按我预设的步骤和规范自动产出视频素材包，从脚本到分镜再到字幕提示词一次给全。这篇文章就把我的完整思路、Skill 文件写法、调试过程和踩过的坑全部摊开讲，适合正在做技术教程、知识科普、网课或者企业内部分享视频的人参考。
1. 先想清楚:为什么做教学视频需要一套"技能"而不是一段 Prompt
1.1 教学视频的产出链条,到底卡在哪儿
我见过不少朋友做视频，上来就打开录屏软件对着屏幕讲，讲到一半发现逻辑乱了，重录；或者写了个长 Prompt 让 AI 出脚本，结果 AI 给了一篇"论文体"，又要自己改半天口语化表达。真正专业的教学视频产出，其实是一条固定的链条：
- 明确教学主题和目标受众。
- 拆解学习目标，决定这节课要解决什么问题。
- 写逐字脚本，包括旁白和演示动作。
- 把脚本拆成分镜，标出每一段的画面内容。
- 为每个镜头准备配图提示词、界面标注或者代码片段。
- 输出字幕分段和封面文案。
这条链条最大的特点就是"固定"。既然固定，就完全可以让 AI 按照一套写死的流程去执行。普通的 Prompt 只能做一次性对话，下次再问又得把所有规则讲一遍，而且很容易聊着聊着就跑偏。Skill 解决的就是这个问题：它把流程本身变成可复用的资产。
1.2 Skill 和普通 Prompt 的本质区别
很多人第一次接触 Skill 会以为它只是一个"加强版 Prompt"。这么理解不算错，但不够准确。Skill 在 Claude Code 里是一套目录结构，核心是 SKILL.md 文件。这个文件里有 YAML 格式的元信息（技能名字、触发条件、描述），还有正文部分。正文写的不是一段零散的指示，而是一套完整的"操作手册"：包括执行步骤、输出格式、注意事项、质量标准。
普通 Prompt 是"告诉 AI 你要什么"，Skill 是"教会 AI 按你的方法做"。这个区别在教学视频场景里非常重要。举个具体例子：你直接对 Claude 说"帮我写一个讲 Git 分支合并的教程脚本"，它大概率给你一篇分章节的文章；但如果你加载一个教学视频 Skill，它会自动知道自己该按"学习目标→逐字脚本→分镜表→配图提示词→字幕分段"的顺序走，而且每段输出的格式、长度、口语化程度都是你预先定好的。
1.3 谁适合用 Skill 来做教学视频
先说我的判断：不是所有人都需要上来就搞 Skill。如果你的视频是随手拍、随缘讲，一周只产出一期，那用普通对话也够用。但如果你符合下面任意一条，就值得认真搭一套自己的 Skill：
- 视频有固定的栏目结构，比如"先抛问题、再讲原理、后上实操、最后总结"。
- 你需要批量产出内容，比如一门课程有几十节，每节都要保持风格统一。
- 你希望 AI 产出的脚本不仅能读，还能直接拿去做 PPT、配图、配音和字幕。
- 你厌倦了每次写 Prompt 都要花 10 分钟复述自己的要求。
我属于最后一条的重度用户。所以我才花了整个下午把流程敲进 SKILL.md，后面每做一期视频，基本只需要给一个主题，剩下的工作 Claude 会按部就班地完成。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 把视频制作流程翻译成 Skill:从设计思路到 SKILL.md
2.1 先画出你自己的"十分钟标准流程"
不要一上来就写文件。先拿张纸，或者在编辑器里列一下：你平时做一个教学视频，按顺序要做哪些事？我列出的流程是这样的，你们可以作为参考模板：
- 确认主题和受众水平，避免脚本写得过高或过低。
- 写出学习目标，要求控制在 1-2 句话，方便视频简介直接使用。
- 生成逐字旁白稿，要求口语化、短句为主。
- 把旁白稿拆分成 6-10 个分镜段落，每个段落标明画面内容。
- 为每个分镜段落生成配图提示词或界面操作说明。
- 输出字幕分段，每段不超过 12 个字符/行（中文场景），方便后期直接导入剪辑软件。
这六步就是我的 Skill 核心流程。你的流程可能不一样，没关系，关键是把它固定下来。Skill 的威力不在于它的代码有多复杂，而在于你把自己的方法论沉淀进去了。
2.2 SKILL.md 的核心结构:让 Claude 一读就知道要干嘛
Skill 的载体是 SKILL.md，它不是一个特别神秘的文件，本质上是一份 Markdown，只是有固定的元信息头。我把我用的文件结构贴出来，你们可以直接抄着改：
markdown复制---
name: teaching-video
description: 将任意知识点转化为完整教学视频素材包。当用户要求制作教学视频、视频脚本、课程大纲、分镜、逐字稿时使用。
---
# 教学视频制作技能
## 目标
产出一套可直接用于录制/剪辑的教学视频素材包，包含学习目标、逐字脚本、分镜表、配图提示词、字幕分段。
## 执行步骤
### 第 1 步:确认主题与受众
- 询问用户主题（如果已提供则跳过）。
- 确认受众水平：新手/进阶/专家，并决定术语解释深度。
### 第 2 步:输出学习目标
- 1-2 句话，直接可放在视频简介前两行。
### 第 3 步:生成逐字脚本
- 按"问题导入→概念解释→操作演示→总结回顾"四段结构组织。
- 口语化，单句不超过 25 个字。
- 每段旁白前用【画面】标注对应演示内容。
### 第 4 步:拆解分镜表
- 输出 Markdown 表格，列为:镜头编号 / 画面内容 / 旁白 / 字幕 / 备注。
- 一节课可分 6-10 个镜头。
### 第 5 步:生成配图提示词
- 每个镜头给出 1 条配图提示词，风格统一为"扁平插画，主色蓝白，留白充足"。
### 第 6 步:输出字幕分段
- 按语义切分，每行不超过 15 个汉字。
- 使用时间轴占位符:【00:00-00:05】。
## 输出格式要求
- 必须严格按第 2 到第 6 步依次输出，不允许合并或跳步。
- 所有文字使用简体中文。
- 若用户未提供特定风格，默认使用口语化、轻松但不失专业的语气。
frontmatter 里的 name 和 description 很关键。description 决定了 Claude 在什么时候调用这个 Skill，你要把触发场景写清楚，比如"制作教学视频""视频脚本""课程大纲"。不然它会犹豫该不该用。
2.3 把"个人偏好"写进规则里
Skill 和普通 Prompt 最大的不同，是它能承载你的隐性经验。举个例子，我早期做视频经常犯的毛病是：脚本写得太书面，念出来像在播新闻。后来我在 SKILL.md 里加了一条硬性规则："所有旁白必须能用念的方式在 5 秒内读完，读不顺就重写。"加了这条之后，产出质量明显好转。
另一个例子是术语处理。技术教学最怕"每个字都认识，连起来听不懂"。我在规则里写道："技术名词第一次出现时，必须紧跟一个生活化类比，比如分支合并类比为多条支流汇入主河道。"这一条直接让我的视频评论区从"没听懂"变成了"这个比喻到位"。
你可以把自己的偏好一条条列进去，比如：不喜欢的开场词、必须规避的口头禅、封面标题的固定句式。这些都是你的视频区别于别人的"风格指纹"。
3. 从零搭一个"教学视频 Skill":环境、目录和调试
3.1 装好 Claude Code 之后再处理两个最常见的报错
这章节是给还没装过 Claude Code 的读者看的。安装本身不复杂，正常情况下只需要一行命令：
bash复制npm install -g @anthropic-ai/claude-code
装完之后验证一下：
bash复制claude --version
能输出版本号就说明环境没问题。但我在网上看到大量新手卡在两个地方，这里提前说清楚。
第一个是 Windows 下最常见的 claude : 无法将“claude”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。这个报错的意思很简单：系统在 PATH 环境变量里找不到 claude 这个命令。解决办法分两步：
bash复制# 第一步:确认 Node.js 全局安装目录
npm config get prefix
把输出的路径（一般是 C:\Users\你的用户名\AppData\Roaming\npm）加到系统环境变量 PATH 里，然后重开终端。大多数情况下，重开终端就能解决。如果还不行，检查一下 Node.js 版本，Claude Code 对 Node 版本有最低要求，老版本很容易出现命令装了但运行不起来的情况。
第二个我常看到的问题是接入第三方模型时出现类似 'deepseek-v4-pro' is not a model this version of claude code recognizes 的报错。这个报错的关键词是"这一版本不认识这个模型名"。说白了就是版本和模型标识符不匹配。遇到这种问题，先去查你当前 Claude Code 版本支持的模型列表，再确认环境变量里 ANTHROPIC_MODEL 或类似配置写的模型名和供应商提供的正式标识符完全一致，包括大小写和连字符。模型名不是随便起的，差一个字母都不行。
3.2 Skill 文件到底放在哪、长什么样
装好环境之后，我们要做的事是创建 Skill 的目录。Claude Code 默认会从两个位置读取 Skill：用户级的 ~/.claude/skills 和项目级的 .claude/skills。
我的建议是：通用的、跨项目复用的 Skill（比如"教学视频制作"）放在用户级；只服务于某个特定项目的（比如"根据本项目代码生成内部分享视频"）放在项目级。这样可以避免技能库越来越乱。
以教学视频 Skill 为例，完整目录结构是这样的：
text复制~/.claude/skills/
└── teaching-video/
├── SKILL.md
└── scripts/
└── split_subtitle.py
SKILL.md 是主文件，负责定义流程和规则；scripts/ 目录放一些辅助脚本，用于处理机械化操作。比如我那个 split_subtitle.py，作用是按标点切分长文本，生成符合字幕规范的分行文本。这种机械活让 Claude 每次用 Python 现写，不如做成固定脚本稳定。
3.3 调试时的判断标准:怎么知道 Skill 真的生效了
创建好文件之后，很多人会问："我怎么知道 Claude 真的用上了我的 Skill？"判断方法其实很简单，看它的输出结构。
如果你在对话里说"我想做一个讲 Docker 的教学视频"，它可以回应你；但如果它没有按 学习目标→逐字脚本→分镜表→配图提示词→字幕分段 的顺序输出，而是直接给了一篇通稿，那说明 Skill 没有被正确触发，或者触发后没有被严格遵守。
我自己的调试方法是先在项目目录里跑一次最小测试：
bash复制claude --skill teaching-video
或者直接在对话里输入 /skill teaching-video 手动指定。这样能排除"触发条件没命中的问题。如果触发了但输出还是不听指挥，问题通常出在 SKILL.md 的正文写得太"软"。你需要把必须执行的步骤写得更像命令，而不是描述。比如不要把"可以拆成几个镜头"写成"必须拆成 6-10 个镜头"，不要把"建议口语化"写成"所有旁白必须以不超过 25 字的短句写成"。AI 对模糊词的理解和我们对模糊词的理解，经常不在一个颗粒度上。
4. 用 Skill 完整跑通一节 10 分钟的视频课
4.1 输入课程主题之后，Skill 产出的第一版内容
理论说再多，不如跑一遍。我拿"用 10 分钟讲清楚 Git 分支合并"当主题，实际跑了一次我的教学视频 Skill。以下是它产出的核心内容骨架，你从结构上就能看出 Skill 在起作用。
学习目标输出得非常简洁：
学完本节，你能够独立完成分支的创建、切换与合并，并理解合并冲突的产生原因与基本处理思路。
逐字脚本部分，它自动套用了四段结构。第一段问题导入是这样的：
你平时写代码是不是总担心把别人的代码改坏？Git 分支就是用来解决这个担心的。它让你在自己的小隔间里干活，干完了再搬回主车间。
这句我很满意，因为它同时完成了"抛问题""引概念""生活化类比"三件事，而这些全部是 SKILL.md 里写明的规则。
4.2 让脚本变成可用的成片素材:旁白、分镜、配图、字幕
Skill 产出的第二大部分是分镜表。这部分的直接价值是：我不用再自己对着脚本头发麻，剪视频时可以直接照着分镜表切镜头。实际输出的表格长这样：
| 镜头编号 | 画面内容 | 旁白 | 字幕 | 备注 |
|---|---|---|---|---|
| 1 | 背景问题动画:两个人在同一份文档上改内容 | 你平时写代码是不是总担心把别人的代码改坏？ | 你平时写代码，总担心改坏别人的代码？ | 可配摇头动画 |
| 2 | 示意图:独立小隔间 + 主车间 | Git 分支就是用来解决这个担心的。 | Git 分支就是用来解决这个担心的。 | 注意用色对比 |
| 3 | 终端实际操作:创建并切换分支 | 我们先用 git branch 创建一个新分支。 | 用 git branch 创建新分支。 | 终端字体调大 |
| 4 | 终端实际操作:合并分支 | 分支任务完成之后，切回主分支执行合并。 | 切回主分支，执行合并。 | 合并命令高亮 |
分镜表之后，配图提示词部分也给得比较规整。比如第 1 条：
扁平插画风格，两个开发者面对同一块白板，白板上被不同颜色的笔迹覆盖，表情困惑。主色蓝白，背景留白。
这组提示词可以直接喂给绘图工具或者拿去做 PPT 配图，不需要我再动脑想"该画什么"。
字幕分段的输出我特别看重，因为这是我以前最烦的部分。它给了一段带时间轴占位符的字幕稿：
text复制【00:00-00:05】你平时写代码，总担心改坏别人的代码？
【00:05-00:12】Git 分支就是用来解决这个担心的。
【00:12-00:18】它让你在自己的小隔间里干活。
【00:18-00:24】干完了再搬回主车间。
每行不超过 15 个汉字，而且是按语义切分的。后期直接拖进剪映或者 PR 的字幕轨道，稍微对齐一下时间轴就能用。这比我以前自己一句句断句快了不止一倍。
4.3 录屏类教学的一个隐形痛点:演示与旁白同步
如果你做的是软件操作类视频，最难受的问题往往不是脚本写不出来，而是录制的时候"手跟不上嘴"。旁白念到第三步操作，鼠标还在点第一步，录到一半就要重来。Skill 帮我解决了这个问题。
我在 SKILL.md 里加了一条要求：所有涉及界面操作的旁白，必须在前面加一个【操作】标记。然后 Claude 输出的脚本里就会出现这样的段落：
【操作】打开终端，输入 git branch -b feature/login 并回车
我们创建一个新的登录取能分支，注意看这里分支名变成了 feature/login。
录制的时候，我只要照着【操作】标记先做动作，再做旁白，完全不用背稿。这条经验我强烈建议做教程类视频的人都试一试，它比什么提词器都管用。
5. 调用 Skill 时最容易翻车的三个地方
5.1 命令都装了，却提示找不到 Claude
这不是 Skill 本身的问题，但确实是每个新手几乎都会遇到的"拦路虎"。我之前在外面帮朋友远程看问题，他安装一切正常，一执行命令就是 claude' 不是内部或外部命令。查了半天，发现他终端窗口是装完 Node.js 之前打开的，PATH 环境变量根本没刷新。这种问题不需要重装，关掉终端重新开一个，大多数情况就好了。
如果重开还不行，再按我前面说的，检查 npm config get prefix 输出的目录在不在系统 PATH 里。这里有个细节：Windows 下修改 PATH 后，不只是终端要重开，某些编辑器（比如 VS Code）也要完全重启，因为它会缓存终端环境。
5.2 接入第三方模型时的模型名报错
很多教程会教大家通过环境变量或者配置文件把 Claude Code 接到第三方模型上。这个过程本身我不展开，但我要提醒一个高频报错：
text复制'deepseek-v4-pro' is not a model this version of claude code recognizes
遇到这个错误，先别怀疑网络问题，你的第一反应应该是：模型名没对上。不同版本对模型的支持列表是有限的，版本不认这个模型标识符，就会直接抛这个错误。
我的排查顺序是这样的：
- 检查当前版本的模型列表或官方文档。
- 检查环境变量里写的模型名是否完整，注意大小写和连字符，比如
deepseek-v4-pro和deepseek-v4pro会被当成两个完全不同的名字。 - 确认配置用的 API 地址和模型名来自同一套服务，不要交叉混用。
这个报错本身不是 Skill 的问题，但如果你连 Claude Code 都用不起来，Skill 就更无从谈起了。
5.3 Skill 被触发了但输出不听指挥
这是我这几个月用下来最值得写的一条。SKILL.md 写得再完整，Claude 也偶尔会"自说自话"，跳过某个步骤，或者把输出格式改掉。我总结下来有三类原因：
第一，规则写得太像建议。比如"可以口语化""建议拆成几个镜头"，这类措辞给 AI 留了太多自由裁量空间。改法是把"可以"换成"必须"，把"建议"换成"一律"。
第二，缺少明确的输出清单。如果你的 Skill 没有在最后列出一份"最终交付物清单"，AI 很可能输出到一半就终止了。我在 SKILL.md 的末尾加了一行："最终交付物必须包含以下六项：学习目标、逐字脚本、分镜表、配图提示词、字幕分段、封面标题三选。"加了这一行之后，产出完整度提升非常明显。
第三，对话太长导致上下文覆盖。如果你的 Skill 调用发生在超长对话的后半段，早期定义的规则可能被淡化。这时候我一般会重新开一个会话再调用，或者在调用后手动说一句"请完整执行 teaching-video 技能，不要跳步"。
6. Skill 和 MCP 怎么选:我的取舍与使用习惯
6.1 一句话讲清两者的职责边界
每次聊到 Skill，总有人把它和 MCP 混在一起。我用一句话讲清楚：Skill 解决的是"怎么做才专业"的问题，MCP 解决的是"能拿到什么数据、能用什么工具"的问题。
拿教学视频打个比方：Skill 是导演手里的分镜本和拍摄规范，MCP 是摄影师手里的摄像机、灯光和话筒。导演定了怎么拍，摄像机负责把画面真正拍下来。两者完全不冲突，实际工作中往往是配合使用的。
如果你要在 Claude Code 里做这些事，它们分别对应不同的做法：
- Skill:规定输出节奏和输出结构，比如"先出脚本再出分镜再出字幕"。
- MCP:把技能输出的内容写入文件、生成图片、调用外部数据源，比如连接文件系统自动保存脚本、连接绘图服务自动生成配图。
6.2 在教学视频工作流里的配合方式
我现在的视频制作工作流是两者混用的。Skill 负责流程编排，MCP 负责把流程各阶段的结果落到实际产物上。
比如 Skill 产出逐字脚本之后，我会让文件系统 MCP 把脚本自动保存成 markdown 文件，按日期和主题命名；配图提示词生成后，交给图像生成工具批量出图；字幕分段生成后，直接通过文件操作生成 srt 格式的字幕文件，省去手动转换。这些用纯 Skill 不是不能做，但有了 MCP 之后，人工介入的环节变得更少了。
我甚至做过一个小实验：让 Skill 把一整节课的完整素材包直接落成一个目录，包括 script.md、storyboard.md、prompts.json、subtitles.srt 四个文件。VScode 里一打开，所有素材都在，录制和剪辑时根本不需要来回翻聊天记录。
6.3 我的三个实用习惯(长期沉淀下来的)
最后分享三个我在反复使用中沉淀下来的习惯。
第一个习惯是"每次踩坑都往回写"。录视频过程中如果发现某个表述总是绕口、某个操作总是被观众问，我就会把这个经验补进 SKILL.md 的规则里。Skill 文件是活的，它不是写一次就完了，而是一节节视频课的"经验账本"。
第二个习惯是"给 Skill 做版本管理"。每次大改规则之前，我会把旧的 SKILL.md 复制一份按日期命名存起来。这看起来有点像给自己找麻烦，但当你发现新规则反而把输出质量改差了的时候，能快速回滚是很救命的。
第三个习惯是"永远保留一个手动兜底步骤"。Skill 产出的东西再完整，我都会自己从头到尾朗读一遍旁白稿。AI 不懂你在镜头前的呼吸节奏，也不懂你哪句话容易笑场。严格检查一遍，是对观众负责，也是对自己的账号负责。
我现在做视频的流程已经固定成：给出一个主题，让教学视频 Skill 产出素材包，再用 MCP 把素材自动归档，最后我只需要把精力放在"真正需要我做的"那部分——对着镜头把课讲好。技术工具能承接的重复劳动，就别再让它占用你的创作心力了。