做科普短视频的人这两年其实都在焦虑同一件事选题不缺缺的是把选题稳定变成成片的能力。尤其数学方向今天这条讲微积分下一条讲概率看着好像都是知识类内容实际拍摄制作、动画设计、文案节奏完全不同很难用一套“通用工作流”去批量复制。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 其他隐藏较深的问题除了上面四条还有一些问题在制作过程中反复出现我也把它们整理成一个排查速查表方便后续快速定位现象可能原因排查手段渲染到一半突然卡死单个 Manim 场景内存占用过大把大场景拆成多个小场景分别渲染配音音色与视频风格不搭TTS 音色选择没有做统一配置固定一个音色并在 Skill 中写入“音色 ID”视频画面模糊渲染分辨率低于 1080p 或码率过低统一输出参数1080p、30fps、高码率片头片尾缺失分镜模板没有写入固定的包装节点在 Skill 流程末尾增加“包装帧”预检概念解释存在数学错误依赖单一 AI 模型判断增加数学内容审核步骤对照参考教材复核这个速查表的思路是把所有出过问题的现象、原因、手段固化下来。以后每次遇到问题先查表再排查而不是重新从零开始摸索。这样积累得越多后续生产就越顺畅。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再谈流量。