10 月 16 日，OpenAI 向所有 API 客户开放了 prompt-to-voice：你用文字描述一个声音，API 生成并保存它，然后你在 GPT-Live 会话里复用它。整个功能就是这样，而且值得精确理解，因为一条边界决定了它到底与你的产品有没有关系。由 prompt 生成的声音可以用于 GPT-Live。Text to Speech、Realtime 和 Chat Completions 这三类 API 不支持它们。如果你的语音流水线跑在这三个界面中的任何一个上，这次发布就够不到你，无论你的描述写得多好。决定可用性的是边界，不是 prompt。
以下内容全部取自官方的 API changelog 和 custom voices 指南，并按惯例提醒：构建时请对照当时页面上的内容核实。
发布了什么
10 月 16 日的 changelog 条目足够简短，可以直接引用：
面向所有 API 客户发布 prompt-to-voice。可通过 API 或 voice Playground 用一段文字描述创建自定义声音，然后在 GPT-Live 会话中复用它。创建 prompt 生成的声音是免费的；语音生成按常规 GPT-Live 会话计费。
该条目列出了它涉及的界面：模型gpt-live-1，以及 APIv1/audio/voices 和v1/live/sessions。关于计费，请逐字理解官方那一句：创建 prompt 生成的声音是免费的，在 GPT-Live 里用它生成语音按常规会话费率计费。这句话没有承诺一次会话要花多少钱，本文也不做超出这句话的价格主张。
同一条 changelog 还为 GPT-Live 增加了九个自然声音，按官方发布的分组照原样列出：Nuri、Juni 和 Flitz（德语）；Brise 和 Sillage（法语）；Nira（印地语）；Harema 和 Shida（日语）；以及 Noeul（韩语）。
用指南自己的话说出这条边界
custom voices 指南毫不含糊地写明了这个限制：
“Prompt 生成的声音可用于 GPT-Live。它们不被 Text to Speech、Realtime 或 Chat Completions API 支持。”
这句话就是全文。正在构建 TTS 流水线、Realtime 语音 agent，或在 Chat Completions 上输出音频的团队，无法把一个 prompt 生成的声音换进去；这个功能根本没有接到那些界面上。如果你曾希望描述一次声音、然后在每个音频端点上通用，今天的答案是不行，而围绕“它肯定会来”做规划并不是一种迁移策略。
通往自定义声音的两条路，以及哪一条能跨过这条边界
指南描述了两种创建声音的方式，它们不能互换：
| Path | What it needs | Where the voice works |
|---|---|---|
| From a description | A text description of the vocal qualities; no reference recording and no consent recording | GPT-Live only |
| From a recording | A consent recording and a short reference sample | GPT-Live, the Text to Speech API, the Realtime API, or the Chat Completions API with audio output |
第二行是多界面产品的逃生通道，而它的要求不是形式主义：一份同意录音是交易的一部分。如果你的用例横跨 TTS 或 Realtime，并且你需要自定义声音，那就是该评估的路径，把同意流程当作产品需求、而不是文书工作来对待。
创建过程实际是怎么走的
这些机制小到可以记在脑子里。向/v1/audio/voices发送一个 JSON 请求，把type设为prompt，一个name，声音描述放在prompt里，并在官方示例中把model设为auto。可选地包含script_hint，即一段引导生成的示例脚本；如果省略，服务会根据你的描述生成脚本。每次成功的请求都会创建一个新的已保存声音，并返回元数据，包括它的id、created_at和原始描述。响应里没有音频、也没有试听，所以要试听就得用这个声音，而不是下载样音。
要使用这个声音，在创建会话时以对象形式传入它，例如{ "id": "voice_123" }，而不是一个具名声音字符串，并把model设为gpt-live-1。指南指出，gpt-live-1支持带英语口音的自定义声音，口音通过session.instructions请求（例如 “Speak British English”）。保存返回的 ID 并留着原始描述：描述是你用来重新生成相似声音的东西，而 ID 是你的会话所引用的东西。因为每次成功的请求都会保存一个新声音，把同一段描述提交两次会产出两个已保存的声音，而不是更新第一个；在你的配置清单里把 ID 对应清楚。
按政策，这个声音不会做什么
指南的“负责任使用”一节很短，但承重，这里忠实复述：
- 负责任地使用声音。不要冒充他人，不要违反使用政策。
- 使用成人声音。不允许使用儿童声音。
- 保持透明。告诉听众这段语音是 AI 生成的，并保留来源元数据、水印或其他合成来源标识。
- 声音不保证唯一。其他人可能生成相似的声音或输出；输出的所有权仍由你与 OpenAI 的协议管辖。
- 条款适用于你和你的最终用户对 prompt-to-voice 的使用。
其中两条有工程后果。透明不只是政策文件里的一句话；如果你在把内容交付给用户的路上剥掉了来源元数据，你就删掉了指南要求你保留的那个标识。而唯一性明确没有被承诺，所以一个声音是审美选择，而不是你在先把它生成出来就能主张的品牌资产。把这五点读作你的产品必须满足的合规要求，而不是建议：尤其是透明义务，落在你的界面和你的流水线上，而不是落在模型上。
它所在的 Live 语境
在 prompt-to-voice 发布前一天，changelog 记录了 GPT-Live 中的原生 Decisions 集成：你的应用可以在用户说话时行动，或对 Live 所说的内容做出反应——要么让 Live 通过原生委派直接调用 Decisions，要么在输入或输出 transcript delta 到达时触发 decision。把两条记录放在一起，产品形态就清楚了：Live 会话是声音居住的地方，也是应用可以对着被说出的内容行动的地方。声音是那次会话的一个组件，而不是一件独立的音频资产。
上线前如何验证
五项检查覆盖了要紧的失败模式，第一项就是边界检查：
- 确认这个集成确实跑在 GPT-Live 上。如果不是，就到此为止，转而评估录音路径或现有的 TTS 声音。
- 把同一段描述生成不止一次并比较结果；已保存的声音应当可复用，但“描述到声音”的映射不是你能够依赖在多次运行间完全一致的规范。
- 用已发布的声音试听每个目标语言，在支持该语言的地方也用你生成的声音试听。
- 演练要紧的会话行为：打断、语音重叠和长回答。
- 保留一个非生成的兜底声音作为配置，这样声音出问题时永远不会让整个会话挂掉。
prompt 与模型变更的验证纪律，包括 golden set 和 shadow run，与本站在任何用户可见变更上采用的纪律是同一套，收录在测试指南里。
清单
- 在围绕 prompt-to-voice 做规划之前，先确认流水线是 GPT-Live。
- 写好描述、创建声音，并保存返回的 ID 及其原始 prompt。
- 把同一段描述生成多次，比较稳定性。
- 试听目标语言。
- 保留一个非生成的兜底声音。
- 接上透明告知，并保留来源元数据。
- 把声音 ID 和描述记进你的配置清单。
- 上线后观察会话行为，采用可观测性指南里的日志纪律。
一次发布，一条清晰的边界，以及一小套随声音一起进入生产的义务。对已经在 GPT-Live 上的团队，10 月 16 日多了一种用语言而不是样本塑造声音的办法；对其他人，它多了一个在看完公告之前先读端点清单的理由。本站所记录的兼容服务，其端点层面的细节在它的文档里，而兼容性清单是追问某个端点实际实现了哪些界面的正确框架。运行 agent 流水线的运维侧内容在 CI 指南里有讲，并且一如既往，对着构建时当下的官方页面核实每一个行为。