面向文本转视频产品团队的 Seedance API 评估框架

Seedance API 评估应回答一个产品问题，而不只是生成一段令人印象深刻的演示视频。真正需要决定的是，你的团队能否以可预测的质量、延迟、安全性和成本，将提示词与参考媒体转化为可接受的视频资产。

截至2026年7月29日，Flatkey 将 seedance-2.5 列为面向文本转视频和图像转视频生成、支持 1080p 输出的 ByteDance 早期访问路线。当前请求模式是异步的：使用 POST /v1/video/generations 创建视频任务，保留返回的任务 ID，并通过轮询 GET /v1/videos/{task_id} 直到作业进入终态。

这个 API 合同很直接。要设计一个有用的Seedance API 评估则要困难得多。本指南为产品经理和工程负责人提供了一套可重复的测试集、一个加权评分卡、一个已接受片段成本指标，以及一个为期五天的上线计划。

快速答案：Seedance API 评估应衡量什么？

从六个门槛评估该 API：

1. 能力匹配：它能否生成你的产品所需的场景、运动、构图和参考一致性？
2. 可重复性：同一类提示词在多次运行中是否都能产生可用结果？
3. 工作流匹配：你的应用能否干净地处理异步任务、轮询、超时、存储和重试？
4. 用户体验匹配：你能否就等待、进度、重新生成和失败设定诚实的预期？
5. 安全性匹配：你的产品能否阻止不允许的输入，并在分发前审查输出？
6. 单位经济性匹配：在包含失败作业和被拒绝输出后，一段被接受的视频片段成本是多少？

不要只根据一次精心挑选的生成结果就批准某个提供商。一个有用的Seedance API 评估应使用固定的提示词集合、重复运行、盲评打分，以及对每个候选模型都相同的验收规则。

从当前 Seedance API 合同开始

Flatkey 当前的 seedance-2.5 模型页面描述了一条早期访问路线，支持提示词输入、可选图片，以及以 MP4 URL 作为完成输出。页面示例创建了一个时长五秒、1080p 的任务：

curl -X POST https://router.flatkey.ai/v1/video/generations \
  -H "Authorization: Bearer $FLATKEY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "seedance-2.5",
    "content": [
      {
        "type": "text",
        "text": "A paper airplane flying over a neon city at dusk"
      }
    ],
    "resolution": "1080p",
    "duration": 5
  }'

然后使用返回的 ID 轮询该任务：

curl https://router.flatkey.ai/v1/videos/TASK_ID \
  -H "Authorization: Bearer $FLATKEY_API_KEY"

在实施之前，请查看最新的 Seedance 2.5 模型页面，因为在早期访问期间，可用性、请求字段和商业条款都可能发生变化。

如果你的团队还没有验证密钥和基础 URL，请先完成现有的 Seedance API 快速入门。待连通性正常、产品团队也准备好判断这条路径是否适合真实用例后，再阅读本文。

在生成片段之前定义评估契约

在 Seedance API 评估中，最具杠杆作用的一步，是在任何人看到结果之前先达成验收契约。否则，利益相关方往往会偏爱看起来最有电影感的那个片段，并在不同轮次之间悄悄改变标准。

写下以下字段：

验收负责人应尽量贴近最终工作流。增长创意负责人可能会接受一个产品渲染团队会拒绝的片段，因为产品形状发生了变化。单一的通用质量分数无法代表所有用例。

构建一个包含 24 个提示词的 Seedance API 测试集

一个实用的测试集，规模要足以暴露失败模式，但也要足够小，便于在路由、提示词模板或模型变更时重复执行。先从 24 个提示词开始，覆盖六个组别。

只要预算允许，每个提示词至少运行三次。一次运行用于测试可行性；重复运行则用于测试你的产品是否可以依赖这种行为。

保持提示词与提供方无关。除非该功能本身就是评估的一部分，否则不要使用只有某一个模型才能理解的提示语法。为每次运行保存提示词、请求参数、任务 ID、时间戳、终态、输出 URL，以及审核员评分。

字节跳动公开的 Seedance 研究强调了指令遵循、运动质量、时间一致性、多镜头叙事和视觉质量等维度。这些都是有用的评估类别，但你的团队应将它们转化为可观察的产品需求，而不是直接照搬研究基准。

使用加权的 Seedance API 评估评分卡

下面的评分卡可作为通用文本转视频产品的起点。在测试前，如果你的用例有不同优先级，请先调整权重。

对每个质量维度按 1 到 5 分评分，再乘以其权重，并将结果归一化到 100。像延迟和完成率这样的运营指标，应直接测量，而不是凭记忆打分。

为了进行公平的 Seedance API 评估，在比较多个模型时，审核员不应知道每个片段由哪个提供方生成。随机化文件名，从审核表中移除提供方元数据，并且在评分完成后再公开模型。

衡量每个被接受片段的成本，而不是每次生成的成本

最有用的视频生成成本指标是：

每个被接受片段的成本 = 总生成支出 / 被接受片段数

如果 30 个任务花费 60 美元，而只有 12 个输出通过审核，那么有效成本就是每个被接受片段 5 美元——而不是每次生成 2 美元。

还应跟踪：

接受率 = 被接受片段数 / 已完成片段数

完成率 = 已完成片段数 / 已提交任务数

每个已发布资产的成本 = 总生成支出 / 实际发布的资产数

这可以防止一条便宜但不稳定的路径，看起来比一条成本更高但更频繁产出可用结果的路径更优。它还将模型评估与团队实际的创意产出或产品吞吐量联系起来。

Flatkey 目前将 seedance-2.5 作为按使用量计费的早期访问版本提供。请使用实时的模型目录和定价页面获取当前商业信息，而不要把静态数值直接复制到规划表格中。

通过一个适配器规范异步工作流

你的产品不应在整个代码库中暴露特定于提供商的任务状态。将 Seedance API 放在一个小型视频生成适配器之后，并对生命周期进行规范化。

type VideoJobState =
  | "queued"
  | "processing"
  | "succeeded"
  | "failed"
  | "expired";

type VideoJob = {
  id: string;
  state: VideoJobState;
  outputUrl?: string;
  errorCode?: string;
  submittedAt: string;
  completedAt?: string;
};

interface VideoGenerationAdapter {
  create(input: {
    prompt: string;
    imageUrl?: string;
    duration: number;
    resolution: string;
  }): Promise<VideoJob>;

  get(jobId: string): Promise<VideoJob>;
}

该适配器应保留提供商任务 ID、原始终态、请求参数以及使用数据，以便调试。产品的其余部分应依赖规范化后的状态。

这个边界让 Seedance API 评估更加真实。你可以在不重写产品流程的情况下，将 Seedance 的质量和运维表现与另一条视频路径进行比较。它还为你提供了一个可控位置，用于实现轮询间隔、超时预算、重试规则、webhook 验证和迁移逻辑。

如需更深入的实现模式，请参阅 面向 Seedance API 团队的稳定 OpenAI 兼容 Base URL 指南。在上线前，请先执行单独的 Seedance API 生产检查清单，涵盖队列持久性、幂等性、存储和事故控制。

将 API 行为映射到产品体验

异步视频路径会带来同步文本端点所没有的用户体验决策。

等待状态

展示请求已被接受，并提供一个持久的任务引用。除非 API 暴露了可信的进度信息，否则不要暗示视频已经接近完成。

超时状态

将慢任务与失败任务区分开来。客户端超时不应自动创建第二次可计费的生成。在允许重试之前，继续检查原始任务。

重新生成

让用户一次只更改一个变量——提示词、参考图像、时长或分辨率——这样团队就能了解结果为什么变好或变差。

输出审查

将提示词和参数与视频片段一起存储。在生成资源进入公开或面向客户的工作流之前，先提供一个内部审查状态。

失败提示文案

将提供商失败转换为可操作的产品消息：不支持的输入、安全拦截、临时容量不足、资源过期或可重试的服务错误。为支持和工程团队保留原始代码。

在 Seedance API 评估 中包含这些 UX 状态。即使某个模型能生成出色的片段，如果其延迟和失败行为无法被清晰地说明，它也可能不是一个合适的产品选择。

将安全与内容审核纳入评估

文本转视频的输入和输出应通过产品特定的控制。至少应当：

• 验证输入媒体类型、大小和来源；
• 在创建付费任务之前拒绝明显不允许或不受支持的请求；
• 记录是谁提交了请求以及适用了哪个政策版本；
• 在公开分发前扫描或审核已完成的输出；
• 为提示词、参考素材和生成文件定义保留与删除规则；
• 防止临时签名 URL 变成产品的永久资产记录。

不要假设提供商的安全层就等同于你的产品政策。你的应用仍然有责任决定用户可以请求什么，以及哪些生成内容可以被存储、展示或发布。

进行为期五天的产品团队评估

第 1 天：锁定契约

选择工作流、验收负责人、24 条提示词、参数、评分权重和最大预算。核实 Seedance 2.5 模型页面上的当前访问权限。

第 2 天：实现适配器

创建任务、持久化任务 ID、安全轮询、规范化状态并存储输出。确认被中断的客户端会话不会丢失该任务。

第 3 天：生成固定测试集

在受控参数下运行同一组提示词。记录每一次请求，包括失败和评审者立即拒绝的输出。

第 4 天：盲评打分

至少让两位评审者独立为这些片段打分。计算接受率、完成率、到达终态的 p50 和 p95 时间、加权质量分以及每个被接受片段的成本。

第 5 天：做出决定并记录

批准以下四种结果之一：

1. 进入有限 beta，针对已测试的工作流。
2. 在限制条件下推进，限制提示词类型、时长、参考输入或用户群组。
3. 继续评估，采用修订后的提示词或更大的样本量。
4. 不继续推进，因为质量、运营、安全或单位经济性未达到约定阈值。

这种五天结构可避免 Seedance API 评估 演变为无边界的创意实验。

示例性的 go/no-go 阈值

在测试前设定阈值。一个假设的产品团队可能要求：

这些都是示例，而不是通用基准。故事板工具可以容忍比自动化产品广告工作流更低的保真度。其价值在于预先设定可衡量的阈值。

What makes this evaluation reusable?

将提示集、评分卡、适配器和结果数据集一起版本化。当访问权限发生变化或出现新的 Seedance 路由时，重新运行同一套包。

保留这些工件：

• 提示集版本；
• 请求 schema 版本；
• 模型和路由 ID；
• 生成参数；
• 原始任务生命周期时间戳；
• 评审者 ID 和盲评得分；
• 接受决定和拒绝原因；
• 成本和使用记录；
• 策略版本；
• 最终 go/no-go 决策。

这会将 Seedance API evaluation 变成一个持久的模型运营资产，而不是一次性的发布文档。当你的产品在一个访问层之后对比视频、图像、音频和语言模型时，同样的结构也支持更广泛的 多模态模型路由。

Final recommendation

只有当 Seedance API 通过了你的工作流验收契约时才使用它——而不是因为某个生成的片段看起来令人印象深刻。验证当前路由，测试固定提示集，盲评输出，把失败纳入单元经济，并将异步生命周期置于适配器之后。

对于 Flatkey 用户，实际流程是：

1. 使用 Seedance API quickstart 验证密钥和路由器；
2. 在 live model page 确认当前 seedance-2.5 访问权限和请求字段；
3. 在本指南中运行评分卡；
4. 在面向客户上线之前完成 production checklist。

严格的 Seedance API evaluation 能为产品、工程、创意、安全和财务团队提供一个共同答案：该路由是否能够可靠地产生适合你实际计划交付的工作流所需的可接受视频。

FAQ

Is Seedance API synchronous or asynchronous?

Flatkey 当前的 seedance-2.5 示例使用异步工作流。应用会创建一个视频任务，保存返回的任务 ID，并轮询视频任务端点以等待完成。

What is the most important Seedance API evaluation metric?

对于大多数产品团队来说，最重要的是每个被接受片段的成本，因为该指标同时包含生成支出和输出可用性。应将其与接受率、完成率、延迟和加权质量分数配合使用。

How many prompts should a product team test?

跨六个行为组的二十四个提示词是一个实用的起点。当预算允许时，对每个提示词运行多次，这样评估衡量的是可重复性，而不是可能性。

Should reviewers know which model produced each clip?

不应该，至少在比较提供商或模型版本时不应该。盲评可以减少品牌偏好和确认偏差。

Does Seedance 2.5 support image-to-video?

Flatkey 的实时模型页面目前列出了用于文本转视频和图像转视频的 seedance-2.5，并支持可选的图像输入。由于它标记为抢先体验，请在实施前确认当前路由和字段。

产品是否应自动重试超时的视频请求？

不要立即创建新的任务。首先检查现有的任务 ID。客户端超时并不能证明提供方任务已失败，而自动重新提交可能会造成重复工作和额外消耗。

Seedance API 评估何时算完成？

当团队已经根据测试前商定的阈值，衡量了质量、重复一致性、完成可靠性、可用输出所需时间、安全处理以及每个被接受片段的成本时，评估就算完成。