AI自动做视频的第三条路径：不生成画面，而是操作电脑

一个被误解的命题

当人们谈论"AI自动做视频"时，脑海中浮现的往往是两种画面：一种是文生视频，你给一段提示词，模型直接吐出一段动画；另一种是自动剪辑，你丢一堆素材进去，脚本按节奏把它们拼接起来。这两种方式听起来差异很大，但据这位B站UP主的分析，它们其实共用同一个边界——画面要么是生成出来的，要么是从素材库里找来的。

而这支视频展示的第三条路径，画面既不是生成的，也不是找来的，而是「发生」出来的。整支视频从第一帧到最后一帧，都是一台电脑自己录下来的，所有命令由AI自己下达，全程没有任何人碰过鼠标和键盘。

这个区别看似微妙，实则彻底改变了问题的性质。原来的题目是"怎么让AI生成一段视频"，现在的题目变成了"怎么让AI用一台电脑真正干活"。后者听起来更难，但它有一个巨大的好处：它是个工程问题，而不是运气问题。

为什么必须"发生"而非"生成"

设想一个具体场景：你要做一支视频，讲解某个软件怎么用、某段代码怎么跑起来、某个后台流程怎么走通。这类画面，文生视频模型根本无法生成——不是画质不够，而是它压根不知道你那台机器上那个软件窗口里第三行写的是什么字。素材库里也搜不到，因为那玩意儿是你的，全世界只有你那台机器上才有。

文生视频（Text-to-Video）模型如Sora、Runway Gen-3、Kling等，本质上是在像素空间中进行概率性采样——模型基于训练数据中的统计规律来"想象"画面应该是什么样子。这意味着它们擅长生成符合一般性视觉规律的内容（如人在走路、风景在变化），但无法生成特定的、精确的、从未在训练集中出现过的界面内容。一个软件教程中某个按钮的确切位置、某段代码的具体内容、某个API返回的实时数据——这些信息对于生成式模型来说是不可达的，因为它们存在于你的本地环境中，而非模型的参数空间中。"发生式"路径绕过了这个根本限制：它不需要模型"知道"画面长什么样，它只需要让事情真实地发生，然后如实记录。

于是只剩一条路：让它在一台电脑上真的发生一遍，再把这台电脑录下来。

你可能会说，这不就是录屏吗？没错，就是录屏。但区别只有一个——录的时候没有人在。 正是这个"没有人在"，把整个命题的难度和意义都重新定义了。

四层架构拆解

作者将整套系统拆成了四层，逻辑清晰得几乎可以直接复述给旁人听。

第一层：只会下命令的Agent

最上层是一个AI Agent，它只做一件事——把想做的事写成一条命令。在演示中，作者只打了一行字"推进再拉开"，右侧三维房间里的角色就自动完成了从26段预存动作中调取、执行的整个过程。

AI Agent（智能体）是当前AI领域最活跃的研究方向之一。与传统的对话式AI不同，Agent具备感知环境、制定计划、执行动作并根据反馈调整策略的闭环能力。在这套系统中，Agent扮演的角色更接近于一个"导演"——它不直接渲染画面，而是通过下达结构化指令来驱动底层系统完成具体操作。这种设计思路与AutoGPT、OpenAI的Computer Use等项目一脉相承，但关键差异在于：这里的Agent操作的不是一台真实的物理电脑，而是一台精心构造的虚拟桌面，从而获得了确定性和可控性。

第二层：一台不存在于屏幕上的电脑

这是整件事的支点。终端窗口里跑的是真实的绘图程序，浏览器窗口里是带着真实登录态的真浏览器标签，图片窗口里是真实的文件。但这台电脑不存在于任何一块物理屏幕上——它的桌面、窗口、光标全都是网页画出来的，而窗口里装的那些东西却是真的。

为什么要这么设计？作者给出了极其务实的理由：录一台真实电脑太难了。 分辨率、系统缩放、通知弹窗、光标形状，随便哪一样都可能在你录到一半时突然改变，而且你往往事后才发现。而录一个网页是「确定的」——它多宽就是多宽，你让它显示什么它就显示什么，一帧不多一帧不少。

传统的屏幕录制面临大量不可控因素：操作系统的DPI缩放在不同显示器间可能不一致；系统通知可能随时弹出覆盖内容；鼠标光标在不同应用间会改变形状；窗口的实际渲染位置可能因为窗口管理器的动画效果而产生亚像素偏移。这些问题在手动录屏时可以靠人眼识别和重录来解决，但在无人值守的自动化场景中，任何一个随机事件都意味着整条流水线的失败。将桌面环境完全用Web技术重建——用HTML/CSS定义窗口布局，用Canvas或DOM渲染内容——本质上是将一个充满随机性的系统工程问题，转化为一个完全确定的前端渲染问题。这种思路在云桌面（如Apache Guacamole）和在线IDE（如GitHub Codespaces的Web界面）中都有先例。

第三层：一台独立的相机

第三层是一台"相机"，它本身也是一个浏览器，只干一件事——对着第二层那个网页收帧，每秒三十张。关键在于，相机和被拍的那台电脑是两个独立进程。这不是洁癖：如果它们是同一个进程，停止录制的那一下操作会把正在演出的那台电脑一起带走。

在操作系统层面，进程是资源隔离的基本单位。当录制程序和被录制的程序运行在同一个进程中时，它们共享同一个事件循环和生命周期。这意味着：如果你想停止录制，发送的终止信号会同时中断正在执行的"表演"；如果被录制的程序崩溃，录制也会立即中断，已经采集的帧数据可能来不及写入磁盘。双进程架构通过操作系统级别的进程隔离来解决这个问题——两个进程通过进程间通信（IPC）或共享内存来传递帧数据，但各自的生命周期互不干扰。这类似于专业视频制作中"录制设备与表演设备物理分离"的原则。此外，独立的录制进程还可以拥有自己的帧缓冲队列，从而平滑处理被录制进程可能出现的帧率波动。

第四层：输出为MP4

最后一层把收集的帧编码成MP4视频文件。至此，"让AI做一支视频"这个题目，就被彻底转译成了"让AI用一台电脑干活"。

真正的门槛在原理之下

原理本身简单到可以一句话讲完，但作者强调：真正难的从来不是原理，而是让这句话真的成立。

他举了一个当天刚发生的例子：右侧那间三维房间需要用到显卡渲染，而虚拟桌面上的浏览器默认以「无头模式」启动，无头就意味着没有显卡。作者开工第一件事就是去检查——它到底有没有WebGL？答案是没有，两个上下文全是空的。

无头浏览器（Headless Browser）是指没有图形用户界面的浏览器实例，常用于自动化测试和爬虫场景。Puppeteer和Playwright是最常见的无头浏览器控制框架。无头模式的核心问题在于：由于没有真实的显示输出，操作系统通常不会为其分配GPU资源。WebGL（Web Graphics Library）是浏览器中进行3D渲染的标准API，它依赖于GPU加速。当无头浏览器缺少GPU上下文时，所有依赖WebGL的3D场景都会渲染失败，但浏览器本身不会抛出错误——它只是静默地返回空白画布。这就是作者所说"没有任何一层会报错"的技术根源。解决方案通常包括使用虚拟帧缓冲（如Xvfb）、启用GPU进程的headful模式，或通过软件光栅化器（如SwiftShader）来模拟GPU渲染。

最要命的地方在于：这种情况下没有任何一层会报错。 命令是绿的，状态是绿的，只有画面是错的——右侧会是一片漆黑。这类隐蔽的失败，才是这套系统真正的"体积"所在。

作者列举了每一层背后隐藏的复杂度：

• 一个能被AI操作的浏览器，要处理登录态、要处理反爬、要管理标签分组，还要在无头和有头模式之间做权衡取舍；
• 一块虚拟桌面，要计算窗口几何、要计算终端网格、要管理帧率，还得回答一个刁钻的问题——你现在看到的这一帧，到底是不是当下的？
• 一套录制机制，要守住开始录制的门禁，要保证两个进程谁也停不掉谁，还得接住停止录制那一瞬间的编码工作。

这些东西，没有一样写在"自动做视频"这五个字里面。可是少任何一样，这五个字都不成立。

结语：门槛在没人愿意写的地方

这支视频最精彩的洞察，恰恰不在于"AI也会做视频了"这个结论，而在于它揭示了一个普遍规律：许多看似神奇的AI能力，其真正门槛并不在算法原理层面——原理往往可以白送给你——而在原理底下那些没人愿意写、写完也没人夸的工程细节里。

作者最后点明：你从头看到这里的每一帧，包括那张原理图，全都是那块虚拟桌面自己录下来的。他给AI的只有一个题目，剩下的全是它自己做完的。

这正是"发生式"AI创作与"生成式"AI创作的本质分野——前者不是让模型凭空想象，而是给它一台真实可操作的电脑，然后忠实地记录下它工作的全过程。