top of page

幕后花絮:我们如何在 30 分钟内做出 28 个 YouTube 视频 🎬

作家相片: Marcel Dütscher
Marcel Dütscher
7月2日
讀畢需時 3 分鐘

一个爸爸、一个孩子和一个 AI,是怎么把一大堆原始游戏录像变成两个完整播放列表的——全程没花一个小时在视频剪辑软件上。


我们终于有自己的 YouTube 频道啦,为 Blocks Beyond the Stars 准备了 22 个 Shorts 和 6 个较长的 Let's Play/教程视频。说真的,它们的制作过程值得讲一讲,因为真正的“剪辑”只花了大约半小时。下面就是完整的流程。

第 1 步:Justus 按下录制键 🎮

每个好玩的游戏视频,都从有人真正玩游戏开始——这份工作当然交给了 Justus。他用 OBS Studio 录了好几段游戏过程,边玩边解说。没有台词稿,也没有重拍,就是他一边玩一边讲自己在做什么。这种原汁原味的劲头正是我们想要的——谁需要一个 10 岁的孩子照着提词卡念稿呢?😄

第 2 步:把声音变成数据 📝

原始录像很棒,但 AI 没法(高效地)“观看”几个小时的视频。所以诀窍是让视频变得能读:我把它们上传到 ElevenLabs,让它生成带时间戳的 JSON 文字转录。一下子,每个视频不再是一堆像素,而成了一份可以搜索的文档:谁在什么时候说了什么。

第 3 步:让 Claude 来“看”录像 🤖

接着,所有内容——视频加上带时间戳的转录稿——都放进了一个 Claude Cowork 项目文件夹。提示词大意是:“利用时间戳文件看看这些视频,想想怎样从中剪出好看的 YouTube Shorts 和较长的视频。”


我还给了它我们的品牌视觉规范——品牌颜色、字体之类的——这样标题和叠加画面看起来才像我们的游戏,而不是随便套的模板。

第 4 步:先头脑风暴,再做计划,然后才动手 🗺️

这一点我想划两遍重点,因为这和我们在 AI 辅助编程中学到的是同一课:别让 AI 一上来就乱动手。


我们先一起头脑风暴:哪些时刻适合做 Short,哪些很无聊,什么样的开头能抓住人,哪些内容干脆跳过。然后我让 Claude 在动任何东西之前先写一份详细的计划(和我们修改代码时一模一样)。要交付的成果很明确:

  • 剪好的视频本身——Shorts 和长视频,

  • 压制在画面里的英文和德文字幕(一个双语家庭项目,永远保持双语 🇩🇪🇬🇧),

  • 以及一份Markdown 文件,里面是每个视频都能直接粘贴的 YouTube 简介。

第 5 步:大功告成 ✨

大约30 分钟后:22 个 Shorts 和 6 个长视频全部完成,带双语字幕,每个都有自己的简介,随时可以上传。整个制作中最费时间的部分是 Justus 玩游戏——不过说实话,在他看来这根本不算工作。😎

第 6 步:剧情反转——上传比剪辑还慢 🐢

好笑的地方来了:做出 28 个视频只花了 30 分钟,可把它们传到 YouTube 上却花了 40 分钟。每个视频都得手动上传、写简介、设定发布时间——点击、粘贴、设置发布日期,再重复,一共 28 次。这一步根本没有 API 可用,所以再多的 AI 魔法也帮不上忙。我们做过的最未来感的视频流水线,竟然卡在了复制粘贴上。🙃

想试试的人,我们有话要说

真正的魔法配方不是某一个工具,而是时间戳。一旦你的录像变成了结构化的文字,AI 就能像分析代码一样分析节奏、开头和精彩片段。先计划,再执行。同样的工作方式,换了一种新媒介。而且给上传时的点点点多留些时间,别只算“剪辑”的时间——2026 年真是个奇妙的年代。😄

📺 来看看成果

  • Shorts 播放列表: Shorts

  • Let's Play 和教程: Let's Play & 教程

点赞、订阅,再告诉我们哪个时刻值得做成下一个 Short。🚀

最新文章

查看全部
为什么新版本叫 2026.7.19,而不是 0.9.2 🗓️

今天更新的人,会从 0.9.1 版本一下跳到 2026.7.19。这看起来像是笔误,其实是一个刻意的决定:我们改变了版本号方案,从“语义化”版本改成了基于日期的版本(年.月.序号)。原因如下。 旧方案回答的是没人问的问题。语义化版本(0.9.1、1.2.3 ……)来自软件库的世界。在那里它很棒:第一个数字承诺“不会破坏任何东西”,第二个承诺“只有新增”,第三个承诺“只有修复”。而游戏不对任何人做这

 
 
大扫除:我们终于把 GitHub 的缓存用对了 🧹

在上一篇技术文章里,我们测量了构建和检查流水线到底花了什么:不是钱,而是等待时间和存储空间。那篇文章的结尾是“清理工作已经计划好,但还没完成”。结果比预想的快:从今天中午起,它已经进入主分支了。下面是数字。 先看结果。我们仓库的缓存用量,从 63 个条目共 5.32 GB,降到了 13 个条目共 2.46 GB。以前每个拉取请求都要跑的 C# 安全分析,现在在那里只需要 4 秒,而不是 4 分半,

 
 
每月一千次构建,而且一次都不花钱 ⚙️

先更正一件事。这篇文章的第一版声称,我们的 GitHub 构建分钟数用完了,被迫升级到 Pro 账号。这是错的,而且只要看一眼文档就能弄清楚:对公开仓库来说,GitHub 的构建分钟数是免费的。产物和缓存也一样。我们的仓库从五月底起就是公开的,所以我们从来没有为任何一分钟付过钱,以后也不会。与其悄悄改掉文字,我们宁愿重写一遍,告诉你们测量到底显示了什么。结果比错误的版本有趣得多。 先猜测,后查看。

 
 

留言


這篇文章不開放留言。請連絡網站負責人了解更多。
bottom of page