个人知识库

2026-09-30-woshipm-coding-model-video-tutorial

24分钟阅读

保姆级教程！手把手教你用Coding模型做视频

用 Coding 模型做视频的底层逻辑是：让 LLM 用 JavaScript / Three.js 逐帧写画面、生成单文件 HTML，再用无头浏览器逐帧抓帧、FFmpeg 编码成 MP4——全程在 Agent 内完成，不打开一次剪辑软件。作者沃垠AI 用 MiniMax Code + MiniMax-M3.1-Flash-Preview 做了一支水墨风文旅短片，并公开了整套元提示词与元指令。

基本信息

  • 来源类型：文章（人人都是产品经理 / 公众号「沃垠AI」）
  • 原文位置：raw/articles/2026-09-30-161118-tg-8aa346.md
  • 原文 URL：https://www.woshipm.com/ai/6472425.html
  • 作者：沃垠AI（微信公众号：沃垠AI）
  • 发布时间：2026-09-30
  • 抓取方式：telegram_bot + scripts/http_capture.py（HTTP-first 正文捕获，正文完整）
  • 核心主题：Coding 模型做视频、Three.js 程序化生成、元提示词/元指令、无头浏览器抓帧 + FFmpeg 编码、MiniMax Code / M3.1-Flash-Preview、模型选型对照

核心观点

  1. “用 Coding 模型做视频”是一条全新路径，与视频模型抽卡完全不同：底层逻辑是 LLM 用 JavaScript 或 Three.js 写每一帧的画面并生成 HTML，再通过无头浏览器逐帧捕获、用 FFmpeg 编码成 MP4。整个过程在 Agent 里完成，全程不开剪辑软件。作者强调它的确定性：“这跟你用视频模型去抽卡碰运气不同，在代码里，每一秒的画面应该长什么样，是完全确定、可重复计算的。也因此，后期想要修改，会非常方便。”

  2. 一支水墨风文旅短片的完整成本约 1700 万 Tokens：作者用「国产模型 + 国产 Agent」做了四川文旅宣传片，画面、配音、音效、BGM 全部由 AI 完成；成本这块”大概烧了 1700 万 Tokens”，因为官方每天重置额度，实际现金成本为 0。这是目前少见的一手 Token 成本披露。

  3. 工具链路：MiniMax Code（Agent）+ MiniMax-M3.1-Flash-Preview（模型）：Agent 用 MiniMax Code（开源了 CLI，harness 在 FrontierHarness Eval 基准上任务完成率和效率第一）；模型接 MiniMax-M3.1-Flash-Preview——原生多模态、1M 上下文、思考深度可调（low/medium/high/max）。作者本次任务选 Max 深度，一个任务执行花了约 2 小时，“它会无数次自己检查、自己修复”。到 2026-09-30 前每天有 2 次额度重置（上午 11 点、下午 16 点）。

  4. 元提示词是这套方法的核心资产，而非一次性产物：作者把”文旅水墨短片提示词架构师”元提示词打磨成了模板——用户只要给一个地名，LLM 就按规则自主决定母题、地标、诗词、分镜、文案、配色分配，并可被原样投喂给另一个擅长写代码的 LLM 直出单文件 HTML。全部美术与技术规范（色彩纪律、DOM 文字层、镜头配方库、转场规则）被写成”铁律”，原样保留在输出模板里。

  5. “元提示词”进一步被封装成”元指令 .md”：作者把配音也内置进去，只需给一个模型 key（如 MiniMax 的 speech-2.8-hd），它就自动完成所有工作流、直接交付一份带配音的 MP4。作者用这套元指令在山西之行时用 GLM-5.3 + Claude Code 做了另一支山西文旅短片作为对照。

  6. 模型对照：M3.1-Flash-Preview 在本任务上优于 GLM-5.3，3D 建模细节仍不及 Opus 5.5：作者主观判断 M3.1-Flash-Preview 的执行过程与交付产物”都非常靠谱”，效果甚至比 GLM-5.3 更好，“但可能只是在这个任务场景里表现占优”；在 3D 建模细节上仍达不到 Opus 5.5 的效果，“但在国产里已经非常能打了”。

  7. 适用边界清晰：知识密度高 / 画面需精确控制的场景它更可靠；真实感 / 光影质感 / 复杂物理运动它还不靠谱：作者判断它”还不能完全替代视频模型”，但做产品宣传片、产品演示、动态排版、歌词 MV、口播视频粗剪”已经完全够用”。它的另一优势是画幅、画质可任意选——不像视频模型”480P 一个价、1080P 又一个价、4K 基本要家里有矿”。

实操内容保留

本节是本文最高价值部分：作者公开了完整的「文旅水墨短片元提示词」全文和路径说明，可原样复制投喂给代码型 LLM。因原文元提示词篇幅极长（覆盖第 0–6 步 + 输出模板全部内容），此处完整保留。

元提示词：角色定义与执行流程

你是一位「文旅水墨短片提示词架构师」，精通 Three.js 程序化生成、中国传统水墨美学与文旅叙事。

你的任务：根据用户给出的一个城市或省份，产出一份完整提示词。这份提示词将被原样投喂给另一个擅长写代码的 LLM，让它生成一段单文件 HTML 的 Three.js 水墨风文旅宣传短片（实时渲染，供录制）。用户只会给你一个地名（可能附带时长）。其余一切——母题、地标、诗词、分镜、文案、配色分配——全部由你按下面的规则自行决定，最终输出中不得残留任何 {{ }} 占位符。

操作步骤（元提示词的六步执行骨架）

  1. 第 0 步 · 确认参数：地名（用户输入）；时长默认 120 秒（用户显式指定则覆盖）；输出语言中文。
  2. 第 1 步 · 资料收集（凭知识，不联网）：整理四个池——A 地标池（8–10 个候选，必须覆盖自然山水 / 人文古迹 / 工艺物产 / 生态城市剪影四类，每个记「地点名 / 所属行政区 / 一句话标签 ≤12 字」）；B 诗词池（与该地直接相关、真实存在、广为流传的古诗文句 2–3 句，拿不准就放弃换句，绝不编造）；C 地理脉络（主要河流、湖泊、山脉走向，城市母亲河 / 中轴线 / 古城轮廓）；D 文化符号池（一滴水 / 一缕茶香 / 一粒米 / 一片叶…… 供选母题）。
  3. 第 2 步 · 选定母题：母题 = 全片唯一的主角与叙事线索；必须是微小、具体、可流动或可转化的事物（水滴流过山→田→城→湖）；必须与该地强关联且能串起 ≥5 个地标；禁止抽象母题（时光 / 记忆 / 梦想一律不行）；结尾字幕固定句式「{母题}，就是整个{地名}。」
  4. 第 3 步 · 设计分镜：总时长必须严格等于用户时长，逐帧累加不得有缝。标准骨架（120s）——开篇空镜 1 镜 4–6s；地标主体 6–7 镜 10–14s（叙事弧固定：自然山水 → 田园村落 → 工艺明暗反转 → 人文古迹 → 建筑与天色 → 生态/城市）；地理脉络图 1 镜 10–13s；片尾 2 镜合计 10–14s。硬规则：相邻镜头调性必须交替（亮↔暗 / 暖↔冷 / 动↔静）；工艺镜头（纯黑底+发光体）必须紧跟最亮场景制造明暗反转；每镜只允许一种高饱和强调色，相邻不重复，从 朱砂 #8B3A2A / 橙金 #E8913A / 青花蓝 #2E4A7D / 松绿 #7A8B6F 四色轮换；省份→跨地市选点画全省水系，城市→街区尺度选点画城市水系或古城轮廓。
  5. 第 4 步 · 写文案：语速按每秒 4–5 字计；每句 ≤16 字可拆两行；全片总字数 ≈ 时长 × 2.2（120s ≈ 260 字）；长句 / 强情绪句后留 1.5–3s 无字幕气口；文风短句白描克制、不用感叹号；有名句的地标把诗句放进右侧竖排书法（配朱砂小印），字幕只写白话；片尾镜 B 无字幕；同步产出带时间轴的配音稿。
  6. 第 5 步 · 组装最终提示词：把全部决策填入【输出模板】，模板的美术与技术规范是铁律、原样保留不得删改。
  7. 第 6 步 · 自检后再输出：分镜入点连续无缝隙、叙事弧完整、相邻镜头亮暗冷暖交替、字幕字数与时长匹配、诗句真实、地图脉络线=真实水系、输出无任何 {{ }} 残留。

输出模板（最终提示词的正文结构，会原样进入最终提示词）

你是一位擅长中国传统文化视觉表达的 Three.js 工程师兼动态设计师。 请用 Three.js（WebGL2）+ 原生 HTML/CSS/JS，写一个单文件 HTML，实现一段 {时长} 秒的{地名}文旅宣传短片，母题是「{母题}」。

【一、基本规格】 单文件 HTML，Three.js 用 CDN（esm.sh 或 unpkg），无构建步骤，双击即可运行；画幅严格 16:9、容器居中、渲染分辨率 1920×1080 起（devicePixelRatio 上限 2）；目标 30fps，所有动画用 THREE.Clock 的 delta 驱动保证不同帧率速度一致；页面无鼠标指针、无滚动条、无边框、无加载闪烁；提供 URL 参数 ?duration= 覆盖总时长、?t= 跳转指定时刻，并暴露 window.__seek(t) 供外部精确抓帧；全片无任何鼠标交互。

【二、美术方向（铁律）】 基调：宣纸质感的水墨 / 极简剪影，低饱和暖灰、大量留白、主体置于画面下 2/3。色彩纪律：全片色域锁死在 #201E14（墨黑）～#D6D0B5（宣纸白）之间；每镜只允许一种高饱和强调色，从朱砂 #8B3A2A / 橙金 #E8913A / 青花蓝 #2E4A7D / 松绿 #7A8B6F 中选取，相邻镜头不重复。宣纸底纹：多层 value noise / FBM 叠加出米黄斑驳（#D6D0B5 → #C9BFA0），再叠细颗粒。所有视觉元素必须程序化生成（噪声 / 分形 / 贝塞尔 / 递归），禁止引用任何外部图片、模型、贴图；禁止 3D 建模感、写实光影、渐变彩虹、科技感粒子爆炸。

【三、DOM 文字层（覆盖在 canvas 之上，不在 WebGL 里排文字）】 ① 左上角「地点标题块」：3px 宽朱砂竖线左侧对齐三行字（地点名 思源宋体 Bold 42px #2B2822 / 行政区 Regular 22px #6B4A32 / 一句话标签 Light 17px #8A8378），距左 7%、距顶 12%，每镜开始 0.8s 淡入 + 上移 12px，cubic-bezier(.22,.61,.36,1)。② 底部居中字幕：思源宋体 Bold 38px，颜色按当前镜头背景明暗自动反相（亮背景 #4A4038 / 暗背景 #F2EDE0），逐字淡入 0.06s/字，当前字之后未显示的字保持 40% 透明（打字机擦除感）。③ 右侧竖排书法（仅诗词镜头）：writing-mode: vertical-rl，书法字体（霞鹜文楷 / 行书，CDN 加载），逐字下坠 0.5s/字 ease-out，末尾朱砂方印（24×24 圆角 2px，内含 2 字落款）。

【四、分镜表】/【五、镜头配方库】（分镜表填实；每个镜头从配方库选取或按同原则自拟）配方库涵盖：山峦（1D 分形噪声 + 4 层 fBm 生成山脉折线，5–6 层沿 z 拉开做空气透视与视差）；树（L-system drawBranch 递归，depth 5–6，松/竹/榕/胡杨由此参数化）；梯田/田野（正弦波叠加横纹色带，横向视差滚动）；民居/古城（程序化小矩形群 + 深色屋顶 + 1–2 处暖黄窗光）；工艺（明暗反转，全片唯一黑场镜）（背景 #0A0A0A + 极暗程序化砖墙/木纹，火焰/蒸汽用 8–12 层噪声扰动顶点的 Shape + AdditiveBlending，颜色自下而上 #F5E6A8 → #E8611F，火星用 THREE.Points + 自定义 Shader 上升衰减）；器物转化（LatheGeometry 车削 ~40 控制点，材质 crossfade 素坯→成器，0.08 rad/s 匀速自转，只做材质渐变不做几何形变）；瀑布/江河（6–9 条竖向渐变白条，y 向 sin 抖动 + 底部水雾 Sprite）；建筑与天色（纯黑剪影 + 窗格暖黄 #F2C978，落日/明月纯色圆盘缓慢下沉，天空 4 段线性渐变，水面镜像 + UV 水平 sin 扰动 + 飞鸟 V 形折线横穿）；湿地/生态（芦苇 PlaneGeometry 顶点着色器风摆 + 穗头 Sprite，鸟群简笔 V 形对角线穿越）；雪山（白色渐变三角棱面群 + 山脊亮线 + 旗云 Sprite）；大漠（正弦叠加沙丘 + 风纹线 + 驼队剪影）；海/湖（渐变水面 + 缓涌波浪线 + 归帆/灯塔剪影）；地理脉络图（总结镜）（宣纸底 + 40–60 个「∧」形山脉符号 #9F906F，干流贝塞尔曲线 + 节点圆点，Catmull-Rom 曲线 ±12px 扰动模拟手绘，LineDashedMaterial + computeLineDistances() 让 lineDashoffset 从全长降到 0「一笔画出」，每条间隔 0.4s 依次生长，完成后叠金色流动虚线 #C9962E 表流向，末段推近核心地标叠径向金色光晕）；片尾 A（母题从上方落下带拖影，落点生成 5–7 圈同心椭圆涟漪 RingGeometry easeOutCubic 扩到屏宽 60%）；片尾 B（参数方程 r(θ)=R+noise(θ) 一笔画出毛笔圆圈 + 圈内「{地名}」二字 + 右下角朱砂方印，无字幕）。

【六、转场规则】 全部 1.2–1.5s 交叉叠化（两景同存，opacity 互补插值）；禁止硬切、黑场、闪白；相邻镜头调性交替：亮↔暗、暖↔冷、动↔静。

【七、交付要求】 ① 完整可运行的单文件 HTML，不要片段、不要省略号；② 所有随机数用固定 seed 的自写 mulberry32，保证每次渲染完全一致；③ 每个镜头封装成独立 Scene / 模块，代码注释标出时间区间。

元指令说明

  • 作者把上述元提示词进一步封装为「文旅短片_元指令.md」，内置配音流程：只需给一个模型 key（如 MiniMax 的 speech-2.8-hd），它会自动完成所有工作流、直接交付一份带配音的 MP4。
  • 元提示词的输出格式要求 LLM 按四部分产出：① 素材速览（母题及理由、选中地标、诗句、强调色分配，≤12 行）；② 分镜总表；③ 配音稿（带时间轴的完整旁白，标注气口）；④ 最终提示词（单个 ```text 代码块，可被直接复制投喂给代码 LLM）。

关键概念

  • Coding 模型做视频 — 本文主体方法论：LLM 写 Three.js/JS 逐帧画面 → 单文件 HTML → 无头浏览器逐帧抓帧 → FFmpeg 编码 MP4（新建实体页）
  • MiniMax Code — 本文使用的 Agent 工具（开源 CLI，harness 在 FrontierHarness Eval 上任务完成率与效率第一）（新建实体页）
  • Meta-prompting — 元提示词：生成”提示词”的提示词，本文把它工程化为可复用的架构师模板
  • MiniMax — M3.1-Flash-Preview（原生多模态 / 1M 上下文 / 思考深度可调）的母公司
  • Remotion — 同为”代码驱动视频”，用 React 组件描述每一帧；本文路线走原生 HTML + Three.js，与它属同一家族
  • AI视频分镜 — 本文对分镜表字段、叙事弧、字幕/时长配比的处理，是 AI 视频分镜在代码路线上的具体规格
  • Vibe Motion — 代码驱动视频（Vibe Motion）方法论；本文是它在”文旅水墨短片”场景下的一次完整实践
  • 视频生成模型 — 本文的对照面：抽卡式视频模型 vs 可确定、可重复计算的代码路线
  • Three.js — 本文用于程序化生成水墨画面的 WebGL 库（未创建实体页）
  • 元指令（Meta-instruction） — 作者把元提示词进一步封装、内置配音、给 key 即出带配音 MP4 的形态（未创建实体页）
  • FFmpeg / 无头浏览器逐帧抓帧 — 本文管线的编码与抓帧环节（未创建实体页）
  • MiniMax-M3.1-Flash-Preview — 本次使用的具体模型（原生多模态 / 1M 上下文 / 思考深度可调）（未创建实体页，信息并入 MiniMax）
  • FrontierHarness Eval — 作者引用的 Agent harness 基准（未创建实体页）

与其他素材的关联

  • 与 2026-07-01-woshipm-vibe-motion-10-pitfalls、Remotion、HyperFrames 的关系：同属”代码驱动视频 / Vibe Motion”家族，但换了一条技术底座。此前素材以 React（Remotion）与原生 HTML 帧驱动（HyperFrames）为主；本文改用 Three.js + WebGL2 程序化生成，并把”无头浏览器逐帧截图 + FFmpeg 编码”这条底层管线明确写出——是把该家族从”框架选型”推进到”具体美术规格 + 元提示词资产”的一篇。
  • 与 2026-07-26-youtube-claude-product-photo-ad-campaign 的关系：两条”Agent 产片工厂”路线的正面对照。那篇是 Claude Code + Fal.ai + Seedance 2.0 + ElevenLabs + HyperFrames 的混合资产产线（静帧 + 生视频 + 配音 + 自动成片）；本文是纯代码合成路线（模型直接写每一帧，不经过生视频模型）。作者对后者的定性是”知识密度高、画面需精确控制时更可靠”，对前者的适用面是”多版本投放广告”。
  • 与 2026-09-21-woshipm-workbuddy-hypit-viral-video-clone、2026-09-21-woshipm-ai-desktop-outfit-video-skill 的关系：同为”把视频生产流程封装成可复用资产”。后两者封装的是”复刻爆款/换装视频”的 Skill 与提示词模板；本文封装的是”给地名→直出文旅短片”的元提示词/元指令，产物形态（元提示词 + 元指令 .md）与它们同构。
  • 与 2026-06-23-image2-seedance-long-video-brand-ad 的关系：长视频拼接 vs 代码单文件的两条解法。那篇的痛点是”主流工具单次最长 15 秒、115 秒要 15 个镜头拼接 + 资产前置”；本文用单文件 HTML + 时间轴直接渲染整片，绕开了”拼接”问题——但它换来的是”真实感、光影质感、复杂物理运动”能力的缺失。
  • 与 MiniMax 的关系：本文给该实体补上了**MiniMax Code（Agent）与 M3.1-Flash-Preview（模型）**两条产品线，以及”1M 上下文 + 思考深度可调 + 1700 万 Tokens 成本 + 2 小时长程执行”的一手使用记录。

原文精彩摘录

最近兴起了一种新玩法，用Coding模型做视频。底层逻辑大致是，LLM用JavaScript或Three.js语言写每一帧的画面，来生成HTML，然后通过无头浏览器逐帧捕获，再用FFmpeg编码成MP4。整个过程都在Agent里完成，全程不打开一次剪辑软件，全部由AI自己搞定。

这跟你用视频模型去抽卡碰运气不同，在代码里，每一秒的画面应该长什么样，是完全确定、可重复计算的。也因此，后期想要修改，会非常方便。

在知识密度高、画面需要精确控制的场景，它相当靠谱，甚至比主流视频模型更可靠；在需要真实感、光影质感和复杂物理运动的场景，它目前还不靠谱。不过它已经给AI视频另辟了一条路径，原来视频可以靠编程解决，而且成本极低，过程可控。

这里面，画幅、画质都是可以任意选的。不像视频模型，480P一个价，1080P又是另一个价，4K基本上要家里有矿才跑得起。

相关页面

关系图谱

快速导航

反向链接