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 指南裡有講，並且一如既往，對著構建時當下的官方頁面核實每一個行為。