企业官网建设流程全解析

做科普短视频的人，这两年其实都在焦虑同一件事：选题不缺，缺的是把选题稳定变成成片的能力。尤其数学方向，今天这条讲微积分，下一条讲概率，看着好像都是知识类内容，实际拍摄制作、动画设计、文案节奏完全不同，很难用一套“通用工作流”去批量复制。2026年这个趋势会更明显：观众对“模板化口播+贴图”已经免疫了，真正的数学内容需求是那些能看懂图形、看懂动态推导、能跟着思考的深度可视化。

我最近一直在折腾一个叫 math-concept-film 的 Skill，用它把数学概念批量制作成科普短视频。这个 Skill 不是某个现成软件的滤镜，它是一套跑在 Agent 体系里的“技能脚本”：从选题、数学推导审核、脚本撰写、分镜生成，到动画参数、字幕样式、配音节奏，全部交给同一套标准化流程去处理。如果你也在做知识类短视频，或者想理解最近很热的 Skill 机制到底能干什么，这篇把我从零搭建到跑通第一条成片的完整过程拆给你看。

1. 为什么是“数学概念短视频”，而不是其他科普内容

1.1 数学概念的天然视频化优势

做内容的人都知道，最容易出爆款的知识类型往往是“看得见的变化”。化学实验有颜色变化，物理实验有运动变化，数学呢？数学很多概念抽象到连文字都难讲清楚。但换个角度想，抽象恰恰意味着可视化空间最大。

以导数为例。文字讲“变化率”很干瘪，但如果用一条连续曲线，再在某个点上放大，逐帧展示切线斜率逐渐逼近极限值，观众一眼就能理解“为什么导数是瞬时变化率”。这种事只有视频能干，而且是动态视频才能干得漂亮。三角函数、极限、曲率、傅立叶变换、概率分布，几乎每一个核心概念都能用图形运动直观表达，这是数学内容在短视频平台上的天然胜场。

数学概念短视频还有一个其他科普不容易复制的特点：它的“画面脚本”具有强确定性。讲历史故事还需要考据素材、找图片，讲数学概念只要把坐标系、函数、几何变换做出来，内容本身就成立了。这意味着它可以被标准化、模板化，非常适合交给 Agent 和 Skill 半自动生产。

1.2 2026年的内容形态变化

2026年做视频，面对的早已不是“能不能用AI生成画面”的问题，而是“如何让AI批量、稳定、风格统一地产出内容”。工具门槛在降低，但内容供给的工业化能力反而成了分水岭。

我观察到一个明确信号：纯靠人工拆解选题、写稿、画分镜的账号，周更两三期已经到极限；而把生产流程拆成“标准化技能”的创作者，有机会把更新频率提升到日更甚至更高。原因很简单，当你把“编导思维”沉淀成 Skill 文件之后，AI 输出的不只是单条内容，而是一整套符合你风格的中间产物，你只需要审核和调整，不需要从零开始。

在数学科普这个细分赛道，2026年会有更多团队入场，但真正稀缺的不是会讲数学的人，而是能把数学内容产品化的人。一个充分设计过的 math-concept-film Skill，就是产品化的核心。

1.3 math-concept-film 要解决的真实痛点

我最早尝试做数学短视频时，遇到三个具体问题，这也是我想做这个 Skill 的最初动机：

第一，数学动画的制作成本太高。直接手写 Manim 代码，一条三分钟的动画要花三四个小时，写完还要改坐标、调颜色，效率非常低。

第二，文案与画面经常脱节。做剪辑的人可能不懂数学，懂数学的人可能不懂视频。旁白讲到“极限逼近”的时候，画面往往还在展示函数的全局图像，信息错位非常严重。

第三，风格无法延续。今天做的片子是蓝色科技风，明天换了一版提示词就变成暖色卡通风，观众一眼看出不是同一系列，账号整体调性稀碎。

这三个问题的共性是：能力不稀缺，稀缺的是流程。math-concept-film Skill 就是把数学审核能力、视频编导能力、动画制作能力封装成一个可重复调用的工具，让人人都有机会做出“团队级”成片。

2. Skill 到底是什么：一次说清 Agent 技能机制

2.1 从“回答问题”到“完成项目”：Skill 的定位转变

在接触 Skill 之前，我理解中的 AI 就是“你问它答”。但从今年开始，AI 产品的主流叙事已经变了：不再强调对话能力，而是强调“完成任务的能力”。 Agent 是任务执行者，Skill 则是 Agent 手里的“岗位说明书”。

你可以把 Skill 理解成一本极其详细的工作手册。手册里会写清楚：这个岗位负责什么、上游谁来提供输入、下游产出交给谁、遇到特殊情况怎么处理、质量标准是什么、需要调用哪些工具。Agent 接到任务之后，不是自由发挥，而是按照手册执行。

math-concept-film 这个 Skill 的定位就是“数学科普视频编导与制作专员”。你给它一个数学概念，比如“贝叶斯定理”，它会按照既定流程输出视频脚本、分镜设计、Manim动画结构、旁白文本甚至字幕样式。这套流程一旦被验证过，后续每个新概念都会自动套用，不会今天一个风格，明天另一个风格。

2.2 Skill 与 Agent、通用提示词的区别

很多人分不清 Skill、Agent 和普通 Prompt 之间的边界，我用一个生活化的类比解释。

普通 Prompt 相当于你在网上发了一个“求教帖”，写了一堆要求，对方怎么理解、怎么执行，全凭运气。Agent 相当于你雇了一个项目经理，它能把大任务拆成子任务、按顺序推进、最终给你交付成果。Skill 则是“萨姆干活的通用流程已经验证过了，以后同样的事直接照做”。

比如你让普通 Prompt 写一条“一元二次函数介绍”的视频脚本，它可能生成很漂亮的文字，但具体到每个时间点该出现什么画面、动画元素坐标怎么排、旁白与字幕的节奏怎么对齐，它给不了。Agent 可以调用工具去执行，但如果缺少 Skill，它也不知道执行的标准是什么，容易跑偏。Skill 则把标准固化下来，Agent 只需要按标准执行。

我之所以强调 Skill 而不是单纯“提示词工程”，原因在于可复用性。一个写好的 Skill 文件可以被多个 Agent 共用，也可以在不同项目中反复迭代。它是资产，而提示词只是一次性的输入。

2.3 为什么用专属 Skill 而不是通用工作流

通用工作流当然能做视频，但做不了“特定风格、特定格式、特定质量控制”的视频。数学科普视频有一个特殊要求：数学表达必须准确，视频节奏必须适合短视频平台的注意力曲线。

通用工作流往往会在两个地方翻车。一是在数学准确性上，AI 写文案时可能会把“对数函数的定义域”写错，或者把“中值定理的条件”漏掉一条；二是在格式稳定性上，生成的脚本表格有时候有时间轴，有时候没有，导致后续制作环节没法复用。

专属 Skill 可以在设计时就把这些要求写死。比如我在 math-concept-film 的 Skill 定义里，明确要求所有动画脚本必须输出“时间码、画面内容、数学公式、旁白文本、字幕文本”五个字段，缺一不可。这就确保了后续步骤无论谁来执行，输入格式都是统一的。

更进一步，专属 Skill 可以做质量校验。每次生产完动画，Skill 都会执行一轮“数学语义检查”，把脚本中对公式的描述和标准教材定义做比对。这个能力如果放在通用工作流里，几乎不可能实现。

3. math-concept-film Skill 的设计与制作

3.1 角色设定：给模型一个“视频编导”人格

我搭建 math-concept-film 时，第一步不是写流程，而是给这个 Skill 定角色。角色决定了 AI 所有后续输出的语言风格和判断标准。

这个 Skill 的角色我拆成了三层，每一层负责不同的专业判断。第一层是“数学内容顾问”，职责是审核概念的准确性，确保不出现定义偏差；第二层是“科普编导”，职责是把数学概念转化成大众能理解的故事线，控制节奏和趣味性；第三层是“视觉设计师”，职责是把故事线转化成具体的动画画面，告诉渲染引擎该画什么、怎么动。

三层角色不是三个不同的 AI，而是同一个 Skill 在不同阶段的“分身”。好处是输出的逻辑能被拉通：数学顾问确定的公式，编导在写旁白时不会歪曲，视觉设计师在做分镜时也会严格对齐。如果只给 AI 一个“帮我做数学视频”的角色，它写出来的东西经常会前后矛盾，数学是数学，文案是文案，两不沾边。

实际配置时，我会在 Skill 描述文件里明确写出这三层角色，并且规定每个角色在流程中的输出物。这个看起来很小的动作，直接决定后续内容的专业度。

3.2 核心流程定义：五步生产管线

技能的核心价值在于流程。我不希望 AI 一次性生成一个完整视频，而是希望它像工厂一样，分步骤产出中间品，让我在每一步都能干预和校准。

目前我在 math-concept-film 里固化的是五步管线：

选取概念：输入一个数学概念，Skill 先检索它的定义、典型应用、常见误区，确定视频要传达的核心信息。这一步的价值是防止跑题。

脚本生成：把核心信息转化为旁白脚本，按照注意力曲线的节奏安排开头、冲突、解释、总结。数学类的开头尤其重要，我会要求 5 秒内必须出现一个具体的“反常识”或“可感知问题”。

分镜设计：把脚本拆成 8 到 15 个镜头，每个镜头对应一个时间码、一组画面元素、一个动效说明。分镜表是后期动画制作的核心依据，没有分镜表直接写 Manim，基本等于盲人摸象。

动画描述：将每个镜头的画面元素转成 Manim 场景逻辑，明确图形类型、参数范围、动画动作、颜色配置。这一步我会让 Skill 输出伪代码或 JSON 结构，后期经过脚本转换直接生成可执行的实现代码。

输出成片：将动画视频、旁白音频、字幕文件、封面文案统一打包，形成一条可以发布的短视频。如果使用剪映等工具，输出物则是可以直接导入的工程文件和字幕文件。

这五步设计完成后，实际制作中我大部分时间花在“验收”——AI 负责生产中间品，我负责检查每一步是否达标。这样做的好处非常明显：如果视频中段出问题，不需要整个重新生成，只需要回到对应步骤修参数。

3.3 模板与参数标准化：保证批量产出

批量生产最怕的就是“每一条都不一样”。要让 20 条视频看起来像一个系列，模板必须严格。

我在 Skill 里内置了三套模板：文案模板、分镜模板、视觉风格模板。文案模板规定旁白的句式结构和单句长度，比如要求“单句不超过 18 个字，每 5 到 8 句设置一个小钩子”；分镜模板规定每个镜头时长分布在 6 到 12 秒之间，开头三个镜头必须完成“引入问题、展示现象、提出疑问”的任务；视觉风格模板则定义主色、辅助色、字体字号、图表样式和动画动效风格。

参数标准化是重头戏。我为了让成片时长可控，做了大量统计，发现旁白语速大约在每分钟 240 字时，既清晰又不会让观众觉得拖沓。由此反推，90 秒的视频旁白字数应在 360 字左右，分镜镜头数在 8 到 12 个之间。这些数字不是拍脑袋定的，而是先人工做了 10 期视频，统计出观众完播率最高的节奏，再反过来固化成 Skill 里的参数。

这里有一个很多人忽略的设计细节：参数不能写死成“硬编码”，要在 Skill 配置里允许单次覆盖。比如说整体时长默认 90 秒，但某个特别复杂的定理，比如中心极限定理，需要 150 秒，制作人可以在调用 Skill 时传入“本条时长 150 秒”，系统自动重新分配分镜数量和旁白字数。标准化的目的不是限制灵活性，而是在灵活和稳定之间找平衡。

3.4 数学符号与动态可视化设计规则

数学视频最大的处理难点，是符号语言与视觉语言的转化。函数、极限、微积分等符号无法直接展示，必须有对应的动态图形逻辑。

我在 math-concept-film 里给视觉设计师角色定义了一套“数学可视化规则表”。比如导数必须展示为曲线与切线的动态变化，定积分必须展示为面积区域随区间移动而变化，傅立叶级数必须展示为多个正弦波的叠加过程。每个数学概念绑定一个或多个“标准可视化方案”，Skill 在生成分镜时会优先匹配方案，而不是现场瞎编视觉。

这套规则表的来源是我对国内外优秀数学可视化视频做的系统拆解。我认为质量最高的不是那种花哨特效堆砌的片子，而是元素少、运动方向明确、数学语义准确的片子。所以视觉风格模板里我刻意做了“减法”：背景使用深色纯色，坐标轴使用浅灰细线，函数曲线使用统一的荧光色系，标注文字只在关键点出现。这样观众视线能聚焦在数学本身，而不是被无关元素干扰。

另外，动态可视化还有一个纪律：运动必须服务于解释。旁白说“当 x 趋近于 2 时”，画面上的 x 轴标记必须同步高亮运动到 2 的位置；旁白说“面积趋近于 0”，画面的填充区域必须同步缩小到消失。如果画面运动和旁白语义脱节，视频做得再华丽，观众的数学理解都不会发生。

4. 从 Skill 配置到第一条成片：实测记录

4.1 先写一个最小可用版本

我的习惯是先做一个能跑的“最小版本”，再逐步完善，不要一上来就追求完美。第一个版本的 math-concept-film 只包含三样东西：角色描述文件、五步流程提示词、一个简单的 CSS 风格参考值。

工具选择上，我用的是目前主流的 Agent 框架配合本地自定义 Skill 文件。Skill 本质上是一个包含结构化配置和提示词的目录，运行时会作为附加上下文加载。具体实现方式不同框架有差异，但核心逻辑一致：Skill 文件告诉 Agent“你是谁、流程是什么、知识库在哪里、输出格式是什么”。

第一次测试我选了“勾股定理”这个最简单的内容。原因很朴素：越简单的概念，越能暴露流程设计问题。测试结果让我发现了一个关键问题——AI 在分镜阶段总是试图用“画面批量展示”代替“逐步推导”。它会把三个正方形一次性画出来，然后给出结论“多了啊”，这完全违反了数学推导的递进逻辑。

这就是为什么 Skill 里需要有角色约束的原因。我后来在分镜模板中强制加入“推导步骤提示”，每一步只允许展示一个新增元素，其他元素保持不动。调整后，AI 的分镜表现立刻就对了。最小版本的测试意义就在于此：用低成本内容发现结构性缺陷，而不是憋了两周做出一个复杂片子才发现流程走不通。

4.2 用三明治式测试校准输出

所谓“三明治式测试”，是我自己总结的一套调参方法：找出最基础的概念（面包底）和最难的概念（面包顶），分别测试 Skill 的稳定性和上限，再测试中间难度的概念，看输出质量是否连贯。

面包底我还是选的勾股定理和“圆的面积公式”，面包顶选了“中心极限定理”和“傅立叶变换”。用这三个难度差异极大的概念去跑同一套 Skill，如果底部稳定、顶部不出大错、中间能保持一致性，说明这个 Skill 基本合格。

这一轮测试帮我暴露出第二个问题：Skill 对数学背景知识默认假设过高。在讲“无界变量”的时候，分镜里直接出现“反比例函数图像无限趋近坐标轴”的描述，但如果观众没学过反比例函数，开头的认知负担就已经过重了。

为此，我在 Skill 里增加了一项“概念依赖检测”步骤：在生成正片之前，先枚举这个概念的“前序知识”，如果前序知识可能超出目标观众水平，则在脚本中加入一个 10 秒左右的“前置铺垫镜头”。这样每次输出都会多一步思考，但成片质量提升非常明显。

4.3 素材与渲染：Manim + 剪辑工具链

分镜设计完成后，下一步就是渲染动画。我最常用的数学动画引擎是 Manim，它有两大优势：一是纯代码定义动画，可批量生成；二是动画逻辑与数学语义天然对应，比如“曲线沿参数方程移动”这类描述可以直接翻译成 API 调用。

arh-concept-film 的 Skill 本身不直接执行 Manim 代码，但它会生成一个标准化的 JSON 中间文件，字段包括场景名、对象类型、坐标范围、动画动作、颜色、时间长度。我这边再写一个 Python 解析脚本，把 JSON 转换成 Manim 场景代码，然后逐条渲染。这样做的原因是把“内容生产”和“代码实现”解耦，即使以后换了渲染引擎，解析脚本只需重写，Skill 本身不用大改。

一个典型的 JSON 片段长这样：

{ "scene": "limit_intro", "objects": [ {"type": "axes", "x_range": [0, 5], "y_range": [0, 3], "color": "#666666"}, {"type": "curve", "expression": "1/(x-1)+1", "color": "#00BFFF", "width": 4} ], "actions": [ {"time": 0.0, "type": "write", "target": "axes"}, {"time": 1.5, "type": "create", "target": "curve", "duration": 2.0}, {"time": 4.0, "type": "highlight_point", "target": {"x": 2.0, "y": 2.0}, "duration": 2.5} ] }

解析脚本读取这段 JSON 后，会生成对应的 Manim 代码。脚本不算复杂，但有几个细节需要注意：时间轴偏移量必须和旁白文本逐字对齐；高亮动画缓动函数选择上，推荐用 smooth 而不是 linear，因为数学动画里“引导注意”需要更顺滑的移动，而不是机械的匀速。渲染出口是 1080p、30 帧的 mp4 文件，这个参数在短视频平台兼容性最好。

配音方面，我会先让 Skill 生成旁白文本，再使用 TTS 合成音频。这里有一个关键步骤：TTS 生成的音频时长无法完全精确预测，所以动画的时间轴必须与音频实际时长对齐，而不是按估算文字数对齐。我的处理方式是先合成音频，根据音频实际时长缩放动画分段的时间码，再渲染视频。先出声音，再动画对齐，顺序不能反，这算是我踩坑后总结出来的最可靠的方法。

4.4 动画批量生成：串行与并发控制

跑通单条成片之后，真正的效率提升来自批量生成。批量生成时我遇到最多的问题不是渲染不了，而是机器资源分配。

Manim 渲染 30 帧的视频，每秒钟画面需要 GPU 连续计算，如果你同时跑四个场景，很容易出现显存溢出或卡死。我采用的策略是“先串行后并行”：先串行渲染所有视频的纯音频和动画分镜清单，确认每个分镜参数无误；然后按镜头维度做并发，但不超过两个渲染进程同时执行。

这背后有一个更底层的问题：批量生产时，每个概念对应的场景数量和渲染时间严重不均衡。简单的“圆的面积”可能只需要 6 个场景，每个 10 秒；复杂的“傅立叶级数”可能需要 20 个场景，渲染时间是前者的五倍。如果只按概念分组执行，短任务的设备会大量空闲。

我现在的做法是先把所有概念的分镜全部拆散，放进同一个任务池，再按场景级别的优先级和依赖关系调度。这样做的好处是渲染队列始终满负荷，坏处是项目状态管理变得复杂。为了应对，我在项目的根目录维护了一个“任务清单”文件，每条任务列明所属视频、场景号、渲染状态、输出路径。生成过程如果崩溃，重启后直接扫描任务清单，跳过已完成项，接着跑未完成项。

这个过程听起来琐碎，但它才是把“个人小技巧”变成“可复制方案”的关键。没有任务状态管理，Skill 再聪明，生成十条视频也只是八个成功的动画碎片加两个残次品。

5. 制作过程中踩过的坑与排查实录

5.1 字幕和旁白对不上：不要在文案阶段定时间码

这个问题我遇到过太多次。最早我希望 Skill 在写分镜时直接给出“第几秒第几秒开始说什么”，但实际验证发现，AI 预估的时间和真实 TTS 渲染的音频时长误差经常超过 10%。旁白念慢了，字幕提前出现，画面也提前切换，整条视频的节奏感完全被破坏。

解决思路分三个层次。第一，旁白文本按语义拆成句级单元，每句独立导出时间戳；第二，动画分镜的时间轴不引用“预估时间”，而是引用“句子 ID”；第三，渲染完成后，用语音识别工具为成品音频重新生成带时间戳的字幕，最后再压制进视频。

现在我的成片流程里，“字幕时间戳永远来自音频识别结果”已经成为铁律。任何 AI 预估的时间码只用来排顺序，不直接用于压制字幕。这样改完之后，字幕延迟问题基本消失，而且因为每句字幕的显示时长和实际语音长度严格匹配，观看体验显得干净利落。

5.2 数学公式渲染成乱码或缺字符

数学公式涉及大量 Unicode 特殊字符，字体缺失时会出现显示异常，尤其是希腊字母和求和符号。我的排查经验是从下往上逐层定位：先检查生成的字幕文件里字符是否正常，再检查字体文件是否支持，最后检查渲染引擎或视频平台的显示兼容性。

字幕文件里出现乱码通常是因为格式没有正确声明“UTF-8”。我在所有字幕生成脚本里统一固定编码，输出时强制指定 UTF-8，并且追加一个 BOM 头，这样在不同播放器和平台上最不容易出现识别问题。

如果字符正常但显示成空心方块，问题就出在字体上。数学符号常用的字体链路是“Noto Sans 加 Noto Sans Math”，但具体到每个平台还要测试。我在 video 项目里设置了一个字体测试场景，专门渲染“α、∑、∫、√、∞”这些高频字符，确认显示无误后再开始批量生产。没有这个测试场景，前期再顺利也白搭，最后压制时全变方块，悔都来不及。

5.3 时长失控：从设计 90 秒变成实际 4 分钟

按我之前的经验，短视频的完播率和时长强相关，数学内容超过 3 分钟，完播率下降非常明显。所以我给 Skill 设置了默认 90 秒的目标时长，但第一次批量测试时，有一些成片跑到了 4 分钟。

原因有两个：一是分镜数量没有守住。虽然默认设置了 8 到 12 个镜头，但有的镜头自己扩展出子镜头，比如“展示图像逼近”这一个镜头，AI 给它拆成了 5 个子动作，每个子动作都有独立的旁白和时长。二是旁白字数没有严格执行。单句如果你允许它超过 18 字，写顺了它就会越写越长，一句话讲三个知识点，导致节奏拖沓。

治理办法是在 Skill 描述里加入“硬约束”字段。比如“全片分镜数最多 12 个”“单个镜头旁白不得超过 40 个字”“如果脚本超长，优先压缩解释性铺陈，而不是压缩核心推导”。同时，在流程中增加了一个校验器：生成完分镜表后，自动计算预估时长，如果超长，直接打回脚本阶段重写。这个“回退机制”极大地解放了我的人工审核量，以前靠眼睛盯时长，现在程序就能拦截一大部分问题内容。

5.4 风格漂移：同系列视频看着不像同一套

风格漂移是批量生产最容易出现但最不容易被发现的坑。单独看每一条视频都很精致，但放在同一个账号里，会发现色彩、字号、动画节奏全都不一样。这会让账号的品牌感完全消失。

我的排查思路是：风格问题不是靠“审美的感觉”去解决，而是靠“视觉参数的统一”。我把所有能影响视觉的元素列成一个检查清单：背景色、主函数曲线颜色、辅助元素颜色、坐标轴线性与颜色、标注字体与字号、运动缓动类型、镜头切换方式。每一个元素都在 Skill 的视觉模板中定义出唯一取值，并且要求所有下游渲染引用模板，不得自行定义颜色值。

比如系列视频的主打色是青色，模板里就写“primary_color: #00BFFF”，任何借用 Ad hoc 颜色写的 Manim 代码都会在审核阶段被打回。这还不够，我还会在每次批量渲染后随机抽三帧，跟基准视频截图做肉眼对比，看色调是否协调。实践证明，视觉参数统一这件事，靠人盯必然出纰漏，靠模板加自动拦截才能形成体系。

5.5 其他隐藏较深的问题

除了上面四条，还有一些问题在制作过程中反复出现，我也把它们整理成一个排查速查表，方便后续快速定位：

这个速查表的思路是：把所有出过问题的现象、原因、手段固化下来。以后每次遇到问题，先查表，再排查，而不是重新从零开始摸索。这样积累得越多，后续生产就越顺畅。

6. Skill 的版本管理与团队协作扩展

6.1 用本地仓库管理 Skill 文件

Skill 文件本质上也是代码，既然是代码，就应该用版本管理。我目前用 Git 做管理，每个 Skill 占一个目录，包含描述文件、模板文件、示例输出、变更记录。这样做的最直观好处是，每次修改都有历史记录，改坏了还能回滚。

比如我想把默认旁白语速从“每分钟 220 字”调成“每分钟 240 字”，只需要修改模板文件里的一个数字，提交一条变更记录，然后做一轮批量测试验证效果。如果测试结果不满意，随时可以 revert 到之前的版本。没有版本管理前，我往往会因为“不敢改”而放弃优化，现在这个问题被彻底解决了。

每次版本迭代，我还会在示例输出目录里保留一个“基准成片”。所有修改是否生效、风格是否变化，都直接和基准视频对比。这个做法非常适合团队协作，新成员不熟悉历史版本，只要看对比就能理解当前的风格标准。

6.2 多人协作时的职责划分

如果团队扩大，Skill 制作和内容创作最好分成两个角色。内容角色负责选题和审核成片质量，技能角色负责维护 Skill 和流水线脚本。两者没有直接上下游关系，而是互相反馈：内容角色在使用过程中发现问题，以 issue 形式提交给技能角色，技能角色修改 Skill，再返回来交付新版本。

我自己倾向于每人对接不同的具体概念：有人负责微积分线，有人负责概率统计线，有人负责几何线。每条线共享同一套视觉模板和流程，但在脚本撰写时允许保留各自的叙事倾向。Skill 里可以设置“叙事风格”参数，在统一风格之上允许个性化微调，相当于同一个产品线的不同 SKU。

团队协作还有一个容易被忽略的点：配置文件权限。Skill 文件最好设置成只读，内容角色不要直接在 Skill 里改参数，而是通过调用参数传入自己的偏好。这样可以避免一个人无意中修改了模板而影响其他人的生产，也让每次输出都有据可查。

6.3 后续扩展：从单条视频到系列课程

math-concept-film 现在做的是单条科普短视频，但它的架构完全可以扩展到系列课程。系列课程和单条视频的区别在于：系列课程有知识依赖关系，第 3 集的内容可能依赖第 1 集交代的概念。

我在 Skill 里预留了一个“知识图谱”字段，每个概念可以标记它的前序知识、后继知识、同级关系。批量生成系列视频时，Skill 会自动检查当前视频的分镜是否引用了“前序视频中尚未解释的概念”，如果引用了，自动加入提示文案“我们在前面的视频里讲过”，并在结尾预告下一集内容。

从单条视频延伸到整个课程体系，这个 Skill 的价值就不是“做个视频”，而是“搭建一个完整的内容知识库”。产出的不只是一个个孤立的视频文件，而是相互关联、有结构的知识点集合。这种结构化内容，无论对账号增长、粉丝沉淀，还是后续的付费课程转化，都有不可替代的长线价值。

关于这套流程，我最后想说的几句

用了 math-concept-film 做了一段时间数学科普视频，我最深的体会是：真正拉开内容差别的，不是你用了多先进的工具，而是你有没有把做内容的“手感”翻译成可以被规则定义的流程。Skill 机制之所以管用，是因为它逼着你把模糊的创作感觉变成清晰的执行标准。

从现阶段的结果看，这条路径的确定性已经很高了：前期花点时间把 Skill 打磨好，后期每条视频的成本会显著下降，风格一致性也会维持在高水平。而且这个框架不局限在数学，任何有明确概念结构、需要可视化表达的知识类内容，都可以复制这套思路。

如果你也想做类似的事情，建议别一上来就做一个“万能视频生成 Skill”，那不现实。先定一个最小的内容品类，把三四个概念跑通，把最常见的问题都踩一遍，再逐步扩大内容范围。磨刀不误砍柴工，这句话放在 AI 内容生产里，就是先磨 Skill，再谈流量。