OpenAI 把全雙工語音 GPT-Live 帶進 Codex：hands-free 語音寫程式怎麼用

瀏覽次數: 1

本文大綱

你還在打字驅動 coding agent，OpenAI 想讓你用「講」的

2026 年 7 月 23 日，OpenAI 把 ChatGPT Voice 正式帶上桌機版 App（macOS + Windows），底層換成 7 月 8 日推出的全雙工語音模型 GPT-Live。官方公告一句話講完它要幹嘛：「用你的聲音，控制電腦、指揮跑在 ChatGPT Work 或 Codex 裡的多個 agent。」對天天用 coding agent 的人，這不是又一個語音助理，而是把「開任務、查進度、改方向」這三件事，從鍵盤搬到嘴巴。

先把話說在前面：這篇不是我實測（桌機語音剛全球推送、開發者 API 也還沒 GA），以下是從 OpenAI 官方公告、社群公告與多家報導整理出的機制與可照做的用法，並清楚標註哪些是官方確認、哪些只是報導、哪些查不到細節。會這樣寫，是因為這類「發表當天」的語音功能最容易被二手摘要灌上錯的數字與模型名，本文寧可保守。

背景：Codex 併進桌機 App，語音才有「可指揮的對象」

要理解語音為什麼現在才有用，得先看 Codex 的變化。OpenAI 把原本獨立的 Codex App 併進新的 ChatGPT 桌機 App（Fortune 報導約在 7 月 9 日整合），Codex 本身還是那個給工程師用的 coding agent，但現在跟 Chat、Work 同住一個桌面視窗，而且能開多條平行 thread 各跑各的任務——一條在重構、一條在修 bug、一條在更新文件，互不阻塞。

有了「多條可獨立跑的 thread」這個底座，語音才有意義。你講一句話，指的是「第 3 條那個重構任務」，而不是對著單一對話框亂喊。官方描述的操作很明確：在語音模式先開一個新 chat 或 task，然後叫 ChatGPT 去 start / check / steer 其他 thread 的工作——開始一件、查看一件、修正一件的方向。換句話說，語音不是拿來「跟 AI 聊天」，是拿來當多工的排程台。

過去打字驅動多 agent 有個隱形成本：你得不斷把手從當前正在做的事（可能是在看設計稿、在白板前想架構）移回鍵盤、切視窗、打字、再切回去。語音把這個 context switch 的成本壓到接近零，這才是 hands-free 對工程師真正的價值，而不是「打字很累」這種表面理由。

運作原理：全雙工 + 背景委派

GPT-Live 跟舊的 Advanced Voice Mode 最大的差別是全雙工（full-duplex）：它同時聽與說，不是「你講完 → 靜音偵測 → 它才答」的半雙工回合制。半雙工的痛在 coding 場景會被放大——agent 開始唸一大段方案，你早就知道方向錯了，卻得乾等它講完、等系統偵測到你停頓，才輪到你糾正，一來一回浪費的都是你的注意力。

拆成三層看：

連續雙向音訊：GPT-Live 把你的聲音當成一條不間斷的串流處理，一邊生成自己的語音、一邊監聽你有沒有開口。官方講它會用「嗯嗯」「對」這類 backchannel 表示在聽，你需要想一下時它也能安靜等；你中途插話，它能停在句子中間、接住你的打斷，而且跨打斷維持對話脈絡。對 coding 場景的實際好處是：agent 講到一半你發現方向不對，可以直接喊停、當場改方向，不必等它把整段唸完——這一點是全雙工相對半雙工唯一但關鍵的贏面。
輕重分流：即時對答（確認、簡短口語回覆、報進度）由語音模型自己扛；需要多步推理、結構化輸出或複雜產碼時，報導指出 GPT-Live 會在背景把重活委派給推理模型（多家報導點名 GPT-5.5），讓語音互動照樣流暢不卡住。這種「前台語音薄、後台推理厚」的分工，是它能一邊跟你閒聊確認、一邊讓 Codex 在背景跑完整任務的關鍵。要提醒的是：OpenAI 官方頁面我抓不到原文（openai.com 對外部抓取回 403），所以「委派給 GPT-5.5」這件事先當「報導指出」看待，別當定案寫進技術文件。
語音當 orchestrator，不是當編譯器：真正寫 code、跑測試、開 PR 的還是 Codex 那條 agent thread。語音層做的是編排——把你的口語意圖解析成「對哪一條 thread、下什麼指令」，執行完再把結果講回給你。理解這一層很重要：你講得越像「對某條任務下的一句 shell 指令」，模型越不會指錯對象；你講得越像「跟朋友發散地聊需求」，它就越可能開錯 thread 或做出你沒要的東西。

延遲方面各家報導數字並不一致（有來源提 GPT-4o Realtime v2 首個音訊區塊中位數約 300–600ms、標題寫「目標 300ms」），連被引用的模型命名都對不太起來，所以延遲數字建議當量級參考，別引用成精確規格。可以確定的方向是：GPT-Live 走的是「語音優先、低延遲串流」路線，取代舊的 Whisper → GPT → TTS 三段式管線，中間少了轉檔與資訊損耗。官方也已宣布 GPT-Live 取代 Advanced Voice Mode 成為 Go／Plus／Pro 的預設語音體驗，免費版則換成 GPT-Live-1 mini。

怎麼把它用起來（可照做）

開啟：更新到新的 ChatGPT 桌機 App（macOS / Windows），方案需為 Plus、Pro、Business、Edu 或 Enterprise 其一（iOS 另走 Remote 用）。進 App 開語音模式即可，公告說是全球推送，不必等分區排隊。
先幫 thread 取名：語音指揮的前提是「你講得出要指哪一條」。開 Codex thread 時就用清楚、好唸、彼此不易混淆的名字（例「auth-重構」「付款-bug」「docs-更新」），別留一堆「新交談 1／新交談 2」，否則你根本沒辦法用一句話點名。
口語指令用「對象 + 動作 + 條件」三段式：把 thread 名放最前面，接一個明確動詞，最後補完成條件與回報方式。例：「幫付款-bug 那條跑一次測試，紅了就把第一個 stack trace 唸給我」「開一條新 thread，把 README 的安裝步驟照現在的 package.json 更新，做完先別 commit」。條件講清楚，模型才不會自作主張。
狀態輪詢用短句：多條平行跑的時候，用「auth-重構現在到哪了？」「哪幾條跑完了？」這種短問句做巡檢，比逐一切視窗快。
善用可被打斷：讓 agent 邊做邊口頭回報，方向錯了立刻插話糾正。這是全雙工最實際的用法，別只把它當成「唸出來的鍵盤」。
重任務仍要用眼睛驗收：diff、PR 內容、測試輸出、報錯堆疊，還是回到畫面上看。語音適合下令、查狀態、修方向；驗收程式碼本身，眼睛永遠比耳朵可靠。

適用場景與 trade-off

適合：手上在忙別的（畫圖、開會、通勤時用 iOS Remote）時開新任務或查進度；平行跑多條 thread 時做狀態輪詢與方向微調；rubber-duck 式先把「要做什麼」用講的想清楚，再落成一條可執行任務。這幾個場景的共通點是——你要傳達的是「意圖」，不是「精確字元」。

別用：需要精準審 diff、貼長 log、逐行改字的場合。語音轉述容易失真，而且程式碼裡的符號、縮排、變數名、大小寫，用唸的效率遠低於用看的，還容易被聽錯成別的 token。另外，安靜辦公室或開放空間對著電腦連講一長串指令，社交成本是真的——這不是技術問題，但會決定你到底會不會天天用它。

對工程團隊的意義

短期別急著改整條工作流。務實的三件事：一，先在個人機器上把「開任務／查進度／喊停」這三個動作用語音跑順，這是投入報酬比最高的部分，也最能看出它到底幫不幫得上你；二，養成 thread 命名規範——這件事你現在用鍵盤也該做，語音只是把它從「建議」變成「剛需」，順手就把團隊的命名慣例先立起來；三，等開發者 Realtime API（報導稱 gpt-realtime／GPT-Realtime-2.1，GA「以週計、非以月計」）真正開放後，才是把語音編排接進自家 CI、內部 agent、值班機器人的時機——目前 GPT-Live 還只在 ChatGPT 消費端，別現在就規劃生產整合。

一句話總結：GPT-Live 進 Codex 沒有讓 agent 更會寫 code，它改的是「你怎麼下令與監看」。把它當成一個嘴巴能操作的 orchestrator，把精準活留給鍵盤與眼睛——而不是幻想能用講的就把整個 feature 講出來。分清楚這兩件事，你才會用得順，而不是玩兩天就關掉。