veo-3.2-prompter

veo-3.2-prompter 技能概览

veo-3.2-prompter 实际解决什么问题

veo-3.2-prompter 是一个面向 Google Veo 3.2 风格视频生成流程的提示词设计技能。它真正的价值不只是“把 prompt 写得更好”，而是把用户零散、模糊的需求，加上可选素材，一并整理成结构化、可执行的输出：包括最终 prompt 和推荐生成参数，并且会按照 Veo 的参考图像机制以及 Gemini API 的约定来组织结果。

谁适合安装这个技能

这个技能尤其适合以下用户：

• 需要基于图片、视频片段、音频方向等混合输入来生成 Veo prompt
• 希望得到比普通自由聊天式 prompt 更稳定、更可控的提示词构建结果
• 重视电影感 prompt 质量、素材处理方式以及参考素材的选择逻辑
• 正在使用或准备接入 Google Veo 3.x 工作流，尤其是 Veo 3.2 / Artemis 风格提示词体系

如果你只需要一句创意文案，不涉及素材，也没有技术约束，那它的帮助就没那么大。

它真正要完成的任务是什么

大多数用户的问题并不是“没有创意”，而是无法把创意转换成一套适合 Veo 使用的指令结构。这套结构需要做到：

• 选对参考方式
• 区分主体、面部、风格、构图和音频意图
• 避免混入其他视频模型不兼容或不支持的语法
• 输出尽量接近可直接交给 API 的结果，而不是一段笼统描述

这正是 veo-3.2-prompter skill 的核心价值。

它和通用提示词助手有什么不同

这个技能最关键的差异，在于它内部的映射逻辑。它采用 atomic-element 的思路，把上传素材拆分并归类到不同角色，例如：

• subject identity
• face identity
• scene environment
• aesthetic style
• composition or first-frame structure
• video extension source
• audio direction

这点非常重要，因为 Veo 并不会把所有参考素材一视同仁。这个技能会帮助你判断某个输入更适合变成 STYLE、SUBJECT、SUBJECT_FACE 类型的参考，还是更应该用文字描述来表达。

在决定采用前要先了解的关键限制

这个仓库在提示词逻辑上很强，但它并不是完整的 SDK 封装，也不是端到端自动化工具。参考资料中明确体现了这些限制：

• Veo 3.2 的语法是围绕 Gemini 风格的 RawReferenceImage 使用方式，而不是 @asset_name 语法
• 参考图像在语法指南中上限为 3 张
• 音频不能直接作为参考图像附加使用；应在 prompt 中描述，并配合 generate_audio=True
• 文档里提到的 Veo 3.2 model ID 被标注为 provisional，而指南中注明当前稳定项是 veo-3.1-generate-preview

如果你的首要需求是可直接用于生产的 API 代码，而不是提示词设计能力，那这个技能只能解决其中一部分问题。

如何使用 veo-3.2-prompter 技能

安装 veo-3.2-prompter 技能

从 pexoai/pexo-skills 仓库安装：

npx skills add pexoai/pexo-skills --skill veo-3.2-prompter

如果你的环境使用的是其他 skill loader，也请继续使用同一个 repo 和 skill slug：veo-3.2-prompter。

先读这些文件

想最快理解 veo-3.2-prompter skill，建议按这个顺序读：

1. skills/veo-3.2-prompter/SKILL.md
2. skills/veo-3.2-prompter/references/atomic_element_mapping.md
3. skills/veo-3.2-prompter/references/veo_syntax_guide.md

这样读更高效，因为 SKILL.md 先讲清工作流，而后两个参考文件解释的则是真正影响输出质量的判断逻辑和 Veo 语法约束。

这个技能需要你提供什么输入

veo-3.2-prompter usage 这种用法在你提供以下信息时效果最好：

• 视频目标
• 主体是什么
• 想要的视觉风格
• 场景或环境
• 镜头类型或相机运动方式
• 时长或节奏预期
• 你上传了哪些素材，以及每个素材分别要控制什么
• 是否需要生成音频、只隐含音频意图，还是忽略音频

即便是简短需求也能用，但如果你能明确标注每个素材的用途，技能表现会明显更好。

如何把模糊需求改写成高质量请求

弱输入：

• “Make a cool ad from these images.”

强输入：

• “Create a 10-second premium product ad for this watch. Use watch_front.jpg to preserve the product appearance, moodboard.jpg for color palette and lighting style, and make the setting feel like a dark luxury studio. Slow push-in camera move, shallow depth of field, high contrast reflections, no human hands, polished cinematic look, generated audio with subtle mechanical ticks.”

为什么后者更好：

• 它把主体参考和风格参考拆开了
• 它给了技能明确的镜头和场景目标
• 它说明了哪些部分必须保持一致
• 它能降低模型把所有图片都当成泛化风格提示的风险

veo-3.2-prompter 如何理解你的素材

veo-3.2-prompter for Prompt Writing 的工作流核心是 atomic element mapping。实际使用时，你应该告诉技能，每个文件主要属于哪一种角色：

• 面部身份参考
• 物体或角色主体参考
• 风格或情绪参考
• 布局 / 首帧参考
• 用于扩展的视频源片段
• 需要在文本里描述的音频灵感来源

这是一个很关键的采用点：同一张图可以承担完全不同的角色，而角色分配错了，prompt 质量往往就会明显变差。

参考素材的选择如何影响输出质量

从附带的语法指南来看，Veo 风格的参考机制并不是通用随意的。常见选择包括：

• SUBJECT：用于产品、物体或非人脸主体的一致性保真
• SUBJECT_FACE：用于保留人脸身份特征
• STYLE：用于 mood board、艺术指导、色板或整体观感

一个实用原则是：不要把参考位浪费在你并不清楚要它起什么作用的图片上。如果某个文件只是提供氛围感，它更适合作为 style reference，甚至直接改写成文字描述，而不是强行作为主体锚点。

实际使用时推荐的工作流

一个靠谱的 veo-3.2-prompter guide 工作流通常是这样的：

1. 收集用户需求和全部素材
2. 按 atomic role 对每个素材分类
3. 选出真正能控制生成结果的最小参考集
4. 明确哪些必须保持一致，哪些可以变化
5. 用文字补充运动、构图和环境
6. 如果需要音频，用文字描述音频方向
7. 生成最终 JSON 输出，包含 prompt 和推荐参数
8. 根据首次输出中的漂移、风格偏差或主体不一致继续修订

这比直接拿一整段混杂描述去 prompt Veo 更有效，因为它会先拆开“控制决策”，再处理“措辞决策”。

最终输出应该长什么样

这个技能的设计目标，是产出一个优化过的单一 JSON 对象，而不是松散的自然语言回答。这个输出通常应包含：

• 最终 prompt 文本
• 推荐参数
• 由附带素材推导出的参考决策
• 与音频生成相关的意图

如果你后续还要把结果交给其他工具、SDK 调用，或内部自动化层，这种结构会非常实用。

这里真正重要的实用提示词写法建议

使用 veo-3.2-prompter 时，最常见、也最有效的质量提升通常来自这些做法：

• 明确命名主要主体，避免歧义
• 明确告诉技能哪个素材对外观最有决定权
• 把风格和身份控制拆开
• 直接写清相机运动
• 说明这是全新生成，还是基于已有视频做 extension
• 用文字描述声音，而不是默认音频文件会被直接当作参考输入

这些并不是泛泛而谈的 prompt 建议，它们都直接对应这个技能面向 Veo 的映射逻辑。

需要避免的误用方式

避免这些常见错误：

• 上传多张图片，却不说明每张图分别控制什么
• 一边要求严格身份一致，一边又给出强烈冲突的风格参考
• 套用其他视频模型的语法习惯，尤其是 @asset_name
• 假设音频上传会像视觉参考一样生效
• 在同一个请求里塞进过多且同等重要的目标

如果你的 prompt 本身就是冲突的，模型通常只会把这种冲突反映出来，而不会替你自动协调。

veo-3.2-prompter 技能常见问题

veo-3.2-prompter 比普通聊天式 prompt 更好吗？

通常是的，尤其当你的任务涉及素材或一致性约束时。普通聊天 prompt 也许能写出一段好看的描述，但如果你需要素材角色判断、Veo 专属参考逻辑，以及更接近可落地实现的最终输出，veo-3.2-prompter 会更有用。

这个技能只适用于 Veo 3.2 吗？

不是。仓库里明确说明，它适用于更广义的 Google Veo 3.x 提示词场景；只是当前指导内容主要围绕 Veo 3.2 约定和 Artemis 风格提示工程来展开。即便如此，在正式用于生产之前，你仍然应该核对最新的 model ID 和当前 API 细节。

新手也能用 veo-3.2-prompter 技能吗？

可以，但前提是新手最好别只给一句“make it cinematic”。如果能提供结构化输入，效果会好很多。这个技能能帮你构建 prompt，但它仍然依赖清晰的源需求和素材标注。

什么情况下不应该使用 veo-3.2-prompter？

以下情况可以直接跳过：

• 你的工作流本身不是面向 Veo 的
• 你只想快速拿一个创意概念，而不是结构化输出
• 你需要的是完整维护好的 API 代码，而不是提示工程逻辑
• 你的生成栈使用的是另一套参考语义完全不同的模型

它对音频 prompt 有帮助吗？

有，但有边界。仓库中的说明把 audio direction 定义为应写进 prompt 文本的内容，而不是作为 Veo reference image 上传。这意味着它对配乐、对白或音效意图是有帮助的，但并不等于它提供了直接的音频 conditioning 基础设施。

这个技能包含可直接运行的代码吗？

严格说不算。这个仓库最有价值的支持内容是参考文档，尤其是围绕 RawReferenceImage 用法和 reference types 的说明。更适合把它理解为高价值的 prompt 设计层，而不是一个打包好的 SDK 集成方案。

如何改进 veo-3.2-prompter 技能的使用效果

提前把素材标签写清楚

提升 veo-3.2-prompter 结果最简单的方法，就是在调用前先给素材加上明确标注。比如：

• portrait.jpg = 保留这张脸的精确身份特征
• shoe.png = 保留产品外观
• moodboard.jpg = 只用于色板和灯光风格
• layout_frame.jpg = 开场构图参考

这个单一改动带来的歧义减少效果，通常比多加一堆形容词更明显。

先排清楚哪些要素必须固定

很多用户会一次性提出太多“必须保留”的要求。更好的做法是先判断什么才是真正不能动的：

• identity
• product shape
• face fidelity
• style
• environment
• camera motion

如果所有东西都要求固定，那实际上就等于没有优先级。这个技能在知道控制层级时，表现会更好。

在第一次请求里加入更具体的电影化信息

想提升 veo-3.2-prompter usage 的质量，可以补充这些细节：

• 镜头感或取景方式
• 相机运动
• 光线方向
• 节奏与镜头能量
• 场景质感
• realism 和 stylization 哪个更重要

单说“cinematic”其实很弱；像“Handheld medium close-up, golden-hour backlight, subtle lens breathing, grounded realism” 这样的描述，技能才更容易把它转成可执行内容。

留意参考角色分配错误

常见失败原因之一，就是把素材分配到了错误的功能角色。比如：

• 目标是保脸，却把 portrait 当成 STYLE
• 把 mood board 当成 SUBJECT，结果反而干扰了身份控制
• 不是挑最强的 1 到 3 个参考，而是一次挂上太多互相竞争的参考

如果第一次输出出现明显漂移，先回头检查角色分配，通常比整段 prompt 重写更有效。

在首次生成后按失败类型修 prompt

拿到第一次结果后，不要只说“make it better”，而是根据具体失败点调整：

• subject drift：强化 subject reference，减少冲突的风格提示
• face mismatch：更明确地表达 SUBJECT_FACE 意图
• weak atmosphere：补强风格和灯光语言
• composition problems：更直接指定 opening frame 或 layout
• bad audio fit：把音频方向改写成清晰的描述性文本

这会比笼统地要求“更好一点”形成更有效的迭代闭环。

对照参考文档校验请求

想进一步提升 veo-3.2-prompter skill 的使用效果，可以把自己的请求对照以下文件检查：

• references/atomic_element_mapping.md
• references/veo_syntax_guide.md

这些文件里有很多用户自己摸索时最容易摸偏的实用逻辑：不同素材类型各自适合做什么、什么时候该用 STYLE 而不是 SUBJECT 或 SUBJECT_FACE，以及当前实际被支持的 Veo 语法假设到底是什么。

根据当前 API 现实调整工作流

由于语法指南把部分 Veo 3.2 细节标为 provisional，更稳妥的做法是把这个技能当成 prompt 与结构化输出层来使用，同时另行核对最新的 Google model 名称和 SDK 签名。这样可以避开一个很常见的采用误区：把提示词逻辑的稳定性，误认为 API 本身也同样稳定。