开发过程中有些细节容易被忽略，今天挑几个重点聊一聊。
🫧个人主页：小年糕是糕手
💫个人专栏：《C++》《数据结构》《Blender 修行笔记》《AI》
🎨各位不能左右天气，但各位可以改变心情；各位不能改变过去，但你可以决定未来！
目录
让 AI 帮忙做一条视频，很容易陷入这样的循环：
第一版能动，但像几页会播放的 PPT；让它“做得高级一点”，背景和配色全换了；接着修字幕，已经满意的开场又跟着改了。最终，视频还没定稿，对话里已经堆了好几版代码。
这篇这篇想讨论的，就是怎样少走这些弯路。
大家采用的路线是：让 AI 写分镜和动画代码，再由程序渲染成视频。 画面里的文字、图形、位置和运动，都可以在代码中找到对应的规则。
下面用一条“30 秒解释二分查找”的知识短片贯穿全文。重点放在需求怎么说、画面怎么约束、返工怎么控制，以及哪些做法能减少无效的 Token 消耗。
一、先分清楚：AI 写代码，渲染器输出视频
在这条路线里，聊天模型主要交付文字和代码。真正把画面变成视频文件的，是后面的渲染程序。
视频目标 → 分镜与时间轴 → 动画代码 → 预览与检查 → 渲染成片
这里以 Remotion 为例。它使用 React 描述画面，根据当前帧计算东西，再把这些帧渲染为视频。宽度、高度、帧率和总帧数，都是明确的配置项。Remotion 基本原理
这里说的“纯代码”，限定为文字、几何图形、图表和动画由程序绘制。如果后来加入人物照片、AI 生成图片、配音或素材片段，就需要额外交代它们的来源与处理方式。
算法演示、产品流程、数据解释、动态排版，都相对适合拿来练习这条路线。第一次就挑战人物表演、复杂运镜和写实场景，会把麻烦扩大到另一套制作流程。
还要记住：只有聊天窗口、没有代码执行环境时，AI 给出代码并不等于你已经拿到了 MP4。 你仍然需要在相应项目中安装依赖、预览和渲染。
二、第一轮提示词，先交代观众和结果
先看一句很容易写出来的需求：
帮我做一个介绍二分查找的视频，要高级、有科技感、流畅一点。
这句话表达了期待，却没有给出足够的判断依据。
“介绍”要讲到哪一步？观众是否知道什么是数组？是横屏还是竖屏？30 秒还是两分钟？“科技感”是深色界面，还是发光粒子？如果这些都交给模型补全，后面就要花时间逐项纠正。
更有效的开头，是先确定这条视频要让谁看懂什么。
提示词 1：先做分镜，不急着写代码
我想用代码渲染一条知识动画，主题是“二分查找为什么能缩小搜索范围”。
目标观众：
刚接触编程，知道数组是什么，但还不熟悉二分查找。
看完后的目标：
能说清楚“先看中间项，根据比较结果排除一侧”，并记住前提是数组有序。
项目约定：
- Remotion + React + TypeScript。
- 横屏 1920×1080，30 FPS，总时长 30 秒。
- 画面只使用代码绘制的文字、矩形、线条和箭头。
- 第一版无配音、无音乐，也不引用外部图片或视频。
- 深色背景、浅色文字，青绿色表示当前关注，灰色表示已排除。
- 数组元素在演示过程中保持原位置，避免观众重新寻找位置。
数据：
数组为 [3,8,12,17,23,29,34,41,48,56,63,71,78,84,91,97]，目标值为 78。
采用闭区间和 mid = floor((left + right) / 2)。
这轮只输出不超过 3 个镜头的分镜表。
每个镜头写清：时间段、观众新知道什么、起始画面、主要变化、结束状态。
总时长必须正好是 30 秒。
不要输出项目代码，也不需要扩展其他创意方案。
这段提示词不算短，但它把后面最容易反复争论的事情先确定下来了。
“无配音”意味着信息要能靠画面读懂；“数组不换位置”意味着排除元素时应弱化它们，而不是把剩余元素重新排成另一行。这些约定会直接影响达成。
至于“你是一位世界顶级导演、资深工程师、动画大师”，可以先放下。对这个任务来说，目标观众、数据和完成状态更有用。
三、分镜要说明变化，不能只有三段文案
下面是一份可以继续细化的分镜示例：
时间观众需要搞懂什么起始画面主要变化完成状态0—4 秒要从有序数组中找 78数组和目标出现目标值被单独强调观众知道任务与前提4—24 秒相对中间项，可以排除一侧完整搜索区间中间项高亮，相对结果出现，区间缩小78 被找到，保留过程痕迹24—30 秒排除范围依赖有序性最终命中状态收起次要标记，突出结论留下“先有序，再对半排除”
它和“第一段讲背景、第二段讲原理、第三段总结”的区别，在于每一段都能对应到画面操作。
其中，第二段还应当进一步拆成轮次。按上面的数组和取中方式，这一次的比较顺序是：
41 < 78 → 保留右侧
71 < 78 → 继续保留右侧
84 > 78 → 保留当前区间左侧
78 = 78 → 找到目标
这些步骤应由算法计算，再用于驱动画面。 不要让模型凭印象写四组动画状态，否则画面可能很顺，算法却已经演错了。
同时，“这一次用了四次比较”和“这个长度的数组最多需要几次比较”是不同的问题。视频只演示了一个例子，就不要把它写成对所有输入都成立的结论。
一句“流畅”，最好落到具体动作上
举个例子，可以把某一轮变化写成：
这一轮按“定位—比较—排除—停留”的顺序进行。
游标先移动到中间项，停止后显示比较符号；
随后将排除区间逐渐变灰，保留区间维持清晰；
数字和数组位置不变，留出阅读停顿后再进入下一轮。
这比“所有元素增加流畅动效”更容易执行，也更容易检查。
镜头有起点、有过程、有完成状态，观众才知道变化意味着什么。单纯让标题飞入、卡片弹跳，未必能帮助解释二分查找。
四、约束画面，要约束那些会造成返工的地方
对代码视频来说，值得提前写清楚的约束，可以分成下面几类：
类别示例主要避免什么问题东西只讲比较和排除，保留“数组有序”前提主题越写越大、解释失真时间30 FPS、900 帧，分镜范围明确时长漂移、镜头重叠版式标题区、主体区、字幕区分开文字遮住演示东西运动一个主要变化完成后，再进入下一个观众不知道该看哪里工程帧驱动动画、资源固定、沿用依赖预览和导出出现差异
这些约束需要服务于具体问题。一个只用文字和矩形的小视频，不需要先写几页电影摄影术语。
1. 把秒数换成帧数
30 秒、30 FPS，对应 900 帧。
帧号从 0 开始，最终一帧是 899。为了减少歧义，可以采用左闭右开的区间：
开场：[0, 120)
过程：[120, 720)
结尾：[720, 900)
这样，第一段包含 0—119 帧，第二段从 120 帧接上。Remotion 的官方说明也明确，最后一帧是总帧数减一。帧数与视频属性
如果第一版使用直接切换，上面的时间轴很容易检查。后来增加交叉转场时，要重新核对重叠区间，不能默认“每个镜头多加半秒”而总时长仍然不变。
2. 先写信息层级，再写风格形容词
“高级感”可以作为方向，但还需要补成可操作的描述：
数组是主视觉，始终位于画面中部；
标题位于上方，字幕位于底部独立区域；
当前中间项使用强调色，已排除元素降低不透明度；
同一时刻只突出一条比较结论；
背景不添加与算法无关的粒子、网格或装饰文字。
字号、边距也可以给出初始值。例如，在 1080p 横屏中，先用 80 像素标题、40 像素字幕、左右 96 像素安全边距试排。这些是本例的起点，不是通用标准。 还要结合实际字体、字幕长度和观看尺寸检查。
如果字幕放不下，优先精简句子、调整换行和区域，而不是一路缩到看不清。
3. 动画必须跟着视频时间走
网页里看着会动的东西，导出时不一定按预想工作。
在 Remotion 中，应根据当前帧计算位置、缩放和透明度，避免依赖组件已经运行了多久。官方文档明确建议用 useCurrentFrame() 驱动动画，并提醒 CSS transitions 等方式可能造成渲染闪烁。动画属性说明
可以把这个要求直接写进提示词：
所有动画状态由当前帧计算。
不要用 setTimeout、真实时钟或 CSS animation/transition 推进时间轴。
同一配置下，定位到同一帧时，主体的位置、文字和强调状态应一致。
若有随机排布，再使用带固定种子的伪随机函数。Remotion 给出的 random(seed) 就用于产生可复现的随机值。随机数说明
不过，没有随机效果就不必添加种子；给聊天模型写一句“固定 seed”，也不能替代代码里的可复现实现。
4. 字体和资源不要留给渲染时碰运气
提示词里最好明确：中文字体使用哪个本地文件、字体是否准备好后再开始渲染、缺失时怎样报告。
第一版也可以限定不用外部图片、远程字体和在线视频，让变量少一点。以后确实需要素材，再逐项加入。
即便采用帧驱动，字体版本、依赖和素材变化仍可能改变结果。因此，要固定的不只有动画函数，还有它依赖的资源。
五、第二轮才让 AI 实现，输出范围要说清楚
分镜确定后，再让 AI 写代码。这样可以先改几行方案，而不是先得到一个很大、方向却不合适的项目。
提示词 2：根据已确认分镜实现
下面这段需要与前面的项目约定、最终分镜一起使用：
请按已确认的项目约定和分镜实现第一版。
先读取当前项目的 package.json、入口和相关组件，沿用已有技术栈与锁文件。
若项目尚不存在，先建立能预览该视频的最小项目，不额外开发后台、账号或素材管理系统。
实现要求：
1. 把数组与目标、视觉参数、分镜时间和动画组件适当分开。
2. 二分查找状态由确定性函数计算，画面读取计算结果。
3. 数组元素位置固定，按“定位—比较—排除—停留”推进。
4. 使用当前帧驱动动画；字体和素材必须明确可用。
5. 保持 1920×1080、30 FPS、900 帧。
6. 第一版先完成准确、清楚的演示，不增加分镜外的效果。
交付时：
- 有文件编辑能力：直接修改文件，简述修改了什么。
- 只有聊天能力：给出必要文件路径和完整代码，不省略关键部分。
- 给出与当前项目匹配的预览、抽帧和最终渲染方式。
- 说明实际执行过哪些检查；没有执行的部分不要写成已通过。
这段提示词里有一个容易忽略的地方：模型能读取工作区，和模型只能看到聊天内容，是两种使用方式。
前者可以让它按需读文件；后者就要给出相关代码和依赖信息。只告诉聊天窗口“看一下我电脑里的项目”，它并不会因此知道项目现状。
六、先看关键帧和局部运动，再导出完整视频
代码没有语法错误，只能说明它跨过了第一道门槛。
对这条短片，可以先检查：
- 开场的标题和数组能否看清。
- 每一轮比较之前、之后，指向的数字和搜索范围是否正确。
- 119/120 帧、719/720 帧附近，是否出现空白或内容重叠。
- 结尾最后一帧是否仍然保留完整结论。
抽帧适合查排版和状态，不能代替播放检查。 游标移动是否突兀、字幕是否来得太快、观众有没有阅读时间，都要看片段才能判断。
小样阶段可以先降低输出分辨率，保留同样的帧率与时间轴。只看一个关键片段，也比反复导出整条视频更便于定位问题。最终仍要在目标规格下检查一次，尤其是字体、边界和文字清晰度。
这里节省的是渲染等待与机器资源。它和下一节的 Token 消耗，需要分开搞懂。
七、怎样省 Token：先减少无效重写
Token 消耗至少涉及你给模型的输入，以及模型生成的输出。多轮任务中，还要考虑客户端实际发送了多少历史、文件内容和工具结果。实际统计应看对应服务或客户端给出的用量信息，不能简单按中文字数换算。Token 统计说明
对这类任务，先处理下面几种浪费，通常比研究怎样把一句话再缩短几个字更有用。
1. 不要每改一个小问题，就要求重写整个项目
字幕遮住数组，应当先修字幕区域；第二轮游标走错位置，应当检查那一轮的状态映射。
一句“重新给我完整优化版”，很容易把修改范围扩大。模型需要输出更多代码，你也需要重新核对更多地方。
提示词 3：把修改写成一个可检查的问题
当前版本的问题：
第 12 秒，底部字幕与数组下方的索引标记重叠。
期望：
字幕保留在底部独立区域，完整可读；
数组位置、算法步骤、配色、总时长和开场保持不变。
本轮修改范围：
先检查字幕组件及其布局配置。
若问题需要改动其他文件，说明关联原因，再做必要的最小修改。
不要顺便重构整个项目，也不要重新设计分镜。
我会提供问题帧，以及相关组件的当前代码。
请输出必要补丁、检查方式和仍需人工查看的部分。
不要重复输出没有变化的文件。
“只输出修改部分”主要减少输出量，不会自动缩短已经发送给模型的输入上下文。这两件事要分别处理。
2. 把稳定约定保存下来，但别把文件当成免费上下文
可以用三个小文件管理项目：
video-spec.md # 目标、技术栈、画幅、风格与验收约定
storyboard.md # 已确认的分镜和时间轴
progress.md # 当前版本、已确认内容、待解决问题
这样做能减少来回描述、避免旧版本混进新需求，也方便模型按任务选择需要读取的内容。
但文件被读入模型后，内容仍然属于输入。“存成文件”本身不会让 Token 费用消失。 有工作区工具时，让它读必要文件；使用普通聊天时，贴本轮所需的约定和片段即可。
同样，整份锁文件、无关组件和大量重复日志，不需要每次都塞进同一轮。
3. 让输出服务于当前阶段
做分镜时，只需要一份可判断的分镜；定位错误时，需要原因和必要补丁；代码完成后，需要检查结果和剩余问题。
如果每轮都要求“详细解释全部代码，再提供三套替代实现”，输出自然会越来越长。
可以限制无关说明，但别把代码输出上限压得过低。拿到一半就截断的实现，往往还要补问，未必更省。
4. 新开对话前，先做一份能接上的交接
对话很长、废弃方案许多时，可以换一个干净的上下文继续。
前提是把当前状态带过去。否则，新对话不知道哪些已经确认，仍然会重复设计。
提示词 4：整理可继续工作的交接
请为下一段对话整理一份项目交接，只保留：
1. 当前目标与必须遵守的项目约定。
2. 当前有效的分镜、代码版本和关键文件位置。
3. 已确认可接受的内容。
4. 尚未解决的问题、出现的时间点、对应错误或截图。
5. 下一步最小修改，以及怎样检查它。
不保留已经放弃的创意和重复讨论。
说明哪些检查实际执行过，哪些只是建议。
文件路径只是索引；下一段对话仍需能读取当前文件，或由我提供相关内容。
交接能整理方向，不能替代当前代码。只有一句“上次做到第二段了”，信息仍然不够。
5. 缓存需要看平台支持，不能靠一句提示词开启
部分 API 提供提示缓存，用于复用重复的前缀，降低相应处理成本和延迟。是否支持、怎样配置、什么情况下命中，都由平台规则决定。提示缓存说明
如果你在开发 API 工具，可以按平台要求组织稳定的项目约定；如果只是使用聊天客户端，就不能默认自己已经控制了缓存。
“请节省 Token”“请使用缓存”不是通用开关。把提示词全改成英文、删除标点或堆缩写，也不该被当成必然有效的省钱方式。
最后再区分一次：把视频从 1080p 改成 720p，主要改变渲染工作量。 只有当你把生成的图片、视频帧等再次输入模型时，相关输入的变化才可能影响那一轮模型用量。
八、把“审美不满意”改写成能修改的要求
“不好看”是真实感受，但模型还需要知道问题落在哪。
下面这组对照，可以直接拿来改写反馈：
原来的反馈更容易执行的反馈像 PPT第二镜头需要持续展示区间收缩，保留数组，不要每轮切换整页太花了删除背景粒子和装饰线；当前比较项保留唯一强调色不够流畅游标先移动并停稳，再出现比较结果；两种变化不要同时抢注意力字看不清精简字幕、调整换行与区域，先保留可读字号节奏不对比较结论出现后增加阅读停顿，从同一段的空等时间中扣除，保持总时长
反馈里还应该写上保留项。
举个例子：“开场排版已经可以，保留；只修改中间演示的运动顺序。”这样，模型知道哪些是问题，哪些是下一版的基础。
如果三套方向还没有选定，就不适合一边改颜色、一边改技术栈、一边改时长。每次同时改变太多东西，最后即使变好了，也很难判断是哪一步起作用。
用 AI 写视频代码，难点常常出现在那句“你应该懂我想要什么”之后。
先把观众、内容和时间轴说明白；再把画面变化写成起点、过程和结束状态；遇到问题时，给出具体时刻、预期结果和保留条件。模型才有机会沿着同一个方向继续工作。
对 Token 也是一样。需要减少的，是反复补充缺失要求、重新生成整份项目、核对已经满意部分的消耗。关键约定值得写完整，已经确定的内容值得留下来。
下一次准备让 AI 做视频时，可以先写下这一句：
这条视频结束时，观众应该比开始时多搞懂什么？
把它回答清楚，后面的分镜和代码就有了取舍依据。
最后我也去做了抖音最近很火的人生曲线和AI发展史的视频这篇博客发布的时候已经也已经上传到我的主页上了，希望可以给大家带来参考，谢谢支持！
这篇笔记就先到这里，后面用到新的思路或者发现有问题再补充。
评论 (0)
暂无评论