Gemini Omni 1.1 Flash 会照做的相机词，和它会无视的那些

把 Google 的视频 prompt 材料读得够久，您会撞见相隔几段的两句话。一句公布了一份运镜清单——dolly、truck、pedestal、crane、whip pan、arc——好像您是在照着菜单点菜。另一句则警告说*「某些高级的相机角度并未获得官方支持。结果和可靠性可能会随整条 prompt 和您的具体用例而变化。」*

两句都是真的，而它们之间的那道缝，正是大多数让人失望的片子的来处。一个被点名的运镜是一次模型多半会照办的请求，不是一个它必须执行的参数。gemini-omni-1.1-flash 上没有相机位姿这个字段——没有机架，没有镜头，只有词语在跟您的其他词语抢位置。这篇文章要说的是这些词里哪些配得上自己占的位置，材料来自 Google 写进文档的东西、Runway 报告的东西，以及 schema 暴露出来的东西。

直接掉出来的那些词

先从做减法开始，它不花一分钱，还买来了 prompt 的空间。Runway 那份相机 prompt 参考对 AI 视频 prompt 里最常见的两个词毫不客气：「『Cinematic』和『4k』被拿掉了，因为它们不干活。这两个词都不改变相机做了什么，而它们占掉的 prompt 空间，用来写运镜更值。」

那是关于他们自家工具的说法，不是 Google 的，但其中的道理是通用的。「Cinematic」描述的是一种印象，不是一个视点：它没说站在哪里、离多远、要让什么保持清晰、往哪个方向走。跟在后面的那一串行李也一样——masterpiece、award-winning、8k、ultra detailed——它们继承自图像模型的 prompt 文化，在那里这些 token 曾经是对着一套非常不同的训练分布念的质量咒语。

正面的说法同样朴素：点名一个具体的运镜，而不是要一个「dynamic cinematic camera」，因为这些模型是把*「相机指令当作空间方向来对待的，不是当作装饰。」*那里面没有一句话说「cinematic」有害。它说的是这个词挤掉了更好的东西，而在一条只有几十个词的 prompt 里，挤占就是全部的胜负。

Google 的清单，以及该信它到什么程度

写进文档的那套词汇，比在 prompt 讨论帖里流传的任何东西都可靠：

有两个细节值得留意。Google 是有意把 zoom 和 dolly 分开的，因为模型会把它们混在一起：zoom 改变的是焦距，而*「这和 dolly 不同，因为相机本身没有移动。」*想让背景相对主体涨起来？要一个 dolly。想让画面收紧而几何关系不变？要一个 zoom。写「zoom in slowly as the camera pushes forward」，您就同时点了两样——一个 dolly zoom，而这几乎从来不是您想要的。

其次，有些被广泛算在 Google 头上的术语，其实不在它的页面上。Oner、push in 和 natural smartphone zoom 出现在那些引用 Google 文档的指南里；我们在那些文档里找不到它们。没写进文档不等于禁用，但它们并不比您自己编的一个说法更有权威。完整的、写进文档的语法在我们的 prompt 指南里。

一条片子一个运镜

Runway 那份参考里最锋利的发现，不是哪些动词管用，而是能放几个。

「堆叠动词（不可靠）：『Orbit the subject and crane up and push in.』分阶段的描述（可靠）：『The camera arcs around the seated figure, then rises above the table to reveal the empty chairs surrounding her.』」

紧随其后的建议是，描述每个阶段画面里装的是什么，而不是把动词摞起来；如果这个复合运镜还是不成，就*「退回到一个运镜，把第二个节拍作为它自己的一条片子生成。」*

Omni 在这件事上多了一条机械层面的理由，来自 Google 自己的文档：除非另有交代，模型默认会产出好几个镜头。您要三个同时进行的运镜，就等于递给了它一条退路——切。绕两秒，切，升两秒，切，剩下的推进去。每一条指令都被照办了，而您想要的一样都没有。那条一句话的解法，「In a single continuous shot」或者「No scene cuts」，能拦住模型用一次剪辑来解决您的含糊。

同一个场景，生成两次，只改相机那一句：

每边四秒，720p，每条三十六美分。主体、房间、光和声音线索完全相同；只有开头那一句不一样，一个锁死的机位对上一个缓慢的推轨。相机那一句是整条 prompt 里杠杆最大的一句，也是大多数人最后才写的那一句。

焦距是方向，不是光学

这里没有镜头。这话值得直说，因为心智模型很要紧。您写「85mm」，模型并不是在算视场角；它去够的是训练数据里所有被标成这个数的东西，而带着这个标签的照片以百万计。回来的是附着在这个数字上的那个样子：背景被压缩、主体从一片柔和里被抠出来、距离被压平。换到短焦上，则是被拉伸的透视、画面里更多的空间、弯掉的边缘。

这也让焦距成了可用的词里效率最高的那一类，四个字符就同时挪动了取景和感觉。流传的经验说法是一致的——大约 24mm 给宽阔的环境，35mm 给纪录片的味道，50mm 给中性的叙事，85mm 给压缩过的亲密戏——把它们读作视觉方向，而不是对字面光学的承诺。

由此而来的有两个习惯。给这个数字派个活儿，别让它停在形容词上：光写「35mm」只是一个 token，而「35mm, the workshop visible behind her throughout」说出了这只广角镜头是为了什么，而且这条从句即便数字被忽略也依然成立。Google 写进文档的那些光学术语——shallow depth of field、deep focus、rack focus、telephoto——用大白话干的是同一件事。还有，永远不要把一个焦距和一条与它矛盾的指令配在一起：「85mm wide establishing shot of the valley」是在同时要求压缩和开阔。

取景是您能指定的东西里最可靠的一样

按相机语言落地的可靠程度排个序，一个规律就出现了：静态属性胜过时间属性。

景别——从 extreme close-up 到 wide establishing——是单个画面的属性。角度也是，双人镜头或过肩镜头的几何关系也是。模型可以在它渲染的第一帧里就满足其中任何一样，然后一直保持住。

而一个 dolly in 是一句关于第一帧对第九十六帧的断言，它必须在中间的每一帧上都活下来，而这个过程里根本没有对相机在哪儿的显式表示。研究文献存在的意义就是去补这道缝：CameraCtrl，视频扩散模型里做相机控制的那篇奠基工作，开篇就指出现有模型*「缺乏对相机位姿的控制，而相机位姿是表达更深层叙事细微差别的一种电影语言」*，然后加了一个位姿条件模块，因为光靠文本不够。我们知道的生产级视频 API 里，没有一个把这条通道暴露出来。

于是有了一个值得背下来的层级。取景和角度：随便指定，可以期待被执行。一个被点名的运镜：多数时候可以期待。两个运镜，或者一个带着速度和停止点的运镜：准备好多跑几条，或者把这个节拍拆开。

改写前后

一条按大多数相机 prompt 的写法写出来的 prompt。里面的每一个词我们都用过。

Cinematic 4k video of a silversmith working at her bench in a workshop.
Dynamic camera movement, the camera orbits her and pushes in and cranes
up over the bench. Epic atmospheric lighting, ultra detailed, shallow
depth of field, professional colour grade, film look, masterpiece,
award winning cinematography, highly detailed hands and face,
beautiful composition, 8k resolution, moody and dramatic.

数数其中有多少是可执行的。三个堆起来的动词，一条片子里不可能全都成立。没有景别，没有焦距，没有关于镜头数量的指令——所以那个写进文档的多镜头默认行为可以随便发作，而桌面上摆着三个互相竞争的运镜时，切开就是阻力最小的那条路。

同一个镜头，重写成只说模型能照做的东西：

In a single continuous shot, no scene cuts. Slow dolly in on a silversmith
at her bench, starting on a medium shot and ending tight on her hands. She
turns a thin silver bracelet against a small torch flame, then taps the
seam twice with a jeweller's hammer. 50mm lens, shallow depth of field, the
far wall of the workshop falling out of focus as the camera closes in.
Eye-level, camera slightly to her right. Sound design: the hiss of the
torch, two light metallic taps, a radio playing faintly in another room.
No dialogue. No music.

四处改动，按分量排序。镜头数量那条从句排在最前，这样含糊就不能靠一次剪辑来回答。三个运镜收成一个，起始和结束的取景都点了名——这正是 Runway 推荐的分阶段描述，写成了一次连续的行进。焦距出场时带着一个后果。而声音拿到了属于它自己的句子，这是按 Google 的建议把音频单独描述，否定作为简短的尾随从句。改写后的版本更朴素、读起来更闷，而这通常正是一条 prompt 已经停止描述情绪、开始描述镜头的标志。

相机该写在 prompt 的哪个位置

顺序这个问题，我们本以为不会有答案。它有一个，来自 Google 的 Veo 指南而不是 Omni 页面：那里的公式是电影摄影、主体、动作、场景、风格与氛围——相机在最前，写在您点出谁在画面里之前——因为这个要素*「是传达基调和情绪最有力的工具。」*Omni 自己的文档列要素时顺序不同，相机排在中间，所以 Google 公布了两套顺序，而我们没有跑过对照实验。

以相机开头这件事，确实经得起 Omni 另一条写进文档的行为的检验，因为镜头数量的指令必须在模型开始编叙事之前落地。它还让一条 prompt 变得可审查：如果第一句没有描述一个视点，那您就没有指导过一个镜头。

schema 不会给您的东西

两条结构性的限制，都不是靠把词写得更好就能修的。

第一条是可复现性。Google 的 API 文档写明*「不支持系统指令、temperature、top_p、停止序列和负面 prompt」*，并让您把否定内容写进 prompt 里。这里没有采样器可以收紧。剩下的是 seed，我们这个模型的 schema 上的一个可选整数，而这就是全部的控制面。

这件事对相机工作的影响，比对 prompt 里其他任何东西都大。灯光返回得略有不同，那还是同一个镜头的另一种调色；一个 dolly 返回成了 pan，那就是另一个镜头。所以要让一个运镜在多次生成之间保持稳定，就意味着固定 seed 并且什么都不改——而改一个词就意味着重新采样。把一个好用的 seed 当作资产看待，把它记在 prompt 旁边。

第二条限制是相机速度没有词汇。「Slow dolly in」就是全部的控制面：没有单位，没有时长，没有办法说这次推进应该在第五秒结束然后停住。时间码语法有一点帮助——Omni 接受方括号范围——所以一条 prompt 可以要求相机在第四秒稳下来。至于它会不会照做，那是另一回事。

快门角度和运动模糊坐在同一栏里：两者都不出现在 Google 写进文档的词汇里。帧率算是擦肩而过——24 fps 在 Omni 页面上只出现在一个算时间的示例里，「12 frames at 24fps」，而不是作为一个 prompt 杠杆。它对推算时间码有用；不是那种您写进去就能指望它起效的东西。

在真正要紧的那一档上，相机实验要花多少钱

相机是 prompt 里那部分您不可能一次做对的东西：您要的是跨时间的行为，却没有参数去约束它，所以您生成、看、调、再生成。要紧的那个数字是一条片子的价格。

在 4K 上，一条八秒的片子在我们这里是 1.44 美元，直连 Google 是 2.43 美元。要六条才落定一个运镜——对任何有具体行进路线的东西来说这都算保守——就是 8.64 美元对 14.60 美元。这个差距是 41%，远远是四个分辨率里最大的一个，也是 4K 这一行成了唯一值得争论的一行的原因。别处的行情是：一秒 4K 在 fal 是 0.30 美元，在 Runware 是 0.32 美元，在 WaveSpeed 是 0.39 美元，而在我们这里是 0.18 美元；Replicate 挂了这个模型，却根本没给每秒的价格。

不过省钱的办法不是更便宜的 4K 一秒，而是别在 4K 上测运镜。十条八秒的草稿跑在 360p 档上要 2.38 美元，而 360p 已经足够看出相机有没有照您说的做——一个运镜在任何分辨率下都读得出来，这正是它便宜好测的原因。十条草稿加一条 4K 成片是 3.82 美元，对着十条 4K 的 14.40 美元。

最上面两档是放大出来的，不是原生渲染——Google 的模型参考把它们标成*「1080p output (upscaled)」和「4K output (upscaled)」*——所以一条 4K 的片子买到的是交付尺寸，不是您正在审的这个镜头里多出来的细节。我们那篇讲四十秒场景的文章讲了在哪些情况下这钱还是值得付。

价格和产品条款都可能变化。在做采购决定之前，请核对各家服务商当前的定价。

简短版

先说镜头数量，再说一个运镜，再说它从哪个取景开始、到哪个取景结束。给焦距一个待在那里的理由。把音频放进它自己的句子。把每一个描述这段视频该让人产生什么感受的词都删掉，把腾出来的空间花在相机在哪里上。

1.1 里到底上了什么，写在发布解读里，而各家价格审计解释了为什么同样的权重按页面不同要价不同。参数和当前价格在文生视频模型页面上。如果只是一个运镜、后面没有任何东西依赖它，先按每秒一美分给 Veo 3.1 Fast 算算账——相机词汇来自 Google 为两个模型共同发布的那份指南，所以练出来的手艺是可以迁移的。

常见问题

Gemini Omni 1.1 Flash 能听懂哪些相机运动术语？

Google 点名了一套运动词汇——static、pan 和 tilt、dolly / truck / pedestal 这三对、zoom、crane、drone 或 aerial、handheld、whip pan、arc——外加角度、景别和光学术语。它同时警告说某些高级的相机角度并未获得官方支持，可靠性会随 prompt 而变化，所以要把一个被点名的运镜读作一次请求，而不是一个参数。

在视频 prompt 里写「cinematic」有用吗？

单独写没什么用。Runway 那份相机 prompt 参考把「cinematic」和「4k」都拿掉了，理由是两者都不改变相机做了什么，而这点空间用来点名一个运镜更值。这个词描述的是一种印象而不是一个视点，所以它没给模型任何可执行的东西——就跟「masterpiece」「8k」以及图像 prompt 留下的其他行李一样。

35mm 或 85mm 这样的焦距数字会改变输出吗？

它们会挪动画面的样子，因为训练数据里的照片在元数据里带着焦距，而这个数字被读成了一个风格线索。长焦倾向于压缩背景、把主体分离出来；短焦拉伸透视、把房间里更多的东西放进来。把它当作视觉方向而不是字面上的光学，并且给它挂上一个后果。

相机指令该放在 Omni prompt 的什么位置？

Google 的 Veo prompt 指南把电影摄影放在最前，排在主体、动作、场景和风格之前，称它是传达基调最有力的要素。Omni 自己的文档把相机术语排在中间。两份都是 Google。以相机开头有一个实际的好处：镜头数量的指令是一个相机决定，它需要在模型开始编叙事之前落地。

能让 Gemini Omni 1.1 Flash 把同一个运镜做出两次吗？

只能靠复用一个 seed。Google 的文档说 temperature、top_p、系统指令、停止序列和负面 prompt 都不支持，这就把 seed——我们 schema 上的一个可选整数——留成了全部的可复现性控制。改动 prompt 里的一个词，您就是在重新采样，所以在某个运镜出来得好的那一刻，就把产出它的 seed 记下来。

我只要了一个运镜，为什么相机会在镜头中间切开？

因为多镜头是默认行为。Google 写明，除非另有交代，Omni 会尝试做出好几个镜头并编出一段叙事，所以一条堆了两三个运镜的 prompt 等于给了它一个借口，把每一个都放进各自的剪辑里满足掉。文档给出的解法是加一条要求单个不间断场景的从句，而退回到一个被点名的运镜则拿掉了那个动机。

能在 Gemini Omni 的 prompt 里指定快门速度或帧率吗？

Google 写进文档的相机词汇里没有任何一条涉及快门角度或运动模糊，我们也不会声称这些术语会被照办。帧率同样不是一个 prompt 杠杆：24 fps 出现在 Google 的 Omni 页面上，是在一个算时间的示例里——「12 frames at 24fps」——而不是一个您可以设定的规格。帧率放到后期去处理。

在 4K 上测试相机 prompt 要花多少钱？

一条八秒的 4K 片子在 E2X 上是 1.44 美元，直连 Google 是 2.43 美元，所以六条是 8.64 美元而不是 14.60 美元——差距 41%，是四个分辨率里最大的。不过在 4K 上测试通常是浪费：一个运镜在 360p 上就读得出来，在那一档上十条八秒的草稿一共 2.38 美元，再加一条 4K 成片，整轮是 3.82 美元。