文章全程提到“无头浏览器”抓帧，但很多人不清楚它到底是什么。简单说，它就是一个没有界面的浏览器内核——能完整渲染网页、执行JS和CSS，但全程在服务器后台静默运行，肉眼看不到窗口。Puppeteer（Node.js）和Playwright（Python/Node）是两大主流操控库，通过DevTools协议直接控制Chromium。方案里用它们逐帧截图之后再用FFmpeg合视频，本质是把Three.js变“摄像机”，而不是靠AI模型直接输出像素流。这套黑盒抓帧的技术栈，来自网页自动化测试领域（Selenium、Puppeteer），现在被拿来当视频生产链条里的最后一环。

文章用Three.js程序化生成画面的方案，其实是绕开了当前AI视频模型最大的软肋：不懂物理。最新评测显示，最顶级的开源模型生成基础物理事件（球碰撞后反弹、物体坠落）的成功率仅22%。百度飞捷科思等团队用“物理脑”引擎来纠偏，而李飞飞直指现有生成式AI只是“画皮”——它们学的是像素的统计分布，而非物理世界的因果机制。所以文章提倡的“代码控制每一帧”方式，虽显笨拙，却恰好回避了AI视频模型的物理幻觉问题：每帧坐标、运动轨迹都由数学和逻辑驱动，不存在“水往高处流”的崩溃。

当下AI视频生成其实分两条路：一是Sora/Veo这类“端到端扩散模型”——你说一句话，模型直接在潜空间里生成像素序列；二是文章示范的“程序化代理生成”——LLM先生成Three.js代码，再由无头浏览器渲染出帧。前者的拐点在于推理速度和物理一致性（当前模型面对‘杯子落下’都常翻车），后者的天花板则在于代码生成的可靠性和画面风格的程序化极限。竞争中有一个关键变量：如果LLM的coding能力（比如M3.1-Flash）继续scale，程序化路线能支撑的产品宣传片、动态排版这类精确画面对标体验可能更快商用——直到端到端模型真正学会“物理引擎”。

文章公开了一套200+行的“文旅水墨短片元提示词”，声称只需给LLM一个地名就能产出完整代码。这本质是“元提示词”的一种极深实践——不是让AI直接写视频，而是先定义一套严格的生成规则（分镜逻辑、配色纪律、母题选择、镜头配方），再让LLM按这套“生成提示词的提示词”去产生一个可执行的子提示词。然而元提示词是“用确定性约束不确定性”的工程，代价是极其脆弱：一旦模型换了（比如从M3.1换成其他家），或场景不匹配文旅，这串元提示词的性价比可能直线下降。真正值得追问的是：通用元提示词的极限在哪？能否抽象出一套坐标变换图形、物理模拟的元层，让“编程做视频”变成一种稳定的工程范式？