截至 2026 年 6 月 12 日,Seedance 2.0 的人脸问题先是路线和授权问题,然后才是提示词问题。虚构人物、通用职业角色、非可识别参考图可以按普通创作处理;本人脸、员工脸、演员脸或客户脸需要走支持真人验证的路线;明星、公众人物、未经同意的相似脸和“怎么绕过人脸检测”的需求,应当在写提示词前停止。先判定你要用的是哪一种脸,再决定是创作、验证、换路线、处理被拒,还是拒绝这个任务。
| 你要做的人脸请求 | 第一判断 | 安全下一步 |
|---|---|---|
| 虚构人物、通用人物、非可识别角色 | 可以创作 | 提示词保持通用,不暗示真实身份。 |
| 使用自己的可识别人脸 | 需要验证 | 选择支持真人验证的路线,并保留验证记录。 |
| 使用演员、员工、客户或达人脸 | 授权后验证 | 先取得用途授权,再使用真人资产或服务商的验证路线。 |
| 人脸参考图被拒 | 重新分类 | 判断它是虚拟、本人、授权真人、公众人物,还是当前路线不支持。 |
| 明星、公众人物或未经同意的相似脸 | 停止 | 不要改写成近似脸、同款气质或隐藏姓名的绕过请求。 |
| 询问怎样绕过审核 | 停止 | 把任务改成允许的虚拟角色或已验证真人流程。 |
Seedance 2.0 里的“人脸”到底分几类
Seedance 2.0 不是不能画人。ByteDance Seed 的官方模型页把 Seedance 2.0 描述为多模态音视频生成模型,可以使用文本、图像、音频和视频作为参考;官方发布页也强调主体一致性、镜头语言、运动节奏和参考控制。这些能力足以支撑普通的人物视频创作,例如“医院走廊里的年轻医生”“城市街头的虚构采访对象”“广告片里的非特定模特”。
问题出现在“这个脸是否指向某个真实的人”。一张真实员工头像、客户自拍、演员照片、明星脸、网红脸,和一个通用人物氛围图不是同一类输入。前者涉及肖像授权、用途边界、真人验证、素材状态、平台规则和事后删除;后者通常只是创意方向。把这两类输入混在一起,会让团队误以为“支持图片参考”就等于“任何真人脸都能上传”。
更准确的判断方式是把“人脸/肖像”单独拉成一个分支。某条路线可以接受图片参考,但仍然拒绝真人头像;某个服务商可以宣传“已验证真人脸”,但那可能依赖它自己的身份验证和授权系统;模型可以生成非常真实的人物,也仍然会拦截公众人物相似脸或冒充请求。先把脸的归属和授权说清楚,再谈提示词、接口和服务商。
当前可以认真考虑的真人脸路线
如果任务涉及可识别真人,最可靠的方向不是寻找提示词技巧,而是选择一个能说明授权、验证、素材状态和可接受用途的路线。你要知道谁是路线负责人,谁完成了验证,素材现在处于什么状态,以及后续生成结果由谁支持。
| 路线 | 可以支持什么 | 不能证明什么 |
|---|---|---|
| BytePlus 真人资产库 | Seedance 2.0 的第一方真人资产处理,包括演员授权、真人验证、素材上传、审核通过和 Asset ID 使用。 | 不代表所有账号、地区、入口都能直接上传任意真人脸。 |
| ComfyUI Seedance 2.0 真人支持 | 合作节点文档说明一次 ByteDance 真人验证、Group ID 或 Asset ID,以及真人一致性视频流程。 | 证明的是 ComfyUI 这条路线,不是所有公开入口的通用通行证。 |
| HeyGen 等服务商的验证真人路线 | 服务商可能把 Seedance 能力包在自己的同意、身份和素材系统里。 | 服务商说法不是 BytePlus、ComfyUI 或其他入口的第一方证明。 |
| 普通 Seedance 创作 | 虚构人物、非可识别角色、通用人物画面。 | 它不是一个真人肖像授权系统。 |

BytePlus 的真人资产库文档给了一个适合生产团队使用的模型:账号创建授权邀请,演员或权利人完成确认和真人验证,素材上传并通过,最后用 Asset ID 在 Model Playground 或视频生成接口中调用。这个流程的核心不是“把一张脸传进去”,而是把真人脸变成一个有授权、有状态、有路线归属的受控输入。
ComfyUI 的 Seedance 2.0 真人支持文档从工作流角度重复了同一个重点:真人生成需要一次 ByteDance 真人验证,并围绕资产、Group ID 或 Asset ID 工作。如果你走这条路线,就把“ComfyUI 路线”“验证前置条件”“资产编号”“失败时的支持入口”写入项目记录。不要把它改写成“任何公开 API 都能绕过真人限制”。
HeyGen 适合作为服务商路线的例子,但只能按服务商路线理解。它的 Seedance 页面声称自己提供经过验证的人脸支持,并把这件事和公开 API 的真人脸限制区分开。这个说法能解释为什么中文和英文市场里都有人搜索“Seedance 真人脸”“Seedance 人脸过审”,但不能替代你阅读该服务商当前的验证、数据、退款、支持和账号资格条款。
BytePlus 真人资产应按流程使用
如果你计划把真实人物放进视频工作流,BytePlus 的思路可以转化成一个操作清单:授权在前,验证在后,素材状态第三,生成第四。顺序不能反过来。
- 由路线负责人创建授权邀请,明确人物、用途和账号。
- 让演员、员工、客户或权利人阅读用途并完成授权。
- 完成真人验证,例如活体或身份相关检查。
- 按平台要求上传真人素材并等待审核状态。
- 仅在授权用途和支持路线里使用已通过的 Asset ID。
- 保留谁授权、何时授权、允许什么用途、归属哪个账号或路线的记录。
这个流程比“上传自拍试试看”慢,但慢是它的价值。它让制作团队有同意记录,让平台有验证边界,也让开发者有可以排查的素材状态。后续生成失败时,你可以检查路线、账号、资产状态和拒绝信息,而不是猜测到底是脸太像公众人物、验证没完成、服务商不支持,还是当前账号没有权限。
不要把 Asset ID 当成普通参考图链接。已验证真人资产是受治理的输入。如果系统保存提示词、生成视频、源头像或资产编号,还要同时决定访问权限、保留周期、删除请求、客户支持和审计路径。只要素材涉及真实人物,这些问题就必须在生产流程开始前确定。
人脸素材被拒时先分类,不要绕过
人脸参考图被拒,不等于系统在邀请你寻找绕过方法。它更像一个信号:当前输入和当前路线之间有不匹配,需要重新判断脸的类型、授权状态和路线能力。

按下面顺序处理:
| 被拒输入像什么 | 应该怎么做 | 不要怎么做 |
|---|---|---|
| 通用角色草图或非可识别氛围参考 | 简化提示词,去掉像真实身份的描述。 | 加上真人姓名、明星风格或暗示身份的词。 |
| 自己的脸 | 换到支持真人验证的路线并完成检查。 | 反复裁剪、压缩、涂抹自拍直到通过。 |
| 演员、客户或员工脸 | 确认书面授权、路线资格和验证状态。 | 只把聊天里的口头同意当成平台授权。 |
| 明星、公众人物或网红脸 | 停止,或改成清楚的虚构非可识别角色。 | 要求同款五官、近似脸、不要写名字但长得像。 |
| 服务商声称支持真人脸 | 阅读该服务商当前的验证、数据、退款和支持条款。 | 默认同样说法适用于 BytePlus、ComfyUI 或其他入口。 |
| 反复被拒但原因不明 | 用非敏感测试素材复现,并联系路线负责人。 | 继续改提示词规避安全过滤。 |
你的排查记录至少应包括:路线、账号、输入类型、人物是否可识别、是否已授权、是否已验证、准确拒绝信息、已尝试的安全 fallback,以及最终选择是验证、换路线、简化创作还是停止。这个记录可以帮助团队区分正常不支持、账号权限问题、素材状态问题和真实的路线故障。
公众人物和绕过请求应当停止
BytePlus 的内容预过滤 FAQ 提到,系统可能会拦截与公众人物脸、声音或视频相似的输出,目标是降低冒充、欺诈和欺骗性深度伪造风险。这个说明同时也意味着两件事:触发过滤不是提示词挑战;没有触发过滤也不等于平台允许你生成某个公众人物。
BytePlus 视频生成模型服务条款还要求遵守可接受使用规则,并禁止绕过或规避安全过滤。落到生产上,规则很简单:不要写人脸遮挡、明星近似脸、隐藏姓名、分割脸部、降低检测置信度或反复试错的教程。只要任务目标依赖安全边界被绕过,它就不是一个可以继续优化提示词的问题。
如果业务目标是合法的,就换表达方式:使用虚构演员、授权达人、已验证员工、可签约模特,或者完全不可识别的角色。如果目标必须让模型输出某个公众人物、未授权客户、员工或混淆性相似脸,正确答案就是不做。
开发和交付要按可审计流程设计
开发者应该把真人脸生成当成可审计工作流,而不是单次接口调用。即使最终实现只有提交、轮询和取回视频,验收标准也不只是“接口返回成功”。

上线前回答这些问题:
| 检查项 | 生产问题 | 要保留的证据 |
|---|---|---|
| 路线负责人 | 哪个平台或服务商负责这条人脸流程? | URL、账号、条款、支持入口。 |
| 授权记录 | 谁授权了肖像,允许什么用途? | 授权记录、权利人确认、日期。 |
| 验证状态 | 真人资产是已验证,还是只是上传了? | 素材状态、Group ID 或 Asset ID、路线说明。 |
| 输入处理 | 头像、提示词和生成视频如何保存? | 保留周期、访问控制、删除路径。 |
| 测试用例 | 是否先用非敏感素材测试? | 测试提示词、预期结果、失败表现。 |
| 被拒处理 | 人脸被拒时安全 fallback 是什么? | 分类路径、支持工单、换路线或停止决定。 |
| 计费和重试 | 重试和失败尝试由谁承担? | 当前路线的计费说明和任务记录。 |
| 停止规则 | 哪些请求永远不接? | 公众人物、冒充、无授权和绕过过滤规则。 |
把实现问题和人脸边界问题分开。如果下一个任务是提交、查询、取消或下载视频任务,去看当前 BytePlus 开发文档和账号控制台。如果下一个任务是选服务商,比较路线归属、条款、数据处理、支持和计费。如果下一个任务是预算,不要从人脸文章里借价格结论;资源包、免费额度、失败计费和模型 ID 都变化太快,必须单独核验。
关于一般访问路线,可看现有的 Seedance 2.0 访问指南。如果问题其实是该不该换到 2.1,请把版本判断留给 Seedance 2.1 与 Seedance 2.0 对比。人脸决策应继续聚焦肖像、授权、验证、被拒和停止边界。
中文环境里常见的说法是“人脸过审”“不让用真人”“突破限制”。这些词可以帮助你识别问题,但不能直接变成生产动作。更安全的写法是把每个词翻译成可执行检查:所谓“过审”,先问素材是否真实人物、是否已经授权、是否走了支持真人验证的入口;所谓“不让用真人”,先看当前路线是否只接受虚拟或非可识别参考;所谓“突破限制”,通常应改成“换到有授权和验证的路线”或“停止这个肖像请求”。这样团队仍然能回应中文用户的真实痛点,但不会把文章或产品支持写成规避教程。
如果你在团队里负责审核需求,可以把每个真人脸任务拆成四张卡片。第一张是人物卡:本人、员工、演员、客户、公众人物、虚构角色。第二张是证据卡:授权记录、验证状态、素材编号、账号归属。第三张是路线卡:BytePlus、ComfyUI、服务商入口或普通创作入口。第四张是失败卡:被拒信息、重试成本、安全 fallback 和停止理由。四张卡都能填清楚,才进入生成;任一张卡缺关键证据,就先补授权、换路线或暂停。
交付给客户或业务方时,也不要只交一个视频文件。至少附上当前路线名称、素材是否已验证、授权用途、生成日期、失败处理方式和删除/支持入口。对内部团队来说,这些记录能防止同一张脸在另一个项目里被越权复用;对客户来说,它说明这条视频不是靠绕过检测得到的,而是按可解释的路线完成的。后续如果要换服务商、换模型或延展到广告投放,也能重新检查授权是否覆盖新用途,而不是把旧素材默认当成永久可用资产。
第一次安全测试怎么做
如果你不确定路线是否适用,先不要上真实人物素材。用虚构角色、合成参考图或已经批准的内部测试素材,确认该路线能生成你需要的镜头、动作、时长和风格。这样做不会解决真人授权问题,但能先排除普通视频生成能力不足、提示词不稳定或输出规格不合适。
这个测试也能帮助你确认团队真正需要的是人脸一致性、人物动作、镜头语言,还是普通角色画面;需求越清楚,越不容易把所有失败都归咎于“人脸限制”本身问题。
然后再做最小真人测试:一个已验证资产、一个清楚用途、一个短视频输出。记录路线、素材状态、提示词、设置、结果、拒绝行为和支持入口。只有当成功、失败和拒绝路径都清楚后,才把客户、员工、演员或达人素材放进批量生产。
最贵的人脸失败往往不是一次生成失败,而是授权说不清、服务商假设错、支持入口找不到、被拒后反复上传、或者没人能说明某个头像和生成结果该如何删除。把这些边界提前写进流程,比后面追着每个失败任务补证据要便宜得多。
常见问题
Seedance 2.0 能用我自己的脸吗?
可以成为本人脸工作流的一部分,但前提是你选择的路线支持真人验证。不要把上传自拍当成充分条件。使用有同意和验证记录的路线,并保留素材状态、账号和用途记录。
员工、演员或客户的脸可以用吗?
只有在授权清楚且路线支持真人资产或已验证肖像时才可以用于生产。保留授权人、用途、路线负责人、素材状态和支持入口,不要只依赖聊天里的口头同意。
ComfyUI 是不是让 Seedance 2.0 可以做真人脸?
ComfyUI 文档说明了一个具体的 Seedance 2.0 真人支持路线,包括 ByteDance 真人验证和资产处理。它是特定工作流,不应被改写成所有公开入口都支持真人脸。
HeyGen 能证明所有 Seedance 路线都允许真人脸吗?
不能。HeyGen 可以作为服务商自己的已验证真人路线,它的同意和身份系统只证明它自己的产品边界。BytePlus、ComfyUI、其他服务商或原始 API 仍然要分别判断。
为什么我的人脸参考图会被拒?
常见原因包括:输入是可识别真人但路线不支持验证,素材像公众人物,缺少授权,当前账号没有对应资格,或者参考图处理方式不支持。先判断脸的类型和路线,再决定验证、换路线、简化成虚构角色或停止。
不写明星名字,只做相似脸可以吗?
不可以。隐藏名字不会让肖像请求变安全。公众人物、明星、冒充和混淆性近似脸都应停止,或改成明确的虚构非可识别角色。
有没有绕过人脸限制的提示词?
这不是正确的工作流。被拒后应当做分类、授权、验证、服务商复核或停止,而不是寻找规避安全过滤的提示词。
换成 Seedance 2.1 会不会更适合人脸?
不要为了避开真人路线判断而切换版本。版本能力、账号入口和人脸授权是不同问题。先看路线负责人文档和同任务测试;如果真正的问题是 2.1 与 2.0 的取舍,再看单独的版本对比。



