哈喽，大家好！

我是阿星👋🏻

因为我经常外出讲座培训，一下就是一两个小时，每次都觉得不弄成短视频可惜了。

所以我就让codex给我做了个切片软件，能直接把长口播视频按语义拆分并导出。

开发这个软件，codex一共用了大概20分钟，这在以前确实不敢想象。不得不说codex太优秀了，它第一阶段的产出物，对我这种最后一定会让实习生去完善的人来说都足够了。因为我真的不想以任何形式直接或间接接触到那种给几个G粗剪的操作。

它会直接把你上传的视频进行转译，

但是大小最好不超过2G，它就会开始读取了。

你可以直接看到对应片段对应的台词

codex直接就可以进行一些打标帮你判断这段好不好

每个次剪辑都有一个单独的文件夹，里面放着你的原材料和output

然后我们直接通过聚合好的口播台词组，来勾选自己到底导出哪一段，它会提前给我打标，告诉我它推荐的这一段到底是混合主题还是什么。

第一版时的分类依据如下，这些都可以改进，但是却是codex20分钟做出来的，放在两年前大概要折腾很久。

这是它给的初版评分标准，其实也够凑合用了，后来我又让它优化了几版。

  

分数（score）
本地规则给候选片段打的综合分，用来排序。主要看时长是否接近目标区间、结尾是否自然、文本里是否有明确主题信号、是否存在边界风险或混题风险。分数越高，越适合优先展示。
置信度（confidence）
系统对“这条候选是否像一个完整独立主题”的把握程度。是语义完整度评分。开头像接上文、结尾没收住、主题跳转太多，都会降低置信度。
weak_ending
表示候选片段结尾可能没讲完。常见依据是结尾停在“因为、所以、但是、如果、比如”等连接词附近，或没有自然句号/问号/感叹号收尾，听起来像后面还有关键内容。
mixed_topics
表示一条候选里可能混了多个独立主题。常见依据是出现明显转场词，比如“接下来、另外、另一方面、再说、回到”等，或者内容从一个主题跳到另一个主题，例如从“企业 AI 营销”跳到“组织管理/技术信仰”。

时序图如下：

整理来看，任何没学过代码的人都能做

1. codex手搓了一个什么

上传视频 -> 自动转写 -> 生成候选片段 -> 人工勾选 -> 导出 MP4。

更准确是一个agentic workflow（带工具调用、状态流转和人工确认节点的工作流），可以把它改造为agent都可以，不过自己用也没啥必要改。它不替用户盲目决定最终结果，而是先把候选整理出来，让用户确认后再执行导出。

2. 问题不是剪视频，而是选哪一段

口播视频最难的不是 FFmpeg 切一刀，而是判断哪一段是完整主题。

最开始我们看到过两个典型问题:

• 一条候选长到 87 秒，不符合短视频节奏。

• 企业 AI 营销这种独立主题，被和别的主题合并在一起，等于剪辑失败。

所以这个工具没有一上来自动导出，而是先生成候选，让人审核。

  

目标流程:
video.mp4
  -> transcript.srt
  -> candidate-windows.json
  -> 用户勾选 candidate_id
  -> FFmpeg 导出 MP4

3. 先做 ASR 转写，再做语义候选

当前默认用 faster-whisper 做 ASR（自动语音识别），

把视频转成带时间戳的字幕 cue（一小段带 start/end 的转写文本）。

  

python3 scripts/topic_clip_plan.py input.mp4 \
  --target-count 5 \
  --min-duration 45 \
  --max-duration 75 \
  --transcriber faster-whisper \
  --whisper-model base \
  --semantic-provider moonshot \
  --semantic-model kimi-k2.6 \
  --output-dir output/run-001

为什么不默认用 PySceneDetect？

因为这个项目主要处理纯语音视频。

PySceneDetect 看的是画面切换，适合 Vlog、纪录片、混剪素材；

但口播拆条核心是 transcript-first，也就是先看转写文本里的语义边界。

4. 候选数量是参考值，不是硬凑

前端现在把“候选数量”改成了“参考候选数量”。

原因很简单: 视频长度和最短片段时长会限制最终数量。

比如一个 214 秒视频，如果每条最短 45 秒，而且要求候选不重叠，最多也就 4 条左右。强行出 5 条，只能重叠或缩短时长。

  

[
  {
    "id":37,
    "start":0.0,
    "end":59.44,
    "duration":59.44,
    "topic":"AMD AI 体验展"
},
{
    "id":266,
    "start":59.44,
    "end":105.68,
    "duration":46.24,
    "topic":"参展模型视频"
}
]

不做强制限制，

如果填写计算时长高于实际时长，就以实际时长为准

系统也不会为了凑数制造重复候选。

5. 语义复审只处理最终候选

中间候选可以很多，但没必要把几百条都丢给模型。

现在流程会先裁剪出不重叠候选，再做 semantic review（语义复审，判断主题、完整性、混题和边界风险）。

重点看几个字段:

  

{
  "semantic_warnings": ["weak_ending"],
  "is_complete_thought": false,
  "confidence": 0.3,
  "rationale": "needs boundary review"
}

其中:

• weak_start_context: 开头像接着上文说。

• weak_ending: 结尾像没讲完。

• mixed_topics: 一个候选里混了多个独立主题。

主要让用的人去参考，这段内容属于什么性质。

6. 用户勾选后才导出

候选生成后，前端显示标题、主题、理由、风险、时间范围和完整转写文本。

用户勾选要导出的 candidate id，后端只导出这些片段。

  

{
  "candidate_ids": [37, 266]
}

后端会把这个选择传给渲染流程:

  

python3 scripts/topic_clip_plan.py transcript.srt \
  --source-media input.mp4 \
  --render \
  --candidate-ids 37,266 \
  --min-duration 45 \
  --max-duration 75 \
  --output-dir output/run-001

导出使用 FFmpeg render（按时间戳渲染 MP4）:

  

ffmpeg -y -i input.mp4 \
  -ss 0.0 -to 59.44 \
  -c:v libx264 -crf 18 -preset fast \
  -c:a aac -b:a 192k \
  clip_01_candidate_37.mp4

这也是为什么它不像传统脚本一样“自动给你最终 3 条”。

内容剪辑里，最后选择权最好留给人。

7. Key 让用户自己填

Kimi/Moonshot 会消耗模型额度。

key的话就是用的人自己填自己的就行了

流量问题也不打算放到网上现在

自己慢慢用慢慢打磨

8. 网页是主入口，CLI / Skill 是补充

这个产品适合先做网页。

因为它需要上传、看候选、读转写、勾选、导出。强交互场景用网页更自然。

CLI 适合开发者批处理:

  

python3 scripts/topic_clip_plan.py input.mp4 \
  --target-count 10 \
  --min-duration 45 \
  --max-duration 75 \
  --output-dir output/batch-001

Skill 适合接进 Codex 工作流，让 Codex 调用这套能力处理素材。

对内更准确的说法是:这是一个 transcript-first 的视频切片工作流，包含 ASR、candidate window generation、semantic review、human-in-the-loop selection 和 FFmpeg render。

9. 20 分钟做出了什么

这 20 分钟不是做完一个完整商业产品，而是跑通了一个可验证原型:

• 默认 45-75 秒，不再生成 87 秒长片段。

• 候选数量改为参考值，不强行凑数。

• 默认不用 PySceneDetect，纯语音视频优先看语义。

• 前端显示候选、风险和完整转写。

• 用户勾选后才导出。

• Kimi Key 由用户自己填写，避免消耗我们的额度。

最终这个工具的价值不是“自动剪完”。

它的价值是把我出去培训和讲座的视频都剪辑一下。

AI 负责整理候选，人负责最终判断，工具负责稳定导出。

有了codex编程是不是很简单？

人人都可以用codex开发出自己的剪辑agent

今天就分享到这里，

Ok，我是阿星，

更多AI应用

我们下期再见！👋🏻