OpenAI Speech 音频怎么保存播放？格式与完整性验收
已有 OpenAI /v1/audio/speech 接入的结果不能一律按 JSON 读取：直接音频响应应按字节保存，事件流则要按协议提取音频。拿到文件后，还要分别确认传输完成、播放器能解码、原文确实读完；听到开头不代表任务通过。本文用于现有 Speech 文件接入的保存验收，官方资料核对日期为 2026 年 10 月 24 日，未发起真实语音请求。
先选对路径：朗读文字，不等于转写或实时对话
已经有确定文字、要生成播报文件，使用文字转语音接口；手里是录音、要得到文字，走音频转写流程。Chat Completions 的音频输入输出和 Realtime 会话又是不同路径，不能直接复用 Speech 的请求体或结束判断。OpenAI 音频工作流说明
云岚API 的某个模型能完成文本对话，不代表该渠道也支持语音、指定声音或音频流。先在控制台核对端点、模型、声音和格式；地址仍不确定时，再看协议与 base_url。
两个格式字段，分别控制什么？
OpenAI 已将下面示例使用的 gpt-4o-mini-tts 及 tts-1、tts-1-hd 列为弃用，计划于 2027 年 1 月 6 日移除。TTS 弃用通知将替代模型指向 gpt-realtime-2.1-mini，并要求按 Realtime 路线规划迁移。它采用会话与音频传输，不能只换模型名沿用下面的请求体；本文没有验证替代路线能否满足你的逐字朗读和文件交付要求，新项目需单独验收。
OpenAI 当前 POST /v1/audio/speech 中，response_format 选择音频格式；stream_format 选择直接音频 audio 或事件流 sse。例如下面是请求体示意，不含认证，也未执行：
{
"model": "gpt-4o-mini-tts",
"voice": "alloy",
"input": "验收开始。订单编号是七二九。验收结束。",
"response_format": "mp3",
"stream_format": "audio"
}
模型和声音来自当前官方接口清单，不能据此推定第三方已上架。tts-1、tts-1-hd 不支持这里的 sse；不要把 stream_format 和其他接口的 stream: true 当成同一个参数。Speech 接口参考
| 准备保存的内容 | 接收方式 | 容易出错的做法 |
|---|---|---|
| 直接音频响应 | 连续读取二进制字节，写入同一临时文件 | 按 UTF-8 转成文字再写回 |
| SSE 音频事件 | 先分帧，再按该接口字段提取、解码音频并检查结束 | 把整段 data: 文本改名为 MP3 |
SSE 基础分帧可看流式接收教程，其中的文本组装代码不能直接当音频解码器。
保存时核对格式，改扩展名不会转码
本例请求 MP3，检查响应 Content-Type 与实际媒体格式是否相符，再采用 .mp3。MP3 常用 MIME 为 audio/mpeg；WAV 有 audio/wav 等写法。媒体类型不是内容真实性证明，播放器仍需读取实际数据。MDN 媒体格式说明
PCM 尤其容易误用：OpenAI 文档中的 PCM 是无文件头的 24 kHz、16 位有符号小端原始采样。它不是改名即可播放的 WAV；播放器需要正确的采样参数，或者先用合适工具封装。这个参数组合也不能外推到其他服务。OpenAI 输出格式说明
建议按以下顺序处理一次保存：
- 记录 HTTP 状态、响应类型、请求标识和本次格式；失败响应先排查错误，别直接保存成“音频”。
- 将字节写入本次独立的临时文件，接收异常或用户取消时保留未完成状态，不能覆盖此前合格文件。
- 读取和写盘都正常结束后，记录字节数，再做解码与听验。返回 JSON、HTML 或类型不符时，先核查实际响应；缺少明确 MIME 时也不能只凭扩展名放行。
- 验收通过后，再把文件交给播放器或发布。记录原文版本与文件对应关系，避免播放器缓存了上次的音频。
向终端用户播放时，按 OpenAI 对该接口的要求，清楚标明这是 AI 生成的语音。官方 TTS 说明
这些是接收端检查步骤，不表示每个服务都会返回相同的响应头或计量字段。
首块能播放，为什么还不能算完整？
网络块只是一次读取的结果，不一定恰好是一段可独立解码的音频。浏览器的 decodeAudioData() 面向完整文件数据，不能拿任意小块反复调用，失败后就认定模型坏了。MDN 解码接口说明
先做完整文件播放，再考虑边收边播。验收应分三层：
| 层级 | 要记录的证据 | 还不能证明什么 |
|---|---|---|
| 传输 | 客户端无接收/写盘异常；事件模式符合其结束规则 | 原文没有漏读 |
| 文件 | 格式可识别、能解码并播放到文件末尾 | 数字、专有名词读对 |
| 内容 | 对照原文检查开头、中段和结尾，记录漏读、重复与读音 | 其他文字、设备或渠道也一定通过 |
用前面的短句先测三处检查点：开头“验收开始”、中间编号、结尾“验收结束”。它是人工设计的验收文本，没有对应的本站实测音频。完整解码也可能只得到一段正常结束但漏读的音频；最终仍需对照全文，长文按段留记录。
保存一份可复核的听验记录
下载语音输出检查与听验模板，包含请求清单、人工记录表和空白 CSV。记录日期、服务与模型、原文版本、声音、两种格式、状态、字节数、时长、播放器及三层判定；每项可以填“通过／不通过／待核／无法判断”，没有预置成功值。
模板不会读取音频、发请求或自动评分。费用填实际单位和账单来源，不用文件字节数反推 token 或价格；重复生成的尝试也要分别记录，必要时用费用对账表。
常见问题
返回 200，保存的 MP3 为什么不能播放？
先确认保存的是音频字节而不是 JSON、HTML 或 SSE 文本，再查格式、写盘中断及播放器支持。200 与非零文件大小都不是完整音频的充分证据。
直接把 PCM 文件改成 WAV 可以吗？
不可以。扩展名不添加容器信息，也不转换采样率、位深和声道；先按实际服务的 PCM 参数解码或封装。
文件能播放，网页却没有声音，是生成失败吗？
不一定。浏览器可能拦截自动播放；检查 play() 返回的错误，并让用户点击播放。NotAllowedError 和不支持媒体格式属于不同分支。MDN 播放接口说明
播放到末尾就能确认文字都读完了吗？
不能。末尾只说明这份文件播放完了；还要对照输入文字检查缺句、重复、数字与读音，并将文件完整性和内容合格分别记录。