企业官网建设流程全解析

1. 项目概述：这个 Skill 到底解决什么问题

先直接说结论：这个项目要做的，是打造一个专属于分镜脚本创作的工作模块，让 Claude 在你丢进来一段文案、剧本甚至只是一句核心创意之后，自动按影视行业的分镜规范，输出结构完整、字段清晰、可以直接拿去拍摄或者继续做二次创作的分镜脚本。分镜脚本是影视、动画、短视频创作里承上启下的关键文件，既要体现文字剧本的叙事逻辑，又要兼顾镜头语言、节奏、声音设计，所以它比普通文案复杂得多。

这几年 AI 生成内容越来越普及，我也见过不少团队直接用通用对话窗口让 AI 写分镜，结果经常会遇到同一个尴尬场面：AI 给出的内容“貌合神离”，章节分了、序号有了、画面也描述了，但景别逻辑混乱、机位角度前后接不上、镜头时长和声音字段直接缺失，甚至同一个故事换一种问法，出来的分镜风格能差到像两个人写的。你要不停地在对话里补要求、纠正格式、强调术语，每做一个新项目就得把这些“条条框框”重新搬运一遍，效率低得让人头疼。

Claude Skills 解决的就是这个“工作流固化”的问题。它等于把一套标准化的创作方法打包成一个独立模块，让 Claude 在相关场景下自动调用。分镜脚本需求量大、结构固定、重复劳动多，恰好是适合做成 Skill 的典型场景。这篇文章我会从结构拆解、目录设计、核心代码、注册加载、问题排查五个层面，把一个真实的“分镜脚本 Skill”从零到一完整复现出来。适合视频编导、动画师、短视频运营、独立创作者，以及所有在折腾 AI 工作流的朋友参考，就算你之前完全没接触过 Skill，只要照着步骤操作，也能把自己常用的创作套路变成 Claude 的职业技能。

1.1 先搞清楚 Claude Skills 到底是什么

很多朋友第一次听到 Claude Skills 会下意识把它当成一个“高级版 prompt 预设”，这个理解方向对了，但不完整。Skills 本质上确实是把一系列指令塞给 Claude，关键区别在于它的呈现形式：它不是一个躺在聊天框里的长文本，而是一个有明确结构的目录，里面可以放说明文档、模板文件、辅助脚本、示例数据。Claude 在执行任务时，会主动读取这个目录，按照说明文档里的操作规范来工作。

打个比方，普通 prompt 有点像你在路边临时找一个帮手，口头告诉他“帮我把这个剧本分一下镜头”，他能做，但你得在旁边不断提醒“景别注意一下”“转场写清楚”“声音设计别漏”。而 Skill 相当于你给这个帮手发了一本印刷好的工作手册、一套标准表格、一个计算器和几个参考案例。他拿到手之后，按手册流程走，填表、计算、检查，最后交给你一份稳定的成品。

在具体落地的时候，Skills 通常依赖 Claude Code 这类支持 Agent 模式的环境运行。Claude 会根据当前任务判断应该调用哪个 Skill，然后进入该 Skill 的上下文，读取里面的规则，再决定是否运行辅助脚本。整个调用过程不需要你在对话里反复强调要求，更像是“上下文自动感知”。

如果你已经习惯了把各种创作模板塞进 system prompt 里，那接触 Skills 之后很可能会产生一种“回不去”的感觉，因为模板是死的，Skill 是活的，模块之间可以有依赖，可以运行外部脚本，可以对生成结果做二次校验。这些东西在纯 prompt 层面很难优雅实现。

1.2 为什么要先做“分镜脚本”这个 Skill

我见过很多朋友第一次做 Skill，一上来就做一个非常宏大的“全能创作助手”，结果目录膨胀到离谱，SKILL.md 里什么领域都写了一点，最后 Claude 反而不知道该按哪套规则执行，效果非常拉胯。如果让我推荐一个最适合练手的方向，分镜脚本绝对排在前三名。

原因很简单：分镜脚本是一种结构化程度极高的文体。影视行业几十年的创作流程已经把它打磨出一套相对稳定的字段体系，镜号、景别、摄法、画面内容、台词、音效、时长、转场、备注，每个字段都有明确的职责。结构化程度高意味着规则容易枚举，规则容易枚举就意味着 Claude 能稳定遵循，这正是 Skill 最能发挥威力的场景。

另一个原因是高频。无论你是做广告、短视频、动画还是短剧，分镜脚本都是开工前的刚需。今天接一个 30 秒的种草视频要写分镜，明天可能又要做一个 60 秒的剧情片，内容千变万化，但框架基本不变。把框架固化成 Skill，让 AI 只负责往里填充符合规范的内容，而我只需要做后期审核和创意微调，省下来的时间非常可观。

最关键的一点，分镜脚本属于“看起来有创意门槛，实则规则比重很大”的创作类型。很多人以为分镜需要天马行空的想象力，实际上一个合格的分镜脚本首先要求的是准确和统一。镜头和镜头之间的逻辑要连贯，景别变化要有节奏，时长和情绪要匹配，这些规则完全可以标准化。反而是那些真正需要灵光一闪的创意环节，比如视觉风格、情绪基调的设计，AI 还做不到完全代劳。

把技能边界想清楚之后，就能明确这个 Skill 的任务定位：它不负责给你灵感，负责的是把已有的创意和文案，翻译成一套没有硬伤、细节完整、拍摄团队能直接理解的分镜脚本。

1.3 做一个 Skill 之前先用一句话定义它

动手写代码之前，我习惯先用一句话把 Skill 的功能边界定义下来。比如我给这个分镜脚本 Skill 的定义是：它接收一段文案或故事，输出一份符合影视行业通用规范的分镜脚本，其中每个镜头包含景别、运镜、画面描述、台词、音效、时长等核心字段，并以可读的 Markdown 表格形式呈现。

这句话有三个重点。第一是输入，明确这个 Skill 处理的是“文案或故事”，不是三无产品；第二是输出，明确要产出的是“分镜脚本”而非普通大纲；第三是格式，明确用“Markdown 表格”作为交付形态。把这些写清楚，后续写说明文档、设计模板、写校验脚本的时候，才有据可依。

实际执行的时候还需要抵抗一个诱惑：不要试图让 Skill 兼容所有情况。比如有人会想让它同时支持漫画分镜、游戏 CG 分镜、舞台调度脚本，这会让规则变得互相矛盾。第一版先把影视和短视频场景做好，后续再通过版本扩展去覆盖更多分支，远比一开始就摊大饼要靠谱。

2. 拆解分镜脚本的核心结构

要想让 Claude 稳定输出分镜脚本，第一步不是写代码，而是先把“分镜脚本”这个文体拆解成机器能理解的数据结构。我们必须让 Claude 清楚地知道：一个镜头里应该包含哪些字段，每个字段允许的取值范围是什么，字段与字段之间存在哪些约束关系。只有把这些全部定义清楚，Skill 里的每一条规则才不会变成废话。

2.1 分镜脚本的行业标准字段

影视行业里，分镜脚本并没有一个全球统一的绝对标准，但国内外主流制作流程里使用到的字段高度重合，核心信息总绕不开下面这些：镜号、景别、摄法/运镜、画面内容、台词/旁白、音效/音乐、时长、转场、备注。

镜号用于给镜头排序，一份脚本里镜号必须连续且唯一。景别描述镜头画面里主体的大小范围，通常分为远景、全景、中景、近景、特写等，有时候还会细分出大远景、大特写。摄法/运镜描述摄影机的运动方式，比如固定镜头、推、拉、摇、移、跟、升、降、环绕、手持等。画面内容指这个镜头里实际出现的具体动作、环境、人物互动，这是所有字段里信息量最大、最需要创意的地方。台词和旁白记录人物说出来的话，有配音（旁白）和同期声之分。音效和音乐承载听觉信息，比如环境音、音效点、背景音乐的起止与强弱。时长是镜头的持续时间，通常以秒为单位，短视频分镜里经常给整数秒，影视项目里可能精确到帧。转场描述镜头之间如何衔接，常见有硬切、淡入、淡出、叠化、划像等。备注用来记录特殊要求，比如道具、服装、特效提示、灯光要求。

在实际的剧组和导演案头，这些字段不一定全部出现，但我会在 Skill 里全部保留，宁多勿缺。因为生成内容时字段齐全，后期就算要删减，也比一开始就缺字段然后想不起来补要方便得多。

2.2 给 AI 建模：从“自由发挥”到“填空题”

拆完字段之后，需要想清楚一件更重要的事情：这些字段里，哪些是 AI 必须严格遵守规则的，哪些是允许它自由发挥的。

镜头号、景别、时长、转场这类字段属于“规范性字段”，取值边界清晰，比如景别不能写“比较近”，要么是“近景”要么是“中景”；时长不能是“一分钟左右”，必须给出具体秒数。画面内容和台词属于“创意性字段”，AI 需要根据原始文案去展开，那里允许一定的文字发挥。但如果对创意性字段不加约束，AI 又会给你写出一部长篇小说——画面描述动辄三五行，导演根本没耐心看。

所以我采用的建模思路是把镜头拆成“填空题”：规范性字段设计成下拉菜单式的枚举，创意性字段则用“一句话描述 + 核心信息点”的格式限制长度。比如画面描述，要求使用 30 到 60 字概括主要动作和主体关系，细节要求可以写进备注。这样既保留了创作自由度，又让整份脚本的阅读成本大幅下降。

关于景别切换，还可以再加一条业务规则：相邻镜头的景别不要两次连续相同，除非是为了刻意强调某种情绪。这条规则在短视频剪辑里非常常见，能让画面节奏更跳跃也更耐看。这种规则不一定写进通用分镜教材，但它来自实战经验，放进 Skill 里就是所谓的“独家手感”。

2.3 一个通用分镜模板的 JSON Schema

为了让 Claude 的输出结构严格可控，我建议在 Skill 里额外放一份 JSON Schema 文件。它有两个作用：第一，作为 Claude 生成 JSON 格式输出时的参照物；第二，配合校验脚本检查最终结果是否符合预期，不符合就报错并要求重新生成。

我设计的 Schema 长这样：

{ "$schema": "http://json-schema.org/draft-07/schema#", "type": "object", "required": ["project_name", "story_type", "total_duration", "shots"], "properties": { "project_name": { "type": "string", "description": "项目名称" }, "story_type": { "type": "string", "enum": ["短视频", "宣传片", "动画", "广告", "短剧"], "description": "内容类型" }, "total_duration": { "type": "number", "minimum": 1, "description": "预估总时长，单位秒" }, "shots": { "type": "array", "minItems": 1, "items": { "type": "object", "required": ["shot_number", "scene", "shot_size", "movement", "content", "dialog", "sound", "duration", "transition", "note"], "properties": { "shot_number": { "type": "integer", "minimum": 1 }, "scene": { "type": "string", "description": "场景描述，如：办公室、城市街道、室内厨房" }, "shot_size": { "type": "string", "enum": ["大远景", "远景", "全景", "中景", "近景", "特写", "大特写"] }, "movement": { "type": "string", "enum": ["固定", "推", "拉", "摇", "移", "跟", "升", "降", "环绕", "手持"] }, "content": { "type": "string", "minLength": 10, "maxLength": 120, "description": "画面内容描述" }, "dialog": { "type": "string", "description": "台词或旁白，无则留空字符串" }, "sound": { "type": "string", "description": "音效、音乐或环境声描述" }, "duration": { "type": "number", "minimum": 1, "maximum": 30, "description": "镜头时长，单位秒" }, "transition": { "type": "string", "enum": ["硬切", "淡入", "淡出", "叠化", "划像", "无"] }, "note": { "type": "string", "description": "备注，道具、特效、灯光等特殊提示" } } } } } }

里面有一个地方需要特别注意：duration 字段我设置了最大值 30。现实里当然有超过 30 秒的长镜头，但在短视频和广告领域，单个镜头超过 30 秒已经属于极端情况。这个限制的目的是在早期阶段就约束 AI 不要生成那种动辄一分钟的长镜头，否则整份脚本的节奏感会立刻垮掉。

Schema 本身不追求百分之百覆盖真实影视项目的所有边界情况，它更像是一个“及格线”，保证输出基础质量。后续如果有特殊项目，比如需要长镜头或特殊转场，我会在 SKILL.md 的规则里针对性地放开。这就是模板和规则互相配合的关系。

3. Skill 目录结构与编写规范

理解了要做什么之后，接下来就要明白 Claude Skills 是怎么在文件系统里组织的。网上关于 Skills 的介绍越来越多，但很多人一上手还是会被目录结构卡住。实际上它没有那么神秘，核心就是：一个文件夹，里面有一个固定的说明文件，再按需放模板、脚本、参考示例。

3.1 目录布局设计

我给分镜脚本 Skill 设计的目录结构是这样的：

storyboard-skill/ ├── SKILL.md ├── templates/ │ ├── storyboard_schema.json │ └── storyboard_template.md ├── examples/ │ └── demo_output.md └── scripts/ └── validate_storyboard.py

SKILL.md 是整个 Skill 的大脑，所有行为规则都写在里面。templates 目录里放两份模板文件：JSON Schema 用来约束输出的数据结构，Markdown 模板用来规定人眼阅读时的最终排版。examples 里放一份演示输出，它的作用是给 Claude 提供一个“好的答案长什么样”的具体参照，同时也能在我调试的时候快速检查格式。scripts 目录里放校验脚本，它可以被 SKILL.md 引用，让 Claude 生成内容之后顺手跑一遍检查，有问题就自动修订。

这里说一下为什么建议把 Schema 单独拆成文件，而不是直接写进 SKILL.md。因为 SKILL.md 本质上仍然是一份偏“人类阅读”的指令文档，如果里面塞了一大段冗长的 JSON Schema，会导致真正重要的行为规则被遮蔽。Claude 读取文档时注意力是有限的，指令越混杂，遵守率越低。拆成独立文件后，SKILL.md 只需要一句话告诉 Claude 去读取模板目录下的文件，逻辑就干净很多。

3.2 SKILL.md 的 YAML 头信息

每个 Skill 的本质都是一个 Markdown 文件，但这个文件需要包含一段 YAML 格式的元数据头。头信息里最核心的是 name 和 description 两个字段。

--- name: storyboard-skill description: 当用户需要将文案、剧本、故事或创意脚本转换为专业分镜脚本时使用。适用于短视频创作、宣传片策划、动画分镜、广告脚本等场景。当用户提到镜头表、分镜、画面拆解、镜头语言设计时，优先使用此技能。 ---

name 是 Skill 的唯一标识。description 的作用更关键，它相当于这个 Skill 对外展示的“广告词”和触发条件。Claude 在判断当前任务需不需要调用某个 Skill 时，就是拿用户的提问和 description 做匹配。所以 description 里要尽量覆盖真实用户会说的说法——不只是“分镜”，还要有“镜头表”“画面拆解”“镜头语言设计”这些同义表达。

很多人第一次写 description 容易犯的毛病是写得太窄，只写“当用户要求写分镜脚本时使用”，导致用户换了一种说法，Claude 就没能触发这个技能。反过来也不要写得太夸张，比如“任何与视觉创作相关的内容都需要使用”，这会让 Skill 在错误场景下频繁被调用。写 description 的尺度，应该把握在“用户确有明确分镜需求”这个范围内。

3.3 让 Claude 稳定执行的 Instructions 写法

正文部分，也就是真正的指令区，我建议按照“任务目标、执行步骤、输出要求、禁忌事项”四个块来组织。任务目标告诉 Claude 这个 Skill 存在的意义；执行步骤是具体的操作流程；输出要求描述最终交付格式；禁忌事项列明什么不能做。

这里分享两条我认为最重要的经验。第一，指令里每个句子都要尽量是“可验证的动作”，让 Claude 理论上可以逐条对照执行。比如“检查所有景别字段是否在枚举范围内”就比“确保字段规范”要可操作得多。第二，执行步骤里要刻意安排一个“自检环节”，比如输出完分镜后，要求 Claude 对着 JSON Schema 自己校验一遍，发现 missing field 或 illegal value 就自动修正。这一招能极大提高最终输出的稳定性，远比你事后肉眼检查更省力。

在 SKILL.md 中还可以引用辅助脚本，说明“生成分镜脚本之后，运行 python scripts/validate_storyboard.py <输出文件>，如果校验不通过，根据报错信息重新修改”。这句话能让 Claude 在条件允许的情况下自动执行检查，而不是仅仅停留在“自己读一遍”这种不可靠的自检上。

4. 完整实现过程

理论铺垫结束，下面进入真正能抄作业的部分。我会从创建目录开始，一步一步把 SKILL.md、模板、校验脚本全部写出来，手把手带你把 Skill 跑起来。整个过程不依赖复杂的开发环境，只需要一个支持 Claude Skills 的客户端和基本的 Python 环境即可。

4.1 初始化项目目录

在终端里执行下面这组命令，先把项目骨架建起来：

mkdir -p storyboard-skill/{templates,examples,scripts} cd storyboard-skill touch SKILL.md

创建完成后，用 tree 命令确认目录结构没问题：

find . -type f -o -type d | sort

到这里，项目文件夹只是一个空壳，下一步开始写核心内容。我习惯先把 templates 目录里的 JSON Schema 放进去，因为它是后面 SKILL.md 的参照对象，先有规则再写手册，顺序比较顺。

4.2 编写模板文件与 Schema

把上一节展示的 JSON Schema 内容保存到 templates/storyboard_schema.json。如果你的 Skill 需要更细的字段控制，可以在 items 里定义 additionalProperties: false，禁止 Claude 加入 schema 之外的字段。不过我在实践里没有一开始就加这个限制，因为真实项目偶尔会需要临时补充一两个自定义字段，限制太死反而让 Skill 显得僵硬。

接着写 Markdown 模板，也就是最终交付给用户阅读的排版格式：

# 项目分镜脚本 - 项目类型：{{story_type}} - 预估总时长：{{total_duration}}秒 - 镜头总数：{{shot_count}} ## 分镜明细 | 镜号 | 场景 | 景别 | 运镜 | 画面内容 | 台词/旁白 | 音效/音乐 | 时长(s) | 转场 | 备注 | |------|------|------|------|----------|-----------|-----------|---------|------|------| | 1 | 城市街道 | 远景 | 移 | 人物从远处走来，背景霓虹灯闪烁 | 无 | 街道环境音 | 5 | 硬切 | 夜晚戏，注意灯光 | | 2 | 城市街道 | 中景 | 跟 | 人物停下脚步，抬头看前方 | 旁白：就是这里 | 音乐渐入 | 3 | 硬切 | 无 | > 备注：所有镜头时长累加应与预估总时长一致。

为什么要保留 Markdown 表格作为最终输出格式？因为在实际的剧组创作场景中，导演、摄影、美术、演员都需要快速读取分镜，Markdown 表格能在一屏里展示完整字段信息，打印和在线协作都非常方便。JSON Schema 主要用于机器校验和存档，最终读给 Team 看的还是这个表格。

4.3 编写 SKILL.md 核心指令

SKILL.md 是整个 Skill 的灵魂，内容质量直接决定最终输出效果。我给出的完整版本如下：

--- name: storyboard-skill description: 当用户需要将文案、剧本、故事或创意脚本转换为专业分镜脚本时使用。适用于短视频创作、宣传片策划、动画分镜、广告脚本等场景。当用户提到镜头表、分镜、画面拆解、镜头语言设计时，优先使用此技能。 --- # 分镜脚本创作助手 ## 任务目标 根据用户提供的故事文案，生成结构完整、字段清晰、逻辑连贯的专业分镜脚本。 ## 输入要求 1. 用户可以直接输入完整剧本，也可以输入故事梗概或创意描述。 2. 如果用户未说明分镜类型，默认按照短视频分镜处理。 3. 如果用户未说明目标总时长，按实际情况推测，并备注说明。 ## 执行步骤 1. 通读用户输入的文案，提炼核心情节、情绪节奏和关键视觉元素。 2. 判断内容类型：短视频、宣传片、动画、广告、短剧。 3. 依据原始文案，按事件发展顺序拆分为多个镜头。 4. 为每个镜头填写字段： - 镜号：从 1 开始连续递增。 - 场景：简洁描述镜头所在空间。 - 景别：从大远景、远景、全景、中景、近景、特写、大特写中选择。 - 运镜：从固定、推、拉、摇、移、跟、升、降、环绕、手持中选择。 - 画面内容：30 至 80 字，描述主要人物、动作和环境关系。 - 台词/旁白：有就写，没有就写“无”。 - 音效/音乐：说明声音设计安排。 - 时长：单个镜头 1 至 30 秒，合理规划节奏。 - 转场：默认硬切，按需选择淡入、淡出、叠化、划像。 - 备注：补充 CGI、灯光、道具、特殊拍摄要求。 5. 检查相邻镜头是否出现连续同景别的情况，如果出现且非刻意强调情绪，修正其中一个。 6. 计算预计总时长：各镜头时长之和。 7. 输出 Markdown 表格格式分镜脚本。 8. 调用校验脚本检查 JSON 结构是否合法。 ## 输出格式 必须严格按照 templates/storyboard_template.md 的 Markdown 表格格式输出。 字段不得缺失，景别和运镜必须使用规定枚举值。

这份 Instructions 里最关键的是执行步骤第 5 条，我刻意加入了“相邻镜头景别检查”这条规则，它来自剪辑实战中的节奏控制经验。AI 默认并不会关注景别之间的排列组合，所以必须显式写出来。实际测试下来，加上这条之后，生成脚本的可读性和节奏感有明显提升。

另一个细节是在输出要求里写“字段不得缺失”。这看起来是句废话，但其实是在给 Claude 一个清晰的优先级信号：哪怕画面描述少写几个字，也不能丢掉必填字段。这比笼统地要求“输出高质量分镜”要实在得多。

4.4 编写辅助校验脚本

为了让 Skill 多一层机器保障，我在 scripts 目录里放了一个 Python 校验脚本。它的核心功能是读取生成的 JSON 文件，检查必填字段和枚举值是否合法，不合法就返回具体错误位置。

import json import sys from pathlib import Path REQUIRED_FIELDS = ["shot_number", "scene", "shot_size", "movement", "content", "dialog", "sound", "duration", "transition", "note"] VALID_SHOT_SIZES = {"大远景", "远景", "全景", "中景", "近景", "特写", "大特写"} VALID_MOVEMENTS = {"固定", "推", "拉", "摇", "移", "跟", "升", "降", "环绕", "手持"} VALID_TRANSITIONS = {"硬切", "淡入", "淡出", "叠化", "划像", "无"} def validate(data): errors = [] if "project_name" not in data: errors.append("缺少 project_name 字段") if "shots" not in data or not isinstance(data["shots"], list): errors.append("shots 必须是非空数组") return errors total_duration = 0 for idx, shot in enumerate(data["shots"], start=1): for field in REQUIRED_FIELDS: if field not in shot: errors.append(f"镜头 {idx}: 缺少字段 {field}") continue if shot.get("shot_size") not in VALID_SHOT_SIZES: errors.append(f"镜头 {idx}: 景别非法 -> {shot.get('shot_size')}") if shot.get("movement") not in VALID_MOVEMENTS: errors.append(f"镜头 {idx}: 运镜非法 -> {shot.get('movement')}") if shot.get("transition") not in VALID_TRANSITIONS: errors.append(f"镜头 {idx}: 转场非法 -> {shot.get('transition')}") duration = shot.get("duration") if isinstance(duration, (int, float)): total_duration += duration if duration <= 0 or duration > 30: errors.append(f"镜头 {idx}: 时长应在 1-30 秒之间") else: errors.append(f"镜头 {idx}: 时长必须为数字") if data.get("total_duration"): if abs(data["total_duration"] - total_duration) > 1: errors.append("总时长与各镜头累加值不一致") return errors if __name__ == "__main__": path = Path(sys.argv[1]) data = json.loads(path.read_text(encoding="utf-8")) errs = validate(data) if errs: print("校验失败：") for e in errs: print(f" - {e}") sys.exit(1) print("校验通过")

这段脚本并不复杂，但它起到了两个作用。第一，在 Claude 生成分镜并输出 JSON 后，可以立即验证输出质量；第二，在调试阶段，它帮我省掉了大量肉眼核对枚举值的时间。脚本里对总时长做了一个软校验，允许 1 秒以内的四舍五入偏差，避免因为时长取整问题导致误报。

4.5 注册 Skill 并完成加载

目录文件都写好之后，接下来要把 Skill 放到 Claude 能扫描到的位置。在 Claude Code 这类支持 Agent Skills 的环境中，通常约定把 Skill 放在项目目录下的 .claude/skills/ 文件夹里，或者放在用户全局配置目录下。我习惯在项目里调试时用局部目录，稳定之后再复制到全局目录。

mkdir -p .claude/skills cp -r storyboard-skill .claude/skills/

复制完成之后，在 Claude Code 对话界面输入 /skills 命令，正常情况下应该能看到 storyboard-skill 出现在列表中。如果没出现，检查目录层级是否正确——很多第一次上手的朋友会把路径放错，导致扫描不到。

加载完成后，直接扔一段故事文案进去测试。比如我拿一段 30 秒的产品宣传文案试，Claude 会自动触发 Skill，按照 Instructions 里的步骤生成分镜表格。注意第一次生成的效果大概率不会尽善尽美，这是正常的，Skills 也需要像 prompt 一样反复调校。

4.6 根据测试结果迭代优化

Skill 写完后不是终点，后续的调试打磨期才是产出真正可用的关键。我第一次测试时，生成的表格里出现了两个问题：一个是景别枚举值写了“全景/中景”这种组合形式，不符合 schema 里单值枚举的要求；另一个是某些镜头的画面描述超过了 120 字，太过冗长，导演阅读负担很大。

处理方式很简单，回到 SKILL.md 里增加一段更明确的约束：

## 禁忌事项 1. 景别和运镜字段只允许填写单一枚举值，严禁写组合形式或模糊描述。 2. 画面内容描述限制在 30 到 80 字之间，超出则拆分或精简。 3. 不要输出额外解释性文字，直接在输出格式中呈现分镜表格。

加完约束继续测试，第二次生成就明显规范多了。这种“测试 → 发现偏差 → 补规则 → 再测试”的循环，是制作 Skill 的常态。Skill 的规则不是越小越好，也不是越多越好，而是要在“约束强度”和“生成灵活性”之间找到平衡点。

5. 常见问题与排查技巧实录

在实际做这个 Skill 的过程中，我陆续踩过不少坑，也帮身边朋友排查过一些问题。这些经验很多不在官方文档里，但它们对技能的可用性影响非常大。这一部分我整理成速查表格，加上一些实操心得，希望能让你少走弯路。

5.1 Claude 没有触发 Skill 或完全无视规则

这是最常见的翻车现场，明明 Skill 已经装好了，结果用户输入“给我拆个镜头”，Claude 就像没事人一样直接自由发挥了。排查顺序通常是先看 description 是否覆盖了用户真实说法。如果你只在 description 里写了“分镜脚本”，那用户说“画面拆解”可能就触发不了。我建议在 description 里尽可能多放几种同义触发词。

排除了触发问题之后，再看 SKILL.md 的指令语气。Claude 本质上是一个偏好遵循结构化指令的模型，你写得越像“工作手册”，它越容易进入对应角色。如果你在 SKILL.md 里写得很随意，比如只有一句“帮用户生成分镜”，那它大概率只会把它当作一个提案，而不是强制流程。所以我在 Instructions 里用了大量祈使句和明确的步骤编号，实际效果比那种“请你尝试……”的客气表述好很多。

还有一种情况是 Claude 虽然加载了 Skill，但在多轮对话后逐渐跑偏，开始按照用户插嘴的随口要求去调整格式，把 Skill 里的规则抛在脑后。针对这个问题，我会在 SKILL.md 的禁忌事项里加一条“除非用户明确要求改变输出结构，否则必须保持既有输出格式”。这条规则能有效守住 Skill 的基本盘。

5.2 输出格式不稳定，字段时有时无

格式不稳定往往不是因为 Claude 能力不够，而是你给它的“格式参照”不够清晰。SKILL.md 里如果只写了“输出包含镜头信息”这种抽象描述，那实际效果全凭模型心情。解决手段有两个，一是把 Markdown 模板放到 templates 目录里，并在 SKILL.md 中明确说“严格参照 templates/storyboard_template.md 的格式”；二是让校验脚本参与强制纠错。

我在实际调试中还发现一个规律：让 AI 先生成 JSON，再由脚本转换成 Markdown，会比让它直接生成 Markdown 表格更稳定。因为 JSON 是机器语言，字段边界天然清晰；而 Markdown 表格是视觉语言，模型经常为了表格美观而省略某些字段。后来我把流程改成这样：Claude 先按 JSON Schema 生成数据 → 校验脚本检查 → 等数据完全合法之后，再渲染成 Markdown 表格。这种两段式流程极大地降低了漏字段的概率。

如果你不想写两段式流程，也可以让 Claude 在生成完 Markdown 之后，自己对照模板逐字段检查一遍，并把检查结果附在输出前面，比如“已检查，所有必填字段均已包含”。这个做法也能起到自我提醒的作用。

5.3 脚本运行失败或找不到文件

校验脚本运行时可能遇到两类问题。第一类是路径错误，Claude 未必知道脚本相对于当前工作目录的位置。在 SKILL.md 里调用脚本时，尽量使用相对路径，并写明是在 Skill 目录下运行。我在 Instructions 里写的是python scripts/validate_storyboard.py，前提是 Claude 需要先进入 Skill 所在目录。如果你发现它总是跑错路径，可以在 Instructions 里直接写完整路径，或者要求 Claude “先查看当前目录下 scripts 文件夹中的内容，再决定如何执行”。

第二类是环境依赖问题。比如本机 Python 版本不一致，或者脚本用到了第三方库。我设计的这个校验脚本只用标准库，就是为了避免这种麻烦。给 Skill 配辅助脚本时，我会建议你优先使用标准库，实在需要第三方依赖，就要在 SKILL.md 里写清楚安装命令，并让 Claude 在执行前先检查依赖是否可用。

还有一个小细节是文件编码。Windows 环境下如果 Python 脚本读取文件时用默认编码，很容易遇到中文乱码或解码错误。我在脚本里打开文件时都指定了encoding="utf-8"，这个细节看着不起眼，但在 Windows 上救我很多次。

5.4 分镜 Skill 的能力边界与人工审查

最后聊一个容易让人忽略的问题：Skill 做得再好，也不能完全替代人的创意判断。我见过有朋友拿 Skill 生成的脚本直接进棚拍摄，结果执行到一半发现某些镜头的机位和演员调度并不现实，返工成本非常高。分镜脚本本质上是拍摄团队的“施工图”，AI 可以帮你把格式做规范、把逻辑理顺，但现场的可执行性还是需要有经验的人把关。

所以我会在 SKILL.md 的输出要求里建议用户做一次人工复核，重点看三件事：景别递进是否符合情绪节奏，机位切换是否在物理上可执行，台词和配音是否与画面时长匹配。让 AI 在脚本最下方加一条提醒：“以上分镜脚本由 AI 辅助生成，建议拍摄前由导演或编导进行现场可行性审核。”这不是为了显得严谨，而是因为此类内容生成工具的最终责任始终在创作者自己身上。

另一个边界是版权和风格模仿问题。制作分镜脚本时，AI 可能会在描述中无意识地贴近某些既有作品的视觉风格，创作者在采纳时应该保持审慎。分镜脚本的参考价值大于最终成片价值，把它当作灵感和效率工具，而不是拍板工具，整体体验会健康得多。

最后分享一个我在实际使用中养成的习惯：每次做完一个项目，我都会把 SKILL.md 微调一遍，把这次项目中踩到的坑以“禁忌事项”的形式补充进去。比如有个项目里 AI 连续好几个镜头都用了“推”的运镜，导致视觉单调，我就加上了一条“同一场戏中连续镜头避免使用相同运镜，除非有明确情绪需求”。每次微调看起来只是一句话，但积累十几稿之后，这个 Skill 会越来越像一个真正带过组的分镜师，而不是一个通用的文本生成器。

Trust the process，动手做一个属于你自己的 Skill，你会发现它带来的效率提升比想象中更明显。如果后续你打算扩展，可以考虑给这个 Skill 加上批量导出 CSV、对接剪辑软件、甚至结合视频理解模块反推参考镜头，那又是另一个值得玩儿的项目了。