9 月，一支音乐视频在技术圈传开了。
AI视频 这两年一直靠文生模型出片。
可这支片子，画面没有一帧来自文生模型。
每一帧都是代码算出来的。
项目名叫 pdoom-video。
作者是一位网名 mexicat 的开发者。
9 月 24 日首次传上代码托管平台。
三天就攒下两千多个收藏，两百多次复刻。
用的还是最宽松的开源许可之一。
它跟眼下主流的做法正好相反。
主流模型先让你丢一段提示词进去，再吐出一段视频。
同一个提示词，两次生成的结果不一样。
画面的细节没法精确控制。
人物也常常前后对不上。
眼下的 AI工具 不少，能把画面管到像素这一级的却没几个。
pdoom-video 不画视频，它写一个会画视频的程序。
画面的位置和颜色，旋转和缩放，全是歌曲时间的一个函数。
时间戳一变，画面就跟着变，同一个时间点永远对应同一帧。
同一份代码跑出来，画面永远一样。浏览器里的预览和导出的成片，能精确到像素级对齐。
整个视频工程还能像代码一样做版本管理，逐行调试。
改一处参数，重新跑一遍就行，不用从头剪。
它不是画视频，是写一个画视频的程序
这句话听着绕，拆开就清楚了。
项目一共四层。
最底下是数据层。它存着歌词的逐词时间戳，还有整首歌的节拍和响度。
往上走是时间轴。它把每个场景锚到某一行歌词上，再吸附到节拍网格。
再往上是场景层。一共十八个独立模块，画风各不相同。
有的像雕刻线条，有的像示波器，有的干脆是一块极简界面。
放到整条链路上看，这更像 AI编程 的一次延伸。
最上面是渲染层。它用 three.js 画图，再叠一层后处理。
光晕、胶片颗粒在这一点点加上来。屏幕上还要再压一层信息。
渲染层里最有工程味的是运动模糊。
传统视频每帧只算一次画面。
镜头一快，就留下幻灯片式的残影。
它的办法是把一帧拆成好几张子帧，分别算完再求平均。它还会自己判断镜头动得多快。
静止画面用十二张子帧。
普通镜头用三十六张。
高速推拉最多能上三百二十四张。
过了阈值就停，不白烧算力。
宁可多等一会儿，也不让画面留下阶梯状的残影。
真正干活的时候，程序会调起一个没有界面的浏览器。它把每一帧算好，再交给编码器压成视频。
声音先被拆开，画面再贴上时间
卡点在这里是一个专门的活。
字幕和画面的变化，不是人手工对齐的。是程序自己算出来的。
第一步，人声分离。
把歌拆成人声和伴奏两条轨。
第二步，强制对齐。
把歌词文字和声音按帧对齐。
第三步，交叉校验。
换一个语音识别模型，把结果再核一遍。
最后一步是节拍分析。
连重拍和鼓点起点都单独跑一遍。
跑完落成两份数据文件。
一份记到每个词。
一份记整首歌的节拍和段落。
时间轴那一层拿这两份数据干活。画面该在哪一句歌词上切换，它自己会算。
歌一换，两份数据重跑一遍，画面就跟着换一套。
一个 AI 编程助手，从分镜写到渲染引擎
这支片子的制作过程，是在一个 AI 编程助手的对话里走完的。
从概念构思开始。
定主题，也定叙事结构和视觉风格。
到分镜设计。
它要写出每个镜头的画面描述。
到音频分析。
它要写出歌词对齐和节拍检测的脚本。
再到渲染核心和十八个场景模块。
最后连渲染和调参，也交给它。
这背后是一种新的分工。
它不再只是帮你补几行代码。
它把一句话的创意，变成能跑能改还能回滚的工程。
不是在替代创作者。
是在把创作者的技术边界往外推。
当然，这套流程也不是谁都能上手。
它要求你会读代码，能改参数。一句话是变不出一支片子的。
画面的风格也偏几何和排版，拍不出真人实景。
代价不便宜，但它开了另一条路
这套做法的代价很直接。
一首 4K 成片，在一台新款笔记本上要渲大约两个半小时。
按一首两分三十六秒的歌算，总帧数超过两万。
平均每帧三十六张子帧，合起来就是七十多万次运算。
它还挑环境。
要装新的运行时，要有无头浏览器，还要有视频编码工具。
苹果电脑上可能还得再配一遍。
作者干脆建议换到 Linux 上跑。
代码渲染这条路，也不是只有它一家在走。
有从组件化框架来的通用方案。
也有开源的、用网页样式定义画面的做法。
它们有个共同点。
都不靠文生模型。
而是让 AI 写代码，把每一帧画出来。
歌和字体也都得自己理顺。
这支片子用的歌不是作者原创的，歌词由一位网友写好，曲子最早交给一家音乐生成服务做出来。
字体挑的是三款免费商用的开源字体，能省掉一笔授权钱。
顺带一提，2026 年不少平台都要求标注 AI 生成内容。这套做法反倒省心，画面本来就不是模型画的。
所以画面生成也在分叉。
一条是生成式，追求逼真和效率。
一条是确定性，追求可控和可复现。
两条不是竞争，是互补。
要快速出创意素材，靠前者。
要精确同步，要批量生产，还要版本管理，靠后者。
图省事就调提示词，想要每条都严格对得上，只能自己写代码。
下次再看到一支这样的片子，可以想想它的每一帧是从哪来的。
