影片筆記：GPT Live 实测：全双工语音，真人感到底有多强？｜ PK 豆包/同传/面试/脑暴/辩论/喜剧｜ Open AI

一句話總結

影片深度解析 OpenAI 發布的 GPT 5.6 更新，核心在於將 Codex 與 ChatGPT 整合，Codex 正式成為 ChatGPT 的一個模式。透過 Work 模式（知識工作）與 Codex 模式（開發者）的切換，以及關鍵功能 Add to Task，實現了從短暫對話（Function）到具備生命週期與狀態的任務對象（Object）的轉變，標誌著 Chat 與 Workflow 的融合及 Agent 入口形態的成熟。

核心重點

架構整合：OpenAI 將 Codex 與 ChatGPT 合体，Codex 不再是獨立應用，而是 ChatGPT 內部的一個模式。介面左上角可切換 Work（知識工作）與 Codex（開發者）模式，系統會根據選擇進行傾向性調整。

模式差異化：

• Work 模式：面向知識工作者，目標是交付成果（如文稿、報告），驗證標準為語義與業務驗收（人判斷）。其世界模型圍繞「成果」組織環境，類似項目經理邏輯。
• Codex 模式：面向開發者/工程師，目標是可運行的軟體系統，驗證標準為機器執行與測試（機器判斷）。其世界模型圍繞「工程狀態」（代碼倉庫）組織環境，類似工程師邏輯。

Add to Task 的革命性：

• 允許在聊天模式中將上下文合併到 Codex 的執行任務中。
• 實現了人類聊天與 AI 任務進程的無縫連結，將對話從短暫的「Function（函數）」轉變為具有生命週期、狀態與歷史的「Object（對象/任務）」。
• 解決了傳統 Chat 生命週期短的問題，無需人工通過元提示詞或 Hand off 文件來縫合，實現動態更新與絲滑的 Agent Loop。

未來展望：此更新被視為具有「劃時代意義」，OpenAI 給出了 Agent 入口的完整形態答案（Chat 併入 Agent）。預測國內大廠 APP 將在短期內跟進此種「All in One」的 Agent 形態。

詳細大綱

I. 更新概覽與三大變化

• 整合現象：OpenAI 將 Codex 與 ChatGPT 合体，Codex 變為 ChatGPT 的模式。
• 圖標處理：更新時若選擇不保留 Codex 圖標，可統一為 ChatGPT 圖標。
• 三大變化點：

模式切換：左上角切換 Work 或 Codex，針對編程或工作任務進行傾向性調整。

傳統聊天入口：在 Codex 內點擊聊天，進入傳統 ChatGPT 模式。

Add to Task（關鍵功能）：將聊天上下文合併至 Codex 執行任務，實現任務與人類聊天對齊的無縫連結。

II. 介面與架構解析

• 應用入口統一：
• ChatGPT 成為統一平台入口與認知層（產品外殼）。
• 底下包含三個模式：Chat 模式、Work 模式（知識工作）、Codex 模式（智能體執行）。
• 圖標與版本區分：
• ChatGPT Classic：傳統經典 APP 圖標。
• ChatGPT (新)：歷史上的 Codex，若更換圖標則與舊版 ChatGPT 圖標一致。
• 統一 GPT：當前整合後的應用名稱。
• 手機端支援：手機端 GPT APP 亦可開啟 Work 模式。

III. Work 模式 vs. Codex 模式深度對比

• 核心定義：
• Work：面向知識工作成果的通用執行代理。
• Codex：面向可運行軟體系統的工程代理。
• 工作對象與使用者：
• Work：對象為成果/項目/任務；使用者為研究員、運營諮詢師、內容創作者、辦公用戶。
• Codex：對象為代碼倉庫中的工程變更；使用者為開發者、工程師。
• 底層邏輯差異：

世界模型（World Model）不同：

• Work：認為自己是開放性知識任務，圍繞「成果」組織環境，優點是拓展性強。
• Codex：認為自己是面對有狀態的計算環境，圍繞「工程狀態」（代碼倉庫）組織環境。

Harness（束縛/規則層）不同：

• Work：類似項目經理邏輯，處理多源信息、矛盾信息與不確定性，擅長跨應用綜合理解與自動化觸發。
• Codex：類似工程師邏輯，關注工作目錄、可寫目錄、沙箱權限、測試狀態與規則文檔。

成功標準不同：

• Work：交付給人看，驗證為語義與業務驗收（人判斷）。
• Codex：交付給計算機執行，驗證為能否跑通、項目是否掛掉（機器判斷）。
• 狀態管理差異：
• 傳統 GPT 內容跟帳號（雲端）。
• 傳統 Codex 內容跟本地設備/文件夾（本地）。
• 預測：Work 模式狀態未來可能跟帳號並與雲端同步；Codex 模式狀態將鎖定在本地設備與倉庫。
• 選擇建議：
• 不單純按是否含代碼選擇，而是看任務最終主對象。
• 業務成果 -> 選擇 Work。
• 持續維護與驗證的計算環境 -> 選擇 Codex。
• 混合用法案例：Work 負責上半場（研究主題、形成逐字稿、發布包）；Codex 負責下半場（獲取項目目錄、本地 TTS 生成音頻畫面、剪輯渲染、API 發布）。

IV. Chat 模式的價值與 Add to Task 的革命性

• Chat 模式的不可替代性：
• 適合開放性思考、討論目標可能性、機制抽象策略判斷。
• 適合非項目目錄依賴的即時問答（數學、情感、醫療、電影分析）。
• 移動端 APP 承擔語音即時交流與移動端對話功能。
• Add to Task 的核心意義：
• 融合 Chat 與 Workflow：將對話變成可持續運行的過程和任務。
• 生命週期延長：
• 過去：Chat 生命週期短，需人工通過元提示詞、Hand off 文件、Codex 回執來縫合延長。
• 現在：系統級解決，Chat 直接變為任務，上下文無需重新構建。
• 從 Function 到 Object 的轉變：
• 過去 Prompt 是 Function（輸入輸出）。
• 現在 Prompt 是 Object（對象），擁有生命週期、狀態、上下文與歷史。
• 動態更新 Loop：任務執行中可同步聊天，將認可的上下文加入任務，實現動態 Update 與絲滑 Loop，Agent 在過程中成長。
• 結論：所有對話都可升級為工作流，所有工作流都是動態的。

V. 未來走向與 OpenAI 的產品演進邏輯

• 市場影響：
• GPT 5.6 更新被視為「劃時代意義」。
• OpenAI 仍是軟體形態的引領者。
• 預測國內大廠 APP 在 1-2 個月內跟進此形態，將 Chat 併入 Agent，實現人類對齊、審核與 Agent Loop 的完整形態升級，最終 All in One。
• OpenAI 的產品演進路徑：

Memory：讓用戶變成持續存在的對象。

Project：讓項目變成持續存在的對象。

Codex：讓工程環境變成持續存在的對象。

Work：讓工作空間變成持續存在的對象。

Add to Task：讓一次聊天變成持續存在的執行對象。

• 數據積累與迭代：
• Codex 近期高頻迭代積累了大量工程數據。
• 這些數據讓 OpenAI 工程師掌握 Agent 工作細節與交互細節，從而給出相對完美的 Agent 入口答案。

工具 / 模型 / 名詞整理

• OpenAI
• GPT 5.6
• Codex
• ChatGPT
• ChatGPT Classic（經典 APP）
• Work 模式
• Codex 模式
• Chat 模式
• Add to Task
• Loop（循環工作方式）
• MCP（模型上下文協議，提及用於打通 Codex 與 GPT）
• TTS（文字轉語音，提及於混合用法案例中）
• API（應用程序接口，提及於混合用法案例中）
• MD 文檔（Markdown 文檔）
• 靈姐說 AI（頻道名稱）
• World Model（世界模型）
• Harness（束縛/規則層，指上下文、工具、權限、審核規則等約束層）
• Function（函數，指過去 Prompt 的輸入輸出特性）
• Object（對象，指現在 Prompt 具備生命週期與狀態的特性）

操作流程整理

進入 ChatGPT 介面：

• 觀察左上角，確認當前處於 Work 或 Codex 模式。
• 若需切換模式，點擊左上角進行切換，系統會根據選擇進行傾向性調整。

執行任務流程：

• 若為知識工作（Work 模式）：
• 進行開放性思考、討論目標可能性。
• 處理多源信息與不確定性。
• 交付成果（如文稿、報告）供人驗收。
• 若為開發任務（Codex 模式）：
• 進入代碼倉庫環境。
• 關注工作目錄、可寫目錄、沙箱權限。
• 執行代碼並通過測試驗證。

使用 Add to Task 功能：

• 在聊天模式中進行對話或討論。
• 點擊 Add to Task 按鈕。
• 將當前聊天上下文合併至 Codex 的執行任務中。
• 任務開始運行，並在執行過程中可同步聊天，將認可的上下文加入任務，實現動態更新。

混合用法流程（案例）：

• 上半場（Work 模式）：研究主題、形成逐字稿、發布包。
• 下半場（Codex 模式）：獲取項目目錄、本地 TTS 生成音頻畫面、剪輯渲染、API 發布。

值得注意的限制或風險

• 模式選擇誤區：用戶不應單純按任務是否包含代碼來選擇模式，而應看任務最終主對象。業務成果應選 Work，持續維護與驗證的計算環境應選 Codex。
• 狀態管理差異：
• 傳統 GPT 內容跟帳號（雲端）。
• 傳統 Codex 內容跟本地設備/文件夾（本地）。
• 預測 Work 模式狀態未來可能跟帳號並與雲端同步；Codex 模式狀態將鎖定在本地設備與倉庫。這可能影響跨設備訪問與數據備份策略。
• 生命週期依賴：雖然 Add to Task 延長了生命週期，但任務的持續運行仍依賴於系統級的支持與資源分配。

逐字稿辨識疑點

• GPT5.6：逐字稿中多次提及此版本號，需查證 OpenAI 官方是否確實發布此版本或為口誤/預測名稱。
• site：在描述 Work 模式工作對象時，逐字稿提及「演示報告 site 等產品」，疑點為「site」在此處語境不明確，可能為口誤或特定內部工具名稱。
• Harness：逐字稿解釋為「套在模型外面的那一套繮繩」，指代上下文、工具、權限、審核規則等約束層，此為影片作者自定義或特定術語，需查證是否為 OpenAI 官方標準術語。
• 疊甲：逐字稿提及「疊甲」，疑點為術語來源不明，可能為特定社群黑話或口誤，指代保護或增強提示詞。
• 手冊/回执：逐字稿提及「Codex 定期的給我回执」，疑點為「回执」一詞在技術語境中較少見，可能為「回執」或「報告」的口誤。

可延伸追問

• OpenAI 官方是否已正式發布 GPT 5.6 版本？該版本號是否為影片作者的預測或口誤？
• 「Harness」作為約束層術語，在 OpenAI 官方文檔中是否有對應的標準名稱？
• Work 模式與 Codex 模式在狀態管理上的差異（雲端 vs 本地）將如何具體影響用戶的數據隱私與備份策略？
• 國內大廠 APP 跟進此形態的具體時間表與產品規劃為何？
• 「疊甲」一詞在該語境下的具體含義與應用場景是什麼？