一门三小时课程，切章摘要从六小时压到八分钟——视频课程的AI章节切分与字幕摘要实践
业务痛点：知识付费团队最耗人力的“隐形工序”
做视频课程业务的朋友都知道，一门课从“录完”到“上架”之间，横着一段极其枯燥的工序：
- 章节切分：讲师一镜到底录了三小时，运营需要反复拖动进度条，找出“这里开始讲环境配置”“这里开始讲第一个案例”，手动打点切章。
- 章节命名与摘要：切完章节后，还要给每章起标题、写简介，方便学员跳转和SEO收录。
- 字幕摘要：全文字幕动辄四五万字，需要压缩成课程亮点、目录页文案、试看章节摘要。
以一门3小时、约4万字字幕的课程为例，一个熟练运营切章加写摘要，实测需要5-6小时。如果一个知识付费小团队每月上架10门课，这就是每月50-60小时的重复劳动——差不多是一个人一周半的全部工时。更糟的是人工切章的颗粒度不稳定：不同运营切出来的章节数从8章到20章不等，用户体验割裂。
我们要解决的目标很明确：把单门课的处理时间从6小时压到10分钟以内，且切分颗粒度统一。
架构设计：三段式流水线
整体架构分三层，独立开发者两三天就能搭完：
[视频文件]
│
▼
① ASR层：视频 → 音频提取 → Whisper类模型转写 → 带时间戳的SRT字幕
│
▼
② 切分层：字幕按时序分块喂给LLM → 输出章节边界时间点 + 章节标题
│
▼
③ 摘要层：按章节切分文本 → LLM生成每章摘要 → 汇总课程亮点
│
▼
[结构化JSON：章节列表 + 时间戳 + 标题 + 摘要]几个关键设计决策：
ASR用开源模型，摘要用API模型。 转写是重计算但模式固定的任务，本地跑Whisper或用便宜的转写服务即可；而章节判断和摘要需要语言理解能力，走LLM API更划算。不要全流程都用大模型——那会把成本抬高好几倍。
切分层用滑动窗口而非一次全喂。 4万字字幕超过多数模型上下文。做法是每次送入约15分钟的字幕片段，让模型输出该片段内的章节边界，窗口之间保留2分钟重叠避免漏切。
统一走AI API网关，而不是直连各家模型。 这是本方案维护成本最低的关键一环，下面细说。
关键实现步骤与代码
核心的章节切分提示词与调用逻辑如下（Python示意）：
CHAPTER_PROMPT = """你是一位课程编辑。以下是带时间戳的字幕片段。
请判断片段内的话题切换点，输出JSON数组，每项包含：
- start: 章节开始时间（秒）
- title: 8-14字的章节标题
要求：只有话题真正切换时才切章，目标章节时长5-15分钟。
字幕片段：
{transcript}
"""
def split_chapters(srt_blocks, llm_client):
results = []
for window in sliding_window(srt_blocks, size=15*60, overlap=120):
resp = llm_client.chat(
model="gpt-4o-mini",
messages=[{"role": "user",
"content": CHAPTER_PROMPT.format(
transcript=format_srt(window))}],
response_format={"type": "json_object"}
)
results += json.loads(resp)["chapters"]
return dedupe_and_merge(results)落地步骤清单：
- 用
ffmpeg抽取音频，调用Whisper得到带时间戳的SRT字幕（约等于视频时长的0.3倍耗时）。 - 滑动窗口调LLM做章节切分，窗口间结果去重合并。
- 按章节切文本，逐章生成50-80字摘要。
- 额外调用一次生成“课程亮点”（3-5条）和目录页文案。
- 人工只做最后校对：抽查章节边界是否合理，平均15分钟内完成。
- 结果JSON写入CMS，自动生成课程目录页。
效率对比：单门3小时课程，原流程5-6小时 → 现在约8分钟机器处理 + 15分钟人工校对，压缩超过90%。 按每月10门课算，一年节省约600小时人力。
为什么统一AI API网关能降低维护成本
这个方案要调用至少两类模型（ASR可以网关化，LLM至少要一个主力+一个备用），独立开发者最怕的是：
- 多供应商SDK各自维护：OpenAI、Anthropic、DeepSeek各一套SDK、各一套鉴权和错误处理逻辑，版本升级经常互相冲突。
- 模型随时会换：今天用A模型的性价比最好，三个月后可能换成B模型。如果代码里写死了供应商，每次换型都要改代码、重测。
- Key管理散乱：不同服务的Key放在不同环境变量里，轮换、审计都很麻烦。
统一走一个OpenAI兼容的API网关后，代码里只有一个endpoint和一套SDK。换模型只改模型名参数，供应商故障时切换备用线路不用改代码，Key集中在网关侧管理。对于一个人维护多条AI流水线的独立开发者来说，这省下的不是一次性的开发量，而是每次模型迭代时反复出现的那半天改造工时——一年下来轻松省出几个工作日。
一些实测经验
- 切分提示词里一定要写明目标章节时长，否则模型会切得过碎（我们最初版本平均每门课切出20+章）。
- 语气词密集的口播内容，建议先做一轮字幕清洗再喂模型，token消耗能降三成。
- 摘要任务用轻量模型足够；只有章节标题这种需要“既准又有传播感”的输出，才值得用更强的模型。
如果你也在准备给视频内容加AI处理流水线，可以从统一接入层开始搭：在 https://api.thistoken.ai/register 注册后即可用一套OpenAI兼容接口调用多家模型，先把流水线跑通，再慢慢优化提示词和成本结构。
---
想直接跑通示例？访问 https://api.thistoken.ai/register 注册 ThisToken.AI，获取 API Key 后即可开始。