MiniMax H3 参考视频怎么用：只借运镜不照抄，附实测请求和账单

MiniMax H3 的参考视频不会自己判断该借什么：只丢一段视频、再写新场景，成片常常把原片的人物和场景一起搬过来。想只借运镜或动作，就在提示词里给参考视频一个明确的任务，紧接着列出不要照搬的人物、服装、动物和场景，再把新画面的主体、地点和光线完整写出来。请求里只放一条 text 和 role 为 reference_video 的 video_url，不要同时放 first_frame 或 last_frame，两者在 API 里互斥。

2026 年 11 月 2 日用这种写法跑过一次：线路是 LaoZhang（它用 MiniMax 开源的 H3 权重自建部署，不经 MiniMax 官方 API），参考片是 MiniMax 官方示例里一段 6.06 秒的手持缓推镜头，拍的是抱着黑色小羊、穿粉色西装的男人。生成的 4 秒 768P 视频 45 秒出片，画面换成了码头上穿黄雨衣的老渔夫，粉色西装、小羊和草地都没有出现，镜头保留了轻微推近加横移。账单是 (4 + 7) × $0.05 = $0.55，6.06 秒的参考片按 7 秒计。这只是一个样本，不保证每次都分得这么干净。

提交前先守住规格：参考视频最多 3 段，每段 2–15 秒，合计不超过 15 秒。越界的请求不一定在提交时报错，同一天两段合计 18.95 秒的请求先被接受，约 3 秒后以 "temporary service error … Please retry" 失败，问题出在素材，不在服务。另外，如果你要改的就是参考视频本身，或者要接着它往下拍，那属于视频编辑或续写，写法和"只借运镜"不同，下面分开讲。

参考生视频、参考转视频、Ref2VA：MiniMax H3 里是同一个模式

MiniMax 官方 API 给 H3 分了三种模式：文生视频、图生视频（首帧和/或尾帧）和参考生视频。参考生视频就是"提示词 + 参考图片、视频或音频"，官方列出的典型用途是参考角色、动作、运镜、风格、音色或剪辑节奏，输出 768P 或 2K、4–15 秒的整数秒视频（MiniMax 视频生成指南，截至 2026 年 11 月 2 日）。官方中文文档叫它"多模态参考生视频"，英文是 Reference Generation；ComfyUI 中文文档把对应节点译成"参考转视频"；Hugging Face 上的开源权重叫 Ref2VA，API 示例和 SGLang 参数里写作 r2va、ref2va。这些名字说的是同一件事。H3 属于海螺系列，排在 Hailuo 01、02 之后，在海螺 App 里也能选 H3 加参考视频生成。

参考视频能做的事有边界。它不是逐像素对齐的编辑，开源实现里也没有"重绘强度"这类参数，所以"保留原片九成、只改一点"这种比例控制不了（MiniMax H3 模型卡）。官方 API 规定图生视频和参考生视频互斥，带了任何参考素材就不能再放首帧或尾帧，而且每个请求都必须有一条非空文本（MiniMax 创建视频生成任务 API 文档）。

同一个端点下的 MiniMax-H3、MiniMax-H3-Highspeed、MiniMax-H3-Lite 和 MiniMax-H3-Max 在 API 文档里都支持参考图片、视频和音频；其中只有 MiniMax-H3 能出 2K，MiniMax-H3-Max 的时长下限是 5 秒。还没决定用不用 H3 的话，先看Wan 3.0、MiniMax H3、Seedance 2.5 怎么选：先看交付约束。

参考视频负责什么：运镜、动作、原片编辑、续写还是声音

先决定参考视频在这次生成里的角色，因为不同角色的提示词写法不同，写错了就会照抄或不起作用。MiniMax 在 Hugging Face 上发布的参考模式提示词指南把这类任务分成 reference generation（参考生成）、video editing（视频编辑）、video continuation（续写）、audio reuse 和 audio reference 几类，并且写明：只提供运镜、剪辑或节奏的参考视频，通常属于 reference generation（MiniMax H3 参考模式提示词写作指南）。

指南里还有两条规则能解释"照抄"从哪来。第一，<Video N> 这个写法留给"整段视频"层面的关系，比如编辑原片、续写、参考它的运镜、剪辑和节奏；如果你要的是视频里的某个人或物，指南会把它定义成单独的主体 <Subject N>，例如"<Subject 1> 是一位女性，外貌来自 <Picture 1>，走路的动作来自 <Video 1>"。第二，它用 fully_preserved、partially_preserved、attribute_transfer、weak_reference 几个标记区分保留程度，其中 attribute_transfer 指把参考里的特征转移到另一个可识别的主体身上，正是"借动作、换人"的情况。这些标记是 H3 改写提示词时用的结构，你自己写普通句子也能用，关键是把"借什么、不借什么"说出来。

指南还写了一句容易被忽略的话：普通参考视频不会仅仅因为文件里有声音，就变成音频参考。想用它的声音，要另外处理，详见文末的问答。

参考视频规格：最多 3 段，每段 2–15 秒，合计不超过 15 秒

截至 2026 年 11 月 2 日，MiniMax 官方 API 文档对参考视频的限制如下。合计 15 秒说的是所有参考视频加起来，和输出视频的 4–15 秒是两回事；参考生视频的 ratio 可以不填，默认是 adaptive，也可以指定 21:9、16:9、4:3、1:1、3:4、9:16（MiniMax-H3-Lite 暂不支持 adaptive）。

提示词本身最长 7,000 字符。这些数字来自 MiniMax 视频生成指南和 API 文档，海螺 App 的界面文字给的也是"最多 3 段视频、合计 15 秒、每段至少 2 秒"。

写请求和提示词：参考视频的任务、排除项、新场景各写一句

请求和提示词的写法可以归成一句话：参考视频负责什么写一句，哪些东西不要带过来写一句，新画面是什么写完整。下面按提交顺序列出步骤，第 4 步的请求体就是 11 月 2 日实测用的那一份。

1. 给每段参考视频只派一个任务。对照上一节的表格，决定它负责运镜、动作、原片编辑、续写还是声音。DomoAI 的 MiniMax H3 参考生视频指南建议一段素材只管一件事，例如"Video 1 只控制动作和运镜，忽略其中的表演者和场景"。
2. 按你用的线路选对指代写法。不同平台提示词里叫参考视频的方式不一样，见下表；写错不一定报错，但模型可能对不上是哪一段。
3. 写提示词的三部分。先写任务（"只用 reference video 1 的运镜：缓慢的手持推镜，围绕主体轻微横移"），再写排除项（"不要照搬 reference video 1 里的人物、服装、动物和草地"），最后写新场景的主体、动作、地点、时间和天气。新场景写得越具体，模型越没有理由回到原片找内容。
4. 组请求体：content 里放一条 text 和一条 video_url，role 设为 reference_video；不要加 first_frame 或 last_frame；写明 resolution、duration，需要固定画幅时写 ratio。
5. 提交后拿 task_id 轮询，官方建议每 10 秒查一次，成功后视频链接在 task.content.url。

实测那次在 LaoZhang 线路上用的是官方文档的自然语言写法 reference video 1，没有用它文档里的 <Video 1> 标签，任务照样按意图完成。只有一段参考视频时两种写法都不容易混淆；同时有多段视频和图片时，按你所用平台的文档写更稳妥。

export LAOZHANG_API_KEY="你的令牌"
export BASE_URL="https://api.laozhang.ai"

curl -s -X POST "$BASE_URL/hailuo/v2/video_generation" \
  -H "Authorization: Bearer $LAOZHANG_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MiniMax-H3",
    "content": [
      {
        "type": "text",
        "text": "Use reference video 1 only for its camera movement: a slow handheld push-in that drifts slightly around the subject. Do not copy the person, clothing, animals or field from reference video 1. New scene: an elderly fisherman in a yellow raincoat mends a net on a wooden pier at dawn, light rain, sea in the background."
      },
      {
        "type": "video_url",
        "role": "reference_video",
        "video_url": {
          "url": "https://cdn.hailuoai.com/prod/hailuo_demo/testsets/h3_promo_eval_ref2va/gallery/sr_v2p26_trio_seed42_20260724/inputs/297573323635_00_%E8%A7%86%E9%A2%911_YnyRbxEwio_video_20260525_163755_1927e9d3.mp4"
        }
      }
    ],
    "resolution": "768P",
    "duration": 4,
    "ratio": "16:9"
  }'

# 返回 {"task_id": "..."}，每 10 秒查询一次
curl -s "$BASE_URL/hailuo/v2/query/video_generation/$TASK_ID" \
  -H "Authorization: Bearer $LAOZHANG_API_KEY"

走 MiniMax 官方 API 时，请求体不用改，把地址换成 https://api.minimax.io/v2/video_generation，查询换成 /v2/query/video_generation/{task_id}，并使用 MiniMax 按量计费（Pay-as-you-go）的 API 密钥。

如果成片还是照抄了参考片，RunDiffusion 的 MiniMax H3 提示词指南给的办法是：再明确一次参考视频只提供动作或运镜，并把不要照搬的东西逐项列出来。动作没有迁移过去时，换一段干净、只有一个动作的素材，写成"把 Video 1 里的 [动作] 转移到 Image 1 的角色身上"；多段参考一起用效果乱时，一段一段地加，确认每加一段都起作用。

2026 年 11 月 2 日实测：只借运镜，45 秒出片，账单 $0.55

这次测试走的是 LaoZhang 的 /hailuo/v2/video_generation 接口，按它的文档，这个接口用 MiniMax 开源的 H3 权重独立部署，不经 MiniMax 官方 API，当时的价格是 768P 每秒 $0.05，参考视频按输出分辨率的每秒单价计，不足 1 秒按 1 秒算。用的是 default 分组、按量计费的令牌，模型 MiniMax-H3，768P、4 秒、16:9，请求体就是上一节的那一份。参考片取自 MiniMax 官方 API 文档里的示例素材：6.06 秒，1920×1080，24 fps，H.264 + AAC，4.4 MB，内容是草坡上一个穿粉色西装、抱着黑色小羊的男人，镜头手持缓慢推近。

任务在 UTC 15:54:50 提交，任务 ID 1793634889518010650。按 10 秒间隔轮询，第 11、22、33 秒都是 running，第 45 秒变成 succeeded；服务端记录的创建到完成时间是 26 秒。查询结果里的 usage 是 total_seconds 11、input_seconds 7、output_seconds 4，账户用量正好增加 55 美分，也就是 (4 + 7) × $0.05 = $0.55。输出文件是 1344×768、24 fps、4.46 秒的 H.264 视频，带 32 kHz 的 AAC 立体声，3.5 MB。

按每秒一帧抽图看，画面是黎明时分木码头上穿黄色雨衣、戴安全帽的老渔夫和背后的海面；参考片里的粉色西装、黑色小羊和草坡都没有出现。镜头方面，主体从画面左侧三分之一处逐渐移向中间并略微变大，是一个带横向漂移的轻微推近，和参考片的运镜一致。提示词里的小雨在画面上看不太出来。

这个结果只有一次运行、一条提示词、一段参考片，画面判断也是目测，不能当作"H3 总能把人物和运镜分开"的保证。另外，下载成片时 CDN 拒绝了 Python urllib 默认的 User-Agent（返回 403），换成带浏览器 User-Agent 的 curl 才下载成功，自己写脚本下载时注意这一点。

提示"临时服务错误"却重试无效：越界请求在哪一步失败

参考视频越界时有两种失败方式：一种在提交时直接返回 HTTP 400，另一种先返回 200 和任务 ID，几秒后再失败，报错文字却写着"临时服务错误，请重试"。后一种最误导人。2026 年 11 月 2 日在 LaoZhang 线路上（768P、4 秒、16:9）逐项试过下面这些输入，两种失败都没有扣费。

两个先接受后失败的任务，在创建时各预扣了 4 秒 × $0.05 = 20 美分，失败后全部退回，账户用量回到提交前的数值。几分钟后提交的合规请求正常成功，所以合计 18.95 秒那一项失败的原因是素材越界，不是服务临时出问题。同样的越界请求没有重试过，但按这个结果推断，重试大概率还是同样失败。1.5 秒那一项同时用了 Base64 传输和过短的片段，分不清是哪个原因触发的。

Atlas Cloud 在 2026 年 8 月 12 日发布的测试里，它自己的接口对所有错误请求都先返回 200，错误在两三分钟后的生成阶段才出现；首帧加参考素材没有报错，而是静默丢掉其中一个输入并照常扣费；两段约 8 秒、合计 16.1 秒的参考音频超过了 15 秒的音频合计上限，也照常完成并扣费，参考视频合计超限的情况它没有测（Atlas Cloud 的 MiniMax H3 参考生视频规则测试）。这份报告已经是三个月前的，和 LaoZhang 线路的结果也对不上，能确定的只有一点：各条线路的校验方式不同，越界请求可能被拒、可能失败、也可能被悄悄改写后照样收费。按文档规格在本地预检，比依赖某条线路替你拦截可靠。

提交前用 ffprobe 预检：超长片段剪成整 6 秒

预检要做的是在提交前把文档里的硬性规格过一遍，并顺便算出参考视频会按几秒计费。下面这个脚本基于 ffprobe，检查段数、单段和合计时长、容器、编码、文件大小、边长、宽高比和帧率，计费秒数按向上取整打印。它只检查公开写明的规格，预测不了成片质量，也预测不了内容审核。

#!/usr/bin/env python3
"""提交前检查 MiniMax H3 参考视频：<=3 段，每段 2-15 秒，合计 <=15 秒，
MP4/MOV，H.264/H.265，<=50 MB，每边 256-5760 px，宽高比 0.4-2.5，23.976-60 fps。"""
import json, math, subprocess, sys

def probe(path):
    out = subprocess.run(["ffprobe", "-v", "error", "-show_entries",
        "format=duration,size,format_name:stream=codec_type,codec_name,width,height,avg_frame_rate",
        "-of", "json", path], capture_output=True, text=True, check=True).stdout
    return json.loads(out)

def check(paths):
    problems, total = [], 0.0
    if len(paths) > 3:
        problems.append(f"{len(paths)} clips: H3 accepts at most 3 reference videos")
    for p in paths:
        info = probe(p)
        fmt = info["format"]
        v = next(s for s in info["streams"] if s["codec_type"] == "video")
        dur, size_mb = float(fmt["duration"]), int(fmt["size"]) / 1e6
        num, den = map(int, v["avg_frame_rate"].split("/"))
        fps = num / den if den else 0
        w, h = v["width"], v["height"]
        total += dur
        print(f"{p}: {dur:.2f}s (billed {math.ceil(dur)}s), {w}x{h}, {fps:.3f} fps, "
              f"{v['codec_name']}, {size_mb:.1f} MB")
        if not 2 <= dur <= 15: problems.append(f"{p}: {dur:.2f}s is outside 2-15 s")
        if v["codec_name"] not in ("h264", "hevc"): problems.append(f"{p}: codec {v['codec_name']} is not H.264/H.265")
        if not ("mp4" in fmt["format_name"] or "mov" in fmt["format_name"]): problems.append(f"{p}: container is not MP4/MOV")
        if size_mb > 50: problems.append(f"{p}: {size_mb:.1f} MB is over 50 MB")
        if not (256 <= w <= 5760 and 256 <= h <= 5760): problems.append(f"{p}: {w}x{h} outside 256-5760 px")
        if not 0.4 <= w / h <= 2.5: problems.append(f"{p}: aspect ratio {w/h:.2f} outside 0.4-2.5")
        if not 23.976 <= round(fps, 3) <= 60: problems.append(f"{p}: {fps:.2f} fps outside 23.976-60")
    if total > 15: problems.append(f"total {total:.2f}s is over 15 s")
    print(f"total reference length {total:.2f}s")
    print("OK" if not problems else "FIX BEFORE SUBMITTING:\n- " + "\n- ".join(problems))
    return not problems

if __name__ == "__main__":
    sys.exit(0 if check(sys.argv[1:]) else 1)

用法是 python3 h3_ref_check.py a.mp4 b.mp4，通过时退出码为 0。2026 年 11 月 2 日在 macOS 26.1、ffprobe 9.0.2 上，用上面实测和失败对照里的几段素材各跑了一次：

ref-video.mp4: 6.06s (billed 7s), 1920x1080, 24.000 fps, h264, 4.4 MB
OK

short-1.5s.mp4: 1.50s (billed 2s), 640x360, 24.000 fps, h264, 0.1 MB
FIX BEFORE SUBMITTING:
- short-1.5s.mp4: 1.50s is outside 2-15 s

dance.mp4: 9.47s (billed 10s), 1080x1922, 30.000 fps, h264, 12.2 MB
dance.mp4: 9.47s (billed 10s), 1080x1922, 30.000 fps, h264, 12.2 MB
total reference length 18.95s
FIX BEFORE SUBMITTING:
- total 18.95s is over 15 s

合计超了 15 秒时，把其中一段剪短再交。下面的命令从第 1 秒开始截取 6 秒并重新编码，重新编码能让时长落在整数秒上，单纯复制流（-c copy）会受关键帧位置影响，剪出来的时长不一定正好：

ffmpeg -ss 1 -i dance.mp4 -t 6 -c:v libx264 -crf 20 -preset veryfast -c:a aac dance-6s.mp4

剪完的 dance-6s.mp4 是 6.00 秒、3.3 MB，计费秒数 6；和 6.06 秒的推镜片一起检查，合计 12.06 秒，结果为 OK。按不足 1 秒按 1 秒计的规则，6.06 秒的片段要付 7 秒，剪到整 6 秒就只付 6 秒。

参考视频怎么收费：输出秒数加参考视频秒数

参考视频本身要按秒收费，费用是（输出秒数 + 参考视频秒数）× 输出分辨率的每秒单价。截至 2026 年 11 月 2 日，MiniMax 按量计费价格页写的是"视频输入按输入时长、以所选模型的输出分辨率计费"：MiniMax-H3 768P 的输出和参考视频都是每秒 $0.08，2K 都是每秒 $0.13；每个任务前 5 张参考图免费，之后每张 $0.04；参考音频免费。

MiniMax-H3-Max 是唯一的例外，它的参考视频比输出更贵：768P 输出每秒 $0.08，参考视频每秒 $0.143；480P 输出每秒 $0.05，参考视频每秒 $0.0553；参考图只免费 2 张。拿一个 5 秒的 768P 任务配 6 秒参考视频来算，MiniMax-H3-Max 是 5 × $0.08 + 6 × $0.143 = $1.258，同样输入在 MiniMax-H3 768P 上是 (5 + 6) × $0.08 = $0.88。

把前面实测的 4 秒 768P 输出放到不同线路上算：LaoZhang 线路实际扣了 (4 + 7) × $0.05 = $0.55，换成剪好的 6.00 秒片段是 (4 + 6) × $0.05 = $0.50。官方 API 用 6.00 秒片段，768P 是 (4 + 6) × $0.08 = $0.80，2K 是 (4 + 6) × $0.13 = $1.30。官方价格页没有写参考视频秒数怎么取整，如果像 LaoZhang 一样向上取整，6.06 秒的原片在官方 768P 上会是 (4 + 7) × $0.08 = $0.88，这个数是推算。

其他平台的计费方式差别很大。fal 的 H3 基础版不另收参考视频费，按输出分辨率每秒计价；fal 的 H3 Max 版按 token 计参考素材，每个请求免费 4,096 个，之后每千个 $0.02，一段 5 秒、24 fps、16:9 的参考片在 768P 下是 32,256 个 token，约多付 $0.56（fal 上的 MiniMax H3 Max 参考生视频页面）。LaoZhang 线路在创建任务时先预扣输出秒数的费用，参考视频的秒数在任务完成后结算，失败任务全额退回。各家视频模型每秒多少钱，见AI 视频生成要多少钱：每秒价格、订阅与成片成本。

ComfyUI 本地跑 Ref2VA：参考视频按 24 fps 读，超长部分被截掉

在 ComfyUI 里用开源权重跑参考视频，参考素材在提示词里用 <Picture i>、<Video k>、<Audio j> 指代，按类型从 1 开始编号，最多 3 段参考视频、每段 2–15 秒。下面几条是 ComfyUI 的 MiniMax H3 参考转视频节点文档、ComfyUI 的 H3 本地教程和 MiniMax 模型卡里写明的行为，这些都是文档说明，没有在本地实际运行过，遇到"参考像没起作用"时可以按这几处对照。

参考完全不起作用，多半是连线或模型选错了。扩散模型要选 ref2va 版本（教程里是 minimax_h3_ref2va_pruned_int8_convrot），不能用首尾帧用的 fl2va 版本；没有接 vae 时，参考图和参考视频只作用于文本编码器，不会生成参考 latent，效果基本等于只剩文字描述。参考视频自带的声音也一样，只有把 ref_video_audio_N 接到对应的 ref_video_N 上才会被使用。

参考只起了一部分作用，先看帧。节点按 24 fps 读取参考视频、不看元数据，所以 30 fps 之类的素材要先转成 24 fps，否则读出来的动作会比原片慢；每段至少要有 5 帧。超过生成长度 length 的参考帧会被直接截掉，length 默认 124 帧（约 5 秒），取值按 17k + 5 对齐，所以 10 秒的参考片配 5 秒的输出，后半段的运镜根本不会被看到。

参考变弱，还要看采样设置。可选的 4 步 Turbo LoRA 更快，但参考和音频的约束会变弱，参考必须守住时用 20–25 步；风格 LoRA 会和参考争抢，教程建议强度约 0.5。另外，开源权重只输出 768p、24 fps，2K 模块没有开源，要调用 MiniMax 托管的 H3-Context-IR 和 H3-Regenerate-2K 接口。

硬件方面，SGLang 的 MiniMax H3 部署指南列出的配置是 4 张 H200、4 张 H100、2 张 RTX 5090 加 384 GiB 内存，或者单张 RTX 4090（峰值约 18 GB，但 4090 方案是在首尾帧模式下测的，不是参考模式）。它的示例里一个参考生视频任务用了 260 秒，同样硬件上文生视频是 37 秒，所以本地跑参考模式要预留明显更长的时间。

MiniMax H3 参考视频的其他问题

参考视频的光线和色调会被带到成片里吗？

可能会。Atlas Cloud 在 2026 年 8 月 12 日发布的测试经验里，把参考视频能锁住的东西列为动作、运镜、调色和颗粒，也就是说参考视频本身就容易把影调带进成片。它那次的提示词既写了 "bright empty covered market, cold clean daylight"（明亮空荡的室内市场、冷而干净的日光），又写了 "carry the grade and grain of the reference clip"（沿用参考片的调色和颗粒），两个要求方向相反，结果参考片的夜景调色占了上风，成片比"明亮"暗沉得多。Atlas 的结论是，一次调用不能既要参考片的影调、又要相反的光线。所以想换光线时，先删掉沿用影调的指令，并把新场景的时间和光线写具体；仍然不行，就去掉这段参考视频，人物身份只靠参考图来保持。11 月 2 日那次实测的提示词没有要求沿用影调，草坡上的参考片换成了黎明的码头，但这只有一个样本。

参考视频自带的声音会被 H3 用上吗？

不一定。MiniMax 的参考模式提示词指南写明，普通参考视频不会仅仅因为文件里有声音就成为音频参考。想借音色或配乐，把音频单独作为 reference_audio 传入，在提示词里写"音色参考 reference audio 1"，官方 API 示例就是这么写的；在 ComfyUI 里要把 ref_video_audio_N 接上。RunDiffusion 的指南还提到，如果原片的对白漏进了成片，就写明参考只提供音色，并把新台词完整写出来。

能先让 H3 帮我把提示词改写好吗？

可以用 MiniMax 官方的 H3-Context-IR 接口（POST /v2/h3_context_ir）。它读取你的文字和参考素材，只返回一份增强后的提示词（在 content.prompt 里，任务类型 h3_context_ir），不生成视频；返回的格式就是参考模式指南里那套带主体和保留标记的结构，可以拿来检查模型是否理解了"只借运镜"。截至 2026 年 11 月 2 日，这个接口在官方 API 文档里有说明，上面的实测没有用到它。

768P 的参考生视频结果怎么变成 2K？

官方 API 有单独的视频重生成接口（POST /v2/video_regeneration），只接受 MiniMax-H3 768P 规格的结果：把原任务的全部 content 原样再传一次，另加一条 role 为 base_video 的视频。按 MiniMax 价格页，重生成和原任务分开计费，原任务里的参考素材要再计一次：参考视频按原时长计，参考图同样前 5 张免费，音频免费。开源权重本地跑出的 768p 结果，也要通过这个托管接口才能升到 2K。

MiniMax H3 Max 能用参考视频吗？

看入口。MiniMax 官方 API 文档写的是 MiniMax-H3-Max 支持参考图片、视频和音频，价格页也单独给出了它的参考视频单价；海螺 App 的界面文字却写着只有 H3 支持参考视频，H3 Max 只支持文字或首尾帧。截至 2026 年 11 月 2 日两边说法不一致，用 API 时以 API 文档为准，用 App 时以界面为准。