1. 分镜脚本为什么值得做成 Claude Skill分镜脚本这件事做过内容的人都知道它有多磨人。一个 30 秒的广告片导演要的是 8 到 12 个镜头每个镜头得写清楚景别、运镜、演员动作、对白、音效、灯光提示。手写一份下来熟练的制片也要两三个小时新手可能一整天都理不顺镜头之间的逻辑。更麻烦的是团队里每个人写分镜的习惯都不一样有人用「近景」有人写「CU」有人把运镜写在描述里有人单独列一行最后交给摄影指导的时候还得再翻译一遍。Claude Skills 正好能解决这类「有固定套路、有专业术语、需要反复产出」的活儿。它不是什么神秘的黑科技本质就是一个文件夹里面放一份SKILL.md指令文档再配上可选的脚本和参考资料。Claude 在对话时先读所有 Skill 的元数据name description判断当前请求跟哪个 Skill 相关相关才把完整的SKILL.md加载进上下文然后按里面的流程干活。这个机制叫渐进式加载好处是哪怕你装了 100 个 Skill常驻上下文也只有每个 Skill 几十个 token 的元数据不会把窗口撑爆。分镜脚本 Skill 适合谁我梳理了三类人。第一类是广告和短视频团队需求高频、格式要求统一把分镜规范沉淀成 Skill 之后新人也能产出符合团队标准的脚本。第二类是独立创作者和学生没有专业制片帮忙Skill 能充当一个懂电影语言的助手帮你把文字剧本翻译成可执行的镜头清单。第三类是内容平台的运营需要批量产出脚本模板Skill 的确定性输出比每次重新描述需求靠谱得多。这篇指南会带你从零做一个storyboard-generatorSkill包含完整的目录结构、SKILL.md的字段写法、验证脚本以及一次真实的分镜生成与校验演示。全程可复制跟着做就能跑通。2. 用 TaoToken 接入 Claude 跑通 Skill 的前置准备Skill 本身是纯文本文件不需要编译但要真正跑起来验证效果你得有一个能调用 Claude 的入口。我实测下来用 TaoToken 的 API 接入是最省事的路径它兼容 Anthropic 的接口格式Claude Code、Cline 这类工具都能直接连。先说清楚要准备的三样东西业内常说的「三件套」Base URL、API Key、Model ID。缺一个都连不上。Base URL 填https://taotoken.net/api注意这里不加任何查询参数。API Key 去控制台生成路径是https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite进去之后新建一个 Key复制出来保存好它只显示一次。Model ID 按你实际要用的模型填比如claude-sonnet-4-5这类标识具体以文档里的模型列表为准文档地址在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite。如果你用的是 Claude Code配置方式是在项目根目录或者用户目录下建.claude/settings.json把环境变量写进去。下面这段可以直接复制把sk-xxx换成你自己的 Key{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: sk-xxx, ANTHROPIC_MODEL: claude-sonnet-4-5 } }如果你用的是 Cline 或者别的支持 MCP 的编辑器插件配置项名字会不一样但核心还是那三件套。Cline 里通常在设置面板填 API Provider 为 Anthropic CompatibleBase URL 填https://taotoken.net/apiAPI Key 填你的 KeyModel 填 Model ID。这里要提醒一句MCP 直连生产数据库这种事千万别干Skill 是拿来处理文本工作流的不是拿来操作线上数据的。配好之后先别急着做 Skill跑一个最小请求确认链路通。用 curl 测一下curl https://taotoken.net/api/v1/messages \ -H x-api-key: sk-xxx \ -H anthropic-version: 2023-06-01 \ -H content-type: application/json \ -d { model: claude-sonnet-4-5, max_tokens: 128, messages: [{role: user, content: 回复两个字通了}] }返回里能看到content数组里有文本就说明 Base URL 和 Key 都没问题。这一步很关键很多人后面 Skill 不触发其实是接入层就没通白白怀疑 Skill 写错了。关于费用和额度TaoToken 的 Coding Plan 适合长期做编码和 Agent 类任务的场景如果你只是偶尔验证一下 Skill用按量的 API 就够了。想了解套餐细节可以看https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite。模型对话的在线体验入口在https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite不想写代码的时候可以直接在网页里试。3. 可复制的 SKILL.md 结构与分镜字段配置现在进入正题动手写 Skill。先建目录结构长这样storyboard-generator/ ├── SKILL.md ├── scripts/ │ ├── validate_storyboard.py │ └── format_storyboard.py ├── references/ │ ├── storyboard_standards.md │ └── camera_movements.md └── assets/ └── templates/ └── storyboard_template.mdSKILL.md是唯一必需的文件其他都是可选。它的开头是一段 YAML 前置元数据用三个短横线包起来。这段元数据决定了 Claude 什么时候会想起你这个 Skill所以 description 的写法是重中之重。--- name: storyboard-generator description: 当用户需要为视频、电影、电视剧、广告或动画项目创建专业分镜脚本时使用此技能。根据剧本或创意概念生成结构化、可视化的拍摄指导包含场景、镜头类型、运镜、演员指导和音效设计。 dependencies: python3.8 ---几个字段的坑我踩过说给你听。name最多 64 个字符只能用小写字母和连字符别写大写也别加感叹号它会变成斜杠命令/storyboard-generator。description最多 200 个字符必须用第三人称官方推荐的措辞是「当用户需要……时使用此技能」而不是「使用此技能当……」。最关键的是description 里要包含触发场景的关键词比如「分镜脚本」「剧本」「镜头」「运镜」因为 Claude 判断是否调用 Skill 靠的是纯语言推理不是正则匹配关键词越贴合用户的实际说法触发越准。元数据下面是 Markdown 正文这是 Claude 真正执行任务时看的指令。我建议按这个骨架来写每个部分都别省# 分镜脚本生成器 ## Purpose目的 将文字剧本、创意概念或场景描述转换为专业的分镜脚本文档。 ## When to Use何时使用 - 需要将剧本转换为分镜脚本 - 有创意概念需要可视化 - 需要为视频项目制作拍摄计划 ## Core Elements核心元素 每个镜头必须包含场景标题、镜头类型、相机运动、演员动作、对白、音效、技术说明。 ## Process工作流程 1. 分析输入内容识别场景和情节点 2. 规划视觉结构设计镜头序列 3. 生成分镜脚本填写所有字段 4. 调用 scripts/validate_storyboard.py 验证 5. 格式化输出 ## Decision Logic决策逻辑 - 目标时长 ≤ 30 秒生成 5-8 个镜头 - 目标时长 ≤ 2 分钟生成 10-20 个镜头 - 目标时长 2 分钟生成 20 个镜头 ## Quality Checklist质量检查清单 - [ ] 每个场景和镜头都有唯一编号 - [ ] 使用标准电影术语 - [ ] 包含音效和音乐提示 - [ ] 视觉连贯性良好字段约定上我建议把镜头类型和运镜的取值固定下来写进references/storyboard_standards.mdSKILL.md里只放摘要。镜头类型用 WS广角、MS中景、CU特写、ECU极特写、OTS过肩、POV主观这套标准缩写运镜用 Dolly In、Dolly Out、Pan、Tilt、Tracking、Crane、Zoom、Static。这样输出的脚本团队里谁看都懂不会出现「近景」和「中景」混用的情况。scripts/里的脚本不进入上下文直接执行所以适合放确定性的活儿比如格式校验和编号连续性检查。references/里的文档按需加载适合放详细的术语表和行业标准。assets/完全不进上下文放模板文件供输出时引用。这个职责边界搞清楚了Skill 的 token 成本才能压下来。4. 验证请求与一次完整的分镜生成演示Skill 写好了得验证它真的能触发、真的能产出合格结果。我拿一个真实需求来演示给一支 30 秒的咖啡品牌广告做分镜。先把 Skill 文件夹放到 Claude Code 能识别的位置通常是项目下的.claude/skills/目录或者用户级的~/.claude/skills/。放好之后重启会话让 Claude 重新读取元数据。然后发请求注意措辞要自然别刻意堆关键词帮我为一条 30 秒的咖啡品牌广告生成分镜脚本。 主题是清晨的第一杯咖啡目标受众是都市上班族 风格温暖治愈最后以产品特写收尾。Claude 会先读所有 Skill 的元数据发现storyboard-generator的 description 里有「广告」「分镜脚本」这些词语义匹配上了就把SKILL.md加载进来按 Process 里的步骤走。它先分析输入识别出「清晨」「上班族」「温暖」这几个关键意象然后按 Decision Logic 里「≤30 秒生成 5-8 个镜头」的规则规划镜头数。生成出来的片段大概长这样SCENE 001: INT KITCHEN - DAWN 场景描述清晨的厨房蓝色时刻的微光透过百叶窗。 水壶冒着热气主角睡眼惺忪地走向咖啡机。 SHOT 1: Wide Shot 镜头Establishing Wide Shot 相机运动Static 场景描述厨房全景主角穿着睡衣走进画面 音效水壶沸腾声清晨的安静 技术说明自然冷光为主暖色台灯补光 SHOT 2: Close-up 镜头Close-up - 咖啡豆 相机运动Slow Dolly In 场景描述咖啡豆倒入研磨机颗粒分明 音效研磨机的低频嗡鸣生成完之后Skill 会调用scripts/validate_storyboard.py做校验。这个脚本干三件事检查场景和镜头编号是否连续、检查是否用了标准术语、检查必需元素是否齐全。跑法很简单python scripts/validate_storyboard.py storyboard_output.md输出是一份报告会告诉你总场景数、总镜头数、用了哪些镜头类型、有没有遗漏音效或技术说明。如果报告里出现「未使用标准镜头术语」的警告说明 Claude 某处写了「近景」而不是「MS」你可以让它重写那一段。我实测下来第一次生成通常能过 80% 的检查项剩下的靠校验报告定位改一两轮就干净了。这个「生成—校验—修正」的闭环正是 Skill 比裸 prompt 强的地方因为校验逻辑是写死在脚本里的不依赖模型每次的发挥。5. 分镜 Skill 常见报错与排查做 Skill 的过程中报错基本集中在接入层和触发层我按真实遇到的错误码给你排一遍。401 错误返回authentication_error。这是 Key 的问题要么 Key 复制时带了空格要么 Key 已经失效。检查settings.json里的ANTHROPIC_AUTH_TOKEN字段确认没有多余字符。如果用的是 Cline注意它有的版本字段名是apiKey而不是authToken填错位置也会 401。local proxy failed这个报错通常出现在 Claude Code 启动时。意思是本地代理层没起来多半是 Base URL 写错了。确认填的是https://taotoken.net/api结尾不要加/v1也不要加斜杠。三件套里 Base URL 错一个字符都连不上。reading choices 相关报错返回体解析失败。这种情况一般是 Model ID 填错了模型名不存在服务端返回的结构跟客户端预期的不一样。去文档里核对当前可用的 Model ID别凭记忆填。OAuth 相关报错提示需要登录或授权。Claude Code 有时会优先走 OAuth 流程如果你用的是 API Key 接入需要在配置里显式指定用 token 认证别让它去走浏览器授权。检查配置里有没有ANTHROPIC_AUTH_TOKEN有的话它会优先用这个。Skill 不触发这个不算报错但最让人抓狂。排查顺序是先确认 Skill 文件夹放对了位置再确认SKILL.md的 YAML 格式没写错三个短横线必须顶格然后看 description 是不是太模糊。如果 description 只写「生成分镜脚本」Claude 很难判断什么时候该用改成「当用户需要为视频、电影、广告项目创建分镜脚本时使用」触发率会明显上升。实在不行直接用斜杠命令/storyboard-generator强制调用绕过自动判断。脚本执行失败报ModuleNotFoundError。这是dependencies字段里声明的依赖没装。Skill 不会自动帮你装包你得手动pip install。建议在SKILL.md里写清楚依赖团队协作时别人一看就知道要装什么。排查的时候有个通用技巧把 Skill 的SKILL.md内容单独贴给模型对话入口让它解释这段指令会怎么执行能快速定位是元数据问题还是正文逻辑问题。模型对话入口在https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite不用写代码就能试。6. 把分镜 Skill 沉淀为团队资产Skill 做完不是终点怎么让它长期可用才是。我的经验是三条。第一把SKILL.md的正文控制在 5000 词以内详细的术语表、行业标准、示例全部挪到references/里。正文只留流程和决策逻辑这样每次触发加载的 token 少响应快成本也低。我见过有人把两万字的规范全塞进SKILL.md结果每次调用都烧掉一大截额度得不偿失。第二脚本要参数化别硬编码。比如镜头时长的默认值、每个场景的镜头数都做成可配置的放在references/下的配置文件里。这样不同项目调整参数不用改脚本改配置就行。第三用 Git 管起来。Skill 文件夹就是一个普通目录git init之后正常提交。每次改SKILL.md或脚本都写清楚 commit message团队里谁改了什么一目了然。版本号写在元数据的version字段里配合CHANGELOG.md回滚的时候有据可查。如果你团队里做分镜的人多还可以基于这个 Skill 派生几个变体比如storyboard-generator-ad专门做广告、storyboard-generator-film专门做剧情片各自的references/放不同的行业规范。元数据的 description 写清楚各自的适用场景Claude 会自动选对的那个。最后说个实用技巧Skill 的校验脚本可以单独拿出来当 CI 检查用。团队提交分镜文档时跑一遍validate_storyboard.py格式不达标直接打回比人工 review 快得多。这套「Skill 生成 脚本校验」的组合才是把分镜脚本真正沉淀成可复用资产的关键。