Wan 3.0 到处都能用，但它们真的是同一个产品吗？

Wan 3.0 已经不只是一次模型发布，而是在变成一场分发事件。

阿里云本月早些时候发布了这款模型。它可以接收文字、图片、音频、视频、文档和公开网页，最长生成 30 秒视频。到了 8 月 24 日，fal、Runway 和 OpenRouter 等创作平台与 API 路径又集中宣布接入。对小团队来说，这种扩散很有价值：你可能无需重建产品，就能通过正在使用的工具接入模型、选择不同地区的端点，或在主路径受阻时切换服务。

但名字都叫 Wan 3.0，并不代表这些路径可以直接互换。

有的提供商会默认扩写 prompt，有的会把扩写结果返回给你；有的会提供 seed 和输出尺寸，有的未必提供。上传方式、安全检查、推理地区、排队行为、结果保存时间、重试语义、价格、条款和来源记录，也可能完全不同。甚至一个技术上生成成功的视频，也可能因为改写了产品事实、丢失参考素材细节、凭空增加文字、没有字幕，或等到用户已经离开才完成，而无法成为合格的产品结果。

本文面向正在把生成式视频加入 onboarding、产品演示、营销、教育或创作者工作流的 AI app builder 用户、非技术创始人和小型产品团队。核心判断是：在每一组“模型 + 提供商”组合取得同一份验收凭证之前，都要把它当成一次独立的产品发布。

你将得到一套清晰术语、一组冻结测试、一则完整的假设产品案例、一个“合格交付成本”公式、一份机器可读的提供商验收凭证、故障演练、决策矩阵，以及一套 48 小时上线流程。本文不是 Wan 3.0 benchmark，也不会宣称哪家提供商最好；它要解决的是，某条路径是否真的适合你向用户承诺的那项任务。

先确认发布了什么，也要守住证据边界

Wan 3.0 目前公开的能力范围相当广。阿里云的官方 API 文档列出了文生视频、首帧生视频、首尾帧生视频、参考素材生视频等模式，输入可以来自图片、视频、音频、文件或公开网页。文档说明，任务采用异步形式，通常需要 1–5 分钟，最长可生成 30 秒视频。官方仓库列出的模式基本一致，并称一次请求最多可使用 20 个多模态素材。

这些是产品能力说明，不是独立质量测评。“pixel-perfect consistency”“cinematic realism”“production-grade”等表达仍属于厂商描述。阿里云自己的发布文章也明确说，音频质感和画面文字准确度仍在改进。该页面同时给出了 Model Studio 当时的按秒价格：480P、720P、1080P 分别为每秒 0.05、0.10、0.20 美元。价格和预览阶段行为都可能变化，因此应该记录页面与核验时间，而不是把这些数字永久写进毛利模型。

分发范围扩大，只能证明更容易用到模型，不能证明各条路径在行为上相同。例如，fal 当前的 Wan 3.0 API schema明确暴露了生成音频、prompt 扩写、增强思考、安全检查、时长、画幅和分辨率等默认值；输出 schema 还包括 seed、时长、实际 prompt 和视频元数据。这是一份具体的服务接口契约，却不能证明另一个平台使用相同默认值、模型 revision、安全层、调度器或后处理流程。

所以，创始人今天真正要问的，不是“我能不能用 Wan 3.0”，而是：哪条路径能交付我的真实用户任务，并留下团队能够解释、付费、恢复和重复验证的证据？

把模型身份、服务路径和产品结果分开

先定义四个术语，可以避免大多数“可替代性”误判。

模型身份（model identity），指模型家族，以及在能够获取时更精确的 revision 或 deployment identifier。Wan 3.0 是家族名称，它未必能告诉你每个第三方入口背后的精确权重、构建日期和服务配置。 路径身份（route identity），指提供服务的完整路径：账号、地区、endpoint、model ID、API 版本、默认参数、审核策略、prompt 转换、调度器、文件服务、输出编码和服务条款。两条路径可以展示同一个模型名，却实际接收不同请求、返回不同凭证。 生成尝试（generation attempt），指一次已提交的任务。它可以在 API 层成功结束，却仍然生成不可用素材。尝试次数影响成本和可靠性，但不等于用户价值。 合格交付物（accepted deliverable），指已经通过冻结检查、能够用于承诺渠道的结果。它不只是最终视频，还可能包括字幕文件、文字稿、必要的画面说明、来源记录、事实审批和源素材权利记录。

层级	稳定问题	应保存的证据
模型	请求并返回了哪个模型或 revision？	提供商 model ID、可用时的 revision、请求时间
路径	哪项服务实际处理了任务？	提供商、地区、endpoint/API 版本、策略与默认值
尝试	这次请求经历了什么？	幂等键、task ID、状态、时间、费用与错误
交付	结果是否完成了用户承诺？	输出 digest、验收项、审核人、衍生文件与决策

不要把这四层压缩成一个“Powered by Wan 3.0”徽章。这个徽章无法告诉客服 prompt 是否被扩写，无法告诉财务失败任务是否收费，也无法告诉隐私负责人参考视频经过哪个地区，更无法向用户证明导出视频没有混入未经核验的产品说法。

比较提供商之前，先冻结用户任务

如果每位测试者都随手写不同 prompt，然后只挑最好看的结果，提供商比较就没有意义。第一步应该是定义一项边界清楚的产品任务。

请用用户语言描述它，例如：“把一张已经审批的产品页和三张品牌图片，制作成 15 秒竖版发布视频；必须保持产品颜色准确，不得新增未经证实的功能说法，英文旁白清楚，带字幕，并在 4 分钟内提供可下载 MP4。”这比“做一个不错的宣传视频”更可验证。

接着冻结任务边界：

输入： 精确文件、公开网页快照、prompt、负面约束、语言和素材授权记录。
预期事实： 视频可以使用的产品名、价格、适用地区、尺寸、颜色与功能。
创作自由： 模型可以自由发挥的镜头运动、背景、节奏、装饰性道具和音乐风格。
禁止输出： 无依据说法、竞品标识、未经许可的人物或音乐、无法辨认的必要文字，以及出现在公开资产里的私密源素材。
交付契约： 画幅、时长范围、分辨率、codec、音频、字幕、文件大小上限、截止时间和下载有效期。
验收负责人： 谁可以批准事实、品牌一致性、无障碍和最终发布。

进入小范围 pilot 前，至少准备 20 个 fixture（固定测试样例）：普通输入、信息密集页面、内容稀疏页面、横竖版参考图、非英文文案、难还原的产品色、小字号、静音、快速运动，以及一次提供商报错。面向用户的营销产品，还应增加容易引发事实误读和权利争议的案例。只供内部做灵感草图的工具，则可以使用更轻的测试集，因为失败草稿的后果较小。

这组冻结案例不是公开 benchmark，而是针对你的产品任务形成的证据。如果采样、重复次数、revision、配置、评审方法和不确定性不足，就不要把结果包装成“提供商 A 全面胜过提供商 B”的公开排名。

保存实际生效的请求，而不只是用户输入的 prompt

视频 API 往往会在生成前转换输入。提供商可能扩写短 prompt、自动判断时长、解析文档、读取公开网页、标准化媒体、执行安全过滤，或加入内部生成指令。这些动作可能提高质量，但也改变了你真正测试的对象。

fal 当前的 schema 明确暴露 enable_prompt_expansion、enable_thinking，并在输出中提供 actual_prompt。阿里云 API 则使用结构化的 media 数组，并把参考素材与严格的首帧/尾帧控制分开。仅这两套接口就足以说明：一个只转发 prompt + files 的通用 adapter，并不能完整表达产品请求。

每次生成都应保存：

用户原始请求和 prompt template 版本；
按顺序排列的源素材 ID、用途、digest、授权记录和上传目的地；
每个显式参数，以及产品依赖的每个默认值；
路径能够返回时的实际 prompt 或扩写 prompt；
安全检查结果和策略版本，同时避免不必要地保存敏感内容；
模型与提供商标识、API/client 版本、地区和请求时间；
可获取时的最终 seed 与输出元数据。

不要把 smart duration 当作纯粹便利功能，而要把它视为产品选择。如果客户购买的是 15 秒广告位，自动选择的 23 秒视频即使更好看，也不等价。prompt 扩写也是如此：创意草稿可以允许自动扩写；涉及监管、产品事实或精确脚本的任务，则可能需要关闭扩写，或把扩写结果送审。

即使 API 返回 seed，也不要承诺确定性复现。提供商仍可能更新模型、调度器、审核策略、编码器或基础设施。seed 是 replay 记录里的一个有用字段，却不是明天还能生成完全相同像素的保证书。

把异步任务做成用户看得懂的状态机

视频生成不是一次普通的 request-response。阿里云文档采用“创建任务，再轮询结果”的流程，并说明 task_id 有效期为 24 小时；它还特别提醒，不要因为等待而重复创建任务。fal 则建议长任务使用队列和 webhook。这些运营差异必须进入产品设计，而不是藏在后端 adapter 里。

可以使用以下明确状态：

已接收 → 排队中 → 生成中 → 已生成 → 验收中 → 可交付

以及以下终态：

已拒绝、失败、已过期、已取消、需要人工审核、交付失败。

界面应该告诉用户当前处于哪一状态，以及离开页面是否安全。前端 timeout 不能证明提供商生成失败；此时盲目重试，可能产生两条需要付费的视频。产品边界应先分配幂等键，把它映射到唯一一项有效的提供商任务，并在创建后继任务前，处理迟到的 webhook 或轮询结果。

在提供商 URL 过期前，把完成的视频下载到团队控制的存储中。记录 digest、媒体元数据和来源 task，确认文件能够播放、时长和尺寸符合凭证、要求的音频确实存在，而且交付给用户的衍生版本就是审核人批准的对象。结果 endpoint 返回 200，不等于客户已经收到文件。

这些运营结果应分别统计：

排队时间；
生成时间；
验收时间；
从提交到可交付的总时间；
提供商失败率；
重复生成率；
迟到成功结果的对账率；
交付失败率；
视频可用前的用户离开率。

一条路径即使中位结果非常漂亮，只要长尾等待经常错过用户的真实使用时机，也可能不适合作为产品服务。

必须在真实发布渠道里验收交付物

不要只看提供商的预览窗口。请导出实际需要的 9:16、1:1 或 16:9 版本，按照产品真实流程压缩，在手机上播放，并分别检查有声和静音状态。

建议使用分层验收表：

检查项	要回答的问题	阻断示例
源素材保真	必须保留的人物、产品、颜色和布局是否正确？	产品颜色发生实质变化
事实保真	每项客观说法是否都有已审批事实依据？	凭空增加续航或折扣
叙事	用户不看 prompt，也能理解预期任务吗？	产品出现前就展示 CTA
动态	转场、物理效果、手部、脸部和物体连续性是否合格？	产品在镜头间突然复制
音频	语音是否清楚，音乐和对白是否合适？	品牌名发音错误
文字	必要文案在交付尺寸下是否准确可读？	价格或 URL 变形
安全与权利	同意、肖像、商标、音乐和策略检查是否完成？	出现未批准的真人肖像
无障碍	字幕、文字稿和必要的画面说明是否齐全？	关键信息只存在于无字幕语音
技术交付	codec、尺寸、时长、大小和播放是否通过？	社交平台拒绝该文件
来源记录	能否把输出连接到源素材、转换过程和批准人？	没有素材来源或审核记录

美国 FTC 的广告证据政策指出，企业在传播明确或隐含的客观说法前，应拥有合理依据。映射到产品设计上，结论很简单：一张产品页并不等于允许视频模型自由发挥。应先提取经过审批的事实清单，再逐项检查语音和画面文字；任何未知说法都交给人工处理。

无障碍也属于交付物本身，不是导出后的清理工作。W3C 的音视频无障碍指南覆盖字幕、文字稿、关键视觉信息说明和无障碍播放器。提供商不一定需要生成全部衍生文件，但你的产品承诺必须说明由谁、在哪一步补齐。如果关键信息只由生成式语音说出，导出后又没有字幕，这条视频就无法为许多用户提供完整信息。

计算每个合格交付物的成本

按生成秒数标出的价格只是成本输入之一。按照阿里云发布时公布的价格，一次 30 秒 1080P 尝试为 6 美元；但一条最终被客户采用的视频，可能经历多个草稿、失败任务、高分辨率重跑、字幕纠正、事实审核，以及存储和交付成本。

使用这个运营公式：

合格交付成本 = 所有生成尝试费用 + 辅助模型/API 费用 + 审核人工 + 修改人工 + 存储/交付费用 + 退款/恢复费用

然后用总成本除以合格交付物数量，而不是提交次数。

假设 100 个客户任务产生了 170 次收费尝试，其中 80 条视频自动通过，12 条经过人工修改后通过，5 个任务退款，还有 3 个在统计截止时仍未解决。分母应该是 92 个合格交付物，而不是 100 个任务或 170 次生成。未解决队列必须单独保留，不能为了让报表好看就暗中归入成功或失败。

除金额外，还要统计修改分钟数。某条路径每次便宜 0.80 美元，却额外增加 6 分钟审核，对小团队来说可能更贵。还可以把草稿和成片分成不同档位：用低分辨率选择故事，只让入选草稿进入高分辨率生成。阿里云公开的分辨率价格阶梯让这种策略在其路径上成为可能，但仍需测试低清草稿能否可靠预测最终成片。

不要默认失败请求免费、安全拒绝一定收费，或排队中取消必然退款。应记录提供商实际产生的 billing event，再用 attempt ID 对账账单。如果产品按固定价格向客户收费，而团队仍不知道提供商如何处理失败和取消费用，这条路径就不应该越过 pilot 门槛。

每换一条路径，都要重新核对权利、隐私、地区和来源

多模态视频可能传输比文字 prompt 更敏感的材料：尚未发布的产品页面、客户截图、员工声音、真人参考视频、pitch deck 和品牌素材。增加一个方便的新提供商，也是在增加一条数据路径。

阿里云的地区与部署范围文档把数据存储地区和服务部署范围分开，并说明不同地区的 domain 会影响模型可用性、限制和运营能力。

其 Model Studio 条款则要求客户自行获得必要权利并独立评估输出，同时说明可能发生跨境处理，且未经单独同意不会使用客户内容改进模型。这些条款只适用于对应的合同路径，不能自动复制到 marketplace、转售商或其他提供商身上。

每条路径都要回答：

与我们签约的是哪个主体？还涉及哪些 subprocessor 或底层提供商？
输入、日志、中间素材和输出在哪里存储与处理？
上传文件、任务和结果保留多久？如何删除？
输入或输出是否会用于训练、人工审核、滥用检测或服务改进？
谁可以上传真人脸部、声音、版权作品、私密页面或客户文件？
使用什么审核策略？能否调整？内容被拒绝后如何处理？
谁拥有或可以使用输出？哪些第三方权利仍由我们负责？
是否生成来源元数据？下载与转码后能否保留？

C2PA 的 Content Credentials 2.4 规范提供了一种绑定来源声明的格式，新版也扩展了 live video 支持。凭证可以帮助保留模型、源素材、编辑和签署历史，但无法证明产品说法真实、肖像已经获得同意，也无法保证平台转码后一定保留元数据。因此，即使交付渠道会移除 Content Credentials，也要保存内部验收凭证。

场景：一项“产品页转视频”功能如何选择首条生产路径

假设有一款小应用 LaunchCut，可以把公开产品页、一个 Logo 和三张审批过的图片，转换成 15 秒竖版发布视频。用户能够修改脚本，应用负责生成镜头、旁白、音乐和字幕。

团队发现 Wan 3.0 同时进入多个平台，希望马上加入自动 failover。但他们没有简单地在一个下拉菜单后接入三个提供商名字，而是冻结了 30 项评估任务：

12 个普通软件或消费品页面；
4 个包含价格脚注的页面；
4 个含表格或小字号 UI 的页面；
4 个中文或双语页面；
3 组包含难还原品牌色的参考素材；
2 个已获同意的真人样例；
1 个先 timeout、后来成功的模拟任务。

LaunchCut 会在生成前提取事实清单。视频只能把产品名、批准的功能名、当前价格、可用地区和 CTA 当作事实。背景与镜头运动可以自由创作；竞品 Logo、证言、性能最高级表达和虚构折扣全部禁止。

路径 A 会返回扩写 prompt，生成也更快，但有 5 条视频把带条件的功能描述改成了绝对承诺。路径 B 较慢，每个合格视频的成本也更高，却能更好地保留事实边界。路径 C 的视频质量很好，但它当前的文档输入要求公开 URL，这与 LaunchCut 对私密草稿的承诺冲突。

团队没有选出所谓“全场最佳”。他们决定：路径 B 用于客户最终交付；路径 A 只能生成明确标注、必须编辑并经过事实扫描的草稿；路径 C 则在验证合适的上传与删除契约前，不接受私密文档。若没有任何路径能在截止时间内达标，就退回人工 storyboard。

这只是用来解释决策方法的假设案例，不是真实 YBuild 客户，不是实测提供商对比，也不能作为当前 Wan 3.0 质量证据。

用一份提供商验收凭证统一证据

每组“模型 + 提供商”都保存一份带版本的凭证。未知字段必须继续写 unknown，不能从另一条路径继承一个让人安心的答案。

yaml

video_provider_release:
  product_job: "把已审批产品页制作成 15 秒竖版发布视频"
  model_family: "Wan 3.0"
  provider: "候选提供商"
  provider_model_id: "已记录值"
  api_schema_version: "已记录值"
  region:
    storage: "已核验值或 unknown"
    inference: "已核验值或 unknown"
  request_contract:
    source_asset_digests: ["sha256:..."]
    source_permissions: "receipt-id"
    prompt_template_version: "launchcut-v4"
    prompt_expansion: "on | off | unavailable | unknown"
    effective_prompt_returned: true
    duration_seconds: 15
    aspect_ratio: "9:16"
    resolution: "1080p"
    audio: true
    safety_policy_version: "已核验值或 unknown"
  job_contract:
    product_idempotency_key: "job-..."
    provider_task_id: "task-..."
    terminal_states: ["ready", "rejected", "failed", "expired"]
    late_success_reconciliation: "已测试"
    result_copied_to_owned_storage: true
  acceptance:
    fixture_set: "video-acceptance-2026-08-25"
    claim_fidelity: "pass"
    source_fidelity: "pass"
    motion_audio_text: "pass"
    accessibility_derivatives: "pass"
    technical_delivery: "pass"
    output_sha256: "sha256:..."
    reviewer: "角色，而非敏感姓名"
  economics:
    attempt_charge: "已关联账单"
    total_correction_minutes: 0
    accepted_deliverable_cost: "已计算"
  data_and_rights:
    retention_and_deletion: "已核验合同/资料"
    training_use: "已核验合同/资料"
    likeness_and_source_rights: "receipt-id"
    provenance_preserved: "yes | no | partial | unknown"
  decision: "ship | draft-only | limited | hold | reject"
  recheck_on: ["模型变化", "schema 变化", "策略变化", "条款变化"]

这份凭证不是为了合规表演。产品用它决定 routing；客服用 task 与 output ID 查问题；财务用 attempt 和 invoice 链接对账；审核人使用事实清单与 fixture；隐私负责人查看数据路径；管理者则根据最终决定和复查触发条件控制发布。

主动运行演示视频不会展示的故障

生产上线前，至少强制触发以下故障：

Prompt 转换漂移： 更换提供商或关闭扩写，检查禁止说法是否重新出现。
参考素材顺序漂移： 交换两个源素材，确认 adapter 仍能保留位置含义。
Timeout 后迟到成功： 让客户端先 timeout，再送达 webhook，确认不会创建重复任务。
结果过期： 等到提供商 URL 无效后再尝试下载，验证自有存储或明确恢复路径。
安全策略不一致： 使用一项已经同意但容易触发策略的 fixture，确认用户能看到有用状态，同时不会暴露内部审核细节。
私密素材泄露： 尝试通过公开 URL 字段发送私有页面。产品应该阻止，而不是要求用户把页面公开。
事实条件丢失： 使用带限定价格或地区限制的页面，拒绝任何删掉限定语的视频。
字幕丢失： 转码并发布最终衍生文件，确认字幕或独立无障碍替代内容仍然存在。
提供商 revision 更新： model ID、默认值、client 或策略变化后，重跑冻结测试集。
高负载 failover： 把有限任务路由给备用路径，比较合格产品结果，而不只是成功 HTTP 响应。

这些是面向具体产品的 pre-deployment 证据，并不代表 fixture 已覆盖所有风险。NIST 的生成式 AI 风险管理框架把上线前测试、持续监控、事故学习和记录局限视为相互关联的实践。应保存失败样例，在路径发生实质变化后重跑，而不是从评估集中删掉不好看的结果。

关键失败不能被平均分掩盖。一条路径生成了 9 个漂亮视频，却有 1 条包含未经审批的医疗说法、泄露草稿或重复收费，不能因此获得“90 分，可以上线”的结论。硬阻断项必须与普通质量评分分开。

选择明确的发布姿态，不要假装所有路径都能互换

姿态	适用条件	产品行为
上线	路径通过硬门槛、合格成本与可靠性目标	允许客户交付，并保存凭证
仅草稿	创意价值高，但事实、权利或一致性仍需编辑	明确标注可编辑草稿，不允许直接发布
限定上线	证据只足够支持某种输入、渠道或地区	在 routing 和 UI 中强制执行边界
暂缓	条款、保存期、账单、revision 或故障行为仍未知	继续测试，不接受客户承诺
拒绝	路径未通过硬门槛或无法恢复	从生产 routing 中移除

接入第二家提供商，并不自动得到 fallback。即使 API 很容易集成，它仍要用同一项冻结任务赢得“限定上线”或“上线”资格。反过来，可替代性也不要求两条路径逐像素相同；它要求两者在声明的容差范围内，都能完成同一项产品承诺。

这套框架适合面向客户的生成式视频、产品演示、广告、onboarding、教育、创作者工具和内部品牌生产。对于一次性个人灵感草图，它会显得过重。它也不能证明版权、隐私、广告、无障碍或 AI 法规合规；实际义务仍需由熟悉目标市场与具体内容的负责人判断。

小团队可执行的 48 小时上线流程

第 0–4 小时： 只选择一项产品任务、一个负责人，定义硬阻断、创作自由、交付要求和当前主路径。记录该路径的 model ID、schema、默认值、地区、价格页面、条款和任务生命周期。 第 4–12 小时： 建立 20–30 个冻结 fixture，并为每个 fixture 准备已审批事实清单。记录源素材权利。加入困难案例、一次 timeout、一次安全检查、一次私密来源，以及一次输出过期。 第 12–24 小时： 在主路径和一条候选路径上运行测试。保存实际请求、task event、输出、费用和修改时间。在目标设备和目标渠道中检查最终衍生文件。 第 24–32 小时： 填完提供商验收凭证。把硬阻断和评分项分开，计算合格交付成本和 ready-time 长尾。解决保存期、训练用途、权利和账单中的未知字段；无法解决时，把路径标记为“暂缓”。 第 32–40 小时： 运行迟到成功、防重复、结果复制、字幕、私密来源和 failover 演练。确认客服能从客户 job ID 找到完整尝试记录。 第 40–48 小时： 选择上线、仅草稿、限定上线、暂缓或拒绝。只发布产品能够强制执行的边界。任何模型、API schema、默认值、安全策略、价格、条款或地区变化，都应触发复查。

Wan 3.0 的分发扩张确实有价值。它能减少接入摩擦，也能给小团队更多路径选择。真正的错误，是把“到处可用”误认为“随时可替代”。模型名告诉你该评估什么；提供商验收凭证才告诉你，团队能够负责任地向用户承诺什么。

参考资料