ChatGPT on KnightLi的博客

Google I/O 之後，GPT 和 Gemini 訂閱怎麼選？普通使用者與開發者對比

Thu, 21 May 2026 08:33:14 +0800

Google I/O 2026 之後，很多人的 AI 訂閱選擇變複雜了。

以前問題比較簡單：寫作、問答、編程、文件分析，大多數人優先看 ChatGPT；如果深度使用 Google 搜尋、Android、Gmail、Docs、YouTube，再考慮 Gemini。現在不一樣了。Google 在 I/O 上把 Gemini 3.5 Flash、Gemini Omni、Antigravity 2.0、Gemini API Managed Agents、Google AI Studio 和 AI Ultra 訂閱一起推出來，Gemini 生態開始從「可選項」變成「強競爭主線」。

這篇文章不做抽象模型跑分，而是回答一個實際問題：普通使用者、開發者、內容創作者和企業使用者，到底該訂閱 GPT / ChatGPT，還是 Gemini / Google AI？

注意：AI 訂閱價格、額度、地區和模型可用性變化很快。本文寫作時間是 2026 年 5 月 21 日，正式訂閱前應以 OpenAI 與 Google 當前頁面為準。

先說結論

如果你只想選一個主力訂閱，可以按這個邏輯：

日常寫作、問答、文件分析、泛辦公、中文英文混合使用：優先 ChatGPT Plus。
高頻編程、需要 Codex、複雜推理、專案級程式碼任務：優先 ChatGPT Plus / Pro，再按額度決定是否升級。
深度使用 Google 生態、Gmail、Docs、Drive、Android、Search：優先 Gemini / Google AI Pro。
重點做影片、AI 影像、Google Flow、YouTube Shorts、Gemini Omni：優先 Google AI Pro / Ultra。
需要 Antigravity、Gemini API Managed Agents、AI Studio 到 Android 的工作流：重點看 Google AI Pro / Ultra。
企業團隊：不要只看個人訂閱，重點看 Business / Enterprise、Workspace、權限、審計和資料邊界。
預算有限：一個主力付費訂閱 + 另一個平台免費層或按量 API，通常比同時訂兩個高階套餐更划算。

一句話：GPT 更像通用生產力和程式碼助手主力；Gemini 在 Google I/O 之後更像 Google 生態裡的系統級 AI 套件。

Google I/O 之後，Gemini 發生了什麼變化

Google I/O 2026 讓 Gemini 的價值不再只取決於 Gemini App 本身。

幾個關鍵變化：

Gemini 3.5 Flash：Google 把它定位為從 prompt 到 action 的高速模型，面向真實 Agent 工作流。
Gemini Omni：從任意輸入創作內容，當前重點從影片開始，支援多模態創作和自然語言多輪編輯。
Google Antigravity 2.0：Agent-first development platform，面向開發者的多 Agent 編排與編程平台。
Gemini API Managed Agents：透過 API 建立可推理、可用工具、可執行程式碼的託管 Agent。
Google AI Studio：從 prompt playground 走向行動端、Android 原生應用生成和 Antigravity 專案匯出。
Google AI Ultra：I/O 後新增 $100/月檔位，並面向開發者、技術負責人、知識工作者和高階創作者。

更重要的是，Google 把 Gemini App 的使用額度從傳統每日 prompt 限制，轉向 compute-used 模型。複雜影片、程式碼和長上下文任務會消耗更多額度，簡單文字任務消耗更少；額度每 5 小時刷新，直到達到週限制。

這說明 Google 正在把 Gemini 訂閱做成「模型 + 應用 + 創作 + 開發工具 + Google 生態」的打包入口。

ChatGPT / GPT 訂閱現在適合誰

ChatGPT 的優勢依然很強，尤其適合把 AI 當作日常工作主力的人。

根據 OpenAI 當前價格頁和幫助文件，ChatGPT Free 可以使用 GPT-5.5 Instant 等基礎能力；Plus 提供 GPT-5.5 Thinking、更多訊息和上傳額度、更強圖像生成、deep research、agent mode、專案、任務、自訂 GPT 和擴展 Codex 使用；Pro 則提供更高額度、GPT-5.5 Pro、更高 Codex 使用量、最大 deep research 和 agent mode。

更適合 ChatGPT 的場景：

寫作、總結、翻譯、改稿。
複雜問答和結構化分析。
文件上傳、表格分析、研究報告。
編程問答、程式碼審查、重構建議。
使用 Codex 做程式碼庫任務。
多語言內容生產。
對模型品質和回答穩定性要求高，但不強依賴 Google 產品。

如果你是普通使用者，ChatGPT Plus 仍然是最穩的主力訂閱。它覆蓋面廣，學習成本低，中文和英文任務都比較均衡。

如果你是開發者，ChatGPT 的關鍵不只是聊天，而是 Codex。OpenAI 幫助文件說明，Codex 可隨符合條件的 ChatGPT 計畫使用，額度隨計畫不同而變化。也就是說，如果你大量使用 Codex 做程式碼修改、PR、重構、測試修復，訂閱選擇要把 Codex 額度一起算進去。

Gemini / Google AI 訂閱現在適合誰

Gemini 的優勢在 Google I/O 之後更清晰：它和 Google 生態綁定更深。

Google AI 訂閱現在不只是 Gemini App 裡的模型額度，還包括 Gemini Omni、Google Flow、Antigravity、AI Studio、部分 YouTube Premium / Lite 權益、Workspace / Android / Search 生態能力等。Google 官方還把 AI Ultra 擴成 $100 與更高階檔位，強調開發者、技術負責人、知識工作者和高階創作者。

更適合 Gemini 的場景：

你深度使用 Gmail、Docs、Drive、Sheets、Slides、Android。
你想把 AI 放進 Google Search、YouTube、Workspace 生態。
你關注 Gemini Omni、Google Flow、影片生成和影片編輯。
你想試 Antigravity、Gemini API Managed Agents、AI Studio mobile。
你需要超長上下文文件理解。
你做 Google 生態應用、Android 原生應用、Workspace 自動化。

Google 官方幫助頁顯示，Gemini Apps 的上下文視窗會隨訂閱提高：無 AI plan 為 32K，AI Plus 為 128K，AI Pro 和 AI Ultra 為 1 million。AI Pro / Ultra 也會提供更高使用限制、更多特性和部分早期功能。

如果你的工作環境已經在 Google 生態裡，Gemini 的價值會被放大。否則，單獨把 Gemini 當作「另一個聊天機器人」來訂閱，性價比就不一定比 ChatGPT 更穩。

普通使用者怎麼選

普通使用者最容易踩的坑，是因為新模型發布就同時訂多個平台。

更理性的選法是先看主場景。

如果你主要做這些事：

寫文章。
查資料。
做總結。
讀 PDF。
寫郵件。
改履歷。
學習語言。
日常問答。

優先選 ChatGPT Plus。它的通用性更好，任務邊界更清楚，不需要你深度綁定某個生態。

如果你主要做這些事：

Gmail / Docs / Drive / YouTube / Android 高頻使用。
希望 AI 直接進入 Google 生態。
想體驗 Gemini App、Daily Brief、Google Search AI、YouTube 內容問答。
需要長上下文讀取 Google 文件。

優先選 Google AI Pro。

如果你只是輕量使用者，兩個平台都先用免費層，等明確遇到限制再付費。不要為了「可能用到」而訂閱高階套餐。

開發者怎麼選

開發者要分兩類。

第一類是以程式碼問答、修 bug、寫腳本、讀程式碼庫為主。優先看 ChatGPT Plus / Pro + Codex。

理由是：

Codex 和 ChatGPT 帳號打通。
ChatGPT 對程式碼解釋、重構、測試、錯誤分析比較穩。
Plus 已經覆蓋很多日常開發任務。
Pro 更適合高頻、長時間、複雜程式碼庫任務。

第二類是面向 Google 生態、Agent 平台、Android、Workspace 或 Gemini API 開發。優先看 Google AI Pro / Ultra。

理由是：

Gemini 3.5 Flash 是 Google I/O 後 Agent 工作流重點模型。
Antigravity 2.0 是 Google 的 Agent-first 開發平台。
Managed Agents 能透過 API 建立帶工具和隔離 Linux 環境的 Agent。
AI Studio 可以和 Android、Workspace、Antigravity 更自然銜接。

如果你是全端開發者，最務實的組合通常是：

ChatGPT Plus 作為日常程式碼與文件主力。
Gemini 免費層或 AI Pro 用於 Google 生態、長上下文和影片/Agent 新能力。
API 按量使用，不要把個人訂閱誤當生產 API 預算。

內容創作者怎麼選

內容創作者的選擇取決於你做什麼內容。

如果你主要做：

文案。
標題。
腳本。
文章。
圖文內容。
資料整理。
多語言改寫。

ChatGPT Plus 依然很穩。

如果你主要做：

影片生成。
短影片創意。
AI 影像。
YouTube Shorts。
Google Flow 工作流。
多模態素材整合。

Gemini / Google AI Pro 或 Ultra 更值得關注。I/O 之後，Gemini Omni 和 Google Flow 是 Google 在創作場景裡的核心牌。

如果預算有限，可以先訂一個文字主力，再用另一個平台的免費層或短期訂閱測試影片能力。影片模型的額度、排隊、時長、解析度和地區限制變化很快，不建議一開始就按長期生產服務規劃。

企業和團隊怎麼選

企業不要按個人使用者思路選。

企業真正要看的不是「哪個模型這週更強」，而是：

資料是否用於訓練。
是否有 SSO、MFA、RBAC。
是否有審計日誌。
是否支援內部知識連接。
是否能控制外掛、連接器和 Agent 權限。
是否符合組織的合規要求。
是否能和現有辦公套件打通。

如果企業已經重度使用 Google Workspace，Gemini 企業方案自然更值得評估。如果團隊已經圍繞 ChatGPT、Codex、OpenAI API 和內部工具鏈搭建流程，OpenAI Business / Enterprise 更自然。

對工程團隊來說，還要單獨評估 Codex、Antigravity、Gemini API Managed Agents、MCP、CI/CD、程式碼權限、倉庫存取和審計。

什麼時候需要 Pro / Ultra

很多人其實不需要高階檔位。

你需要 ChatGPT Pro 的典型信號：

每天長時間使用 ChatGPT。
Plus 額度經常不夠。
高頻使用 Codex。
經常跑 deep research、agent mode、複雜推理。
需要 GPT-5.5 Pro 這類更高階模型。

你需要 Google AI Ultra 的典型信號：

高頻使用 Gemini、Flow、Antigravity。
需要更高 Gemini / Antigravity 使用額度。
做影片創作、AI 影像、長上下文研究。
深度依賴 Google 生態和新功能優先體驗。
需要 Gemini Spark、Project Genie 或更高級訂閱權益。

如果你只是每天問幾次問題、偶爾寫文章或改程式碼，Plus / Pro、AI Pro / Ultra 這類高階檔位可能都不是剛需。

最省錢的訂閱策略

更推薦這種組合：

先選一個主力付費訂閱。
另一個平台先用免費層。
真正需要 API 時再按量付費。
影片、Agent、深度研究類高消耗功能按月開關，不要全年盲訂。
每月復盤一次：本月有沒有真的用滿額度？

幾個常見組合：

普通辦公：ChatGPT Plus + Gemini 免費層。
Google 生態使用者：Google AI Pro + ChatGPT 免費層。
開發者：ChatGPT Plus/Pro + Gemini API/AI Studio 按需。
影片創作者：Google AI Pro/Ultra + ChatGPT 免費層或 Plus。
企業團隊：不要用個人套餐拼，直接評估 Business / Enterprise / Workspace 方案。

訂閱前檢查清單

付費前先確認這些問題：

你的地區是否支援目標套餐？
你要用的模型是否包含在該套餐裡？
Codex、Antigravity、Flow、Omni 是否真的可用？
影片功能是否有地區、年齡、排隊或解析度限制？
API 呼叫是否包含在訂閱裡，還是單獨計費？
文件上傳、上下文視窗、agent mode、deep research 是否有額度限制？
資料隱私設定是否符合你的專案要求？
你是否已經有 Google One、Workspace、ChatGPT Business 或學校/公司帳號權益？

尤其要注意：個人訂閱不等於 API 免費，不等於商用無限額度，也不等於企業合規。

小結

Google I/O 之後，Gemini 的競爭力明顯增強，尤其是在影片、多模態、Google 生態、Android、AI Studio 和 Antigravity 方向。但 ChatGPT 仍然是更穩的通用主力，特別是在日常寫作、複雜問答、文件分析、程式碼輔助和 Codex 工作流裡。

最簡單的判斷是：

不知道選哪個：先選 ChatGPT Plus。
深度 Google 使用者：選 Google AI Pro。
高頻開發者：看 Codex 和 Antigravity 誰更貼近你的工作流。
影片創作者：優先看 Gemini Omni、Flow 和 Google AI Pro / Ultra。
企業使用者：按合規、權限、審計和現有辦公生態選，而不是按模型熱度選。

AI 訂閱不是越多越好。真正划算的方式，是明確一個主力工作流，再把其他平台作為補充，而不是為每一場發布會都多開一個長期訂閱。

參考來源：

AI Agent 到底怎麼進化的？2022-2026 五代演進完整梳理

Sat, 16 May 2026 19:19:52 +0800

AI Agent 的發展不是一夜之間發生的。

2022 年底，ChatGPT 還只是會聊天的視窗。到 2026 年，Agent 已經開始具備工具調用、文件操作、電腦控制、長期記憶、遠端協作和常駐執行能力。四年時間裡，它從「回答問題的模型」逐步變成「能推進任務的數位工作者」。

如果按時間線看，AI Agent 大致經歷了五代演進。每一代都解決了上一代的核心缺陷，也製造了新的泡沫和新的安全問題。

總覽：五代 Agent 時間線

階段	時間	關鍵詞	能力變化	核心問題
第零代	2022 年末 - 2023 年初	對話框	會生成文本，但不能行動	模型和現實世界斷裂
第一代	2023 年中 - 2023 年末	工具調用	能輸出結構化調用，接入 API 和 RAG	開環執行、任務迷路
第二代	2023 年末 - 2024 年	工程化工作流	有規劃、狀態、反思和多 Agent 協作	工作流易複製，低代碼泡沫
第三代	2024 年 - 2025 年	Computer Use	能看螢幕、點滑鼠、操作 GUI	權限、安全和誤操作風險
第四代	2025 年 - 2026 年	MCP / Skills / 常駐	有工具網路、長期上下文和專業技能	常駐執行擴大風險半徑
第五代前瞻	2026 年之後	閉環與世界模型	可能擁有更強記憶、驗證和物理行動能力	治理難度繼續上升

2022 年末：第零代，ChatGPT 對話框時代

第零代的起點，是 2022 年 11 月 30 日 ChatGPT 發布。

這一代 AI 還不能算真正的 Agent。它有很強的語言生成能力，但主要被困在對話框裡。它可以寫一段 Python 代碼，卻不能在你的電腦上執行；可以規劃旅行，卻不能打開網站訂票；可以告訴你文件應該怎麼改，卻不能進入文件系統執行修改。

這一代的能力邊界很清楚：

能理解自然語言；
能生成文章、問答、代碼和方案；
不能主動訪問最新資料；
不能穩定讀取企業內部資料；
不能執行外部動作；
不能管理長期任務狀態。

所以第零代最核心的問題是：模型能力和現實世界之間斷裂。它能想、能說，但不能行動。

這一階段也出現了第一波泡沫：提示詞工程師、提示詞模板市場、提示詞課程和提示詞認證。早期模型確實對 prompt 很敏感，但市場把一個臨時補丁誤解成了長期護城河。

後來 GPT-4 級別模型、系統提示、函數調用和產品預設引導逐漸成熟，大量提示詞模板失去稀缺性。這個現象後來反覆出現：新能力出現時，中間層爆發；下一代系統把能力內化後，中間層蒸發。

2023 年中：第一代，工具調用覺醒

第一代 Agent 的關鍵詞是工具調用。

2023 年 6 月，OpenAI 發布 function calling。它允許開發者向模型描述函數名、用途、參數類型和 JSON Schema。模型理解用戶請求後，可以不再輸出普通自然語言，而是輸出一個結構化 JSON 調用，再由外部系統執行。

這一步的架構意義很大：模型開始從「只會說話的大腦」，變成可以驅動外部工具的大腦。

第一代的關鍵能力包括：

根據用戶意圖選擇工具；
輸出結構化參數；
調用外部 API；
把 API 結果帶回模型繼續推理；
通過 RAG 接入外部知識；
通過插件和知識庫形成早期 persona。

同一時期，RAG 和向量資料庫流行起來。它們解決的是模型不知道最新資訊、企業私有資料和內部知識的問題。系統先檢索相關文檔片段，再把材料放進上下文，讓模型基於這些材料回答。

於是第一代 Agent 的基本結構出現了：

你是誰：系統提示和 persona；
你知道什麼：知識庫、RAG、私有文檔；
你能做什麼：函數調用、插件、外部 API。

這一代最典型的泡沫是 AutoGPT。它展示了一個很誘人的想法：用戶只給一個宏大目標，AI 自己拆解任務、搜索、寫文件、評估、循環，直到它認為完成。

但 AutoGPT 很快暴露問題。它缺少狀態約束、終止條件和可靠反饋，經常陷入錯誤方向，反覆調用錯誤參數，或者燒掉大量 API 請求。第一代的教訓很直接：工具加死循環，不等於生產級 Agent。

2023 年末到 2024 年：第二代，工程化工作流

AutoGPT 的失敗讓行業意識到，不能只靠模型自由發揮。複雜任務需要結構化流程。

第二代 Agent 的關鍵詞是工程化工作流。Agent 不再只是一次模型調用，而是一個有狀態、有控制流、有評估機制的軟體系統。

這一代的關鍵能力包括：

任務規劃：把大目標拆成步驟；
狀態管理：記錄任務進行到哪裡；
反思修正：生成後自評，再修改；
工具編排：在不同工具之間切換；
人機協作：在關鍵節點讓人確認；
多 Agent 協作：讓不同角色分工。

典型範式是 ReAct，也就是 Reasoning + Acting。模型先推理，再調用工具，再根據觀察結果進入下一輪推理。這樣 Agent 不再盲目行動，而是每一步都有可審計的邏輯和反饋。

第二代的價值，是把模型能力放進可控流程裡。一個設計好的 workflow，有時能讓較小模型完成比單次大模型調用更穩定的結果。

但這一代也帶來低代碼 Agent 平台泡沫。很多平台用拖拽方式組合 prompt、RAG、插件和流程，確實降低了搭建門檻。但如果一個流程可以被低成本複製，平台本身就很難形成護城河。

低代碼工具能吃到早期紅利，但紅利不等於壁壘。

2024 到 2025 年：第三代，Computer Use 進入真實界面

第三代 Agent 的關鍵詞是 Computer Use。

此前的工具調用主要依賴 API，能做什麼取決於開發者提前接好什麼接口。但現實世界裡，大量軟體沒有理想 API，或者 API 不開放、不完整、不統一。

Computer Use 類能力讓模型開始看螢幕、點滑鼠、操作 GUI。它把通用電腦界面本身變成工具。

第三代的關鍵能力包括：

識別螢幕內容；
點擊按鈕、輸入文本、切換視窗；
操作網頁和桌面軟體；
讀倉庫、改文件、跑測試；
查看終端輸出和錯誤資訊；
更接近真實工程助手。

這一步把 Agent 從「調用已接好的工具」，推進到「像人一樣操作軟體界面」。它也讓 coding agent 更接近真實工作流：讀專案、改代碼、運行測試、根據報錯繼續修。

但信任邊界也擴大了。AI 操作電腦，意味著它可能誤點、誤刪、誤提交，也可能被網頁、文檔或界面文字誘導。提示注入不再只是聊天問題，而可能變成文件操作、權限和系統安全問題。

第三代的核心教訓是：越接近真實操作，越需要沙箱、審批、回滾和最小權限。

2025 到 2026 年：第四代，MCP、Skills 和常駐數位員工

第四代 Agent 的關鍵詞是常駐、連接、記憶和專業化。

這一代的重點不只是單次任務更強，而是 Agent 開始擁有長期上下文、工具網路、專業技能和時間感。它不再只是一次聊天裡的助手，而更像一個能持續工作的數位員工。

MCP 解決的是工具連接問題。它讓 Agent 用標準方式連接文件系統、資料庫、瀏覽器、設計工具、專案管理工具和企業系統。協議一旦穩定，很多只做「工具連接中間層」的專案就會被壓縮。

Skills 解決的是專業方法問題。工具告訴 Agent 能做什麼，技能告訴 Agent 應該怎麼做。一個好的 skill 不只是 prompt，而是把領域流程、約束、檢查方式、常見坑和工具調用順序封裝起來。

第四代的關鍵能力包括：

長期記憶：保存用戶偏好、專案規則和歷史任務；
專案上下文：讓 Agent 理解代碼庫、文檔和工作規範；
工具網路：通過 MCP、API、瀏覽器和文件系統連接外部世界；
專業技能：用 Skills 封裝任務方法；
常駐執行：可以等待、喚醒、提醒和繼續跟進；
遠端協作：用戶可以從不同設備回來審批和調整。

這一代 Agent 開始有「員工感」：有身份和職責邊界，有長期上下文，有專業工作方法，有時間感，有工具權限，也能在無人盯著時繼續推進任務。

但能力越像員工，風險半徑也越像員工。長期執行、讀取本地資料、持有密鑰、調用工具、處理任務，都讓安全問題從邊緣變成中心。

尤其要注意一點：文本也是攻擊面。如果 Agent 會讀取並遵循 Markdown、說明文檔、技能包、網頁內容，那麼惡意文本就可能改變它的行為。提示注入不再只是聊天問題，而是供應鏈問題、權限問題和執行安全問題。

第四代的核心教訓是：常駐 Agent 不只需要能力，還需要治理。

2026 之後：第五代前瞻，閉環、內在記憶和世界模型

第五代還不是確定歷史，更像是沿著前面四年的演進邏輯繼續外推。

成熟 Agent 至少需要三層閉環：

執行閉環：每一步操作後驗證結果，不符合預期就回滾、修正、重試；
時間閉環：跨多個喚醒週期追蹤長期目標，而不是做完一次動作就結束；
認知閉環：知道哪些資訊確定，哪些只是猜測，哪些已經過期。

第二個方向是內在記憶。過去的記憶大多在模型外部：RAG、向量庫、會話記錄、本地文件、memory.md。如果未來模型架構本身支援跨會話持久狀態，Agent 的記憶系統會被重構。

第三個方向是世界模型。今天很多 Agent 仍是反應式的：觀察、響應、再觀察。真正高風險任務需要模型能預演行動後果。

第四個方向是具身化。前幾代主要發生在數位空間：API、螢幕、文件、瀏覽器、企業工具。下一步可能是把 Agent 的行動能力延伸到物理世界。

第五代真正要解決的問題，是如何讓 Agent 不只會執行任務，還能理解行動後果、管理長期狀態，並在更大風險半徑內保持可靠。

這條時間線背後的六條規律

第一，基座模型能力仍然是天花板。Agent 不是大模型之外的魔法，而是大模型能力通過工程系統釋放出來的方式。

第二，工程化架構會放大模型能力。規劃、驗證、反思、修正、評估和權限控制，比單次生成更接近可交付結果。

第三，開放協議會重塑價值分配。MCP、Skills、專案上下文規範一旦穩定，競爭焦點會從「誰先接了工具」轉向「誰沉澱了真實領域能力」。

第四，Agent 演化的隱含主線是人機信任邊界擴展。從信任文本，到信任 API 調用，到信任複雜工作流，到信任電腦操作，再到信任常駐執行，每一代都把風險半徑往外推。

第五，每一代事故都會變成下一代鐵律。AutoGPT 的無限循環推動結構化編排，vibe coding 的失控推動評估驅動開發，誤刪生產環境推動最小權限和沙箱，技能投毒推動供應鏈安全。

第六，Agent 生態會反覆經歷爆發和滅絕。能力升級會創造臨時中間層，模型或平台內化後又會消滅這些中間層。把時間窗口誤判成護城河，是 AI 創業裡很危險的錯覺。

真正的護城河

AI Agent 領域真正的護城河，不是搶先包裝某個新能力。

更可靠的護城河大概有三類。

第一，垂直領域深度。你是否真的理解一個行業的流程、風險、異常和責任邊界。

第二，資料飛輪。你是否能從真實使用中積累高品質反饋，不斷改進流程、評估、微調和產品判斷。

第三，用戶信任。用戶是否願意把更高價值、更長期、更有風險的任務交給你，而不是只把你當成一次性工具。

當某項能力被平台或基座模型吞噬之後，仍然能沉澱流程、反饋、責任邊界和信任的產品，才更可能留下來。

最後

從 2022 年到 2026 年，AI Agent 的演進不是「模型越來越會聊天」，而是「人類願意交給 AI 的事情越來越多」。

真正成熟的 Agent，不是最敢自動執行的系統，而是知道何時執行、何時驗證、何時暫停、何時請人確認的系統。

如果要判斷一個 Agent 產品是否有長期價值，可以問一個問題：當這個能力被下一代模型或平台內置後，它還剩下什麼？

答案如果是領域流程、真實資料、可驗證結果和用戶信任，那才可能是長期價值。

Codex 手機遠端存取來了：用 ChatGPT App 跟進 Mac 上的編程任務

Sat, 16 May 2026 17:42:40 +0800

OpenAI 在 2026 年 5 月中旬把 Codex remote access 帶進 ChatGPT 手機 App。這個功能的重點不是「在手機上寫程式」，而是讓你用手機遠端跟進 Mac 上正在執行的 Codex。

它更像一個行動審批和監控入口：Codex 繼續在電腦上讀專案、跑命令、改檔案、看測試結果；手機端負責查看進度、回答問題、補充指令和批准操作。

對經常讓 Codex 跑長任務的人來說，這個變化很實用。你不必一直坐在電腦前等它卡在哪裡，離開工位後也能從 ChatGPT App 接上現場。

它能做什麼

根據 OpenAI Codex remote connections 文件，手機端遠端存取可以：

在 Mac 主機上的專案裡開啟新 thread，或繼續已有 thread；
發送後續指令，回答 Codex 的問題，調整任務方向；
批准命令和其他操作；
查看輸出、diff、測試結果、終端輸出和截圖；
在 Codex 完成任務或需要你注意時收到通知；
在多個已連接主機和 thread 之間切換。

也就是說，手機端不是簡化版聊天視窗，而是接入了 Codex 目前的工作現場。

使用前需要什麼

第一，你需要有可用的 Codex 權限，並且手機和 Mac 使用同一個 ChatGPT 帳號與 workspace。

第二，手機上要安裝最新版 ChatGPT App，iOS 或 Android 都可以。如果 App 裡看不到 Codex，先更新 ChatGPT。

第三，主機目前要求是 Mac，並且需要保持在線、喚醒、正在執行 Codex App。OpenAI 文件明確寫到，行動端設定和裝置控制目前需要主機上執行 Codex App for macOS，不能從 Codex CLI 或 IDE Extension 完成設定。

第四，如果帳號或 workspace 要求 MFA、SSO 或 passkey，需要先完成對應認證。團隊 workspace 還可能需要管理員開啟 Remote Control access。

Codex 手機遠端存取的限制

第一，當前需要 macOS host。手機端連接的是 Mac 上執行的 Codex App，不是直接連接 Codex CLI、IDE Extension，也不是任意 Linux / Windows 開發機。

第二，主機必須在線。Mac 需要保持喚醒、連網，並持續執行 Codex App。如果電腦睡眠、斷網或 Codex 關閉，手機端遠端會話就可能斷開。

第三，連線依賴掃碼流程。你需要先在 Mac 端開啟 Set up Codex mobile，再用手機掃描 QR code 進入 ChatGPT 完成綁定。

第四，遠端操作仍然要經過審批流程。手機端可以批准命令和其他操作，但你仍然要看清 Codex 請求做什麼，再決定是否繼續。

所以它適合「人離開電腦後繼續跟進任務」，不適合替代完整開發環境，也不適合把主機長期無人值守地開放給遠端操作。

怎麼連接

設定流程從 Mac 上的 Codex App 開始。

在 Mac 上開啟 Codex。
在側邊欄選擇 Set up Codex mobile。
Codex 會為這台主機開啟遠端存取，並顯示 QR code。
用手機掃描 QR code，進入 ChatGPT 裡的 Codex mobile setup 流程。
確認同一個 ChatGPT 帳號和 workspace。
完成必要的 MFA、SSO 或 passkey 驗證。
設定成功後，這台 Mac 會出現在手機端 Codex 裡。

連接完成後，可以在 Mac 端 Codex 的 Settings > Connections 管理已連接裝置，也可以設定是否讓電腦保持喚醒、是否啟用 Computer Use、是否安裝 Chrome extension。

手機端適合做什麼

手機端最適合三類操作：審批、糾偏和查看結果。

Codex 需要執行命令、存取檔案或繼續某個動作時，你可以在手機上看清請求，再決定是否批准。當 Codex 誤解需求、測試失敗或需要方向判斷時，也可以直接補充一句說明。最後，你可以查看 diff、測試輸出、終端日誌和截圖，不必回到電腦前才知道任務進度。

真正有價值的不是手機寫程式，而是把手機變成工程任務的隨身控制台。

常見問題

如果手機上看不到主機，先確認 Mac 上 Codex App 仍在執行，並且開啟了 Allow other devices to connect。手機和主機也必須使用同一個 ChatGPT 帳號與 workspace。

如果審批請求沒有出現，可以打開 ChatGPT 手機 App，進入 Codex，再重新掃碼或從主機重新開始設定。團隊帳號還要確認管理員是否已允許 Remote Control access。

如果遠端會話斷開，通常要檢查 Mac 是否睡眠、網路是否斷開、Codex App 是否關閉。

如果認證卡住，就先完成 MFA、SSO、passkey 流程。企業環境裡，權限問題往往要管理員介入。

適合哪些場景

它適合經常讓 Codex 跑較長程式修改任務、需要離開工位後繼續審批和跟進、同時管理多個專案或 thread，並且以 Mac 作為主力開發機的人。

不太適合主要使用 Windows 或 Linux、只用 Codex CLI 或 IDE Extension、希望手機端獨立完成完整開發環境，或網路不穩定的人。

我的判斷

Codex 手機遠端存取的意義，不是把開發工作搬到手機螢幕上，而是讓「等待 Codex 跑完」的時間更可控。

以前 Codex 長任務經常卡在審批、追問、測試失敗或方向確認上。現在這些節點可以透過 ChatGPT 手機 App 處理，Mac 繼續做真正的工程執行，手機負責輕量決策。

如果你已經在 Mac 上重度使用 Codex，這個功能值得開啟。如果你只是偶爾問幾句程式問題，它的價值可能沒那麼明顯。

參考資料

ChatGPT File Library 是什麼：文件保存、容量限制和隱私邊界

Sat, 16 May 2026 17:40:14 +0800

ChatGPT File Library 可以理解成 ChatGPT 裡的文件庫。

以前你在某個對話裡上傳文件，更多像是一次性給這輪聊天使用。File Library 出現後，上傳到 ChatGPT 或由 ChatGPT 建立的文件會保存到帳號裡，之後可以在 Library 中重新找到、下載、刪除，或者在新對話裡再次引用。

這讓 ChatGPT 更像一個長期資料工作區，而不只是臨時聊天視窗。

它會保存哪些文件

ChatGPT 會自動保存你上傳或建立的文件，包括：

文件；
試算表；
簡報；
PDF；
圖片；
ChatGPT 生成的文件。

生成圖片仍會繼續出現在 Images 標籤頁。File Library 更像是統一管理上傳文件和生成文件的地方。

如果你經常讓 ChatGPT 分析 PDF、整理表格、生成文件、處理簡報，這個功能會減少重複上傳，也方便在不同對話裡繼續使用。

怎麼把文件加入新對話

在支援的客戶端裡，可以從輸入框附近的附件或新增選單進入文件選擇。

常見流程是：

打開 composer 選單，也就是附件或新增按鈕。
選擇 Add from library。
選擇要引用的文件。

Release Notes 還提到，Library 和 composer 裡的 Recent files 支援 Web、iOS 和 Android。

怎麼查找和管理

在網頁端，可以從左側邊欄進入 Library，集中查看上傳和生成的文件。

文件可以按類型和來源篩選。官方說明頁提到的篩選維度包括上傳文件、生成文件、圖片、文件、試算表、簡報和 PDF。

Storage 入口可以查看總使用量、剩餘容量，以及是否超過限制。Release Notes 說明，儲存管理可從 Settings > Storage 進入，文件也可以直接在 Library 中刪除。

各方案容量

OpenAI 在 2026 年 5 月 14 日的 Release Notes 中給出的容量如下：

方案	File Library 容量
Free	500 MB
Go	4 GB
Plus	20 GB
Business	20 GB
Pro	100 GB

這個容量包括上傳文件，也包括 ChatGPT 建立的文件，例如文件、試算表、簡報和圖片。

單文件限制

OpenAI 說明頁列出的文件限制包括：

上傳到 GPT 或 ChatGPT 對話的單個文件最大 512 MB；
文字和文件類檔案最多 200 萬 token；
CSV 或試算表通常約 50 MB，具體取決於每列大小；
圖片單張最大 20 MB。

這些限制和帳號總容量是兩回事。即使你的帳號還有很多剩餘空間，單個文件也不能超過對應上限。

刪除和下載

文件會保存在帳號中，直到你手動刪除。

刪除方式一般是在 Library 中選中文件，然後點擊刪除或垃圾桶圖示。OpenAI 說明頁表示，刪除後文件會立即從帳號中移除，並計畫在 30 天內從 OpenAI 系統中永久刪除，除非已去識別化並與帳號脫離關聯，或出於安全、法律義務需要保留更久。

文件也可以從 Library 中下載。對於經常讓 ChatGPT 生成文件、表格或簡報的人，下載和清理會成為日常維護的一部分。

Temporary Chat 不會保存文件

如果你在 Temporary Chat 中上傳文件，文件不會保存到帳號或 Library。

File Library 的預設邏輯是方便長期複用，而 Temporary Chat 更適合臨時、敏感、不想留下長期上下文的任務。

資料和訓練設定

OpenAI 說明頁表示，文件和聊天會按照你的設定與資料控制項使用。

如果開啟了 Memory，文件和聊天可能會幫助 ChatGPT 在對話之間記住對你有用的資訊。對個人服務使用者來說，如果開啟了 Improve the model for everyone，OpenAI 也可能使用提交到 ChatGPT 的內容，包括上傳文件，來改進模型表現。這個設定可以在 Settings > Data Controls 中關閉。

這意味著 File Library 不是一個單純的本機資料夾。它是雲端帳號功能，使用前要想清楚哪些資料適合上傳。

適合怎麼用

File Library 適合長期分析同一組 PDF 或報告、反覆處理課程資料和會議材料、繼續修改 ChatGPT 生成的文件或表格、在多個對話裡複用同一份素材。

不太適合上傳高度敏感的身分證明、合約、病歷、財務流水，也不應把它當成正式雲端備份，或在不了解資料控制設定時上傳公司內部文件。

我的判斷

ChatGPT File Library 的價值不只是「多了一個文件列表」。它改變的是 ChatGPT 的使用方式：過去是一輪一輪聊天，現在開始變成帶資料沉澱的工作空間。

但這也帶來新習慣。使用者需要定期清理文件，關注容量，區分普通聊天和 Temporary Chat，也要檢查資料控制設定。

如果你經常用 ChatGPT 看文件、改表格、整理資料，File Library 會明顯省時間。如果你只是偶爾上傳一份敏感文件問幾句，反而要更謹慎。

參考資料

OpenAI 新一代 Realtime 語音模型：GPT-Realtime-2、即時翻譯與串流轉寫

Sat, 09 May 2026 10:58:47 +0800

OpenAI 在 2026 年 5 月 7 日發布了新一代 Realtime API 語音模型，重點不只是「說得更像人」，而是讓語音代理可以在即時對話中理解、推理、呼叫工具、翻譯和轉寫。

這次更新包括三個模型：

GPT-Realtime-2：面向即時語音 Agent 的主模型，支援更強推理、工具呼叫和長上下文。
GPT-Realtime-Translate：即時語音翻譯模型，支援 70 多種輸入語言到 13 種輸出語言。
GPT-Realtime-Whisper：低延遲串流語音轉文字模型，用於字幕、會議記錄和即時工作流。

如果說早期語音助手更像「問一句、答一句」，這次更新的方向更接近「邊聽邊做事」的語音介面。

GPT-Realtime-2：語音 Agent 的主力模型

GPT-Realtime-2 面向即時語音互動場景。它不只是回答問題，還要在使用者說話、改口、插話、補充限制時保持上下文，並在必要時呼叫工具完成任務。

官方重點提到的能力包括：

可以在回答前輸出簡短提示，例如「我查一下」，讓使用者知道系統正在處理。
支援並行工具呼叫，適合日程、搜尋、訂單、客服系統等多工具場景。
失敗恢復更自然，避免語音會話突然中斷或沉默。
上下文窗口從 32K 提升到 128K，適合更長的對話和複雜任務流。
對專業術語、專有名詞、醫療詞彙等場景有更好的保持能力。
語氣和表達方式更可控，可以根據場景調整為冷靜、同理、確認或更有活力的語氣。
reasoning effort 可調，支援 minimal、low、medium、high、xhigh，預設是 low。

這意味著開發者可以把語音 Agent 用在更複雜的業務裡，而不是只做簡單問答。例如客服可以邊聽使用者描述邊查訂單；旅行應用可以根據航班變化主動給出下一步建議；房產應用可以根據使用者口頭條件篩選房源並安排看房。

即時翻譯：面向跨語言語音產品

GPT-Realtime-Translate 的定位是即時語音翻譯。使用者可以用自己的語言說話，對方聽到翻譯後的語音，同時還能看到即時轉寫。

它適合的場景比較明確：

多語言客服。
跨境銷售和售前溝通。
線上教育和直播活動。
國際會議與活動主持。
影片平台和創作者內容在地化。

即時翻譯的難點不只是「翻譯準」，還包括低延遲、自然停頓、語氣保留、口音適應和專業詞彙處理。OpenAI 這次強調的是讓跨語言對話更接近自然交流，而不是等一整段說完後再翻譯。

串流轉寫：讓語音內容馬上進入工作流

GPT-Realtime-Whisper 是新的串流語音轉文字模型。它的價值在於把語音在發生時就變成可處理文字，而不是等錄音結束再統一轉寫。

常見應用包括：

會議即時字幕。
課堂和直播字幕。
即時會議紀要。
語音 Agent 的連續聽寫輸入。
客服、醫療、招聘、銷售等高頻語音場景的後續流程。

對產品來說，串流轉寫可以明顯縮短「說話到可操作文字」的時間。字幕更快出現，會議記錄可以邊說邊生成，後續摘要、任務提取、CRM 寫入等流程也能更早啟動。

價格與可用性

這三個模型都已經在 Realtime API 中可用。官方給出的價格是：

模型	價格
`GPT-Realtime-2`	音訊輸入 $32 / 1M tokens，快取輸入 $0.40 / 1M tokens，音訊輸出 $64 / 1M tokens
`GPT-Realtime-Translate`	$0.034 / 分鐘
`GPT-Realtime-Whisper`	$0.017 / 分鐘

OpenAI 還提到，Realtime API 支援 EU Data Residency，並受到企業隱私承諾覆蓋。對於歐洲企業或有資料駐留要求的語音產品，這是需要單獨評估的一點。

對開發者意味著什麼

這次發布的重點，是語音能力開始從「輸入輸出層」變成「產品互動層」。

過去很多語音功能只是把語音轉成文字，再把文字回覆轉成語音。真正難的是中間那層：理解使用者意圖、處理打斷、補全上下文、呼叫工具、告訴使用者系統正在做什麼、在失敗時自然恢復。

GPT-Realtime-2 試圖把這部分能力直接放進即時語音模型裡。對開發者來說，最值得關注的不是單次回答品質，而是它能否支撐持續會話和多步驟任務。

比較適合優先嘗試的產品包括：

客服語音 Agent。
車載和行動端語音助手。
旅遊、訂票、房產、金融等需要邊問邊查的服務。
多語言會議和跨境溝通工具。
即時字幕、會議紀要和通話質檢系統。

也要注意安全和告知

OpenAI 在發布頁中強調，Realtime API 會包含多層安全措施，例如對會話進行主動分類，必要時中止違反政策的內容。開發者也可以透過 Agents SDK 增加自己的安全護欄。

還有一個容易被忽略的要求：當終端使用者正在與 AI 互動時，開發者需要清楚告知，除非場景本身已經足夠明顯。

這對客服、銷售、教育、醫療等場景都很重要。語音越自然，越需要在產品設計上明確邊界：使用者知道自己在和 AI 溝通，也知道哪些操作會被記錄、轉寫或觸發工具呼叫。

總結

OpenAI 這次 Realtime API 更新，把即時語音從「能聽能說」推進到「能邊聽邊處理任務」。

GPT-Realtime-2 負責更複雜的語音 Agent，GPT-Realtime-Translate 負責跨語言即時交流，GPT-Realtime-Whisper 負責低延遲轉寫。三者合在一起，覆蓋了語音產品裡最常見的三個基礎能力：對話、翻譯和轉寫。

如果你正在做客服、車載、會議、教育、跨境溝通或行動端語音助手，這次更新值得重點測試。真正需要驗證的，不只是模型聽起來是否自然，而是它在長對話、打斷、工具呼叫、失敗恢復和成本控制上的表現。

參考連結：

OpenAI：Advancing voice intelligence with new models in the API

GPT-5.5、GPT-5.5 Instant、GPT-5.5 Thinking 和 GPT-5.5 Pro 有什麼區別

Thu, 07 May 2026 21:59:33 +0800

OpenAI 現在把 GPT-5.5 拆成了幾個更明確的使用層級：Instant、Thinking 和 Pro。

很多人看到 GPT-5.5、GPT-5.5 Instant、GPT-5.5 Thinking、GPT-5.5 Pro 會混在一起。簡單說：GPT-5.5 是這一代模型能力的總稱，Instant 是日常快速模型，Thinking 是深度推理模式，Pro 是更高強度的研究級模式。

快速對比

名稱	本質	適合場景	速度/成本	可用性
GPT-5.5	GPT-5.5 主模型/家族名；在 ChatGPT 裡通常對應 GPT-5.5 Thinking 的能力定位	複雜工作、程式碼、研究、分析、工具呼叫	比 Instant 更重，但能力更強	Plus、Pro、Business、Enterprise
GPT-5.5 Instant	快速預設模型，替代 GPT-5.3 Instant	日常問答、寫作、摘要、輕量程式碼、快速查詢	最快、最省額度	面向所有 ChatGPT 使用者逐步推出
GPT-5.5 Thinking	深度推理模式	難題、長上下文分析、複雜程式碼、研究、文件密集任務	較慢，但推理更穩	付費使用者可手動選擇
GPT-5.5 Pro	更高強度的研究級模式	高風險/高精度任務：法律、商業、教育、資料科學、科研分析	最慢、最重，追求品質	Pro、Business、Enterprise、Edu

如果只想記一個選擇規則：

日常快速任務：用 GPT-5.5 Instant。
複雜推理和程式碼分析：用 GPT-5.5 Thinking。
特別難、特別重要、需要更全面嚴謹：用 GPT-5.5 Pro。

GPT-5.5 是什麼

單獨說 GPT-5.5 時，通常是在說 GPT-5.5 這一代主模型能力，而不是某一個固定按鈕。

OpenAI 對 GPT-5.5 的定位是「面向真實工作的更強模型」。它重點提升的是：

agentic coding；
複雜程式碼除錯；
研究和資料綜合；
文件、表格、簡報生成；
電腦使用和跨工具工作；
長任務中的持續推理和自我檢查。

在 ChatGPT 裡，使用者看到的不是一個籠統的 GPT-5.5 按鈕，而是更具體的 Instant、Thinking、Pro。所以如果有人說「我在用 GPT-5.5」，最好再問一句：是 Instant、Thinking，還是 Pro？

GPT-5.5 Instant：預設、快速、日常使用

GPT-5.5 Instant 是新的快速預設模型。OpenAI 官方說明裡，它開始替代 GPT-5.3 Instant，成為 ChatGPT 的預設模型，並在 API 中作為 chat-latest 提供。

它適合這些任務：

日常聊天；
快速問答；
普通寫作；
摘要文章；
改寫郵件；
輕量程式碼解釋；
簡單表格和清單；
不需要長時間推理的任務。

Instant 的核心優勢是速度和預設可用性。你不需要每次都手動選擇推理模式，也不需要為普通問題付出更高延遲。

它還有一個變化：OpenAI 強調 GPT-5.5 Instant 的回答更清晰、更簡潔，並且個人化能力更強。對普通使用者來說，這意味著它更適合「每天一直開著用」。

需要注意的是，Instant 不是「最強模式」。遇到複雜數學、長程式碼、架構設計、多檔案分析、嚴肅研究時，它可能會自動切換到 Thinking，也可能需要你手動選擇 Thinking。

GPT-5.5 Thinking：複雜任務的主力

GPT-5.5 Thinking 是更適合複雜任務的推理模式。

它適合這些場景：

程式碼除錯；
架構設計；
多步驟推理；
長文件分析；
學術資料整理；
商業方案推演；
資料分析解釋；
需要比較、權衡、驗證的任務。

Thinking 的特點是會花更多時間推理。OpenAI Help Center 提到，當 GPT-5.5 Thinking 或 GPT-5.5 Pro 開始推理時，可能會先顯示一個簡短 preamble，說明它打算怎麼做。使用者也可以在模型還在 thinking 時追加指令，提前調整方向。

在 ChatGPT 裡，手動選擇 Thinking 時，還可以調整 thinking time。官方說明中，Plus 和 Business 使用者可以使用 Standard 和 Extended；Pro 使用者還會有 Light 和 Heavy 等更多選項。

我的理解是：Thinking 是「認真幹活」的預設選擇。只要任務涉及多步驟、長上下文或高準確性要求，就比 Instant 更合適。

GPT-5.5 Pro：研究級、更重、更嚴謹

GPT-5.5 Pro 是面向更難問題和更高精度工作的模式。

它適合這些場景：

法律材料分析；
商業研究；
教育和課程設計；
資料科學；
科研資料綜合；
高風險決策前的深度審閱；
多文件、多約束、多輪驗證任務。

OpenAI 在 GPT-5.5 發布說明中提到，早期測試者認為 GPT-5.5 Pro 相比 GPT-5.4 Pro，在完整性、結構性、準確性、相關性和實用性上都有明顯提升，尤其在商業、法律、教育和資料科學領域表現更強。

Pro 的缺點也很明顯：它更慢、更重，不適合每個小問題都用。它更像「專家審閱/研究夥伴」，而不是日常聊天入口。

另外，Pro 在工具支援上有特殊限制。OpenAI Help Center 寫明，Apps、Memory、Canvas 和圖像生成不適用於 Pro。如果你的任務需要這些 ChatGPT 功能，可能要用 Instant 或 Thinking。

工具支援有什麼不同

根據 OpenAI Help Center，GPT-5.5 Instant 和 GPT-5.5 Thinking 支援 ChatGPT 的常用工具，包括：

Web search；
Data analysis；
Image analysis；
File analysis；
Canvas；
Image generation；
Memory；
Custom Instructions。

GPT-5.5 Pro 更偏研究級推理，但不是所有 ChatGPT 工具都可用。尤其要注意：

Apps 不可用；
Memory 不可用；
Canvas 不可用；
圖像生成不可用。

所以選擇模型時，不只看「哪個更聰明」，還要看你要用哪些工具。

上下文窗口有什麼區別

官方 Help Center 給出的 ChatGPT 上下文窗口說明大致是：

模式	上下文窗口
GPT-5.5 Instant	Free：16K；Plus/Business：32K；Pro/Enterprise：128K
GPT-5.5 Thinking	付費檔手動選擇時通常為 256K；Pro 檔可到 400K

這意味著：

普通聊天和短文件，Instant 足夠；
多檔案、多輪研究、長程式碼庫分析，Thinking 更合適；
特別長、特別複雜的高精度任務，Pro 使用者可以利用更大的上下文和更重推理。

怎麼選

日常問答

用 GPT-5.5 Instant。

它速度快，足夠聰明，適合隨手問、快速寫、快速改。

寫文章、摘要、改郵件

優先用 GPT-5.5 Instant。

如果文章很長、需要結構重寫、需要多輪校對，再切到 GPT-5.5 Thinking。

寫程式碼和除錯

簡單程式碼解釋用 Instant。

多檔案除錯、架構設計、複雜報錯分析，用 Thinking。如果是非常棘手的長期工程問題，可以考慮 Pro。

研究和資料分析

普通資料整理用 Thinking。

如果是法律、商業、科研、資料科學這類高精度任務，用 Pro 更合適。

需要圖像生成、Canvas、Memory

優先用 Instant 或 Thinking。

不要預設選 Pro，因為 Pro 不支援部分 ChatGPT 工具。

簡短結論

GPT-5.5 Instant 是日常預設模型，快、清晰、省額度，適合多數普通任務。

GPT-5.5 Thinking 是複雜任務主力，適合程式碼、研究、長文件、分析和多步驟推理。

GPT-5.5 Pro 是高精度研究模式，適合更難、更重要、更需要嚴謹性的任務，但工具支援和速度都更受限制。

GPT-5.5 本身更像這一代模型的總稱。真正選擇時，要看你在 ChatGPT 裡選的是 Instant、Thinking 還是 Pro。

ChatGPT、Claude Code 和 Gemini 的記憶機制有什麼不同？

Thu, 07 May 2026 14:47:17 +0800

AI 產品裡的「記憶」正在變得越來越重要。它標誌著 AI 從「單次對話工具」走向「長期協作夥伴」：不用每次重新介紹背景，不用反覆解釋偏好，也不用讓模型一次次重新理解項目。

但不同產品裡的記憶並不是一回事。ChatGPT、Claude Code 和 Gemini 都在解決「AI 如何記得更久」的問題，但它們的設計目標、儲存位置、透明度和適用場景差異很大。

截至 2026 年 5 月 7 日，可以把它們粗略理解成三類：

ChatGPT 更像「個人助理記憶」。
Claude Code 更像「工程項目記憶」。
Gemini 更像「Google 生態上下文」。

ChatGPT：圍繞人的長期偏好

ChatGPT 的記憶機制主要面向個人協作。它關心的是「你是誰」「你偏好什麼」「你長期在做什麼」。

OpenAI 目前把 ChatGPT 的記憶分成兩類：saved memories 和 chat history。

saved memories 是 ChatGPT 保存下來的重要資訊，比如你的名字、偏好、目標、常用技術棧、寫作習慣等。你可以直接要求它記住某件事，它也可能在對話中自動保存它認為未來有用的資訊。

chat history 則是讓 ChatGPT 在回答時參考過去聊天。它不等於把每一段聊天都完整變成記憶，而是在需要時從過往對話裡找相關上下文。

所以 ChatGPT 的核心邏輯是：跨會話理解同一個使用者。

典型例子包括：

「以後給我程式碼示例時盡量簡潔。」
「我主要使用 Python 和 TypeScript。」
「我正在寫一個關於 AI 工具的 Hugo 部落格。」
「我喜歡先看結論，再看細節。」

這些記憶不是綁定某個單獨項目，而是跟隨帳號和個人使用習慣。

Memory Sources：讓個性化來源更可見

OpenAI 在 2026 年 5 月的更新中強調了 Memory sources。

它的作用不是新增另一種記憶，而是讓使用者看到 ChatGPT 在個性化回答時參考了哪些來源。根據 OpenAI 幫助文件，Memory Sources 可能顯示：

過去聊天。
保存記憶。
自定義指令。
文件庫中的文件。
已連接 Gmail 中的郵件。

其中，文件和 Gmail 的可見範圍會受到計畫、地區和連接狀態限制。OpenAI 也明確說明，Memory sources 不一定展示影響回答的所有因素，而是幫助使用者理解和管理個性化。

這一步很重要。因為 AI 越會「記住你」，使用者越需要知道它到底根據什麼在回答。否則個性化很容易變成黑箱：你感覺它好像知道你，但不知道它為什麼知道。

ChatGPT 的優勢是跨會話、跨主題持續理解個人偏好；風險是記憶容易過期，或者使用者忘了某條舊記憶還在影響回答。因此，適合定期清理 saved memories 和舊聊天。

Claude Code：圍繞程式碼庫和工程規則

Claude Code 的記憶機制更偏工程協作。它關心的不是「使用者平時愛喝什麼咖啡」，而是「這個程式碼庫應該怎麼改」。

Claude Code 有兩類容易混在一起的記憶：

顯式項目記憶：CLAUDE.md。
自動項目記憶：Auto Memory。

CLAUDE.md 是最基礎、最穩定的項目記憶文件。它可以放在項目根目錄，也可以在子目錄中存在。Claude Code 會讀取這些文件，把它們作為項目說明和操作規則。

適合寫進 CLAUDE.md 的內容包括：

常用構建、測試、lint 命令。
程式碼風格和命名規則。
項目架構說明。
模組邊界和危險區域。
團隊約定和提交流程。

如果 CLAUDE.md 放在程式碼庫裡，它可以提交到 Git，成為團隊共享的 agent 說明書。這一點和 ChatGPT 的雲端個人記憶完全不同。

Claude Code Auto Memory：自動累積項目經驗

Claude Code 現在也有 Auto Memory。它的目標是讓 Claude 在多個會話之間自動累積項目經驗，而不要求使用者每次手寫說明。

根據 Claude Code 文件，Auto Memory 會讓 Claude 在工作過程中為自己保存筆記，例如構建命令、調試發現、架構說明、程式碼風格偏好和工作流習慣。它不會每個會話都保存，而是判斷哪些資訊未來可能有用。

這裡有一個容易誤解的點：Auto Memory 預設不是把內容寫到項目根目錄的 .claude/memory.md。官方文件說明，每個項目會在使用者目錄下擁有自己的 memory 目錄，路徑類似：

`1`	`~/.claude/projects/<project>/memory/`

其中 MEMORY.md 會在每次對話開始時載入前 200 行或前 25KB，詳細內容則可能被拆到其他主題文件裡。Auto Memory 文件是本機本地的 Markdown 文件，使用者可以透過 /memory 查看、編輯或刪除。

這讓 Claude Code 的記憶更像「本機上的項目經驗庫」。它比 ChatGPT 的個人記憶更貼近程式碼庫，也比單純的 CLAUDE.md 更動態。

但要注意，Auto Memory 是機器本地的，不會天然跟隨程式碼庫同步到其他機器或雲環境。如果要團隊共享穩定規則，仍然應該優先寫進項目中的 CLAUDE.md。

Gemini：圍繞 Google 生態上下文

Gemini 的記憶邏輯又不同。

Gemini 也有保存資訊和參考過去聊天的能力。Google 幫助文件提到，使用者可以保存關於生活、工作或偏好的資訊，也可以讓 Gemini 在回答前參考過去聊天。Gemini 使用這些資訊時，可能會在回答底部的來源區域顯示 Your saved info 或 Previous chats。

但 Gemini 的差異化不只在「保存幾條偏好」，而在 Google 生態整合。

在使用者授權和功能可用的前提下，Gemini 可以透過連接的 Google 應用獲取上下文，例如 Gmail、Google Drive、Docs、Sheets 等。它的優勢不是讓使用者一條條教它記住什麼，而是把已有的 Google 帳號資料變成可檢索的工作上下文。

典型區別是：

ChatGPT 記得：「我最近在做 LTO 磁帶機修復。」
Gemini 可能可以從 Gmail 找到購買確認郵件，或從 Drive 裡讀取相關維修筆記。

當然，這不代表 Gemini 可以無條件讀取你所有 Google 資料。它取決於帳號類型、地區、權限、連接應用、Keep Activity 設定和具體產品可用性。對企業或學校帳號，還可能受 Google Workspace 管理員控制。

所以更準確地說，Gemini 的記憶不是一個單純的「備忘錄」，而是「保存資訊 + 過去聊天 + Google 生態連接」的組合。

三者核心差異

維度	ChatGPT	Claude Code	Gemini
核心對象	人和偏好	項目和程式碼庫	Google 帳號與生態資料
典型記憶	偏好、背景、長期目標	架構、命令、規範、調試經驗	saved info、過去聊天、Gmail/Drive/Docs 上下文
儲存形態	OpenAI 帳戶內的記憶和聊天上下文	`CLAUDE.md`、`MEMORY.md`、本地 Markdown 文件	Google 帳號活動、保存資訊、連接應用資料
透明度	Memory sources 可見一部分來源	Markdown 文件可直接查看和編輯	透過來源提示、Gemini Apps Activity 和 Google 設定管理
跨項目能力	強，跟隨使用者帳號	弱，主要跟隨項目或本機項目 memory	強，取決於 Google 生態資料和權限
團隊共享	不適合直接共享	`CLAUDE.md` 可隨 Git 共享	主要依賴 Workspace 和權限體系
最適合	個人偏好和長期助理	長期程式碼項目和 agent 協作	Google Workspace 資料檢索和跨工具工作

該怎麼選擇和使用

如果你想讓 AI 記住「我是誰、我喜歡什麼風格、我長期怎麼工作」，ChatGPT 的記憶更合適。

它適合保存個人偏好，例如寫作風格、常用技術棧、回答格式、職業背景、長期項目方向。它的重點是減少自我介紹成本，讓每次新對話更快進入狀態。

如果你想讓 AI 記住「這個程式碼庫怎麼改、哪些命令能跑、哪些坑不能踩」，Claude Code 更合適。

穩定規則寫進 CLAUDE.md，團隊共享；動態經驗交給 Auto Memory 輔助累積；關鍵決策最好仍然整理進文件或 CLAUDE.md，避免只停留在本機自動記憶裡。

如果你的資料大量存在 Gmail、Drive、Docs、Sheets 裡，Gemini 的生態上下文更有優勢。

它適合查找過去郵件、整理 Google Drive 文件、聯動日曆和辦公資料。使用 Gemini 的關鍵，不是反覆在聊天裡提醒它，而是確保相關應用連接、權限和活動設定正確。

一個實用分工

可以把三者這樣分工：

ChatGPT 記住「我的通用偏好」。
Claude Code 記住「這個倉庫的工程知識」。
Gemini 檢索「我在 Google 生態裡的資料」。

也就是說，ChatGPT 更像私人秘書，Claude Code 更像項目裡的資深工程同事，Gemini 更像 Google 帳號裡的資料索引員。

這三種記憶沒有絕對高低，只是目標不同。

最需要警惕的是把它們混為一談。個人偏好不一定適合寫進項目記憶；項目架構不一定適合存在雲端個人記憶；Google 生態檢索也不等於模型真正「長期理解」了你。

簡短判斷

AI 記憶的下一階段，不是簡單地「記得越多越好」，而是記憶要分層、可見、可控。

ChatGPT 的重點是跨會話個人化，Claude Code 的重點是程式碼項目連續性，Gemini 的重點是 Google 生態上下文。真正好用的長期 AI 協作，不是把所有資訊塞進一個黑箱，而是讓不同類型的記憶待在合適的位置。

個人偏好放在個人記憶裡，工程規則放在程式碼庫裡，歷史資料放在原本的文件和郵件系統裡。AI 要做的，是在需要時準確呼叫這些上下文，而不是把所有東西混成一團。

從 ChatGPT Release Notes 看 OpenAI 的產品節奏

Thu, 07 May 2026 14:31:22 +0800

OpenAI 的 ChatGPT Release Notes 是觀察 ChatGPT 產品節奏的一個直接入口。這個頁面會持續記錄 ChatGPT 的模型、功能、帳戶安全、應用整合和客戶端體驗變化。

截至 2026 年 5 月 7 日查看，頁面頂部顯示最近更新為「yesterday」，最新條目集中在 2026 年 5 月 5 日。它們看起來是幾條普通更新，但放在一起，其實能看出 ChatGPT 正在往哪裡走：預設模型更可靠，記憶更可控，辦公場景更深入，帳戶安全也在補強。

最新重點一：記憶來源變得可見

5 月 5 日的第一項更新，是 ChatGPT 的記憶改進。

OpenAI 表示，Plus 和 Pro 使用者會逐步獲得更個性化、更連續的回答。ChatGPT 可以更好地使用過去聊天、保存記憶、可用文件，以及已連接 Gmail 中的上下文，來提供更貼合使用者的建議、推薦和下一步行動。

這類能力的價值在長期使用中才明顯。使用者如果正在做一個項目、寫一系列文章、跟進一組郵件或反覆處理同類工作，最煩的就是每次都要重講背景。更強的記憶能力，就是為了減少這種重複。

但記憶越強，使用者越需要知道模型到底用了什麼上下文。因此 OpenAI 推出了 memory sources。使用者可以在回答下方查看相關保存記憶、過去聊天、自定義指令，以及在特定情況下被引用的文件和 Gmail 郵件。

如果其中的資訊已經過期、不準確或不再相關，使用者可以更正、刪除，或標記為不相關。

個性化不只是「更懂你」

很多人談 AI 個性化時，只關注「模型更懂我」。但真正能長期使用的個性化，還必須解決三個問題：

使用者能不能看見模型參考了什麼。
使用者能不能修改或刪除這些資訊。
使用者能不能在不需要記憶時關閉它。

Release Notes 裡明確提到，memory sources 只在使用者自己的帳戶體驗中顯示，分享聊天時不會把這些來源暴露給其他人。使用者也可以刪除聊天、使用臨時聊天、關閉記憶、斷開應用連接，並管理內容是否用於改進模型。

這說明 OpenAI 不是只在堆個性化能力，也在給個性化補控制介面。對長期助手來說，這一步很關鍵。

最新重點二：GPT-5.5 Instant 成為預設模型

同一天，OpenAI 還把 GPT-5.5 Instant 作為 ChatGPT 新預設模型推出，替代所有使用者原來的 GPT-5.3 Instant。

Release Notes 對這次模型更新的描述很務實：更準確、更清晰、更簡潔，圖片理解、STEM 問題，以及何時使用網頁搜尋的判斷也更好。

這類預設模型更新對使用者影響很大。大多數使用者不會每天切換模型，他們感受到的 ChatGPT 品質，就是預設模型的品質。預設模型少一點幻覺、少一點廢話、少一點無意義追問，實際體驗就會明顯改善。

OpenAI 還提到，GPT-5.5 Instant 會減少過度格式化和不必要的裝飾性內容。這一點雖然小，但很貼近日常使用。很多時候，使用者並不需要一篇結構完整的小論文，只需要一個準確、直接、能執行的回答。

付費使用者還可以繼續使用 GPT-5.3 Instant 三個月，之後該模型會退役。

最新重點三：ChatGPT 進入 Excel 和 Google Sheets

5 月 5 日的第三項更新，是 ChatGPT for Excel 和 Google Sheets 全球上線。

這項功能把 ChatGPT 放進 Microsoft Excel 和 Google Sheets 側邊欄，讓使用者可以在表格裡直接構建、更新和理解資料。官方提到的場景包括追蹤表、預算、公式、多工作表文件、情境分析和表格清理。

這說明 ChatGPT 不只是停留在「聊天窗口裡回答問題」。它正在進入使用者已經工作的地方。

對辦公使用者來說，表格是非常高頻的真實工作現場。很多公司、團隊和個人的業務資料，並不在複雜的資料平台裡，而是在一堆 Excel 和 Google Sheets 文件裡。如果 ChatGPT 能在表格旁邊直接理解資料、寫公式、整理多表和解釋結果，它的使用門檻會比複製貼上到聊天窗口低很多。

OpenAI 也提醒，依賴公式或分析前仍然要檢查輸出。這點很現實：AI 可以加速表格工作，但不能替使用者承擔財務、營運或業務判斷的全部責任。

4 月底的鋪墊：安全和模型選擇

再往前看，4 月 30 日的 Advanced Account Security 也值得注意。

這是一個面向個人 ChatGPT 帳戶的可選安全設定。開啟後，帳戶會使用更強的登入方式，例如 passkeys 或相容安全密鑰，並關閉密碼登入、郵件或簡訊登入碼、郵件帳戶恢復等較弱路徑。它還包括恢復密鑰、更短活躍會話、登入通知和會話管理控制。

這類功能說明 ChatGPT 帳戶的重要性在上升。隨著文件、記憶、應用連接、郵件、表格和工作項目逐漸進入 ChatGPT，帳戶安全就不再是普通登入問題，而關係到使用者的長期工作上下文。

4 月 28 日，OpenAI 還把模型選擇入口移到輸入框附近，並把 Thinking 和 Pro 模型的 thinking effort 控制放進模型選擇器。這是一個典型的產品細節改動：模型越來越多以後，使用者需要更容易在發送消息前選對工具。

4 月下旬的另一個方向：更快的普通回答

4 月 22 日，ChatGPT 推出 Fast answers。

這個功能用於常見的資訊查詢。當問題不需要個性化，且 ChatGPT 有高置信答案時，它可以更快返回結果。Fast answers 不引用過去聊天或記憶，使用者也可以在個性化設定裡關閉。

這和記憶增強看起來相反，其實是同一個產品邏輯：不同問題需要不同處理方式。

有的問題需要結合使用者長期背景，比如「幫我繼續規劃上週那個項目」。有的問題只需要快速準確，比如「世界七大奇蹟有哪些」。前者需要記憶和上下文，後者需要速度和清晰。ChatGPT 正在把這些路徑拆開。

產品節奏的變化

從這些 release notes 可以看到，ChatGPT 的更新已經不只是模型發布。

現在的更新同時覆蓋：

預設模型品質。
記憶和個性化。
應用連接和辦公插件。
帳戶安全。
模型選擇和互動入口。
快速回答和行動端體驗。

這意味著 ChatGPT 正在從單點 AI 聊天產品，變成一個更完整的工作平台。模型能力仍然重要，但產品體驗、上下文管理、工具入口、帳戶安全和第三方應用整合都同樣重要。

簡短判斷

這份 ChatGPT Release Notes 最值得看的，不是某一條具體更新，而是它們組合出的方向。

OpenAI 正在讓 ChatGPT 同時變得更快、更懂上下文、更能進入辦公場景，也更可控、更安全。GPT-5.5 Instant 負責提升預設回答品質，memory sources 負責解釋個性化來源，Excel 和 Google Sheets 負責進入真實工作文件，Advanced Account Security 則為更重的帳戶使用補上保護。

接下來，ChatGPT 的競爭力不會只取決於模型參數，也會取決於它能否把這些更新組織成穩定、清晰、使用者願意長期託付上下文的產品體驗。

ChatGPT Release Notes 更新：記憶來源、GPT-5.5 Instant 和表格插件

Thu, 07 May 2026 14:30:15 +0800

OpenAI 的 ChatGPT Release Notes 頁面在 2026 年 5 月初更新，最新一批重點包括三件事：ChatGPT 的記憶來源和個性化能力增強，GPT-5.5 Instant 成為新的預設模型，以及 ChatGPT for Excel 和 Google Sheets 全球上線。

這幾項更新放在一起看，方向很清楚：ChatGPT 正在從一個聊天入口，繼續變成更持續、更個性化、也更貼近辦公場景的工作助手。

Memory sources：個性化要更透明

最新更新裡，最值得關注的是 memory sources。

OpenAI 表示，ChatGPT Plus 和 Pro 使用者會開始獲得更強的記憶改進。ChatGPT 可以更好地從過去聊天、保存的記憶、可用文件，以及已連接的 Gmail 應用中提取相關上下文，用來給出更貼合使用者的想法、建議和下一步行動。

這意味著使用者不必在每次新對話裡反覆解釋自己的項目背景、偏好、工作習慣或已有材料。對於長期寫作、項目規劃、資料整理、學習和團隊協作來說，連續性會更強。

但個性化越強，透明度就越重要。OpenAI 因此推出 memory sources，讓使用者看到哪些資訊幫助 ChatGPT 個性化了某個回答。使用者可以點擊回答下方的 Sources 圖示，查看相關保存記憶、過去聊天和自定義指令。Plus 和 Pro 使用者還可能看到資料庫中的文件，以及已連接 Gmail 中被引用的郵件。

如果某些資訊過期、不相關或錯誤，使用者可以更正、刪除，或標記為不相關。

記憶控制仍然是關鍵

OpenAI 也說明，memory sources 不一定展示影響回答的全部因素，後續還會繼續改進這個視圖。

這個提醒很重要。它說明 memory sources 不是完整的「模型思考日誌」，而是讓使用者理解個性化上下文的一種產品介面。它能提高可見性，但不能把所有影響因素都完全展開。

隱私和控制方面，OpenAI 表示 memory sources 只會顯示在使用者自己的帳戶體驗裡。如果使用者分享聊天，相關 sources 不會出現在共享聊天中。使用者也可以刪除聊天，使用不會使用或更新記憶、也不會出現在歷史記錄中的臨時聊天，關閉記憶，隨時斷開應用連接，並管理自己的內容是否用於改進模型。

這說明 ChatGPT 的個性化正在走一條更明確的路線：既要更懂使用者，也要讓使用者知道它為什麼這麼回答，並保留管理入口。

GPT-5.5 Instant 成為預設模型

Release Notes 還確認，GPT-5.5 Instant 正在作為 ChatGPT 的新預設模型推出，並替代面向所有使用者的 GPT-5.3 Instant。

這次預設模型更新主要改善幾個方面：

準確性。
清晰度和簡潔度。
圖片理解。
STEM 問題回答。
判斷何時需要聯網搜尋。

OpenAI 強調，GPT-5.5 Instant 在事實可靠性上更好，尤其是在準確性更重要的提示詞中表現更穩。它也會給出更緊湊、更直接的回答，減少不必要的追問，降低過度格式化和無意義裝飾帶來的干擾。

對使用者來說，這類變化可能不會像新功能按鈕那樣顯眼，但會影響每天打開 ChatGPT 時的體感：回答更少繞路，更少囉嗦，也更少在簡單問題上堆格式。

個性化和預設模型結合起來

GPT-5.5 Instant 對 Plus 和 Pro 網頁端使用者還會更有效地使用過去聊天、文件和已連接 Gmail 的上下文。

這和 memory sources 是同一條產品線。模型不只是「更聰明」，還要在合適的時候知道你之前做過什麼、關心什麼、已經提供過哪些材料。比如繼續一個項目、寫一份計畫、整理郵件裡的資訊，或根據過去偏好給出建議時，ChatGPT 可以減少重複詢問。

付費使用者仍可在三個月內透過模型配置繼續使用 GPT-5.3 Instant，之後該模型會退役。

ChatGPT for Excel 和 Google Sheets

另一個重要更新，是 ChatGPT for Excel 和 Google Sheets 全球上線。

它把 ChatGPT 放進 Microsoft Excel 和 Google Sheets 的側邊欄中，讓使用者可以在表格裡直接構建、更新和理解資料。OpenAI 提到的場景包括：

追蹤表。
預算。
公式。
多工作表文件。
情境分析。
表格清理。

在可用地區和條件下，它還支援 Skills 和 apps。

這類功能的意義很直接：很多辦公資料並不在專門的 BI 系統裡，而是在 Excel 和 Google Sheets 裡。把 ChatGPT 放進表格側邊欄，比讓使用者複製貼上到聊天窗口更自然，也更容易進入真實工作流。

使用限制和安裝方式

Release Notes 提到，Free 和 Go 計畫包含有限使用量；Plus 和 Pro 使用與 Codex 相同的 agentic 使用限制。如果使用者超出計畫限制，可以購買額外 credits。

安裝方式也比較直接：Excel 版本從 Microsoft Marketplace 安裝，Google Sheets 版本從 Google Workspace Marketplace 安裝，然後使用符合條件的 ChatGPT 帳戶登入。

OpenAI 也提醒，使用者在依賴公式或分析前需要檢查輸出。這點不能忽略。AI 可以加速表格工作，但公式、預算、財務和業務分析仍然需要人工複核。

近期更新脈絡

如果把 4 月底到 5 月初的 release notes 放在一起看，ChatGPT 的方向更清楚。

4 月 30 日，OpenAI 推出 Advanced Account Security，給個人 ChatGPT 帳戶提供更強的登入要求和帳戶保護，包括 passkeys、安全密鑰、恢復密鑰、更短會話和登入通知。

4 月 28 日，模型選擇入口移到輸入框附近，讓使用者在發送消息前更容易選擇模型；Thinking 和 Pro 模型的 thinking effort 控制也被放進模型選擇器。

4 月 22 日，ChatGPT 推出 Fast answers，用於一些不需要個性化、且模型有高置信答案的常見資訊查詢。Fast answers 不引用過去聊天或記憶，使用者也可以在個性化設定裡關閉。

這些更新都圍繞同一個目標：讓 ChatGPT 更適合日常高頻使用。該快的時候快，該個性化的時候個性化，該需要安全保護和可見控制的時候給出入口。

簡短判斷

這次 ChatGPT Release Notes 的重點，不是單個功能，而是產品形態繼續收束。

GPT-5.5 Instant 提升預設回答品質，memory sources 讓個性化更可見，Excel 和 Google Sheets 插件把 ChatGPT 放進辦公表格，Advanced Account Security 和模型選擇改動則補上帳戶安全和操作體驗。

ChatGPT 正在變成更長期的工作層：它會記住更多上下文，進入更多工具，也承擔更多日常任務。接下來真正需要觀察的是，個性化透明度是否足夠清楚，辦公插件在真實複雜表格裡是否穩定，以及使用者能否在便利和控制之間保持平衡。

GPT-5.5 Instant 發布：ChatGPT 預設模型變得更準、更短、更懂你

Thu, 07 May 2026 14:28:40 +0800

OpenAI 在 2026 年 5 月 5 日發布 GPT-5.5 Instant，並開始把它作為 ChatGPT 面向所有使用者的預設模型。

這次更新的關鍵詞不是「更大」或「更炫」，而是更貼近日常使用：回答更準確、更簡潔，語氣更自然，也更會利用使用者已經分享過的上下文。對 ChatGPT 來說，預設模型的變化尤其重要，因為它影響的是最多使用者每天實際打開就會用到的體驗。

預設模型為什麼重要

Instant 是 ChatGPT 的日常主力模型。很多使用者不會手動切換模型，也不會研究不同模型之間的差異。他們感受到的 ChatGPT，就是預設模型的品質。

所以 GPT-5.5 Instant 的意義不只是新增一個模型名，而是把基礎體驗整體往前推了一步。OpenAI 在公告中提到，這次更新讓日常互動更有用、更順手：不同主題下的回答更緊湊，聊天語氣更自然，也能在合適的時候更好地使用已有上下文。

這種改進看起來不如一次大型多模態發布顯眼，但對幾億級使用者來說，預設模型少犯錯、少囉嗦、少問多餘問題，本身就是很大的產品變化。

更少幻覺，更可靠的回答

OpenAI 把準確性放在了第一位。

官方表示，在內部評測中，面對醫學、法律、金融等高風險提示詞，GPT-5.5 Instant 相比 GPT-5.3 Instant 產生的幻覺聲明減少了 52.5%。在使用者曾經標記過事實錯誤、難度更高的對話中，不準確聲明減少了 37.3%。

這兩個數字值得注意。它們說明 OpenAI 不只是追求模型「會說」，而是繼續壓低錯誤事實的發生率。尤其是在醫療、法律、金融這類領域，模型不能只給出流暢答案，還要更謹慎、更少編造。

當然，這不等於使用者可以把 ChatGPT 當成專業意見的替代品。更準確的模型仍然需要在高風險場景裡保留核查、引用來源和人工判斷。但從產品體驗看，預設模型的事實可靠性提升，會減少很多日常使用中的誤導。

日常任務能力增強

GPT-5.5 Instant 不只是在事實性上改進，也提升了多種日常任務能力。

OpenAI 提到，它在分析照片和圖片上傳、回答 STEM 問題，以及判斷何時使用網頁搜尋方面都有提升。這裡的重點是「判斷何時搜尋」。很多使用者並不關心模型內部是否呼叫工具，只關心答案是否新、是否準、是否能解釋清楚。

如果模型能更好判斷哪些問題需要聯網，哪些問題可以直接回答，使用者就不必反覆提醒「你去查一下」。這會讓 ChatGPT 更像一個主動可靠的助手，而不是只會等待明確指令的聊天框。

公告中的數學示例也體現了這個方向。GPT-5.5 Instant 在一開始認可錯誤解法後，能繼續檢查並發現代數錯誤，再回到正確方程求解。真正重要的不是它從不出錯，而是它更有機會在推理鏈條中發現問題並修正。

回答更短，但不是變少

OpenAI 還強調，GPT-5.5 Instant 的回答更緊、更直接，同時保留必要內容和 ChatGPT 的友好語氣。

這點對預設模型很關鍵。很多使用者對 AI 回答的疲勞感，不來自資訊不夠，而來自結構太重、鋪墊太多、格式太滿。一個簡單問題被拆成五個小標題、十幾條注意事項，反而會讓人覺得不自然。

GPT-5.5 Instant 的目標，是減少無謂的冗長和過度格式化，少問不必要的追問，也避免讓回答顯得雜亂的裝飾性內容。對日常辦公、寫作建議、生活諮詢和快速解釋來說，這類改進往往比單項基準分更影響體感。

更短不等於更淺。好的預設模型應該能判斷使用者需要的是一句可執行建議、一段解釋，還是完整方案。GPT-5.5 Instant 的方向，就是把這種分寸感做得更穩。

個性化能力繼續增強

這次更新的另一條主線，是個性化。

OpenAI 表示，Instant 現在更擅長使用過去聊天、文件以及已連接 Gmail 中的上下文，讓回答更貼合使用者。它會判斷什麼時候額外個性化能改善答案，並更快搜尋過去對話中的相關內容，減少使用者反覆交代背景。

這對長期使用 ChatGPT 的人很有價值。比如做計畫、寫文章、選工具、整理項目、延續一段工作流時，使用者往往已經在過去對話裡提供過偏好、約束和上下文。如果模型能自然接上，就會減少很多重複說明。

但個性化也必須配合透明度和控制。否則使用者會不知道模型為什麼突然提到某個偏好，也不知道哪些記憶正在影響回答。

Memory sources：讓個性化更可見

OpenAI 同時推出 memory sources，覆蓋所有 ChatGPT 模型。

它的作用是讓使用者看到哪些上下文被用於個性化回答，例如保存的記憶或過去聊天。如果某些內容過期、不準確或不想再被使用，使用者可以刪除或更正。

OpenAI 還說明，如果使用者分享一段聊天，memory sources 不會展示給其他人。使用者仍然可以刪除不希望被引用的聊天，在設定中修改保存記憶，或使用不會使用和更新記憶的臨時聊天。

這一步很重要。AI 助手越個性化，就越需要解釋「我是根據什麼在回答你」。Memory sources 不一定展示所有影響因素，但至少讓個性化從黑箱裡走出來一部分。

可用性安排

GPT-5.5 Instant 從公告當天開始向所有 ChatGPT 使用者推出，並替代 GPT-5.3 Instant 成為預設模型。在 API 中，對應 chat-latest。

對付費使用者來說，GPT-5.3 Instant 還會保留三個月，可透過模型配置設定存取，之後會被退役。

增強個性化功能會先在網頁端向 Plus 和 Pro 使用者推出，行動端隨後上線，並計畫在接下來幾週擴展到 Free、Go、Business 和 Enterprise。Memory sources 會在網頁端向 ChatGPT 消費者計畫推出，行動端也會隨後跟進。不同地區可用的個性化來源可能會不同。

簡短判斷

GPT-5.5 Instant 是一次面向預設體驗的升級。

它不只是模型能力變強，而是在回答準確性、表達密度、語氣、上下文使用和個性化透明度上一起調整。對普通使用者來說，最直接的變化應該是：少一點廢話，少一點事實錯誤，更容易接上你的背景。

對 OpenAI 來說，這也是預設助手形態的繼續演進。ChatGPT 不再只是「每次從零開始回答問題」的工具，而是在逐步變成能記住偏好、理解上下文、知道何時搜尋，並且讓使用者管理這些記憶來源的長期助手。

ChatGPT 提示「此聊天已被標記為可能存在網路安全風險」的原因與處理

Wed, 06 May 2026 00:17:00 +0800

使用 ChatGPT 或類似大型語言模型時，偶爾會遇到提示：「此聊天已被標記為可能存在網路安全風險」（This chat was flagged for possible cybersecurity risk）。這表示平台的自動安全系統偵測到對話內容可能違反使用政策。

下面分析這個提示的觸發原因、實際影響和處理方式。

為什麼會被標記

輸入內容敏感

對話中包含了可能被解讀為有害的內容，例如：

要求生成惡意程式碼或腳本。
分析或利用網路漏洞。
詢問非法活動相關內容。
尋求繞過安全限制的指令。

誤報（False Positive）

即使意圖是合法的程式碼分析或技術研究，系統仍可能把網路安全相關術語誤判為潛在攻擊企圖。AI 審核模型對關鍵字的敏感度較高，技術討論和攻擊行為之間的分界線有時不夠精確。

平台審核機制

系統會自動掃描對話內容進行風險評估。在較新版本（如 2026 年 4 月更新）中，觸發這類提示的情況更常見，說明平台可能引入了更嚴格的外部審核流程。

提示出現後的影響

目前聊天被終止：平台可能限制或停止目前會話的生成。
風險記錄：多次觸發風控會被記錄，累積到一定程度可能影響帳號狀態。
高敏感度趨勢：審核機制在持續收緊，技術討論時更容易碰到邊界。

如何處理

新建聊天

最直接的方式是放棄目前對話，點擊「New Chat」開始一次全新會話。此前的上下文不再延續，通常就不會再次觸發同一審核。

調整提示詞

檢查之前輸入的內容，去掉可能被判定為敏感的詞彙，換一種更中性的方式提問。例如把「如何繞過某限制」改成「某限制的原理是什麼」，把「怎麼寫一個攻擊腳本」改成「這類腳本通常利用什麼機制」。

不要嘗試繞過

避免透過提示注入等方式強迫 AI 回答被拒絕的問題。這類行為會增加封號風險，而且往往適得其反。

確認操作本身

如果並未進行高風險操作（如分析釣魚連結或編寫病毒），大概率是 AI 對技術概念的誤讀。這種情況可以考慮向平台回報，但短期內效果有限。

注意隱私

不要將包含敏感個人資訊或商業機密的內容用於 AI 分析。即使不觸發風控，也存在資料外洩風險。

預防建議

技術討論時盡量使用中性的術語描述問題。
避免在一個會話中集中討論大量敏感主題。
定期清理不必要的歷史會話。
重要帳號避免頻繁觸碰審核邊界。

小結

「此聊天已被標記為可能存在網路安全風險」通常由自動審核觸發，不一定代表帳號違規。處理優先級很清晰：新建聊天 > 調整措辭 > 不要硬碰。日常使用中注意措辭邊界，可以避免大部分觸發。

ChatGPT 和 Codex 登入要求驗證手機號，可能是什麼原因

Wed, 06 May 2026 00:08:45 +0800

最近有些用戶會遇到一個情況：ChatGPT 帳號已經註冊成功，但登入 ChatGPT 或 Codex 時，系統又要求驗證手機號。尤其是在使用 Codex 時，這個提示更容易讓人困惑：帳號明明能註冊，為什麼登入工具時還要補手機號？

這類問題通常和帳號風控、免費額度濫用、網路環境以及帳號安全策略有關。下面把常見原因和處理思路整理一下。

為什麼會要求驗證手機號

最直接的原因是風控升級。

Codex 面向用戶開放後，免費額度會吸引大量真實用戶試用，也會吸引批量註冊、批量領取額度的行為。如果有人用註冊機批量建立帳號，再用這些帳號消耗免費額度，平台就會更容易收緊驗證策略。

從用戶側看到的結果就是：原本只需要信箱或第三方登入的帳號，在登入 ChatGPT 或 Codex 時，突然被要求補充手機號驗證。

這不一定代表你的帳號一定有問題，也可能是觸發了更高風險的登入環境。例如：

使用了被大量用戶共享的網路出口。
當前 IP 段被頻繁用於註冊或異常登入。
帳號剛註冊不久，卻馬上訪問高消耗工具。
登入裝置、地區、網路頻繁變化。
免費帳號使用行為和批量帳號相似。

如果近期出現帳號異常、登入受限或誤封，也可能和網路環境被連帶標記有關。尤其是多人共享的節點，風險會明顯更高。

Codex 為什麼更容易觸發

Codex 和普通聊天不同，它更接近開發工具，可能涉及更高的資源消耗，也更容易被批量帳號拿來消耗免費額度。

所以同一個帳號在普通 ChatGPT 頁面裡看起來正常，到了 Codex 登入流程裡卻觸發手機號驗證，並不奇怪。可以把它理解為：不同產品入口會有不同的風險判斷。

對正常用戶來說，這類驗證通常不是為了為難單個用戶，而是為了限制批量註冊和免費額度濫用。但如果你的網路環境不乾淨，也會被誤傷。

處理方法一：升級 Plus

如果你是長期使用 ChatGPT 或 Codex，最簡單的處理方式是升級 ChatGPT Plus。

從實際使用體驗看，付費帳號通常比免費帳號更不容易觸發這類額度濫用風控。Plus 帳號本身也更適合穩定使用 Codex、ChatGPT 高級模型和其他高頻功能。

不過要注意：升級 Plus 並不等於永遠不會再觸發驗證。如果升級後仍然要求手機號，常見原因還是網路環境問題。

這時可以優先檢查：

是否使用了大量用戶共享的網路。
當前出口 IP 是否頻繁變化。
是否長期使用低品質代理或公共節點。
是否同一網路下有大量 OpenAI 帳號登入。

如果條件允許，換一個更穩定、更乾淨的網路環境再登入，通常比反覆重試更有效。

處理方法二：檢查網路環境

很多登入驗證問題，看起來像帳號問題，本質上是網路問題。

如果某個出口 IP 被大量用戶共用，或者曾經被用於批量註冊、異常登入、自動化請求，就更容易被標記。此時即使你是正常用戶，也可能在登入 ChatGPT 或 Codex 時被要求額外驗證。

可以從這幾個角度排查：

換一個更穩定的網路環境。
避免使用公開、廉價、多人共享的節點。
儘量減少短時間內頻繁切換地區。
不要在同一瀏覽器裡頻繁切換多個帳號。
如果使用代理，優先選擇品質更穩定、濫用更少的線路。

也可以借助第三方網路品質檢測工具查看當前 IP 的風險情況，但檢測結果只能作為參考，不能完全代表 OpenAI 的內部判斷。

處理方法三：按要求完成手機號驗證

如果系統明確要求手機號驗證，最穩妥的方式仍然是按要求完成驗證。

建議優先使用自己可長期接收驗證碼的號碼。這樣以後如果帳號出現安全驗證、恢復登入、異常提醒，也能繼續處理。

不建議把重要帳號綁定到來路不明、多人共用或無法長期使用的號碼上。短期看可能能通過驗證，長期看會帶來帳號找回、安全審計和二次驗證風險。

如果你使用的是工作帳號、團隊帳號或長期依賴的開發帳號，更應該避免使用不可控的臨時號碼。帳號安全比臨時省事更重要。

升級 Plus 時要注意什麼

如果你準備升級 Plus，可以先確認幾件事：

帳號本身可以正常登入。
當前網路環境穩定，不頻繁跳地區。
支付方式可靠，不要使用來源不明的代付。
升級後保留好付款記錄和帳號信箱。
不要把帳號借給多人共用。

很多帳號問題並不是出在 Plus 本身，而是出在升級前後的網路、支付和共享使用習慣上。一個帳號如果長期多人共用、頻繁異地登入、經常切換環境，即使付費也可能觸發安全驗證。

如果只是偶爾試用，免費帳號也可以繼續用。但如果你已經把 Codex 當成日常開發工具，Plus 會更適合長期使用。

不建議繼續薅免費額度

Codex 這類工具的免費額度本來是為了讓正常用戶體驗和試用。如果大量批量帳號持續消耗免費額度，平台最終只能繼續提高風控強度。

結果就是正常用戶也會受到影響：登入更麻煩，驗證更多，封禁誤傷更多，帳號使用成本更高。

對真正把 Codex 用在寫程式碼、改專案、跑工程任務的人來說，與其把時間花在規避風控上，不如把帳號和網路環境整理乾淨。長期看，這比重複註冊新帳號、切換節點、處理驗證問題更省事。

小結

ChatGPT 或 Codex 登入時要求驗證手機號，通常和帳號風控、免費額度濫用、網路環境風險有關。它不一定代表帳號本身違規，但說明當前登入環境或帳號狀態觸發了更高等級的驗證。

處理順序可以很簡單：

先檢查網路環境，避開多人共享和高風險出口。
長期使用就考慮升級 Plus。
如果系統要求手機號驗證，優先使用自己可長期控制的號碼完成。
避免批量註冊、共享帳號和頻繁切換登入環境。

穩定使用 AI 工具的核心不是一直繞過驗證，而是讓帳號、網路和使用方式都儘量正常。這樣才能減少登入麻煩，也能降低後續被誤傷的機率。

OpenAI 推出 Advanced Account Security：ChatGPT 和 Codex 帳號多了一層高強度保護

Fri, 01 May 2026 06:15:29 +0800

OpenAI 在 2026 年 4 月 30 日推出了 Advanced Account Security，這是面向 ChatGPT 帳號的可選進階安全設定。

它主要服務兩類使用者：一類是記者、民選官員、政治異議人士、研究人員等更容易遭遇定向攻擊的人；另一類是希望給 ChatGPT 和 Codex 帳號加上更強保護的安全敏感使用者。

這項功能開啟後，不只保護 ChatGPT，也會保護同一登入帳號下存取的 Codex。

為什麼 ChatGPT 帳號需要更高安全等級

現在很多人會把 ChatGPT 用在越來越私密、越來越高風險的工作裡。

一個 ChatGPT 帳號裡可能包含：

個人問題和長期對話
工作文件與專案上下文
已連接工具和工作流程
Codex 裡的程式碼與開發任務
企業、研究或安全相關材料

如果帳號被接管，損失不只是聊天記錄外洩。攻擊者還可能存取連接的工具、查看敏感上下文，甚至干擾使用者正在進行的工作。

所以 OpenAI 這次推出的不是一個普通登入選項，而是一組更嚴格的帳號保護措施。

Advanced Account Security 包含哪些保護

OpenAI 把這項能力放在 ChatGPT 網頁端帳號的 Security 設定裡，使用者可以主動開啟。

開啟後，它會從幾個方面提高帳號安全性。

第一，登入方式更強。

Advanced Account Security 要求使用 passkeys 或實體安全金鑰，並禁用基於密碼的登入。這樣做的目的，是讓更抗釣魚的登入方式成為預設選擇。

第二，帳號恢復更嚴格。

傳統帳號恢復經常依賴信箱或簡訊。如果攻擊者控制了使用者的信箱或手機號碼，就可能藉此重設帳號。為降低這個風險，Advanced Account Security 會禁用郵件和 SMS 恢復，改用更強的恢復方式，例如備用 passkeys、安全金鑰和恢復金鑰。

這裡有一個重要代價：開啟後，帳號恢復會更依賴使用者自己保管這些恢復方式。OpenAI 明確說明，已開啟該功能的使用者如果遺失恢復手段，OpenAI Support 無法協助恢復帳號。

第三，工作階段時間更短，管理更清楚。

OpenAI 會縮短登入工作階段，以降低裝置或活躍工作階段被盜用後的暴露窗口。使用者也會收到登入提醒，並可以查看和管理目前登入的裝置工作階段。

第四，自動排除訓練。

對處理敏感資訊的人來說，不讓對話用於模型訓練是一項重要隱私設定。開啟 Advanced Account Security 後，這個偏好會自動生效：這些帳號的對話不會用於訓練 OpenAI 模型。

與 Yubico 合作推廣實體安全金鑰

OpenAI 還宣布與 Yubico 合作，給使用者提供定製的安全金鑰組合。

其中包括：

YubiKey C Nano：適合長期插在筆電上，日常登入摩擦更小
YubiKey C NFC：適合作為備用，也方便在筆電和行動裝置之間使用

OpenAI 表示，使用者也可以使用其他符合 FIDO 標準的實體安全金鑰，或者使用軟體 passkeys。

這說明 Advanced Account Security 並不綁定某一種硬體，而是圍繞抗釣魚認證方式設計。

Cyber 可信存取使用者會被要求開啟

OpenAI 還提到，針對 Trusted Access for Cyber 的個人成員，如果他們要存取更強、更寬鬆的網路安全模型，從 2026 年 6 月 1 日開始將被要求開啟 Advanced Account Security。

組織使用者可以用另一種方式滿足要求：證明自己的單一登入流程已經採用抗釣魚認證。

這個安排很合理。越強的模型能力越需要更強的帳號保護，尤其是面向網路安全研究、漏洞分析和紅隊等場景時，帳號本身就會成為高價值目標。

適合誰開啟

這項功能不一定適合所有人。

如果只是普通聊天，且不想承擔更嚴格帳號恢復帶來的複雜性，可以先觀望。

但以下使用者值得認真考慮：

經常在 ChatGPT 中處理敏感工作材料的人
使用 Codex 處理私有程式碼倉庫的人
記者、公共事務人員、研究人員、企業高階主管等高風險使用者
網路安全從業者
已經習慣使用 passkeys 或實體安全金鑰的人
對帳號被釣魚、簡訊劫持或信箱接管特別敏感的人

開啟之前，最好先準備好備用 passkey、安全金鑰和恢復金鑰，並確認它們被妥善保存。否則，安全性提高的同時，帳號恢復難度也會明顯提高。

這對 AI 產品意味著什麼

Advanced Account Security 不是一個模型能力更新，但它反映了 AI 產品正在進入更高風險的使用階段。

當 ChatGPT 和 Codex 開始承載工作流程、程式碼、文件、企業連接器和長期上下文時，帳號就不再只是「登入聊天工具」的入口，而是 AI 工作環境的鑰匙。

這類產品越像個人工作台，帳號安全、恢復機制、工作階段管理和訓練資料控制就越重要。

OpenAI 這次把 passkeys、實體安全金鑰、恢復限制、工作階段管理和訓練排除放到同一個設定裡，方向是對的。它讓高風險使用者可以用一個明確入口，把帳號保護提升到更適合敏感工作的級別。

小結

Advanced Account Security 可以理解為 ChatGPT 和 Codex 的高安全模式。

它透過更強登入、更嚴格恢復、更短工作階段、登入提醒和自動排除訓練，降低帳號被接管後的風險。代價是使用者需要更認真地管理自己的恢復方式，因為開啟後傳統郵件和簡訊恢復不再可用，OpenAI Support 也無法替使用者兜底。

如果你已經把 ChatGPT 或 Codex 用在重要工作裡，尤其是涉及私有程式碼、敏感文件或高風險身份，這項功能值得關注。

參考連結：

Introducing Advanced Account Security - OpenAI

ChatGPT、Claude、Gemini 怎麼分工：日常對話、程式開發與特殊能力該怎麼選

Sat, 25 Apr 2026 10:51:19 +0800

現在很多人不再只用一個模型，而是會在 ChatGPT、Claude 和 Gemini 之間來回切換。問題也因此變得很實際：到底什麼任務該交給誰？

這件事之所以容易讓人糾結，不是因為三家都不夠強，而是因為它們已經強到開始「分工不同」。如果還是用「誰更聰明」這種非常籠統的標準去選，反而更容易選錯。

如果先講一個簡化版結論，可以大致這樣理解：

日常對話和綜合型任務，很多人會先想到 ChatGPT
命令列程式開發、長上下文協作、持續推進型任務，Claude 往往更順手
需要依賴 Google 生態、搜尋、多模態入口或某些產品級特殊能力時，Gemini 更有存在感

下面分三塊來講。

1. 日常對話：為什麼很多人還是先打開 `ChatGPT`

對大多數一般使用情境來說，ChatGPT 仍然很像「預設入口」。

這裡說的不是某一個 benchmark，而是整體體驗：
當你臨時想問一個問題、整理一個思路、寫一段文案、做一份初稿、總結一篇資料時，ChatGPT 通常給人的感覺會比較均衡。

它的優勢往往體現在幾個地方：

回答風格比較穩定
一般使用者上手門檻低
多數綜合型任務不需要太多額外調教
產品完成度高，適合高頻日常使用

所以如果你的任務是下面這種：

幫我整理一個主題
把一段想法寫成結構化內容
總結一篇長文
腦力激盪幾個方案
把表達潤飾得更清楚

那 ChatGPT 往往就是一個很自然的起點。

這並不代表它在所有專業任務裡都一定最強，而是它在「廣譜通用」這件事上，通常更像一個預設工作台。

2. 命令列程式開發與長任務：為什麼很多人更偏向 `Claude`

一旦任務從「聊一聊」切換成「把事情持續做完」，很多人的偏好就會開始轉向 Claude。

尤其是在這些場景：

命令列程式開發
大型專案上下文理解
多檔案協作修改
長鏈路除錯
一邊讀程式碼一邊推進任務

這類任務的關鍵，往往不是單輪回答有多驚艷，而是模型能不能在更長的任務鏈裡保持穩定。

Claude 經常被偏愛的原因，通常不是「它一句話比別人更會說」，而是：

對長上下文任務更耐用
連續讀檔案、讀日誌、讀規則時體驗更穩定
更適合逐步推進複雜編碼任務
在命令列與 agent 工作流裡更常被當成主力模型

如果你是在做 vibe coding、命令列修 bug、理解專案結構，或跨多個檔案改功能，Claude 的優勢會更容易體現出來。

簡單說，Claude 比較像那種適合一起「幹活」的模型，而不只是適合問一句答一句。

3. `Gemini` 的優勢往往不在「跟別人正面拼一切」

很多人討論 Gemini 時，容易把問題問成：它到底是不是三家裡最強。

但從實際使用體驗來看，更有用的問題通常不是這個，而是：它在哪些情境裡特別值得單獨拿出來用。

Gemini 的價值，往往更容易體現在這些方向：

Google 生態整合
搜尋與資料取得
多模態入口
某些產品側功能聯動

如果你的工作流本來就和 Google 的工具鏈很近，例如：

搜尋
文件
郵件
瀏覽器側使用
手機端入口

那 Gemini 的實際便利性可能會高於單純的模型分數對比。

也就是說，Gemini 的可用性很多時候來自「它在哪裡更順手接入你的工作流」，而不只是「它單輪回答是不是贏了誰」。

4. 真正有用的選法，不是問誰最強，而是問任務類型

把三家模型放在一起比較時，最容易踩的坑就是試圖找出一個「唯一最強」。

但現實裡的任務差異太大了：

有的是一次性問答
有的是長對話陪跑
有的是程式碼工程
有的是資訊檢索
有的是多模態處理
有的是工具鏈協作

所以更有效的選法，通常是按任務類型來分：

需要一個綜合型、日常高頻、打開就能用的助手：先看 ChatGPT
需要長上下文、命令列、程式開發協作、持續推進複雜任務：優先試 Claude
需要借力 Google 生態、搜尋、多模態入口或某些產品聯動能力：重點看 Gemini

這樣分工，比硬要爭一個總冠軍更接近真實使用。

5. 為什麼很多重度使用者會同時訂三家

從輕度使用者視角來看，同時訂三家模型服務很容易顯得「重複」。
但從重度使用者視角來看，這更像是在為不同任務配不同工具。

原因很簡單：
如果三家的長處已經開始明顯分化，那麼同時使用它們，本質上就不是重複付費，而是在降低任務切換成本與試錯成本。

例如：

日常整理和綜合問答，用 ChatGPT
程式開發主任務，用 Claude
某些檢索、多模態或 Google 相關鏈路，用 Gemini

這種組合方式的邏輯，和設計師同時裝多個軟體、開發者同時使用多個 IDE，並沒有本質差別。

6. 什麼時候不要來回切太多模型

當然，模型多也不一定總是更好。

如果你本身還在建立穩定工作流，過早在三個模型之間頻繁橫跳，反而可能讓自己更亂。常見問題包括：

同一個任務來回重複講三遍
不同模型給出不同建議，自己更難判斷
上下文斷裂，協作成本反而更高
還沒形成自己的使用邊界，就先被工具選擇拖住

所以更穩的方式通常是：

先給每個模型一個主場景
在主場景裡連續用一段時間
再逐步形成自己的分工習慣

這樣你會更容易得到真正可複用的經驗，而不是永遠停留在「今天換這個試試」的階段。

7. 可以先這樣記住

如果只想先記一個夠用的版本，可以直接記這張口語化分工表：

ChatGPT：更像通用型預設助手
Claude：更像長任務和程式開發協作主力
Gemini：更像在搜尋、多模態和 Google 生態裡更有優勢的工具

這不是絕對規則，也不是說三者彼此不能替代，而是一個更接近真實使用體驗的起點。

真正重要的不是選出「宇宙最強模型」，而是盡快知道：
你手上的這類任務，用哪個模型最省時間、最省心、最容易做出結果。

OpenAI 發布 GPT-5.5：更強的智慧體編碼、知識工作與科研能力

Fri, 24 Apr 2026 08:39:56 +0800

OpenAI 在 2026 年 4 月 23 日發布了 Introducing GPT-5.5。從官方頁面來看，這次更新的重點不是單純「模型更聰明」，而是更強調模型能不能把複雜任務持續推進下去。

官方給 GPT-5.5 的定位，是一個更適合真實工作的模型。它不只要回答問題，還要能寫程式、除錯、查資料、分析資料、產生文件和試算表、操作軟體，並在多個工具之間來回切換，直到任務完成。

1. GPT-5.5 主要強在哪裡

這次發布頁裡反覆出現的幾個方向，可以概括為四類：

智慧體編碼
電腦操作與工具使用
知識工作
早期科研輔助

也就是說，GPT-5.5 的重點不是短問短答，而是更長鏈路的任務。例如一個工程問題不只是「這段程式碼怎麼改」，而是要理解專案結構、定位失敗原因、修改相關檔案、補測試、驗證結果，並盡量減少使用者反覆提示。

OpenAI 也特別強調，GPT-5.5 在 Codex 任務中更省 token。這點很實際，因為編碼智慧體一旦開始讀檔案、跑命令、修 bug，token 消耗會非常快。如果模型能用更少步驟完成同樣任務，實際成本和等待時間都會下降。

2. 編碼能力是這次最重要的展示方向

官方稱 GPT-5.5 是目前最強的 agentic coding 模型。

幾個公開指標裡，比較值得注意的是：

Terminal-Bench 2.0：GPT-5.5 達到 82.7%
SWE-Bench Pro：GPT-5.5 達到 58.6%
OpenAI 內部的 Expert-SWE：GPT-5.5 也高於 GPT-5.4

這些測試的共同點是，它們更接近真實工程流程，而不是只考單個演算法題。特別是 Terminal-Bench 這類任務，會涉及命令列操作、規劃、試錯、工具協調和多步驟驗證。

對日常開發者來說，這裡的意義很直接：模型是否能接住更大的任務，取決於它能不能長時間保持上下文、自己檢查假設、知道什麼時候該跑測試、知道改動會影響哪裡。

GPT-5.5 在 Codex 裡的價值，也主要體現在這些地方。它更像是可以接手一段工程任務的協作者，而不是只會補全程式碼片段的工具。

3. 知識工作開始變成重點場景

除了寫程式，OpenAI 這次也把 GPT-5.5 放到了更廣的辦公場景裡。

官方提到，GPT-5.5 在 Codex 中可以更好地產生文件、試算表和簡報，也更適合處理營運研究、試算表建模、業務材料整理這類任務。結合電腦操作能力之後，它的目標不是只給建議，而是能直接參與「找資料、理解內容、呼叫工具、檢查輸出、整理成結果」這整條流程。

發布頁裡還提到 OpenAI 內部已經在多部門使用 Codex，包括軟體工程、財務、傳播、市場、資料科學和產品管理等。這裡真正值得關注的不是某個單點案例，而是 OpenAI 正在把 Codex 從開發工具擴展為通用工作工具。

在 ChatGPT 裡，GPT-5.5 Thinking 面向 Plus、Pro、Business 和 Enterprise 使用者；GPT-5.5 Pro 則面向更難問題和更高準確率需求，提供給 Pro、Business 和 Enterprise 使用者。

4. 科研能力不只是「答題更強」

GPT-5.5 的科研展示也很重。

官方提到它在遺傳學、定量生物學、生物資訊學、數學證明等方向都有改進。這裡的重點不是模型能不能背出一個知識點，而是能不能處理更接近真實研究的問題：讀資料、發現異常、提出分析方式、解釋結果，並根據中間結果繼續推進。

發布頁裡提到的 GeneBench 和 BixBench，都更偏多階段科學分析任務。OpenAI 還提到，一個內部版本的 GPT-5.5 借助自訂工具鏈，幫助發現了關於 Ramsey numbers 的新證明，並用 Lean 做了驗證。

這類案例還不能簡單理解為「AI 已經能獨立做科研」，但它說明模型正在從問答工具往研究協作者靠近。尤其是在程式碼、資料、論文、實驗想法混在一起的場景裡，GPT-5.5 的長鏈路推理和工具使用能力會更重要。

5. 推理效率：更強但沒有明顯變慢

一個容易被忽略的點是，OpenAI 說 GPT-5.5 在真實服務中的 per-token latency 與 GPT-5.4 相當。

通常更大的模型、更強的模型會帶來更高延遲。OpenAI 這次強調，它們透過推理系統最佳化，讓 GPT-5.5 在智慧提升的同時保持速度。發布頁裡還提到，Codex 分析生產流量模式並編寫負載分配相關啟發式演算法，使 token 產生速度提升超過 20%。

這個細節很有意思：模型不只被基礎設施服務，也反過來幫助改進服務它的基礎設施。

6. 安全策略會更嚴格，尤其是網路安全方向

GPT-5.5 的網路安全能力更強，所以 OpenAI 同時加強了安全限制。

官方說明中提到，GPT-5.5 在網路安全能力上比 GPT-5.4 有提升，因此會部署更嚴格的分類器，尤其針對高風險活動、敏感網路安全請求和重複濫用行為。

這意味著一部分使用者在使用網路安全相關能力時，可能會遇到更多拒答或限制。OpenAI 也提供了 Trusted Access for Cyber，用於讓經過驗證的防禦性使用者獲得更少不必要阻礙。

對普通開發者來說，可以簡單理解為：合法的安全加固、漏洞修復、程式碼審計會繼續被支援，但高風險攻擊鏈路會被更嚴格地控制。

7. 可用性與 API 價格

根據 OpenAI 發布頁，GPT-5.5 的可用性如下：

ChatGPT：GPT-5.5 Thinking 面向 Plus、Pro、Business、Enterprise 使用者
ChatGPT：GPT-5.5 Pro 面向 Pro、Business、Enterprise 使用者
Codex：GPT-5.5 面向 Plus、Pro、Business、Enterprise、Edu、Go 方案
Codex：上下文視窗為 400K
Codex Fast mode：產生速度約 1.5x，成本為 2.5x

API 方面，OpenAI 表示 gpt-5.5 和 gpt-5.5-pro 會很快開放。

官方給出的 API 價格是：

gpt-5.5：輸入 5 美元 / 1M tokens，輸出 30 美元 / 1M tokens
gpt-5.5-pro：輸入 30 美元 / 1M tokens，輸出 180 美元 / 1M tokens
gpt-5.5 API 上下文視窗為 1M
Batch 和 Flex 為標準 API 價格的一半
Priority processing 為標準價格的 2.5x

這個價格明顯高於很多日常模型，所以它更適合高價值任務：複雜工程改造、長文件分析、自動化辦公、科研輔助、重要業務流程，而不是普通閒聊。

8. 怎麼看這次發布

如果只看一句話，GPT-5.5 的重點是：OpenAI 正在把模型從「回答問題」繼續推向「完成工作」。

它最值得關注的地方，不只是 benchmark 分數提升，而是幾種能力開始匯合：

更強的長任務保持能力
更穩定的工具使用
更好的工程上下文理解
更適合文件、試算表、研究和業務流程
更長上下文和更高 token 效率
更嚴格的高風險能力控制

對開發者來說，最值得試的是 Codex 裡的複雜工程任務。對企業使用者來說，更值得關注的是它能不能把一部分跨工具、跨文件、跨流程的工作變成可交付結果。

GPT-5.5 不是一次只面向聊天體驗的小更新，而更像是 OpenAI 在繼續推進「AI 作為工作執行層」的方向。

OpenAI 發布 ChatGPT Images 2.0：圖像生成開始走向可直接交付

Wed, 22 Apr 2026 14:21:45 +0800

OpenAI 在 2026 年 4 月 21 日發布了 Introducing ChatGPT Images 2.0。從官方頁面來看，這次更新想強調的並不只是「圖片更好看了」，而是圖像生成正在往「更可控、可排版、可直接交付」的方向走。

如果只看這篇發布頁，它更像一組高密度能力展示，而不是傳統意義上的技術說明。頁面幾乎沒有展開模型結構、訓練細節或基準測試，而是用大量示例圖直接回答一個問題：現在的 ChatGPT 圖像生成，能不能把過去還要靠設計師反覆修圖、補字、調版式的工作，進一步前移到生成階段。

01 這次更新最明顯的訊號

官方頁面裡最醒目的幾個關鍵詞，其實已經把重點說得很清楚：

Greater precision and control
Stronger across languages
Stylistic sophistication and realism

這三點放在一起看，含義很明確。

第一，不再只強調「想像力」，而是強調控制力。頁面裡出現了大量海報、雜誌頁、宣傳頁、資訊圖、角色設定頁、分鏡漫畫、印刷書籤這類示例。它們的共同點不是單張視覺衝擊力，而是需要同時處理文字、層級、留白、構圖、風格統一和輸出比例。這說明 OpenAI 在刻意把產品定位從「生成一張圖」往「生成一份可以拿去用的視覺成品」推進。

第二，多語言文字能力被單獨拎出來做展示。頁面裡不僅有多語種海報、書籍封面、韓文旅宿宣傳頁、日文漫畫，還有專門強調 typography 的示例。這很關鍵，因為過去圖像模型最容易翻車的地方之一，就是一旦涉及長文本、複雜版式或非英文文字，穩定性會明顯下降。現在 OpenAI 把它放到發布頁核心位置，本身就是在傳遞一個訊號：文字渲染和跨語言排版，已經成為它們認為值得正面展示的能力。

第三，風格覆蓋面被拉得很寬。官方示例同時覆蓋了寫實攝影、復古拼貼、Bauhaus 海報、時尚大片、黑白紀實、兒童繪本、日漫、青年漫畫、教育資訊圖、產品網格圖、角色設定頁等多種形式。這裡想表達的不是「模型能模仿很多畫風」這麼簡單，而是它正在嘗試從單一美術風格輸出，走向更完整的視覺任務適配。

02 為什麼說它在走向「可直接交付」

從這頁內容來看，ChatGPT Images 2.0 更像一個「圖像製作工作台」能力升級，而不只是更強的文生圖模型。

過去很多模型雖然也能生成漂亮圖片，但一旦使用者需求變成下面這些任務，體驗就會迅速下降：

做一張帶完整標題、副標題和說明文字的海報
做一頁資訊密度較高的雜誌或宣傳頁
做帶連續角色和連續敘事的漫畫頁
做需要固定比例、特定版式和明確品牌感的行銷物料
做包含多語言文字的正式視覺內容

而 OpenAI 這次展示的例子，幾乎都在正面回應這些老問題。

例如頁面裡有教育資訊圖、設計趨勢海報、書籤印刷稿、咖啡店開業海報、旅遊宣傳頁、產品周邊展示圖、論文海報重製圖。這類內容有一個共同特徵：它們不是「給人看一眼覺得不錯」就結束，而是更接近真實工作流裡的半成品甚至成品。

換句話說，這次更新真正重要的地方，可能不是單張圖品質又提升了多少，而是模型開始更像一套可用於內容生產、品牌物料、教育傳播和輕量設計工作的生成系統。

03 這對 ChatGPT 產品定位意味著什麼

從發布頁的組織方式，也能看出一些產品層面的變化。

OpenAI 沒有把 ChatGPT Images 2.0 包裝成一個只服務創意圈的圖像模型，而是不斷用「研究、推理、資料轉化、版面整理、知識表達、行銷輸出」這些場景去展示它。頁面裡甚至還有把數學證明、設計趨勢、歷史筆記、學術論文可視化的例子。

這意味著圖像生成在 ChatGPT 裡的角色，已經不只是「給聊天配圖」或「生成一張插畫」，而是在向更通用的表達層靠攏。它想做的是：當使用者已經在 ChatGPT 裡思考、查資料、整理內容、寫文案之後，最後一步連視覺產出也一起完成。

如果這個方向繼續推進，圖像功能的競爭點就不再只是審美和寫實程度，而會越來越依賴下面這些能力：

是否能穩定處理複雜文字
是否能維持跨頁面或多面板的一致性
是否能生成更接近真實工作物料的版式
是否能在研究、寫作、行銷、教學這些任務裡自然接上前面的上下文

04 這篇發布頁沒有說什麼

當然，發布頁的寫法也決定了它更適合「看方向」，不太適合「看細節」。

截至官方頁面 2026 年 4 月 21 日的內容，它主要展示的是結果，而不是方法。頁面沒有詳細展開：

模型與上一代相比的量化提升
文字準確率或多語言渲染的明確指標
複雜版式任務的失敗邊界
API、價格、調用方式或企業側接入細節
安全策略和生成限制的具體更新

所以更準確地說，這篇文章傳遞的是產品訊號，而不是完整技術規格。

05 簡單結論

如果只用一句話概括 ChatGPT Images 2.0，這次更新最值得注意的不是「更會畫」，而是「更會做成品」。

OpenAI 顯然希望把圖像生成從靈感型工具，往可執行、可排版、可溝通、可交付的生產工具推進。文字控制、多語言、版式、風格跨度、長頁面內容組織，這些原本最容易暴露短板的地方，現在反而成了它主動展示的賣點。

這不代表圖像生成已經完全解決了設計工作裡的所有問題，但至少從這次發布頁可以看出，競爭重心正在變化。未來誰更強，可能不只是看誰能出一張更驚豔的圖，而是看誰能更穩定地做出一份真的能拿去用的視覺內容。

codex-quota 實戰指南：保留命令列的本機、Web 與 Docker 用法

Thu, 16 Apr 2026 18:13:04 +0800

這個專案做什麼

codex-quota 是一個輕量工具，可查詢 ChatGPT Codex 配額使用情況，資料來源是 https://chatgpt.com/backend-api/wham/usage。

主要功能：

支援單帳號或多帳號（account/*.auth.json）查詢。
輸出 five_hour%、weekly%、weekly_reset，並標記來源（network 或 cache）。
對暫時性失敗（408、429、5xx）做指數退避重試。
內建本地快取，減少配額耗盡時的重複請求。
提供 Web Dashboard、JSON API、auth 檔管理頁面。

優點：

輕量：單腳本即可執行，依賴簡單。
實用：CLI 與 Web 兩種入口都能使用。
可部署：支援 Docker 與 Docker Compose。
易維運：支援重試、快取與定時刷新。

先準備好帳號憑證

在 account/<name>.auth.json 建立憑證檔，例如：

{
  "tokens": {
    "access_token": "eyJ...",
    "account_id": "user-xxxxxxxx"
  }
}

說明：

access_token 與 account_id 是查詢介面所需欄位。
檔名中的 <name> 會作為結果中的帳號名稱。

本機 CLI 用法（保留原命令）

安裝依賴：

`1`	`pip install -r requirements.txt`

說明：安裝專案執行依賴。

查詢全部帳號：

`1`	`python codex_quota.py`

說明：讀取 account/*.auth.json，彙總輸出所有帳號配額。

查詢單一帳號：

`1`	`python codex_quota.py your_account_name`

說明：只查詢 account/your_account_name.auth.json。

強制刷新（跳過快取）：

`1`	`python codex_quota.py --refresh`

說明：忽略本地快取，直接請求最新介面資料。

CLI 參數說明（README 對齊）

account_name：可選帳號名（不含 .auth.json）。
--account-dir：憑證目錄，預設 account。
--chatgpt-url：配額介面位址。
--raw-json：輸出完整 JSON 回應體。
--raw-headers：輸出回應標頭。
--refresh：忽略快取。
--retries：重試次數，預設 3。
--retry-delay：基礎重試間隔秒數，預設 2.0。

Web Dashboard 用法（保留原命令）

啟動服務：

`1`	`python codex_quota_service.py --host 0.0.0.0 --port 8081`

說明：啟動 HTTP 服務並監聽 8081 埠。

存取位址：http://localhost:8081

Service 參數：

--host：監聽位址，預設 0.0.0.0。
--port：服務埠，預設 8081。
--interval-seconds：排程刷新間隔，預設 3600。
--account-dir：憑證目錄，預設 account。
--state-file：狀態檔路徑，預設 <account-dir>/codex_quota_web_results.json。
--account-name：可選，單帳號模式。
--chatgpt-url：配額介面位址。
--retries：重試次數。
--retry-delay：基礎重試延遲。
--refresh：排程刷新時忽略 CLI 快取。

HTTP 介面（方便接自動化）

GET /：Dashboard 頁面。
GET /api/results：最新結果 JSON。
GET /refresh：立即刷新並跳回 /。
GET /auth：列出 auth 檔。
GET /auth/new：新建 auth 檔表單。
GET /auth/edit?name=<account>：編輯 auth 檔表單。
POST /auth/save：建立/更新 auth 檔。
POST /auth/delete：刪除 auth 檔。

Docker 用法（保留原命令）

建置映像：

`1`	`docker build -t codex-quota .`

說明：將目前專案打包為 codex-quota 映像。

執行容器（映射 8081）：

`1`	`docker run --rm -p 8081:8081 -v ./account:/app/account codex-quota`

說明：

--rm：容器退出後自動刪除。
-p 8081:8081：主機埠映射到容器埠。
-v ./account:/app/account：把本地憑證目錄掛載進容器。

存取位址：http://localhost:8081

Docker Compose 用法（保留原命令）

啟動：

`1`	`docker compose up --build`

說明：依 docker-compose.yml 建置並啟動服務。

存取位址：http://localhost:8081

使用建議

多帳號場景優先使用 Dashboard，便於統一查看與管理 auth 檔。
告警或自動化整合優先使用 GET /api/results。
公開倉庫不要提交真實 access_token。
若看到大量暫時性錯誤，可調大 --retries 與 --retry-delay。

Codex 額度怎麼算：5 小時限額、週限額與 Credit 消耗

Wed, 15 Apr 2026 22:50:00 +0800

很多人第一次看 Codex 額度時，會以為 5 小時限額 是一個短期餘額池，只有它用完之後才開始扣 週限額。

實際不是這樣。Codex 更像是同時檢查多個額度窗口：短窗口防止短時間爆量，週窗口限制一週總量。一次 Codex 使用通常會同時計入這兩個窗口。

所以你看到：

1
2

5 小時額度還剩很多
但 weekly 額度已經下降

通常是正常現象。

01 先記住結論

Codex 額度可以先按下面三句話理解：

5 小時限額 和 週限額 是同時生效，不是先後扣除。
週限額用完後，即使 5 小時額度還有，通常也不能繼續用同一個訂閱額度池。
Codex 不是簡單按訊息條數計費，而是和模型、tokens、任務複雜度、上下文、執行位置有關。

用偽代碼表示就是：

can_use_codex =
    five_hour_remaining > 0
    && weekly_remaining > 0
    && 沒有觸發其它產品策略限制

5 小時窗口重置，只恢復 5 小時額度；不會恢復 weekly 額度。weekly 額度要等自己的 reset，或者在支援的方案裡購買額外 credits。

02 為什麼會同時扣兩個窗口

可以把 Codex 的額度想成兩個閘門：

窗口	作用
5 小時窗口	防止短時間高頻使用
週窗口	控制一週總使用量

每次 Codex 任務都會產生一次實際消耗。這個消耗會反映到目前相關的 rate limit 窗口裡。

因此不是：

1
2
3

先扣 5 小時額度
5 小時額度用完後
再扣週額度

而更像是：

1
2
3

一次 Codex 請求
=> 計入 5 小時窗口
=> 同時計入週窗口

這就是「5 小時額度沒用完，但 weekly 也在下降」的核心原因。

03 現在更應該看 token-based credits

OpenAI 沒有公開一個使用者可以完全複算的 Codex 扣費公式。官方公開的是 rate card、影響因素和不同模型的 credit 單價。

截至 2026-04-15，Codex rate card 的主口徑已經是 token-based credits。也就是根據輸入 tokens、快取輸入 tokens、輸出 tokens 折算 credits。

官方給出的示例價格如下：

模型	輸入 / 1M tokens	快取輸入 / 1M tokens	輸出 / 1M tokens
GPT-5.4	62.50 credits	6.250 credits	375 credits
GPT-5.4-Mini	18.75 credits	1.875 credits	113 credits
GPT-5.3-Codex	43.75 credits	4.375 credits	350 credits
GPT-5.2-Codex	43.75 credits	4.375 credits	350 credits
GPT-5.1-Codex-Max	31.25 credits	3.125 credits	250 credits
GPT-5.1-Codex-mini	6.25 credits	0.625 credits	50 credits

所以一個粗略估算公式是：

本次消耗
≈ 輸入 tokens / 1,000,000 × 模型輸入單價
+ 快取輸入 tokens / 1,000,000 × 模型快取輸入單價
+ 輸出 tokens / 1,000,000 × 模型輸出單價

這不是精確帳單公式，但足夠解釋趨勢：輸出很貴，長上下文很貴，高能力模型更貴。官方還說明 Fast mode 會消耗 2 倍 credits，Code review 使用 GPT-5.3-Codex 的價格。

04 不要再只看「訊息條數」

同樣發 10 次 Codex，消耗可能完全不同。

輕量任務通常更省：

改一個小函式
解釋一段短程式碼
寫一小段文案
在明確文件裡做局部修改

重任務會更貴：

掃描大型程式碼庫
長時間執行 agent
多輪讀取、編輯、測試、修復
產生大量程式碼或長報告
使用 cloud task
開啟 fast mode

因此，訊息數量 只能作為很粗略的感覺，不能用來判斷真實消耗。

05 local task 和 cloud task 的差別

Codex 裡很容易拉開消耗差距的是執行位置。

local task 更像是在你的本地工作區裡讀文件、改程式碼、跑命令。cloud task 則把任務交給雲端環境託管執行，適合更長、更自動化的流程。

從額度角度看，cloud task 往往更貴。原因也很直接：

需要雲端執行環境
任務通常更長
工具調用更多
上下文更大
自動化鏈路更完整

如果只是普通程式碼編輯、文章整理、局部修復，優先 local task 會更省。cloud task 更適合確實需要雲端託管的任務。

06 為什麼 weekly 掉得特別快

如果你覺得「5 小時額度沒怎麼動，但 weekly 掉很多」，常見原因有這些：

使用了 cloud task。
使用了更貴的模型。
開啟了 fast mode。
上下文很大，Codex 讀了很多文件或保留了很長對話。
輸出很長，比如大量程式碼、長報告、長日誌分析。
任務鏈很長，比如搜尋、編輯、測試、修復、再測試。
自己的額度腳本把窗口標籤解析錯了。

如果你是用腳本讀 /backend-api/wham/usage 之類的字段，不要只看加工後的 five_hour%、weekly%。最好先看 raw JSON 裡的：

limit_window_seconds
percent_left
reset_at
bucket / feature 名稱

常見窗口長度可以這樣判斷：

limit_window_seconds = 18000
=> 約 5 小時窗口

limit_window_seconds = 604800
=> 約 7 天窗口

如果腳本把兩個窗口標反，就會誤判額度變化。

07 更省額度的使用方式

想讓 weekly 撐得久一點，可以這樣用：

把大任務拆成小任務。先處理一個文件、一個 bug、一個功能點。
能 local 就 local，謹慎使用 cloud task。
明確告訴 Codex 相關路徑，減少無關掃描。
避免一次塞入巨大日誌、長文件、無關上下文。
輕量任務可以用更便宜的 mini 模型。
長任務前先讓 Codex 出計畫，再進入執行。
不需要長報告時，明確要求「簡短回答」。

最實用的記憶方式是：

是否能繼續用
= 短窗口還有額度
&& 週窗口還有額度

消耗快不快
= 模型價格
× tokens
× 輸出長度
× 任務複雜度
× 執行位置

這個模型不能精確對帳，但足夠解釋大多數 Codex 額度現象。

Codex 額度用量統計

Sun, 12 Apr 2026 00:01:33 +0800

如果你想查看 Codex 目前帳號的額度剩餘情況，可以直接寫一個小腳本去請求 ChatGPT 的 /backend-api/wham/usage 介面。

這類腳本的思路很簡單：

從 auth.json 裡讀取 tokens.access_token 和 tokens.account_id
請求 https://chatgpt.com/backend-api/wham/usage
在請求標頭裡帶上 Authorization: Bearer ... 和 ChatGPT-Account-Id
解析回傳結果裡的五小時窗口和週窗口額度

適合做什麼

這個方法適合你在本地快速確認：

五小時額度還剩多少
週額度還剩多少
額度會在什麼時候重置

如果你有多個帳號，也可以讓腳本批次讀取 account/*.auth.json，統一輸出一張摘要表。你目前登入的 ChatGPT 帳號所對應的 auth.json，通常可以在 ~/.codex/ 目錄下找到。

最關鍵的輸入

腳本通常只依賴兩項憑證：

access_token
account_id

它們通常都可以從本地 auth.json 中取得。只要這兩個值有效，請求標頭就能按下面的形式組織：

headers = {
    "Authorization": f"Bearer {auth_token}",
    "Accept": "application/json",
    "ChatGPT-Account-Id": auth_account_id,
    "Origin": "https://chatgpt.com",
    "Referer": "https://chatgpt.com/",
    "User-Agent": "Mozilla/5.0",
}

回傳結果怎麼看

介面回傳後，重點看的是兩類窗口：

five_hour
weekly

腳本可以把它們統一整理成下面幾項：

剩餘額度百分比
重置時間
對應的時間窗口長度

如果介面欄位名稱有差異，也可以順手相容 primary_window、secondary_window、five_hour_limit、weekly_limit 這些變體。

常見問題

如果腳本回傳 401，通常表示 access_token 已過期或無效。

如果回傳 403，通常表示目前帳號沒有權限存取這個介面，或者帳號狀態異常。

如果你看到同一個回應裡欄位命名不一致，也不用太意外。實際處理時最好先把不同命名方式統一映射後再輸出。

參考連結

codex-auth-manager：https://github.com/RioArisk/codex-auth-manager

程式碼

import argparse
import base64
import json
import os
import sys
from datetime import datetime, timedelta, timezone
from pathlib import Path
from typing import Any

import requests


UTC = timezone.utc
CST = timezone(timedelta(hours=8), name="CST")
JSONDict = dict[str, Any]


def parse_args() -> argparse.Namespace:
    parser = argparse.ArgumentParser(
        description="Query ChatGPT Codex usage from /backend-api/wham/usage."
    )
    parser.add_argument(
        "account_name",
        nargs="?",
        help="Account name used to load account/<account_name>.auth.json. If omitted, load all *.auth.json files in account/.",
    )
    parser.add_argument(
        "--account-dir",
        default="account",
        help="Directory containing <account_name>.auth.json files.",
    )
    parser.add_argument(
        "--chatgpt-url",
        default="https://chatgpt.com/backend-api/wham/usage",
        help="ChatGPT usage endpoint.",
    )
    parser.add_argument(
        "--raw-json",
        action="store_true",
        help="Print the full JSON response body.",
    )
    parser.add_argument(
        "--raw-headers",
        action="store_true",
        help="Print response headers.",
    )
    return parser.parse_args()


def print_json(data: Any) -> None:
    print(json.dumps(data, indent=2, ensure_ascii=False))


def load_auth_json(path_str: str | Path | None) -> JSONDict | None:
    if not path_str:
        return None
    path = Path(path_str).expanduser()
    if not path.is_file():
        return None
    try:
        return json.loads(path.read_text(encoding="utf-8"))
    except (OSError, json.JSONDecodeError):
        return None


def get_nested_string(data: JSONDict | None, *keys: str) -> str | None:
    current: Any = data
    for key in keys:
        if not isinstance(current, dict):
            return None
        current = current.get(key)
    return current if isinstance(current, str) and current else None


def format_dt(dt: datetime | None) -> str:
    if dt is None:
        return "-"
    return dt.astimezone(CST).strftime("%Y-%m-%d %H:%M:%S %Z")


def format_cst(dt: datetime | None) -> str:
    return format_dt(dt)


def epoch_ms_to_dt(value: Any) -> datetime | None:
    if value is None:
        return None
    try:
        raw = int(value)
    except (TypeError, ValueError):
        return None
    # Newer responses sometimes use epoch seconds, older ones use epoch milliseconds.
    timestamp = raw / 1000 if raw > 10**11 else raw
    return datetime.fromtimestamp(timestamp, tz=UTC)


def first_dict(data: Any, *keys: str) -> JSONDict | None:
    for key in keys:
        value = data.get(key) if isinstance(data, dict) else None
        if isinstance(value, dict):
            return value
    return None


def decode_jwt_exp(token: str) -> datetime | None:
    parts = token.split(".")
    if len(parts) != 3:
        return None
    try:
        payload = parts[1]
        payload += "=" * (-len(payload) % 4)
        data = json.loads(base64.urlsafe_b64decode(payload.encode("ascii")))
        exp = data.get("exp")
        if exp is None:
            return None
        return datetime.fromtimestamp(int(exp), tz=UTC)
    except (ValueError, TypeError, json.JSONDecodeError):
        return None


def get_percent_left(value: JSONDict) -> float | int | None:
    percent_left = value.get("percent_left")
    if percent_left is None:
        percent_left = value.get("remaining_percent")
    if percent_left is not None:
        return percent_left

    used_percent = value.get("used_percent")
    try:
        if used_percent is not None:
            return max(0, 100 - float(used_percent))
    except (TypeError, ValueError):
        return None
    return None


def resolve_limit_window(value: JSONDict) -> JSONDict:
    if (
        "reset_at" not in value
        and "reset_time_ms" not in value
        and isinstance(value.get("primary_window"), dict)
    ):
        return value["primary_window"]
    return value


def parse_limit_entry(name: str, value: Any) -> JSONDict | None:
    if not isinstance(value, dict):
        return None

    value = resolve_limit_window(value)

    percent_left = get_percent_left(value)
    reset_time_ms = value.get("reset_time_ms")
    if reset_time_ms is None:
        reset_time_ms = value.get("reset_at")

    window_seconds = value.get("limit_window_seconds")

    return {
        "name": name,
        "percent_left": percent_left,
        "reset_time_ms": reset_time_ms,
        "reset_at": epoch_ms_to_dt(reset_time_ms),
        "limit_window_seconds": window_seconds,
    }


def infer_limit_name(window_seconds: Any) -> str | None:
    if not isinstance(window_seconds, (int, float)):
        return None
    if window_seconds <= 6 * 3600:
        return "five_hour"
    if window_seconds >= 6 * 24 * 3600:
        return "weekly"
    return None


def relabel_rate_limits(primary: JSONDict | None, secondary: JSONDict | None) -> tuple[JSONDict | None, JSONDict | None]:
    for entry in (primary, secondary):
        if not entry:
            continue
        inferred_name = infer_limit_name(entry.get("limit_window_seconds"))
        if inferred_name:
            entry["name"] = inferred_name

    if primary and secondary and primary.get("name") == secondary.get("name"):
        if primary.get("name") == "weekly":
            primary["name"] = "five_hour"
        else:
            secondary["name"] = "weekly"

    if primary and primary.get("name") == "weekly" and secondary is None:
        return None, primary

    if secondary and secondary.get("name") == "five_hour" and primary is None:
        return secondary, None

    return primary, secondary


def parse_rate_limits(data: JSONDict) -> tuple[JSONDict | None, JSONDict | None]:
    primary = None
    secondary = None

    for primary_key in ("five_hour", "five_hour_limit", "five_hour_rate_limit", "primary"):
        if primary_key in data:
            primary = parse_limit_entry("five_hour", data.get(primary_key))
            if primary:
                break

    for secondary_key in ("weekly", "weekly_limit", "weekly_rate_limit", "secondary"):
        if secondary_key in data:
            secondary = parse_limit_entry("weekly", data.get(secondary_key))
            if secondary:
                break

    if primary is None:
        primary = parse_limit_entry("five_hour", data.get("primary_window"))
    if secondary is None:
        secondary = parse_limit_entry("weekly", data.get("secondary_window"))

    return relabel_rate_limits(primary, secondary)


def format_percent(value: Any) -> str:
    return f"{value:g}" if isinstance(value, (int, float)) else str(value if value is not None else "-")


def percent_sort_value(value: Any, descending: bool) -> tuple[int, float]:
    if isinstance(value, (int, float)):
        numeric_value = float(value)
        return (0, -numeric_value if descending else numeric_value)
    return (1, 0.0)


def get_auth_paths(account_dir: str, account_name: str | None) -> list[Path]:
    base_dir = Path(account_dir)
    if account_name:
        return [base_dir / f"{account_name}.auth.json"]
    return sorted(base_dir.glob("*.auth.json"))


def get_account_name_from_path(path: Path) -> str:
    suffix = ".auth.json"
    return path.name[: -len(suffix)] if path.name.endswith(suffix) else path.stem


def build_summary_row(account_name: str, five_hour: JSONDict | None, weekly: JSONDict | None) -> JSONDict:
    return {
        "account": account_name,
        "five_hour_percent": five_hour["percent_left"] if five_hour else None,
        "weekly_percent": weekly["percent_left"] if weekly else None,
        "weekly_reset_at": weekly["reset_at"] if weekly else None,
    }


def print_summary_rows(rows: list[JSONDict]) -> None:
    if not rows:
        return

    sorted_rows = sorted(
        rows,
        key=lambda row: (
            percent_sort_value(row.get("five_hour_percent"), descending=True),
            percent_sort_value(row.get("weekly_percent"), descending=True),
            format_cst(row.get("weekly_reset_at")),
            row["account"],
        ),
    )

    display_rows = []
    for row in sorted_rows:
        display_rows.append(
            {
                "account": str(row["account"]),
                "five_hour": format_percent(row.get("five_hour_percent")),
                "weekly": format_percent(row.get("weekly_percent")),
                "weekly_reset": format_cst(row.get("weekly_reset_at")),
            }
        )

    headers = {
        "account": "account",
        "five_hour": "five_hour%",
        "weekly": "weekly%",
        "weekly_reset": "weekly_reset",
    }
    widths = {
        key: max(len(headers[key]), max(len(item[key]) for item in display_rows))
        for key in headers
    }

    print(
        f"{headers['account']:<{widths['account']}}  "
        f"{headers['five_hour']:>{widths['five_hour']}}  "
        f"{headers['weekly']:>{widths['weekly']}}  "
        f"{headers['weekly_reset']:<{widths['weekly_reset']}}"
    )
    for item in display_rows:
        print(
            f"{item['account']:<{widths['account']}}  "
            f"{item['five_hour']:>{widths['five_hour']}}  "
            f"{item['weekly']:>{widths['weekly']}}  "
            f"{item['weekly_reset']:<{widths['weekly_reset']}}"
        )


def validate_token_inputs(
    token: str,
    account_id: str,
    auth_token: str | None,
    auth_account_id: str | None,
) -> int | None:
    if token.startswith("sess-"):
        print("status: invalid_token_type", file=sys.stderr)
        print(
            "message: --chatgpt-token looks like a session token (sess-...). Use the JWT access_token instead.",
            file=sys.stderr,
        )
        if auth_token:
            print(
                "hint: Found tokens.access_token in auth.json; omit --chatgpt-token or pass that value instead.",
                file=sys.stderr,
            )
        return 1

    token_exp = decode_jwt_exp(token)
    if token_exp is not None and token_exp <= datetime.now(UTC):
        print("status: expired", file=sys.stderr)
        print(f"message: access_token expired at {format_dt(token_exp)}", file=sys.stderr)
        if auth_token and auth_token != token:
            auth_token_exp = decode_jwt_exp(auth_token)
            hint = format_dt(auth_token_exp) if auth_token_exp else "unknown time"
            print(f"hint: auth.json contains a different access_token expiring at {hint}", file=sys.stderr)
        return 1

    if auth_account_id and account_id != auth_account_id:
        print("warning: supplied --account-id does not match auth.json tokens.account_id", file=sys.stderr)

    return None


def handle_error_response(response: requests.Response, data: Any, raw_json: bool) -> int | None:
    if response.status_code == 401:
        print("status: expired", file=sys.stderr)
        print("message: Token 宸茶繃鏈熸垨鏃犳晥", file=sys.stderr)
        if raw_json:
            print_json(data)
        return 3

    if response.status_code == 403:
        print("status: forbidden", file=sys.stderr)
        print("message: 璐﹀彿宸茶灏佺鎴栨棤鏉冭闂?, file=sys.stderr)
        if raw_json:
            print_json(data)
        return 3

    if response.status_code >= 400:
        print(f"HTTP {response.status_code}", file=sys.stderr)
        print_json(data)
        return 3

    return None


def fetch_chatgpt_usage(auth_path: Path, args: argparse.Namespace) -> tuple[int, JSONDict | None]:
    auth_data = load_auth_json(auth_path)
    account_name = get_account_name_from_path(auth_path)
    auth_token = get_nested_string(auth_data, "tokens", "access_token")
    auth_account_id = get_nested_string(auth_data, "tokens", "account_id")

    if not auth_data:
        print(f"{account_name}: auth file not found or invalid", file=sys.stderr)
        return 1, None

    if not auth_token:
        print(f"{account_name}: missing access_token", file=sys.stderr)
        return 1, None

    if not auth_account_id:
        print(f"{account_name}: missing account_id", file=sys.stderr)
        return 1, None

    validation_error = validate_token_inputs(
        auth_token,
        auth_account_id,
        auth_token,
        auth_account_id,
    )
    if validation_error is not None:
        return validation_error, None

    headers = {
        "Authorization": f"Bearer {auth_token}",
        "Accept": "application/json",
        "ChatGPT-Account-Id": auth_account_id,
        "Origin": "https://chatgpt.com",
        "Referer": "https://chatgpt.com/",
        "User-Agent": "Mozilla/5.0",
    }

    try:
        response = requests.get(args.chatgpt_url, headers=headers, timeout=60)
    except requests.RequestException as exc:
        print(f"Request failed: {exc}", file=sys.stderr)
        return 2, None

    if args.raw_headers:
        print("=== Headers ===")
        print_json(dict(response.headers))
        print()

    try:
        data = response.json()
    except ValueError:
        print(f"HTTP {response.status_code}", file=sys.stderr)
        print(response.text, file=sys.stderr)
        return 3, None

    error_response = handle_error_response(response, data, args.raw_json)
    if error_response is not None:
        return error_response, None

    if args.raw_json:
        print("=== Raw JSON ===")
        print_json(data)
        print()

    rate_limits = first_dict(data, "rate_limit", "rate_limits")

    if rate_limits is None:
        return 0, build_summary_row(account_name, None, None)

    five_hour, weekly = parse_rate_limits(rate_limits)
    return 0, build_summary_row(account_name, five_hour, weekly)


def main() -> None:
    args = parse_args()
    auth_paths = get_auth_paths(args.account_dir, args.account_name)
    if not auth_paths:
        print("No auth files found.", file=sys.stderr)
        sys.exit(1)

    exit_code = 0
    summary_rows: list[JSONDict] = []
    for auth_path in auth_paths:
        current_exit_code, summary_row = fetch_chatgpt_usage(auth_path, args)
        exit_code = max(exit_code, current_exit_code)
        if summary_row is not None and not args.raw_json:
            summary_rows.append(summary_row)

    if summary_rows:
        print_summary_rows(summary_rows)
    sys.exit(exit_code)


if __name__ == "__main__":
    main()

ChatGPT on KnightLi的博客

Google I/O 之後，GPT 和 Gemini 訂閱怎麼選？普通使用者與開發者對比

先說結論

Google I/O 之後，Gemini 發生了什麼變化

ChatGPT / GPT 訂閱現在適合誰

Gemini / Google AI 訂閱現在適合誰

普通使用者怎麼選

開發者怎麼選

內容創作者怎麼選

企業和團隊怎麼選

什麼時候需要 Pro / Ultra

最省錢的訂閱策略

訂閱前檢查清單

小結

AI Agent 到底怎麼進化的？2022-2026 五代演進完整梳理

總覽：五代 Agent 時間線

2022 年末：第零代，ChatGPT 對話框時代

2023 年中：第一代，工具調用覺醒

2023 年末到 2024 年：第二代，工程化工作流

2024 到 2025 年：第三代，Computer Use 進入真實界面

2025 到 2026 年：第四代，MCP、Skills 和常駐數位員工

2026 之後：第五代前瞻，閉環、內在記憶和世界模型

這條時間線背後的六條規律

真正的護城河

最後

Codex 手機遠端存取來了：用 ChatGPT App 跟進 Mac 上的編程任務

它能做什麼

使用前需要什麼

Codex 手機遠端存取的限制

怎麼連接

手機端適合做什麼

常見問題

適合哪些場景

我的判斷

參考資料

ChatGPT File Library 是什麼：文件保存、容量限制和隱私邊界

最新可用範圍

它會保存哪些文件

怎麼把文件加入新對話

怎麼查找和管理

各方案容量

單文件限制

刪除和下載

Temporary Chat 不會保存文件

資料和訓練設定

適合怎麼用

我的判斷

參考資料

OpenAI 新一代 Realtime 語音模型：GPT-Realtime-2、即時翻譯與串流轉寫

GPT-Realtime-2：語音 Agent 的主力模型

即時翻譯：面向跨語言語音產品

串流轉寫：讓語音內容馬上進入工作流

價格與可用性

對開發者意味著什麼

也要注意安全和告知

總結

GPT-5.5、GPT-5.5 Instant、GPT-5.5 Thinking 和 GPT-5.5 Pro 有什麼區別

快速對比

GPT-5.5 是什麼

GPT-5.5 Instant：預設、快速、日常使用

GPT-5.5 Thinking：複雜任務的主力

GPT-5.5 Pro：研究級、更重、更嚴謹

工具支援有什麼不同

上下文窗口有什麼區別

怎麼選

日常問答

寫文章、摘要、改郵件

寫程式碼和除錯

研究和資料分析

需要圖像生成、Canvas、Memory

簡短結論

相關連結

ChatGPT、Claude Code 和 Gemini 的記憶機制有什麼不同？

ChatGPT：圍繞人的長期偏好

Memory Sources：讓個性化來源更可見

Claude Code：圍繞程式碼庫和工程規則

Claude Code Auto Memory：自動累積項目經驗

Gemini：圍繞 Google 生態上下文

三者核心差異

該怎麼選擇和使用

1. 日常對話：為什麼很多人還是先打開 `ChatGPT`

2. 命令列程式開發與長任務：為什麼很多人更偏向 `Claude`

3. `Gemini` 的優勢往往不在「跟別人正面拼一切」