你有没有遇到过这种场景：刚让 Claude 写好一份带镜号、景别、运镜的分镜表，过两天换个对话，它又把“特写”写成“近距离拍摄”，把转场方式写得乱七八糟。重复描述需求、反复纠正格式，是最消耗耐心的环节。我后来把整套分镜制作流程做成了一个 Claude Skills，每次一句话就能让 Claude 进入“分镜师”角色，输出稳定规范的分镜脚本。这篇指南会从 Skills 的底层机制讲起，演示怎么从零构建一个分镜脚本 Skill，包括目录结构、SKILL.md 的写法、触发规则，以及我在真实使用中踩过的坑和修复方法。无论你是视频编导、动画创作者，还是刚接触 Claude Code 的开发者，照着这份指南做一次，就能完全掌握自定义技能的制作逻辑。

1. 先搞懂 Claude Skills 的工作机制，才不会做出一堆废文件

我不建议一上来就埋头写提示词。Skills 的机制虽然不复杂，但如果你不理解它的加载方式和触发原理，很容易做出一个“看起来挺像样，实际却永远不被调用”的文件夹。动手之前，先花五分钟把下面几个概念理清。

1.1 Skill 和普通对话指令的本质区别

以前我们让 Claude 干活，基本靠两种方式：要么在对话框里写一段很长的临时指令，要么把常用指令存成一个系统级 Prompt。前者的痛处在于每次都要重新交代，而且模型很容易把上一轮的要求“说丢”；后者则过于粗暴，等于把所有任务都绑在一个超长的上下文里，既费 token，又会让 Claude 在无关任务中混入多余的行为。

Skill 走的是第三条路：把能力打包成目录，按需加载。目录里面放一个 SKILL.md 作为主入口，里面写清楚这个技能负责什么、应该按什么步骤工作、输出要符合什么格式；如果需要参考资料，还可以在旁边放独立的 Markdown 文件或脚本。当 Claude 接到一个任务时，它会根据每个技能的描述信息判断“当前这个请求是否适合调用这个技能”，适合就把它加载进来，不适合就完全忽略。

换句话说，Skill 让 Claude 从“一个什么都懂一点、什么都只能临时发挥的聊天对象”，变成了“一个装了各种工具包、能按场景切换专业身份的协作者”。这也是它和普通对话指令最大的区别：指令是即时生效的，而 Skill 是持久化、可复用、可维护的。

1.2 Skill 的目录挂载与发现流程

每个 Skill 本质上就是一个以技能名命名的文件夹，里面至少要有一个 SKILL.md 文件。Claude Code 在启动后会扫描固定的技能目录，把你手工放进来的文件夹识别成可调用的能力。

目录分两级：一是用户级目录，通常在~/.claude/skills/下，放全局通用技能，所有项目都能用；二是项目级目录，在项目根目录的.claude/skills/下，放只属于当前项目的内部技能。我开发分镜脚本技能时放在用户级目录，因为写分镜这件事不依赖具体代码项目，属于跨项目能力。

扫描流程大概是：启动对话时，Claude 会列出技能目录中每个文件夹的 frontmatter（后面会讲），把这些技能的 name 和 description 加入决策上下文。真正轮到你发出请求时，它再根据 description 决定是否读取具体的 SKILL.md，然后开始执行里面的指令。这里有个特别容易被忽略的点：技能能否被发现，靠的是 description；技能能否被正确执行，靠的是 SKILL.md 正文；技能能否用得顺手，靠的是参考资料的组织方式。

1.3 frontmatter 里的 name 和 description 决定技能是否被“叫醒”

SKILL.md 顶部有一段 YAML 格式的 frontmatter，最关键的两个字段是 name 和 description。name 好理解，就是技能的名字；description 才是真正的“触发器”。

Claude 判断什么时候调用这个技能，基本完全依据 description 的语义匹配度。所以描述里要写清楚三件事：这个技能处理什么类型的输入、输出什么形态的结果、适合哪些具体场景。比如分镜脚本技能，我一开始写的 description 很贪心，想着多写几个场景覆盖更多需求，结果它在“帮我整理会议纪要”时也会莫名其妙跳出来，因为描述里包含了“整理”和“项目”这类通用词。后来我把描述收敛成只有“剧本、分镜脚本、镜头表、故事板、短视频脚本”这几个强相关词，误触发率立刻低了很多。

还有一个细节：name 不要随便带空格或奇怪符号，尽量用短横线连接的小写英文，例如shot-list-generator。目录名、name、技能文件夹名字三者保持一致，能省掉很多排查时间。

1.4 为什么我选择“分镜脚本”当第一个技能

技能制作这件事，选第一个练手项目很重要。我见过很多人第一个技能就做“全流程项目管理助手”，结果功能太宽、边界模糊，写了一堆指令却总在关键任务上失效，最后弃坑。分镜脚本是很好的练手对象，因为它有三个天然优势：

第一，输出结构极其明确。分镜表就是“镜号、景别、运镜、画面内容、时长、音效、转场”这些字段的组合，几乎不会出现语义模糊地带。第二，行业里有成熟规范可以参照。影视和广告行业沉淀了几十年的分镜表写法，你只需要把这些规则整理成 Claude 能理解的自然语言。第三，价值立竿见影。我拿一个真实短视频脚本来测试，过去手动写分镜要一小时，现在让 Claude 生成初版后我只需要微调细节，五分钟内就能得到一张能直接拿去拍摄的表格。

2. 沉淀领域知识：分镜脚本不是一句话模板，而是整套表格逻辑

很多人做技能时犯的最大的错，就是只在 SKILL.md 里写“你是一个分镜师，请把用户输入转成表格”。这句话没有信息量。模型确实知道分镜是什么，但“知道”不等于“输出稳定”。如果你不把字段标准、术语表、节奏规则固化下来，它每次输出的表格都可能换一种格式。

所以制作分镜脚本技能的第一步，不是写代码，而是把你自己脑子里的分镜知识全部倒出来，整理成可被模型读取的规范文件。

2.1 先定义输出标准：一张分镜表应该有哪些字段

我参考了影视行业的通用表格，又结合短视频制作的实际需求，最后确定了一套七字段的输出标准。每个字段都有明确含义，不允许 Claude 自行增减。

这个表看起来简单，但把它固定成模板的意义非常大。它规定了 Claude 每次输出的“骨架”，模型只需要在骨架里填内容，不需要重新发挥创造力去设计一个新表格。对使用者来说，跨多个项目拿到同一格式的分镜表，才有可能做后续的批量分析和自动化处理。

你可能注意到，有些更专业的分镜表还会包含灯光、服装、道具、美术备注等字段。对电影级制作来说那些字段确实必要，但对日常短视频、演示动画、广告短片而言，七字段已经足够。做技能时不要一味追求完整，输出字段越少越不容易出错，必要字段后续可以再补充。

2.2 景别、运镜、转场的控制词表，建立 Claude 的“行业黑话”

模型其实知道景别术语，但它在具体输出时经常用同义词替换，比如把“特写”写成“近景特写”，把“推镜头”写成“镜头缓缓靠近”。这在人类作者那里是文采，在分镜表里就是灾难——拍摄团队看到不统一的术语，会立刻停下来问到底怎么拍。

我的解决办法是给 Claude 建一个控制词表，限制它只能使用表内的术语。景别就六个：远景、全景、中景、近景、特写、大特写。运镜就八个：固定、推、拉、摇、移、跟、升、降。转场就八个：硬切、叠化、淡入、淡出、黑场、白场、划像、甩镜。

不要小看这个限制。控制词表本质上是在缩小模型的输出空间，输出空间越小，出错的概率就越低。把这些词写进参考资料里，再在输出模板中注明“术语必须严格使用控制词表中的词”，Claude 就会老实很多。如果你觉得某些场景需要超出词表的表达，可以单独开启一个“备注”字段，让它在备注里自由发挥。

2.3 把时长和镜头数的估算规则写进技能

分镜表不是把场景描述拆成句子就行，它必须考虑真实拍摄的节奏。一个 30 秒的短视频，如果生成 20 个镜头，每个镜头只有 1.5 秒，画面会碎到没法看；如果把一个 3 分钟的短片只分成 8 个镜头，每个镜头停留 20 多秒，观众又会觉得拖沓。所以我需要把节奏规则也写进技能。

我用的是一套简单经验规则：30 秒以内的短内容，8 到 12 个镜头，平均每个镜头 2 到 3 秒；1 分钟左右的广告或宣传片，15 到 20 个镜头，平均 3 到 4 秒；3 分钟以上的剧情短片，按场景划分，普通对话场景每个镜头 3 到 5 秒，动作或情绪变化场景 1 到 2 秒。规则不用太精确，给 Claude 一个区间，它就能输出靠谱的时长建议。

这里还有一个技巧：不要让 Claude 把每个镜头的时长都写成整数。真实拍摄时，过长镜头常是 4.2 秒、2.8 秒这种不规则数字，这恰恰是节奏呼吸感的一部分。直接告诉 Claude“时长可以精确到小数点后一位”，输出会更有实操感。

2.4 为什么这些知识要写进 Skill，而不是依赖模型自己发挥

有人会问：Claude 本身知道景别，也知道分镜表长什么样，为什么非要手动写一堆规则？我的回答是：模型的知识面是“百科全书式”的，什么类型都有涉猎，什么风格都输出过；而你需要的是“固定标准式”的输出，每一次都要在同一格式框架里完成。这两者的矛盾只能靠外部规范解决。

举一个我实测过的例子：同一个剧本，我在普通对话里让 Claude 写分镜，它给出的景别排序毫无逻辑，特写、全景、中景混在一起；而我把同样的剧本交给做完的分镜 Skill，它会自动按“先全景交代环境、再中景交代人物关系、最后特写捕捉情绪”的叙事逻辑来组织镜头顺序。差别之所以这么大，就是因为 Skill 里明确写了“景别设计应该由远及近、由环境到细节”的规则。

模型在没有约束的时候，倾向于生成“看起来正确”的内容；在有了明确规范之后，才会生成“符合你要求”的内容。Skills 的本质，就是把你的规范变成模型的默认行为。

3. 动手制作分镜脚本 Skill：目录、核心文件与调用链路

理论部分讲完了，进入实操。这部分我给出完整的制作过程，你照着做一遍，就能得到一个可用的分镜脚本技能。中间每个关键步骤我都会解释为什么这样做，避免你只抄动作、不理解逻辑。

3.1 建立技能目录与参考资源结构

我建议一开始就把目录结构设计好，不要把所有内容塞进一个 SKILL.md。分镜技能的文件结构如下：

~/.claude/skills/ └── shot-list/ ├── SKILL.md └── references/ ├── shot-term-glossary.md ├── duration-rules.md └── output-template.md

在命令行里执行：

mkdir -p ~/.claude/skills/shot-list/references touch ~/.claude/skills/shot-list/SKILL.md

为什么要拆成多个文件？第一，SKILL.md 本身会作为指令的一部分被加载进上下文，太长会占用上下文空间，所以主文件必须精炼；第二，参考资料文件不是每一次都要全量加载，Claude 可以在需要时按需读取，效率更高；第三，后续维护更轻松——想改术语表就去 references 目录，不用重写整个技能。

Windows 用户注意路径，在用户主目录下同样会有一个.claude文件夹，创建方式一样，只是路径写法不同。

3.2 编写 SKILL.md 的 frontmatter 与任务定义

SKILL.md 是技能的心脏。它由 frontmatter 和正文两部分组成。在我的分镜技能里，frontmatter 是这样写的：

--- name: shot-list-generator description: 将剧本、故事梗概或短视频创意转化为专业分镜脚本表格。适用于短视频编导、影视分镜、动画分镜、广告脚本制作等场景。当用户提供文字剧本、故事段落、拍摄创意并要求生成镜头表、分镜表、故事板时使用。 ---

正文部分，我按五段式组织：角色定位、输入理解、工作流程、输出规范、硬性约束。完整内容大致如下：

# 角色定位 你是一名资深影视分镜师，擅长将文字剧本转化为可拍摄的分镜脚本表格。你的输出必须符合影视行业通用规范，同时兼顾短视频平台的节奏习惯。 # 输入理解 用户的输入可能是完整的剧本、一段故事梗概，甚至只有一句话创意。你能接受的输入形态有： 1. 完整的场景剧本 2. 一段带情节的段落文字 3. 一句描述核心画面的创意短语 在开始生成分镜之前，先判断输入属于哪种形态，并做一次简短的“需求确认”。如果信息缺失严重，例如没有人物、没有场景、没有事件，不要硬编，直接向用户询问最关键的缺失信息。 # 工作流程 第一步：读取 references/shot-term-glossary.md 中的术语表，确保后续输出遵循统一术语。 第二步：根据用户提供的文本，拆解出场景、角色、核心动作。 第三步：按照 references/duration-rules.md 中的节奏规则，把场景拆成若干镜头。 第四步：按照 references/output-template.md 规定的字段和顺序输出分镜表。 # 输出规范 严格遵守 output-template.md 中的表格模板，字段顺序不可调整。每个镜头都要有独立的镜号，景别、运镜、转场必须使用术语表中的标准词。 # 硬性约束 1. 不允许省略任何镜头参数，不允许用“同上”代替重复内容。 2. 用户输入不足时，允许最多问一次问题，之后仍按现有信息生成。 3. 如果输入是故事梗概，必须先补充“角色设定区”，再生成分镜表。

这段正文的核心思路是：用最短的指令把工作流讲清楚，同时把具体细节交给参考资料。你会发现我在 SKILL.md 里没有写具体景别有哪些，因为那不应该是主文件的职责。

3.3 把输出模板做成独立文件，强制约束格式

references 目录里的内容决定技能输出的“下限”。output-template.md 是我最重要的一个文件，它直接定义分镜表长什么样。这里贴出关键部分：

# 输出模板 输出必须包含两个部分：角色设定区、分镜表。 ## 角色设定区 | 角色名 | 性别/年龄 | 外形特征 | 服装 | 出现场次 | | --- | --- | --- | --- | --- | | 示例角色A | 男/25岁 | 短发，戴眼镜 | 深灰色卫衣 | 1、2 | ## 分镜表 | 镜号 | 景别 | 运镜 | 画面内容 | 对白/音效 | 时长 | 转场 | | --- | --- | --- | --- | --- | --- | --- | | 1 | 远景 | 固定 | 城市清晨，街道人流稀疏，主角从远处走来 | 环境音：远处车流声 | 3.5s | 叠化 |

这里的关键在于“角色设定区”。分镜表需要兼顾镜头和叙事，如果角色关系没定清楚，后面每个镜头都要重复描述人物，Claude 很容易在第五六个镜头时把角色特征写岔。把角色设定固定在开头，相当于给整个分镜表打了地基。

3.4 用一条最简单的指令验证技能是否生效

文件全部建好后，关键是验证技能有没有被正确加载。我会在项目目录里启动 Claude Code，输入这样一条指令：

请用分镜技能，把下面这段内容处理成一份分镜表：夜晚的便利店，两个老同学偶遇，短暂寒暄后各自离开。

如果技能生效，Claude 会显示出角色设定区，然后输出一份完整的分镜表；如果技能没生效，它大概率只会给你一段普通文字描述，或者给你一个随便编的表格。每次修改技能后，我都用这一条固定测试指令做回归，确认改动没有破坏原有功能。

4. 从文本到分镜的核心转换链路：输入理解、场景拆分、镜头编排

技能文件做好只是第一步，它能不能产出高质量分镜，还要看 Claude 在具体任务里的执行逻辑。我拆解一下这条转换链路里的关键环节，这些也是调教技能时最值得投入精力打磨的地方。

4.1 角色梳理：先锁定人物、服装和环境

分镜脚本和文学脚本的最大区别，是它必须落实到“可见的视觉元素”上。文学脚本可以写“他很沮丧”，分镜脚本必须写清楚沮丧如何被看见——是低着头、肩膀下垂、还是把钥匙用力扔在桌上。所以我要求技能先输出角色设定区，等于强制 Claude 进入“视觉化思维”。

实测中，角色区的作用非常明显。当输入里提到“两个老同学”时，如果没有角色设定区，Claude 可能在前三个镜头里把人物描述成模糊的“两个人”，到第四个镜头突然想到该区别对待他们，于是临时补一句“其中一人穿着红色外套”。看起来没问题，但读分镜的人会发现这个人“凭空出现”了。有角色区后，Claude 从一开始就会明确“人物A：白衬衫，瘦高；人物B：卫衣，短发”，后面所有镜头都基于这个基准展开。

4.2 按场拆分：一个“时间+地点+事件”一个场景

Scene 拆分是分镜的核心步骤。我的做法是让技能遵循“一个场景 = 一个连续的时间 + 一个稳定的空间 + 一个完整事件片段”的规则。把用户输入的长段落先切分成多个场景，再在每个场景内部做镜头编排。

举例来说，前面那句“夜晚的便利店，两个老同学偶遇，短暂寒暄后各自离开”，从文字形态看只有一句话，但拆开看，它可以是一个完整场景，也可以是两个场景：便利店内部寒暄是一个场景，两人走出便利店后分道扬镳是另一个场景。分镜技能选择了“一个场景”的处理方式，因为输入信息没有强烈暗示时间或空间发生断裂。

如果用户的剧本包含“第二天早上”，那就明显是新场景了，需要在新场景里重新交代环境。把这些规则写进 SKILL.md 的输入理解段落，Claude 就不容易把跨越多个时空的内容硬塞进一个镜头序列里。

4.3 镜头怎么分配，才不浪费拍出来的素材

场景拆分完成后，真正吃功夫的是镜头编排。我总结了一套给 Claude 用的镜头分配原则：引入镜头要给全景交代环境，对话镜头要用中景和近景交替，情绪高点用特写，动作过程用跟拍或移动镜头，每个场景的第一镜不直接进细节。

这套原则看似简单，但它涉及一个导演思维问题：镜头顺序决定了观众的情绪节奏。如果连续十个镜头全是中景，观众会无聊；如果全是特写，观众会晕。我的技能里专门写了一条规则：在一个场景内，至少包含一个交代环境的景别和一个捕捉情绪的景别。目的就是防止单调。

只要把这类原则写清楚，Claude 的镜头编排水平会立刻从“记流水账”提升到“有节奏感”。我在几次测试里发现，同一段剧本在加了这条规则后，生成的分镜表明显更接近人类导演的第一版草稿。

4.4 一个完整案例：从一段文案到一张可拍摄的分镜表

空讲理论不够直观，我放一个我实测过的完整输出。输入文本是我们之前用的那句话：夜晚的便利店，两个老同学偶遇，短暂寒暄后各自离开。

按我的技能规则，Claude 输出的角色设定区是：

分镜表如下：

这个输出已经可以直接拿去拍摄或者做成动画分镜。最让我满意的是第三到第四镜的衔接——从近景推到特写，情绪是递进关系，不再是机械地重复信息。

5. 踩坑实录：我在真实使用中修过的四个问题

再完美的设计落到真实环境，也一定会碰到问题。下面四条是我在分镜技能实际使用中遇到并修掉的坑，每一条都附上了排查思路和解决方案，希望能帮你省掉我走过的弯路。

5.1 description 范围过宽，导致技能被乱触发

我最早把 description 写得很长，囊括了“视频制作、广告文案、创意策划、内容创作、动画”等大量词汇。结果我在让 Claude 做普通内容创作时，它也时不时加载分镜技能，导致输出里莫名其妙出现“镜号”“景别”这样的表格字段。

排查思路是从“触发链路”反推的。既然技能只在特定请求下才应该被加载，说明问题一定出在语义匹配入口，也就是 description 本身。我在描述里用了太多通用创作词，模型无法准确判断业务边界。

修复方法是收敛描述范围：只保留“分镜脚本、镜头表、故事板、shot list”这几个强相关的触发词，删除所有描述场景的冗余词汇，再在描述里加了一句“不适用于没有镜头拆分需求的任务”。修复后，乱触发的情况基本绝迹。这件事提醒我：description 的价值不在于“做得丰富”，而在于“边界清晰”。

5.2 长剧本下表格字段错位，最后的办法是分块输出

第二个坑出现在处理一分钟以上的长剧本时。剧本变长，镜头数量增多，Claude 在输出完整的单张表格时开始出现截断和字段错位：有的行少写一个转场，有的行把画面内容和音效合并到同一格。当时我以为是模型能力问题，试着在 SKILL.md 里加入“注意表格完整性”等提醒，收效甚微。

后来我换了个思路：让输出分块。给技能加了一条规则，超过十个镜头的分镜脚本，先输出分镜表，再单独输出完整的 JSON 版数据，并且要求每个表格都必须有表头字段。分块之后，表格长度变短，Claude 出错率大幅下降。

这里的关键认知是：模型对长表格的结构化稳定性是有限的。与其寄希望于它自己保持稳定，不如在技能设计上主动降低单次输出长度。JSON 版本还有一个额外好处，它可以直接被脚本程序读取，方便后续做自动化处理。

5.3 角色一致性翻车：多镜头后主角从短发变长发

这是最让我哭笑不得的一个坑：一个包含十一个镜头的分镜表，生成到第七个镜头时，主角从短发变成了长发。原因是 Claude 在生成长表格时，上下文记忆会被新内容冲淡，早期镜头里的角色描述到了后期就模糊了。

我用了两个手段解决。一是在 SKILL.md 里加入“角色锁定”规则，要求所有角色描述必须沿用角色设定区中的原始表述，每次提到人物都带上姓名代号；二是把角色设定区从输出模板的一部分，变成了整个流程的第一步。这两个手段一起用上之后，角色漂移问题基本消失。

这条经验对任何涉及角色一致性的技能都适用，不仅限于分镜。如果你做的是系列故事生成、角色对话设计、甚至连环画脚本，强烈建议在技能里加入类似的锁定机制。

5.4 技能安静地不生效，检查目录命名和文件大小

最后一个坑不是功能逻辑问题，而是最基础的文件问题。有一次我新建了一个技能文件夹，重启后输入测试指令，Claude 完全没有任何反应，像个隐形人。排查了很久，最后发现目录文件夹名叫shot-list-generator，而 SKILL.md 内部的 name 字段写成了shot list generator，中间多了空格，导致识别失败。

另一个隐蔽问题是 SKILL.md 文件太大。当我把大量案例直接塞进主文件时，技能加载效率急剧下降，甚至出现加载超时。后来我强制规定：SKILL.md 主文件控制在 150 行以内，所有扩展内容全部移动到 references 子目录。文件变小之后，加载速度和执行稳定性都恢复了。

建议大家在技能做好之后，养成一个检查习惯：确认目录名与 name 字段一致、frontmatter 结构完整、主文件精简短小、引用路径正确。这四个点全部满足，技能基本就不会静默失效。

6. 进阶玩法：让分镜技能真正成为你的制作搭档

基础版本做好之后，你会发现这个技能已经能稳定干活了。但如果你想把它的价值放大，还有一些进阶玩法值得探索。下面这几个方向我都在实际项目中试过，效果不错。

6.1 风格参数化：一套技能应对电影感、短视频、广告三种需求

同一个分镜技能，能不能同时服务电影感短句和快节奏短视频？我的做法是引入风格参数。在输入阶段，用户可以在文本开头增加一行：“风格：短视频”或“风格：电影感”，技能根据风格参数调整镜头分配逻辑。

具体来说，我在 duration-rules.md 里增加了风格分支：电影感风格优先长镜头和固定机位，镜头时长偏长，转场多用叠化和淡入淡出；短视频风格优先快切，镜头时长短，转场多用硬切和甩镜。这样一套技能内部就有了“子模式”，不需要为每种风格单独做一个技能。

这个思路适用于很多技能。与其不断复制粘贴新手版，不如把差异点抽成参数，让技能根据参数自行切换工作方式。

6.2 面向 AI 视频生成工具的分镜输出

现在很多人做分镜不是为了人工拍摄，而是为了给 AI 视频生成工具提供提示词。这是一个非常实用的扩展方向。我在技能里增加了一个可选的输出模式，分镜表生成完成后，如果用户标注“需要生成提示词”，就把每个镜头单独扩写成一句完整的生成提示词。

生成的提示词格式大致是：主体 + 动作 + 场景 + 景别 + 运镜 + 光线 + 时间。比如分镜表里“人物A抬头看表，特写，推镜头，夜晚便利店”会被改写成“一个戴圆框眼镜的短发男人，在夜晚便利店内抬头看表，特写镜头，缓慢推进，暖黄色灯光，疲惫表情”。

这样做的好处是让同一个技能兼容“人工拍摄”和“AI 生成”两种工作流。本质上，分镜表本身是一种结构化的视觉语言，而 AI 生成提示词需要的恰恰是结构化信息——两者天然相通。

6.3 与故事板、角色设定等其他技能协作

如果你在 Claude Code 里同时装了多个技能，可以尝试让它们协同工作。比如“角色设计技能”先定义主角的外形，“场景构建技能”负责生成环境描述，“分镜脚本技能”再基于这些结果生成镜头表。我在实际流程中，会先让分镜技能输出角色设定区，再把这部分数据给图像生成工具去画角色图，最后回到分镜表完成镜头拆分。

技能之间的数据传递不需要什么特殊机制，只要输出格式足够规范，Claude 会在后续任务中复用之前生成的表格内容。这也说明了为什么统一的字段标准如此重要——不同技能之间想要协作，首先要能在同一个数据格式上对话。

6.4 用 Git 管理你的技能集

最后一个进阶建议可能有点程序员化，但非常值得采纳：把整个技能目录放到 Git 仓库里管理。我在改版技能时经常遇到这种情况——新的描述写法让某个测试用例变好了，却让另一个用例变差了。没有版本管理的话，你根本不知道之前那份“写得还行”的版本长什么样。

我的习惯是每次修改都提交一次，commit message 写清楚改了哪个环节、预期效果是什么。然后用 3 到 5 条固定测试指令做回归。长期看，这比“改完凭感觉”要可靠得多。技能集发展壮大后，Git 管理能帮你轻松回滚到任意历史版本。

做 Claude Skills 这件事，看起来是技术活，本质上是知识管理。分镜脚本技能也只是一个起点——当你理解了怎么把领域知识封装成技能，你可以把同样的方法用在周报生成、教学备课、设计评审、代码重构等任何一个自己熟悉的领域。我在刚做完这个技能时，最意外的收获不是每次省了多少时间，而是它把“写分镜”从一件依赖临时发挥的事情，变成了一条稳定可靠的生产流水线。