OmniHuman-1.5 提示词配方：可直接复制粘贴的说话人头像视频提示词

为什么提示词结构比措辞更重要

大多数团队写第一个说话人头像提示词时，只写一句话，然后花几个小时反复改写，试图找到一句有魔力的短语。这种方法注定失败，因为 OmniHuman-1.5 响应的不是巧妙，而是规格说明。提示词就是一段短视频的规格说明：谁出镜、说什么、画面如何构图、台词如何演绎。其中任何一项缺失或与其他项纠缠不清，模型就只能猜测，而猜测正是一致性问题的来源。

一个有用的心智模型是把提示词看作四个堆叠的模块，共同供给一个输出：

• 主体——谁出镜，以及在稳定、可描述的层面他们长什么样。
• 台词——要说的确切话语，逐字写出来。
• 构图——景别、机位角度、背景，以及主体在画面中的位置。
• 演绎——节奏、能量、语气，以及让台词听起来像说出来的、而非背诵的小幅身体动作。

一旦把这些分开，迭代就变得可控。你可以不改台词只改演绎，或重写主体描述而不重新构图。如果所有内容都挤在一段流畅的文字里，每次编辑都是全局编辑，你永远无法把输出的变化归因于输入的某个具体改动。

这也解释了为什么表面上读起来差异很大的两个提示词可能产生相似的结果：它们编码了同样的四个模块。而看起来几乎相同的两个提示词可能差异巨大，因为其中一个悄悄漏掉了某个模块——通常是演绎，这是人们最容易忘记写下来的部分。

本指南中的配方都基于同样的四个模块。它们的用意是让你复制、改编，然后故意拆解，以便看清每个模块在起什么作用。

开始前的一个提醒

OmniHuman-1.5 的提示词处理方式并未完全公开，而未公开的旋钮是会变的。下面的每个配方都避免使用凭空编造的参数、权重语法和厂商特定的标志。相反，它依赖对主体、台词、构图和演绎的平实、明确、自然语言的描述。这样配方保持可移植，也避免你把流水线建立在可能并不存在的语法上。

当某个配方需要约束模型可能无法可靠遵守的东西——精确的时间点、不寻常音素上的精确唇形同步、非常长的台词——指南会明确指出，并建议在提示词之外处理，而不是指望写进文本就能实现。

如果你想通过单一统一 API 运行这些配方，而不是拼凑各模型的单独集成，HiAPI.ai 的视频端点就是这里所述一切的目标路径。

可直接复制粘贴的提示词解剖

在配方之前，先看它们共同遵循的模板。读一遍，你就能凭记忆重建其中任何一个。

[SUBJECT]
A [age range] [gender presentation] with [hair], [distinguishing feature],
wearing [clothing]. Natural, realistic appearance, no stylization.

[SCRIPT]
Say exactly: "<your script here>"

[FRAMING]
[Shot size] shot, [camera angle], [subject position in frame].
Background: [background description]. Lighting: [lighting description].

[DELIVERY]
Speaks at [pace]. Tone: [tone]. [Optional physical behavior cue].
Camera is static.

关于每个字段为何这样写，几点说明。

主体

保持描述稳定而具体：年龄段、性别呈现、发型、一两个显著特征、服装。避免堆叠形容词——每个多余的描述词都是模型在多次运行之间可能漂移的又一个点。如果你需要在多个片段中使用同一个人，逐字冻结这个模块，永远不要编辑它。

台词

Say exactly（逐字说出）这个短语在起实际作用。它表明后面的文本是语音内容，而非场景描述。把台词放进引号里，让边界明确无误，并保持为纯散文——不要舞台指示、不要括号说明、不要标记。

构图

景别（特写、中景、中远景）、机位角度（平视、略微仰拍）和主体位置（居中、略偏画面左侧）都可以用普通词语描述，并且都会实质性地改变输出。背景和光线也属于这里，因为它们是镜头的一部分，而不是演绎的一部分。

演绎

这个模块是大多数人跳过的。节奏、语气和一个身体行为提示（轻微点头、一个手势、姿态变化）对感知自然度的贡献，比反复重写主体描述大得多。保持一两个提示就好——超过这个数，模型就必须做选择。

结尾约束

以 Camera is static（镜头固定）结尾，是抑制不请自来的镜头运动的一种低成本方法，后者是说话头生成中常见且分散注意力的失败模式。它不是参数，而是普通指令，属于配方的一部分。

你不应该放进模板的内容

不要在提示词文本里写帧率、分辨率、种子和模型版本字符串。那些是请求层面的问题，不是提示词层面的问题，混入其中会让提示词更难 diff、更难复用。让提示词管内容，让 API 调用管基础设施。

配方：单人讲解片段

主力配方。适用于文档旁白、课程内容、公告视频，以及任何由主持人念一段准备稿的场合。

[SUBJECT]
A person in their early 30s, gender-neutral presentation, short dark hair,
wearing a plain crew-neck sweater. Natural, realistic appearance, no stylization.

[SCRIPT]
Say exactly: "In this walkthrough we'll cover three things. First, how to set up
the project. Second, the configuration options that matter most. And third, how
to verify everything is working before you ship."

[FRAMING]
Medium shot, eye level, subject centered with a small amount of headroom.
Background: softly out-of-focus home office with a bookshelf.
Lighting: soft key light from the left, no harsh shadows.

[DELIVERY]
Speaks at a measured, conversational pace. Tone: friendly and instructional.
Occasional small nod on sentence boundaries. Camera is static.

为什么有效

台词足够短，能保持连贯——大约三句话，分句边界清晰。构图刻意平淡：居中、平视、柔和背景。平淡构图在这里是个优点，因为它让多次运行之间的输出差异容易识别。如果背景开始变化，你就知道是模型的问题，而不是你的镜头描述的问题。

演绎模块给了一个身体提示（在句子边界处偶尔轻微点头），它与台词结构自然对应。这种演绎提示与台词形态之间的对应关系值得复制：与台词节奏匹配的提示读起来自然，与之冲突的提示读起来随机。

改编它

• 更长的台词：保持相同的构图和演绎，在段落边界处把台词拆成多个片段，而不是强行做一次长生成。当每个片段结构相似时，跨片段的一致性更容易保持。
• 不同受众：只改语气词（“权威”、“温暖”、“轻快”）然后重跑。这是配方中杠杆率最高的单次编辑。
• 品牌人设：冻结主体模块，只改服装。这样把服装与脸和头发隔离开，而后者是最容易漂移的字段。

已知局限

非常长的台词——一次生成好几段——往往在接近结尾时失去节奏一致性。计划每个片段几句话，然后在剪辑器里组装。不要试图通过向提示词添加节奏指令来解决长度问题；提示词不是时间控制器。

配方：短社交钩子

短视频的生死就在前两秒。这个配方用能量换取讲解配方的中性，并且故意比其他配方更短。

[SUBJECT]
A person in their late 20s, wearing a casual button-up shirt.
Natural, realistic appearance, no stylization.

[SCRIPT]
Say exactly: "Stop scrolling. If you've ever shipped a feature that broke in
production, this is the one setting you probably missed."

[FRAMING]
Close-up shot, slightly below eye level, subject centered and filling most of
the frame. Background: simple solid-color wall. Lighting: bright, even, frontal.

[DELIVERY]
Speaks quickly with confident energy. Tone: direct and conspiratorial.
Leans in slightly on the first sentence. Camera is static.

值得借鉴的设计选择

特写加略低于平视营造亲密感和一丝紧迫感。这是短视频的视觉语法，而且完全可以用普通构图语言表达——不需要特殊语法。

纯色背景消除了与快节奏剪辑争夺注意力的视觉噪音。在短视频中，背景永远不该是画面中有趣的部分。

最多两句话。钩子是一个注意力单元，不是段落。如果你的想法需要三句话，那就属于另一个配方。

一个与第一句匹配的身体提示。“在第一句时略微前倾”之所以有效，是因为第一句就是钩子。把提示与它所属的节拍配对。

改编它

用相同的主体和构图运行三个不同的钩子台词，然后从输出中挑选。因为除台词模块外一切都被冻结，片段之间的差异可以归因于写作，而这正是你做钩子 A/B 测试时想要的。

已知局限

非常快的演绎可能在密集技术术语上降低清晰度。如果你的钩子包含产品名、缩写或需要念出的数字，把节奏词从“quickly”改为“briskly”再比较。这是演绎模块即使在台词锁定后仍可能需要第二轮调整的唯一地方。

配方：产品演示旁白

这个配方用于产品界面或一系列步骤上的旁白，此时清晰度比个性更重要，节奏需要留出空间让观众的眼睛跟上。

[SUBJECT]
A person in their mid 30s, wearing a neutral blazer over a plain shirt.
Natural, realistic appearance, no stylization.

[SCRIPT]
Say exactly: "Open the settings panel from the left navigation. Choose the
integration you want to connect. Paste your key into the credential field.
Then save, and run a test call from the same screen to confirm the connection."

[FRAMING]
Medium close-up, eye level, subject positioned slightly left of center to leave
room on the right of frame. Background: clean, uncluttered neutral wall.
Lighting: soft, even, no rim light.

[DELIVERY]
Speaks slowly and evenly, with a brief pause at each step boundary.
Tone: calm and precise. Minimal movement. Camera is static.

最重要的构图提示

“略微偏左居中，以在画面右侧留出空间”是这个配方中最重要的一行。演示通常与屏幕录制或 UI 叠加合成，而偏离中心的构图给你的剪辑师留出了放置它们的位置。在提示词中不花任何代价，却省去一次重新渲染。

节奏作为结构性指令

“在每个步骤边界处短暂停顿”是关于结构的指令，不是时间参数。它告诉模型台词有四个单位的节奏。你不是在指定毫秒——你是在告诉它节拍在哪里。保持台词中的步骤数少且对应关系清晰；如果台词有六个步骤而演绎提到边界处的停顿，那仍然是一条指令，而且仍然可读。

改编它

• 多段：把每个步骤渲染为自己的片段，使用相同的主体和构图模块，然后拼接。这样给你干净的剪辑点，并在整个序列中保持外观一致。
• 叠加驱动的剪辑：如果某个步骤需要的视觉节拍比它的口头台词更长，添加一个尾部静音片段，而不是拉长演绎指令。静音是后期制作的问题。

已知局限

停顿是请求，不是保证。如果精确的停顿位置对与屏幕动作同步至关重要，计划在剪辑器中调整，并把生成的片段视为除剪辑时间之外一切内容的音视频真相来源。

测试并迭代配方

配方是一个假设。在扩大规模之前先验证它。

第 1 步：写一个测试台词

准备一段短台词——两到三句话——涵盖你真实内容中的难点：最长的词、最不寻常的专有名词、你实际会说的数字。测试台词应该是对抗性的，而不是讨好的。模型轻松处理的测试句什么也告诉不了你。

第 2 步：生成基线

用测试台词不加修改地运行一次配方。保存输出以及产生它的确切提示词文本。这个基线是你之后每次比较的参照点。

第 3 步：每次运行只改变一个变量

这就是全部的纪律。挑一件事，只改那一件：

• 台词长度——相同提示词，多一句话。
• 构图——从中景到中近景，其他都不动。
• 演绎语气——替换一个词（“友好”改为“轻快”）。

如果你在同一次运行中既改了构图又改了语气，而输出变好了，你只学到某个东西起了作用，而不知道是哪一个。那是一次浪费的运行。

第 4 步：保留 diff 日志

对每次运行，记录提示词变体、那一处改动，以及一行结论。被拒绝的变体与被接受的同样有价值，因为它们告诉你边界在哪里。一个带时间戳和 diff 的简单文本文件就足够了；你不需要特殊工具。

第 5 步：提升或丢弃

当一个变体明显优于基线时，把它提升为新基线，并在将其定为生产配方之前，用完整测试台词重新测试。对一句话有帮助的改动可能对另一句话有害。

不要迭代什么

不要迭代提示词无法控制的东西。如果你的问题是分辨率、宽高比或种子确定性，你就在错误的层面——去看你的请求参数，而不是提示词。花运行次数反复改写提示词来修复基础设施问题，是团队浪费生成预算最常见的方式。

关于样本量的说明

说话头生成存在固有的运行间变化。每个变体只生成一个样本可能会误导你。在得出结论之前，用测试台词为每个变体生成两到三个样本，并在样本之间比较，而不是挑最好的那个。

常见失败模式及如何通过提示词规避

这些是最常出现的问题，附带从提示词侧解决它们的调整。这些都不需要发明参数。

主体在片段之间漂移

症状：头发、服装或年龄在各段之间看起来不同。 修复：在所有提示词中逐字冻结主体模块，其中什么都不改——不改同义词，不改词序。变化通常来自片段之间好意的重写。

演绎读起来像背诵，而不是说话

症状：表情平淡、没有微动作、诡异的静止。 修复：在演绎模块中添加一个身体行为提示，并确保它与台词中的一个节拍对应。同时检查台词是否以口语语体写成——缩略形式、短分句、句子片段。正式散文无论你加什么语气词，读起来都像正式演绎。

不请自来的镜头运动

症状：缓慢变焦、漂移或平移，而你并没有要求。 修复：在演绎模块末尾加上明确的固定镜头指令。如果运动仍然存在，删除提示词中其他地方暗示运动的词（“动态”、“充满活力的构图”、“移动镜头”）。

背景与主体争夺注意力

症状：模型把注意力放在背景细节而非脸上。 修复：把背景描述简化为一个短语，并添加将主体与墙壁分开的光线（从一侧打柔和主光）。背景词更少，而不是更多。

长台词节奏崩溃

症状：演绎开头不错，接近结尾时变得匆忙或平淡。 修复：缩短台词。这是可靠的修复方法，任何提示词措辞都无法补偿。改为在自然边界处拆成多个片段。

密集术语上清晰度下降

症状：产品名、缩写或数字不清晰。 修复：把节奏词从快改为从容；如果某个特定术语仍然错误，考虑在台词中按音标重新拼写——同时承认这会让台词更难读，应作为最后手段。

输出忽略了提示词的一部分

症状：某个整个模块似乎毫无效果。 修复：检查模块冲突。如果主体模块说“穿着正式西装”，而构图模块说“休闲咖啡馆”，模型就必须调和矛盾，可能丢掉某些东西。在假定模型有错之前，先让四个模块彼此一致。

相同运行之间结果不一致

症状：相同提示词，不同输出。 修复：这是预期内的变化，不是提示词 bug。为每个变体在两到三个样本上建立验收标准，当你进入标准范围内时就停止调优。通过提示词措辞追求完美确定性没有生产力。

把提示词当作有版本的资产

活在聊天窗口里的提示词不是可复现的资产。一旦你有了两个配方以及每个配方的几个变体，你就有了源代码——它应该像源代码一样被管理。

把提示词存放在使用它们的代码旁边

在生成脚本所在仓库中保留一个 prompts/ 目录。每个配方一个文件，纯文本或 markdown，四个模块完整且可读。提示词文本应能作为字符串加载，而不是粘贴在函数体里。

命名让名字能预测输出

一个编码意图的命名方案比聪明更有价值：

prompts/
  explainer-single-speaker-v3.txt
  social-hook-closeup-v2.txt
  walkthrough-voiceover-v1.txt

版本后缀不是装饰。当某个模块的改动影响输出时递增它；不要为注释中的拼写错误递增它。

diff 提示词，而不只是二进制

当输出质量变化时，你需要回答“输入中什么变了？”对纯文本提示词做 git diff，一条命令就能回答。嵌入在混有请求参数的 JSON blob 中的提示词则不能。让提示词文本与请求配置分离，这样 diff 保持可读。

把提示词与生成的资产一起固定

当你保存一个生成的片段时，记录是哪个提示词版本产生了它——在文件名、附属元数据文件或资产数据库中。六周后，当有人问为什么系列中的一个片段看起来不同时，答案应该一次查询就能找到，而不是靠猜。

像审查代码变更一样审查提示词变更

改变构图或主体的提示词编辑是一次视觉变更。像 UI 变更一样对待它：开一个 pull request，附上改动前后的样本输出，让另一个人看看。这是捕捉本应被冻结的模块中意外漂移的最廉价方式。

维护一个配方索引

prompts 目录中的一个简短 README，列出每个配方、它的用途以及当前版本，能让每个新贡献者免于反推你的意图。它也是记录已知局限的地方，比如讲解配方中的台词长度上限，这样约束被记录下来，而不是被重新发现。

从平台开始，然后专业化

如果你要把这些配方接入流水线，HiAPI.ai 的 OmniHuman-1.5 视频端点为你提供单一调用接口，这样随着你添加配方，仓库布局和版本方案保持稳定。复制一个配方，用短测试台词运行它，一次改变一个变量，并提交优于你基线的版本——这个循环就是全部方法。