OpenAI on KnightLi的博客

GPT-5.6 爆料：150 萬 token 上下文視窗意味著什麼

Wed, 27 May 2026 13:55:06 +0800

2026 年 5 月 26 日，有爆料稱多名開發者在 OpenAI Codex 後端日誌中發現了尚未官宣的 GPT-5.6 相關痕跡，其中一個內部代號為 iris-alpha，傳聞支援 150 萬 token 上下文視窗，並可能在 2026 年 6 月發布。

這類資訊目前仍屬於爆料，不等於 OpenAI 官方發布。更穩妥的看法是：它展示了下一代大模型可能繼續沿著「更長上下文、更強程式碼能力、更好前端生成」幾個方向推進。

爆料裡提到哪些模型代號

報導提到，開發者在相關日誌中看到的不只 iris-alpha，還包括 ember-alpha 和 beacon-alpha 等版本。

這些名字現階段更像內部測試代號。它們是否都屬於 GPT-5.6 系列、最終會不會對應公開 API 模型、發布時間是否會改變，都還沒有官方確認。

所以不要急著把這些代號當成最終產品名。真正值得關注的是它們暴露出來的能力方向。

150 萬 token 上下文為什麼重要

報導裡最醒目的數字是 150 萬 token 上下文視窗。

爆料中給出的對比是：

目前 GPT-5.5 API 為 105 萬 token
Codex OAuth 渠道約為 40 萬 token
GPT-5.6 傳聞提升到 150 萬 token

上下文視窗決定模型單次能接收和利用多少資訊。它包括使用者輸入、歷史對話、系統提示、檔案內容、日誌、程式碼 diff、測試輸出等。

如果這個數字屬實，GPT-5.6 對幾類任務會更有意義：

閱讀大型程式碼倉庫
分析長篇合約或技術文件
連續追蹤複雜專案
保留更長的 agent 工作歷史
在一次任務裡處理更多檔案和更多測試回饋

但上下文視窗變大，不代表模型一定「更聰明」。它只是讓模型能看到更多材料。模型是否能從長上下文裡準確檢索、歸納、保持目標一致，還要看訓練、推理策略和工具調用能力。

真實世界測試的訊號

報導還提到，有開發者在輔助工具 OpenCode 中做了較極端的真實世界測試：當輸入達到約 90 萬 token 時，模型仍能流暢回應，甚至處理超過 105 萬 token 的請求。

如果這個回饋準確，它說明 OpenAI 可能不僅在擴展理論視窗，也在處理長輸入下的回應穩定性。

對 AI 程式設計來說，這點比「視窗數字」本身更重要。開發任務裡的上下文往往不是乾淨的長文本，而是程式碼、日誌、錯誤堆疊、依賴檔案、設定檔和使用者指令混在一起。模型不僅要裝得下，還要找得準。

前端介面生成能力也被提到

這次爆料還提到了 GPT-5.6 的前端生成能力。

據報導，爆料截圖中模型在幾乎沒有詳細提示詞的情況下，生成了一個名為 Lumen Notes 的極簡記事應用介面。報導強調的表現包括：

柵格布局更成熟
配色更克制
字體層級更清晰
導航結構更完整

如果這類能力穩定，AI 程式設計模型的價值會繼續從「能寫程式碼」轉向「能生成更接近可用產品的介面」。這也是 Codex、Claude Code、Cursor、Gemini CLI 等工具最近都在推進的方向：不只是補函式，而是從需求到介面、測試、修復形成閉環。

還提到了哪些競爭模型

同一批爆料還提到，Anthropic 的 Claude Sonnet 4.8、Google 的 Gemini 3.5 Pro，以及 xAI 的 Grok 5，都可能瞄準 2026 年 6 月發布。

這部分同樣要按傳聞看待。即便多個模型確實都在 6 月前後更新，最終能力也要等官方文件、API 實測和真實開發任務驗證。

不過大方向很清楚：模型廠商的競爭已經不只是聊天能力，而是更長上下文、更強工具調用、更穩的程式碼編輯、更好的 UI 生成，以及更適合 agent 長任務的可靠性。

我的判斷

如果 GPT-5.6 的 150 萬 token 上下文視窗最終成真，它對 Codex 這類程式設計 agent 的意義會比普通聊天更大。

因為 agent 程式設計天然會消耗大量上下文：讀倉庫、跑測試、看日誌、比較 diff、保留使用者偏好、連續修復問題。上下文越長，agent 越有機會在一次任務裡保留完整線索。

但我更關心三個實際問題：

長上下文下的定位能力是否穩定。
大量日誌和程式碼混合輸入時，模型是否會被噪音帶偏。
API、Codex、ChatGPT、OAuth 等不同入口是否會給出一致的上下文上限。

所以這條爆料可以關注，但不適合過早下結論。等 OpenAI 官方發布模型卡、API 文件和真實價格之後，再判斷 GPT-5.6 是否真的適合大型程式碼倉庫和長任務 agent 工作流，會更穩。

OpenAI Symphony 是什麼？Codex 編排、Issue 驅動與 AI Agent 開發工作流

Mon, 25 May 2026 00:17:32 +0800

OpenAI 最近開源了一個很有意思的 Codex 編排規範：Symphony。

它不是另一個聊天式編程助手，也不是一個完整的新 IDE。更準確地說，Symphony 是一套面向 Codex 的「工作編排方式」：把類似 Linear 的 issue tracker 變成編程智能體的控制平面，讓每一個未關閉的任務都能對應一個持續運行的 Agent。

官方文章裡有一句話很能概括它的方向：過去工程師要同時盯著多個 Codex 會話，不斷分配任務、審查輸出、糾偏和重啟；Symphony 想解決的，正是這個上下文切換瓶頸。

Symphony 解決的不是寫代碼，而是管理 Agent

單個 Codex 會話適合互動式開發：你給它一個任務，它修改代碼，你 review，再繼續追問。但當團隊開始同時使用多個 Agent 時，問題會從「代碼能不能寫出來」變成「誰在做哪件事、做到哪一步、失敗後誰來接手」。

OpenAI 的做法是把工作重心從「會話」切到「任務」：

issue 是真正的工作單元；
每個未關閉 issue 都可以映射到一個獨立 Agent 工作空間；
Symphony 負責持續輪詢任務看板，決定哪些任務需要啟動、重試、停止或回收；
Codex 在工作空間裡執行實作、測試、提交、建立 PR、更新狀態等動作；
人類不再微操每個會話，而是審查結果、調整目標和維護邊界。

這背後的變化很關鍵：Agent 不再只是一個被人類臨時喚起的工具，而是開發流程裡持續運行的一類執行者。

為什麼是 issue tracker？

因為團隊已經用 issue tracker 管理真實工作。

需求、bug、重構、遷移、調研、優先級、阻塞關係、負責人、里程碑，這些資訊本來就沉澱在 Linear、GitHub Issues 或類似系統裡。Symphony 沒有重新發明一個龐大的控制台，而是把這些現有系統當作 Agent 的任務入口。

這樣做有幾個好處：

工作不必從 issue 複製到聊天視窗裡。
人類可以繼續按熟悉的方式建立、拆分、排期和關閉任務。
Agent 的狀態變化能回寫到同一個工作系統裡，方便團隊非同步協作。
任務依賴可以自然形成 DAG，讓未阻塞的任務並行推進。

如果把傳統 CI 看成「代碼提交後的自動化」，Symphony 更像是「issue 建立後的自動化」。

它的核心工作流

一個典型的 Symphony 流程可以理解為：

创建 issue
  -> Symphony 轮询到可执行任务
  -> 为该 issue 创建独立 workspace
  -> 启动 Codex agent session
  -> Agent 阅读任务、修改代码、运行测试
  -> 创建或更新 PR
  -> 写回任务状态、评论、证据和交付物
  -> 人类 review、合并或要求修改

官方規範裡還強調了幾個工程化點：

每個 issue 使用獨立工作空間，降低相互污染；
編排器維護重試、並發和恢復狀態；
工作流策略放在倉庫內的 WORKFLOW.md，讓團隊把 Agent 應該如何處理任務寫成可版本化的規則；
實作需要保留可觀測性，至少要有結構化日誌；
成功狀態不一定是 Done，也可以是交給人類 review 的中間狀態。

這說明 Symphony 不是簡單地「讓 AI 自動寫代碼」，而是在定義一套可運行、可恢復、可審計的 Agent 工作系統。

目標驅動，而不是死板狀態機

OpenAI 在文章裡提到一個重要轉變：早期他們嘗試把很多動作寫死在外層 harness 裡，例如提交代碼、跑測試、處理 GitHub 流程。但隨著 Codex 能力增強，這種方式反而限制了 Agent。

後來的方向是給 Agent 設定目標，而不是把每一步都寫成固定狀態轉換。

比如，一個任務的目標可以是「完成 Vite 遷移並確保 CI 通過」。Agent 可以自己判斷是否需要改配置、修測試、讀 CI 日誌、處理 review feedback，甚至拆出新的後續 issue。Symphony 負責提供邊界、上下文和運行框架，而不是替 Agent 規定每一個動作。

這也是它和傳統自動化腳本的區別：腳本擅長重複確定流程；Symphony 面向的是帶有不確定性的工程任務。

和普通 Codex 使用方式有什麼不同？

普通 Codex 會話更像「人帶著 AI 寫代碼」：

人類打開會話；
人類描述任務；
人類觀察輸出；
人類隨時糾偏；
任務結束後再開下一個會話。

Symphony 更像「團隊把任務池交給一組 Agent 執行」：

人類寫清楚 issue；
系統持續發現可執行任務；
Agent 在獨立環境裡推進；
結果以 PR、評論、測試狀態、影片或分析報告的形式返回；
人類在關鍵節點做 review。

這不是替代工程師，而是把工程師從「同時照看多個會話」的負擔裡解放出來。OpenAI 在官方文章中提到，在部分團隊中，合併到主分支的 PR 數量有明顯提升；但更值得注意的是工作方式的變化：試驗一個想法、發起一次重構、驗證一個假設的啟動成本變低了。

適合哪些場景？

Symphony 更適合這些任務：

常規功能實作；
已有代碼庫裡的小型重構；
基礎設施遷移；
依賴升級；
測試補齊；
CI 修復；
調研後生成實作計劃；
根據 review feedback 繼續修改 PR。

它不一定適合高度模糊、需要強業務判斷或架構拍板的任務。對這類問題，互動式 Codex 會話仍然更自然，因為人類需要在過程中持續參與。

風險和邊界

Symphony 的吸引力很強，但真正落地時不能只看「自動化」這一面。

幾個邊界要提前想清楚：

issue 必須寫清楚，否則 Agent 會把模糊需求放大成錯誤實作；
Agent 的權限要收斂，尤其是倉庫、密鑰、生產環境和第三方服務訪問；
每個工作空間要隔離，避免多個任務相互污染；
CI、測試、lint 和 review 仍然是必須的質量門；
任務狀態、PR 連結、日誌和失敗原因要可追蹤；
人類 review 不能省，尤其是涉及安全、計費、資料遷移和權限邏輯的改動。

官方倉庫也把 Symphony 定位為 trusted environment 裡的工程預覽和參考實作，而不是一個拿來就能無腦替代研發流程的成品平台。

我對 Symphony 的理解

Symphony 最有價值的地方，不在於它用了 Linear，也不在於參考實作選擇了 Elixir，而在於它重新定義了編程 Agent 的入口。

過去我們習慣從聊天視窗啟動 AI 編程：這很靈活，但規模一大，人類注意力就成了瓶頸。Symphony 把入口放回 issue tracker，讓 Agent 圍繞真實任務持續工作。這樣一來，AI 編程從「個人效率工具」開始向「團隊工作流基礎設施」靠近。

如果你已經在使用 Codex、Claude Code、Cursor Agent 或類似工具，Symphony 值得關注的不是某個具體實作，而是它背後的模式：

不要只管理 Agent 會話，要管理需要完成的工作。

這可能會成為下一階段 AI 編程工具的關鍵分水嶺。

參考連結

AI 數學里程碑：OpenAI 推翻 Erdős 單位距離猜想意味著什麼

Fri, 22 May 2026 22:21:46 +0800

OpenAI 在 2026 年 5 月 20 日公布了一項很不尋常的研究結果：內部一款通用推理模型在平面單位距離問題上找到新的構造，推翻了數學界長期相信的一個上界猜想。

這不是一個普通聊天機器人隨口給出的答案，而是 OpenAI 內部通用推理模型在一組 Erdős 問題評估中產生的證明。證明已經由外部數學家檢查，OpenAI 也公開了證明文本、配套說明和模型推理思路的刪節版。

問題是什麼

平面單位距離問題由 Paul Erdős 在 1946 年提出。問題本身很好理解：在平面上放置 n 個點，最多能有多少對點之間的距離剛好等於 1？

數學上通常把這個最大數量記為 u(n)。如果把點排成一條直線，可以得到大約 n - 1 對單位距離。若把點排成方形網格，每個點和上下左右相鄰點形成單位距離，數量大約可以達到 2n。Erdős 還給出過更精細的縮放方形網格構造，使單位距離點對數量達到 n^(1+C/log log n) 的量級。

長期以來，數學界普遍認為這類網格構造接近最優。對應的猜想可以粗略寫成：u(n) 不會超過 n^(1+o(1))。這裡的 o(1) 會隨著 n 增大趨近於 0，意思是單位距離點對數可以比線性成長略快，但不應該出現一個固定指數優勢。

OpenAI 模型給出的結果打破了這個直覺。它構造出一族無限多的例子：對於無窮多個 n，可以得到至少 n^(1+δ) 個單位距離點對，其中 δ 是固定正數。OpenAI 官方文章提到，原始 AI 證明沒有給出明確的 δ 數值，但 Will Sawin 後續改進顯示可以取 δ = 0.014。

證明過程為什麼特別

這次突破最有意思的地方，不只是結論本身，而是證明路線。

Erdős 早期構造可以透過高斯整數理解。高斯整數形如 a+bi，它把普通整數擴展到複平面中，並保留了類似唯一分解的性質。借助這種數論結構，可以解釋為什麼某些縮放後的網格會產生很多單位距離。

OpenAI 模型沒有繼續沿著普通幾何直覺推進，而是把問題帶到更複雜的代數數論中。官方解釋稱，新證明使用更一般的代數數域，利用其中更豐富的對稱結構製造大量單位長度差，從而在平面中形成更多距離剛好為 1 的點對。

更技術一點說，證明涉及無限類域塔和 Golod-Shafarevich 理論。這些工具對代數數論研究者並不陌生，但它們突然出現在一個歐氏平面裡的組合幾何問題中，才是外部專家認為這項結果很有啟發性的原因。

這個過程大致可以拆成四步：

從單位距離問題的傳統網格構造出發，把「點之間差值長度為 1」轉化為代數結構中的範數和差值問題。
用更複雜的代數數域替代高斯整數，讓可用的單位長度差數量變多。
借助無限類域塔和 Golod-Shafarevich 理論證明所需數域確實存在。
把代數構造重新落回平面點集，得到在無窮多個 n 上超過 n^(1+o(1)) 的單位距離點對數量。

也就是說，AI 不是簡單搜尋已有證明，而是把組合幾何和代數數論連接起來，提出了一條人類主流直覺之外的構造路線。

專家反應

OpenAI 官方文章列出了多位數學家的評價，整體態度相當積極，但重點並不完全相同。

組合數學家 Noga Alon 認為，這個問題是 Erdős 最喜歡的問題之一，幾乎所有組合幾何研究者都思考過它。讓他意外的是，正確答案並不符合長期相信的 n^(1+o(1)) 圖景，而新構造還優雅地使用了高級代數數論工具。

菲爾茲獎得主 Tim Gowers 把這件事稱為 AI 數學的里程碑。他的判斷很重：如果這篇論文由人類寫成並投稿到頂級數學期刊，他會毫不猶豫建議接收。這個評價真正強調的是證明品質，而不是 AI 話題本身。

數論學者 Arul Shankar 的關注點在模型能力。他認為這篇論文說明當前 AI 模型已經不只是數學家的助手，還能夠提出原創且巧妙的想法，並把它們推進到完整證明。

Thomas Bloom 在配套說明裡提出了一個更審慎的標準：評價 AI 生成證明，關鍵要看它有沒有讓人類更理解問題。在他看來，這個結果給出的答案是謹慎的肯定。它說明數論構造對離散幾何的影響可能比過去想像得更深。

這些反應共同指向一點：數學界並不是因為「AI 做出來了」就接受結果，而是因為證明可以被檢查，路線能解釋問題，結論也確實改變了原有理解。

這是否意味著 AI 替代數學家

還不能這樣理解。

這次案例裡，AI 提出了關鍵構造和證明路線，但結果成為嚴肅數學成果，仍然依賴外部數學家的檢查、解釋和補充。配套論文的作用也很重要：它把 AI 給出的證明放回數學語境中，解釋為什麼這個構造重要、它與已有研究有什麼關係、未來可能影響哪些問題。

更合理的判斷是：AI 開始進入數學研究上游，但沒有把人類專家擠出研究過程。

過去幾年，AI 在數學裡的角色主要是解競賽題、生成證明草稿、輔助形式化證明、檢索資料或改寫論證。這些任務通常仍由人類指定方向。單位距離問題這次的不同之處在於，模型面對長期開放問題，提出了新構造，並把論證推進到可審查狀態。

這會改變數學研究中的勞動分配。模型可能更擅長批量嘗試長鏈條路線、連接遠距離知識、探索研究者不一定優先嘗試的方向。人類數學家的價值則會集中到幾個更高層的問題上：

選擇哪些問題值得研究。
判斷 AI 給出的結果是否可信。
解釋結果在學科中的位置。
決定哪些路線值得繼續投入。

對未來科研的影響

這件事對 AI 產業的意義，可能比對單個數學猜想的意義更大。

數學是檢驗推理能力的理想場景。問題定義清楚，證明能被逐步檢查，一條長論證只要中間斷裂就無法成立。如果模型能在數學中保持複雜論證的連貫性，並連接不同學科工具，那麼類似能力也可能遷移到其他科研領域。

OpenAI 官方文章也把影響延伸到生物、物理、材料科學、工程和醫學。這裡不能簡單理解為「AI 很快會自動做科學發現」。更現實的變化是，AI 可能先成為科研中的路線生成器和假設放大器：它提出大量可能路徑，人類專家篩選、驗證、解釋，再把少數有價值的路徑推進下去。

這會帶來三類變化。

第一，研究速度可能被拉高。很多開放問題不是沒人能理解，而是可嘗試路線太多、跨領域成本太高。AI 如果能持續提出可審查構造，會擴大研究者的搜尋半徑。

第二，跨學科連接會變得更常見。單位距離問題原本屬於組合幾何，新證明卻借助代數數論。未來類似「遠距離知識遷移」可能成為 AI 科研工具的重要價值。

第三，專家審核會更重要。AI 生成的路線越多，越需要可靠的驗證機制。數學可以用證明審查來過濾錯誤，其他實驗科學還需要實驗、資料、復現和安全評估。AI 越像研究者，人類判斷越不能省略。

這和 IMO 解題有什麼不同

過去幾年，AI 數學能力常常透過競賽題來展示，比如 IMO 難度題目、大學數學題或者形式化證明任務。這些測試很重要，但它們和這次單位距離問題突破不是一類事情。

競賽題通常有明確題面、確定答案和相對固定的解題範圍。模型要做的是在有限時間內找到一條可驗證的解法。即使題目很難，它仍然屬於「已被設計出來的問題」，背後通常存在人類出題者預期的解題路徑。

開放數學問題則不同。它沒有標準答案，也不保證現有方法能解決。研究者需要判斷哪些方向值得嘗試，哪些工具可能跨領域遷移，哪些構造雖然反直覺但有機會成立。OpenAI 這次結果的意義正在這裡：模型不是只解一道已知題，而是在一個長期開放問題中提出新構造，並改變了原有猜想。

所以，這次突破更接近數學研究，而不是數學考試。

為什麼數學適合檢驗 AI 推理

數學是檢驗 AI 推理能力的高壓場景，因為它很難靠流暢表達蒙混過關。

一條數學證明必須層層成立。定義是否準確、引理是否可用、推導是否跳步、結論是否真的覆蓋目標命題，都可以被專家逐段檢查。只要中間某一步斷裂，整條證明就站不住。

這讓數學比很多開放式寫作任務更適合作為推理能力的測試場。模型不僅要給出看起來合理的答案，還要讓答案經得起複核。單位距離問題這次尤其有代表性：結論重要，證明路線也能被外部數學家審查和解釋。

當然，數學也不是唯一標準。現實科研還涉及實驗誤差、資料品質、設備條件和工程約束。但數學提供了一個清晰窗口：如果模型能在這裡產出新證明，至少說明它在長鏈條推理和跨領域連接上已經出現了值得認真對待的能力。

AI 證明為什麼仍然需要人類數學家

AI 給出證明，並不等於人類數學家可以退出。

第一，證明需要驗證。AI 生成的論證可能有漏洞、隱藏假設或符號誤用，必須由專家檢查。第二，證明需要解釋。一個結果為什麼重要、它和已有理論有什麼關係、它打開了哪些新問題，這些都不是形式上「證完了」就自動完成的。

第三，證明還需要改進。OpenAI 原始證明沒有給出明確的 δ，後續由 Will Sawin 改進到可以取 δ = 0.014。這說明人類專家仍然在壓縮、澄清和增強結果。

更重要的是，數學研究不是只追求「有一個證明」。研究者還要判斷哪條路線更有價值，哪些問題值得繼續推進，哪些構造可能遷移到其他領域。AI 可以擴大搜尋空間，但學術判斷仍然需要人。

這對 OpenAI 模型路線意味著什麼

從產品視角看，這件事說明 OpenAI 的模型路線正在從「回答問題的聊天助手」，轉向「能參與複雜任務的推理系統」。

聊天助手強調對話、總結、寫作和工具調用。科研推理系統則要能長期保持目標，組合多個領域的知識，生成可驗證的中間步驟，並把探索結果整理成專家能審查的形式。單位距離問題這次展示的，正是後者的一部分。

這也解釋了為什麼 OpenAI 會公開證明、配套說明和模型推理摘要。對科研任務來說，最終答案本身不夠，過程也必須能被檢查。未來面向科研、工程和專業知識工作的模型，很可能會越來越強調可追蹤推理、可複核輸出和專家協作介面。

換句話說，模型不只是更會聊天，而是更像一個可以分擔研究探索的系統。

普通讀者該怎麼看

這件事不宜神化，也不該輕描淡寫。

不宜神化，是因為 AI 還沒有變成獨立科學家。這個結果仍然需要人類數學家檢查、解釋和改進，也需要放回數學共同體中接受長期審視。一次突破不能直接推出「所有科學問題都快被 AI 自動解決」。

不該低估，是因為它確實越過了一個重要門檻。模型不只是複述知識，也不只是解訓練過的相似題，而是在開放問題中給出新構造，並讓專家認為它有數學價值。

更穩妥的理解是：AI 正在成為研究者的強力協作者。它可能先改變的是探索速度、跨領域連接和證明草稿生成，而不是一夜之間替代學術共同體。對普通讀者來說，最值得關注的不是「AI 是否取代數學家」，而是「人類如何利用 AI 擴大能研究的問題範圍」。

結論

OpenAI 這次結果的重要性，不只是推翻了一個近 80 年的猜想，而是展示了通用推理模型參與前沿研究的一種形態：提出構造、連接跨領域工具、產出可由專家審查的證明。

它還不是「AI 獨立科學家」的終點，但已經不是簡單的解題助手。未來幾年，數學可能會繼續成為觀察 AI 科研能力的窗口：哪些問題能被模型推進，哪些證明需要人類補全，哪些跨領域連接會被重新發現，都值得持續關注。

參考資料：

OpenAI：《An OpenAI model has disproved a central conjecture in discrete geometry》：https://openai.com/index/model-disproves-discrete-geometry-conjecture/
OpenAI proof PDF：https://cdn.openai.com/pdf/74c24085-19b0-4534-9c90-465b8e29ad73/unit-distance-proof.pdf
OpenAI companion remarks：https://cdn.openai.com/pdf/74c24085-19b0-4534-9c90-465b8e29ad73/unit-distance-remarks.pdf
OpenAI model reasoning summary：https://cdn.openai.com/pdf/1625eff6-5ac1-40d8-b1db-5d5cf925de8b/unit-distance-cot.pdf

Cerebras IPO 大漲背後：晶圓級 AI 晶片能挑戰英偉達嗎

Mon, 18 May 2026 00:19:51 +0800

Cerebras Systems 終於登上了公開市場。

這家以「晶圓級 AI 晶片」聞名的公司，於 2026 年 5 月 14 日在納斯達克掛牌交易，股票代碼為 CBRS。根據 Cerebras 官方公告，其 IPO 發行價為每股 185 美元，公開發行 3450 萬股 Class A 普通股，其中包括承銷商全額行使的 450 萬股超額配售權。

上市首日，Cerebras 股價大幅高開，一度接近 386 美元。按發行價計算，公司募資規模超過 55 億美元，是 2026 年以來美國市場最受關注的 AI 硬體 IPO 之一。

這也是為什麼它會被很多媒體稱為「英偉達挑戰者」。不過，把 Cerebras 簡單理解成「下一個英偉達」並不準確。它真正特殊的地方，是選擇了一條和傳統 GPU 完全不同的技術路線。

Cerebras 做的不是普通 GPU

Cerebras 的核心產品是 WSE，完整名稱是 Wafer-Scale Engine，中文通常可以理解為「晶圓級引擎」。

傳統晶片製造會把一整片晶圓切割成許多小晶片，再進行封裝、測試和出貨。Cerebras 反過來做：它盡可能把整片晶圓直接做成一顆超大晶片。

這條路線的好處很直觀：

晶片面積更大。
片上計算單元更多。
片上 SRAM 更接近計算核心。
資料在晶片內部移動距離更短。
更適合特定 AI 推理和訓練負載。

在 AI 計算裡，資料搬運往往比單純計算更難最佳化。Cerebras 的思路是盡量把計算和儲存留在同一片矽上，減少資料頻繁離開晶片帶來的延遲和能耗。

這也是 WSE 路線最吸引人的地方：它不是沿著 GPU 的老路繼續堆規模，而是試圖用更大的單顆晶片，換取更高的片上頻寬和更低的資料移動成本。

為什麼市場會興奮

AI 晶片市場目前高度依賴英偉達。無論是訓練大模型、部署推理服務，還是建設 AI 資料中心，英偉達 GPU 都是最主流的選擇。

這讓市場天然會關注兩類公司：

能否降低對英偉達供應鏈依賴。
能否在某些 AI 工作負載上提供更高效能或更低成本。

Cerebras 正好踩中了這兩個敘事。

它不是做通用 CPU，也不是做普通加速卡，而是直接圍繞 AI 訓練和推理設計系統。公司也一直強調，其晶圓級晶片和雲端推理平台在某些模型推理場景中可以提供極高吞吐。

這類故事在 2026 年非常容易被市場放大。AI 基礎設施仍在擴張，企業、雲端廠商和模型公司都在尋找更多算力來源。只要一家晶片公司能證明自己在某些場景裡不是「又一個小 GPU」，市場就會願意給它很高關注度。

OpenAI 合作讓想像空間變大

Cerebras 被關注的另一個原因，是它和 OpenAI 的關係。

據媒體報導，Cerebras 與 OpenAI 簽訂了金額超過 200 億美元的合作協議。搜狐原文提到，截至 2025 年底，這一協議帶來的剩餘履約義務達到 246 億美元。

對一家剛上市的 AI 硬體公司來說，這類長期協議非常重要。它意味著公司不只是有技術故事，還有大客戶需求作為支撐。

不過，長期訂單和最終收入之間不能直接畫等號。AI 資料中心建設還受制於製造產能、封裝、供電、交付節奏、客戶預算和模型路線變化。尤其是晶片公司，拿到訂單只是第一步，能否按期交付、能否穩定擴產、能否把毛利率做出來，才是更難的部分。

客戶集中仍然是最大風險之一

Cerebras 的風險也很明顯：客戶集中度高。

搜狐原文提到，G42 曾在 2024 年貢獻 Cerebras 85% 的收入，2025 年降至 24%；阿聯酋穆罕默德·本·扎耶德人工智慧大學則在 2025 年貢獻了 62% 的收入。這意味著，即便 G42 占比下降，公司收入仍然高度依賴少數大客戶。

對 AI 基礎設施公司來說，客戶集中有兩面性。

好處是：大客戶能帶來快速成長、長期合約和訂單可見性。

風險是：如果客戶削減預算、改變技術路線、延後資料中心建設，或者監管環境發生變化，公司收入波動會非常大。

這也是市場看 Cerebras 時不能只看 IPO 漲幅的原因。上市首日股價反映的是熱度和預期，長期估值最終還是要看收入結構、交付能力、利潤率和客戶多元化。

技術路線的短板：記憶體容量

WSE 的優勢很突出，但短板也同樣清楚。

搜狐原文提到，WSE-3 晶片配備 44GB SRAM，而英偉達 B200 配備 192GB 記憶體。Cerebras 的設計把大量計算和 SRAM 放在同一片晶圓上，這能減少資料移動，但也限制了可用記憶體容量。

對大模型來說，記憶體容量直接影響上下文長度、批次處理規模和模型部署方式。上下文窗口越來越長，旗艦模型已經普遍朝百萬級 token 上下文發展。在這種趨勢下，片上 SRAM 的容量限制會成為現實約束。

傳統 GPU 可以透過 HBM 堆疊、封裝擴展和多卡互聯繼續增加記憶體容量。Cerebras 的晶圓級路線則更難簡單擴記憶體，因為整片晶圓面積已經被計算單元和 SRAM 占用。想增加 SRAM，就可能犧牲計算面積。

這不代表 Cerebras 技術路線失敗，而是說明它更像一種面向特定工作負載的架構選擇。它可能在某些推理場景非常強，但未必能覆蓋所有 AI 訓練和推理需求。

它會取代英偉達嗎

短期內，Cerebras 不太可能取代英偉達。

英偉達的優勢不只是 GPU 效能，還包括 CUDA 生態、開發者工具、系統整合、網路互聯、整機方案、雲端廠商支援和客戶遷移成本。AI 公司選擇英偉達，很多時候不是因為單顆晶片某個指標最好，而是因為整套生態最穩。

Cerebras 更現實的機會，是在特定 AI 負載上成為補充方案：

高吞吐推理。
特定大模型服務。
對延遲和片上頻寬敏感的任務。
想降低單一 GPU 供應鏈依賴的客戶。
願意為效能試用新架構的大模型公司。

也就是說，它不是「英偉達殺手」，更像是 AI 算力市場裡一條激進的替代路線。

小結

Cerebras IPO 大漲，說明資本市場仍然願意為 AI 基礎設施故事付出高溢價。

它的晶圓級晶片路線確實有獨特性，也讓它和普通 AI 加速卡公司區分開來。再加上 OpenAI 等大客戶合作，Cerebras 有了足夠強的市場想像空間。

但風險同樣不能忽視：客戶集中、交付壓力、記憶體容量限制、生態壁壘，以及和英偉達競爭時的系統級差距，都會決定它能走多遠。

對普通讀者來說，Cerebras 最值得關注的不是股價漲了多少，而是它證明了一件事：AI 算力競爭不會只有 GPU 一條路。未來的大模型基礎設施，可能會同時容納 GPU、晶圓級晶片、自研加速器和雲端專用推理平台。

參考資料

Codex 支援 ChatGPT 移動端遠端存取，Enterprise 工作區可用 Access Tokens

Sun, 17 May 2026 09:12:07 +0800

OpenAI 在 2026 年 5 月 14 日更新了 ChatGPT Enterprise & Edu Release Notes，重點只有兩件事：Codex 支援透過 ChatGPT 移動端遠端存取，Enterprise 工作區可以使用 Codex access tokens 做受控自動化。

這不是一次模型能力發布，而是 Codex 產品形態的變化。Codex 正在從「本地或網頁裡的編程助手」，變成可以長時間執行、可以遠端接管、可以接入企業自動化流程的 coding agent。

這次更新是什麼

根據 OpenAI Help Center 的說明，Codex 現在支援從 ChatGPT mobile app 遠端存取。使用者可以在手機上連接正在執行的 Codex 環境，持續跟進長時間任務，並在需要時介入。

同時，ChatGPT Enterprise 工作區新增 Codex access tokens。它們面向可信的非互動式本地工作流，讓自動化流程可以使用 ChatGPT workspace identity 和企業控制，而不需要每次透過瀏覽器登入。

可以把這次更新理解成兩個入口：

移動端遠端存取：解決「Codex 跑長任務時，人不在電腦前怎麼辦」。
Access Tokens：解決「企業自動化腳本如何以受控身份呼叫 Codex 工作流」。

移動端遠端存取解決什麼問題

Codex 的典型任務並不總是幾秒鐘完成。真實開發裡，它可能要閱讀程式碼庫、修改多個檔案、執行測試、等待命令輸出、根據錯誤繼續修復，甚至需要使用者中途批准某些操作。

過去這類任務往往要求使用者守在本地 Mac、桌面端、CLI 或 IDE 旁邊。現在，ChatGPT 移動端可以變成一個遠端控制台，讓使用者離開電腦後仍能跟進 Codex。

OpenAI 提到，移動端可以展示底層環境的即時狀態，包括：

專案上下文。
approvals。
screenshots。
terminal output。
diffs。
test results。

使用者也可以在手機上回答 Codex 的問題、重定向執行、批准操作、查看輸出，並在不同 connected hosts 之間切換。底層任務仍然運行在 Mac host 或連接的遠端環境中，手機端負責查看和控制。

這對開發者有什麼價值

這項能力最適合長時間、需要中途確認的開發任務。

例如：

Codex 正在跑一組耗時測試，你出門後仍想看結果。
Codex 修改了多個檔案，需要你在手機上看 diff 後批准下一步。
Codex 執行到某個危險操作前等待確認，你可以遠端處理。
本地 Mac 上有多個 connected hosts，需要在手機上切換查看狀態。

它的價值不是讓你在手機上寫程式，而是讓你不用一直守著電腦。Codex 繼續在原環境裡工作，你只在關鍵節點介入。

這也說明 Codex 的使用方式正在接近「後台 Agent」：任務可以持續執行，使用者不必全程在線，但仍要保留審批和控制權。

Access Tokens 解決什麼問題

Codex access tokens 面向 ChatGPT Enterprise 工作區。它們的重點不是普通個人使用者登入，而是企業內部可信自動化。

企業裡經常有一些本地或內部流程需要非互動式執行，例如：

定時執行程式碼檢查。
在受控機器上觸發 Codex 工作流。
將 Codex 接入內部開發工具鏈。
在不開啟瀏覽器的情況下使用工作區身份。

Access tokens 讓這些流程可以帶著 ChatGPT workspace identity 執行，同時繼續受企業策略約束。相比臨時人工登入，它更適合自動化；相比隨便共享個人憑據，它也更容易納入治理。

它不是普通 API key

這點很重要。Codex access tokens 不應該被理解成一個簡單的「萬能 API key」。

OpenAI 的說明裡提到，access tokens 可用於 ChatGPT Enterprise 工作區，管理員可以管理工作區級可用性，擁有允許角色的成員可以建立自己的 tokens。治理介面在可用情況下也會反映 access token 活動。

也就是說，access tokens 被放在企業權限、角色和審計框架裡：

管理員可以決定工作區是否開放。
不是所有成員都天然可以建立。
token 活動可以進入治理視圖。
它繼承 ChatGPT workspace identity 和企業控制。

這和個人隨手產生一個長期密鑰不是一回事。

安全預設值：Remote Control 預設關閉

Codex mobile remote access 涉及程式碼環境、終端輸出、diff、測試結果和操作審批。如果預設開放，會帶來明顯企業安全風險。

因此 OpenAI 的預設策略是：remote control 預設關閉，管理員或 owner 需要在 Workspace settings 中啟用。

啟用移動端遠端存取時，還可能涉及：

workspace-enabled Remote Control access。
SSO。
多因素認證。
passkey。

這說明它是需要企業 IT 和安全團隊參與配置的能力，而不是「更新 App 後所有人自動可用」。

使用前需要更新什麼

OpenAI 提到，要使用移動端遠端存取，需要更新兩端：

ChatGPT mobile app。
macOS 上的 Codex app。

如果工作區啟用了相關要求，移動端設定過程還可能觸發 SSO、多因素認證或 passkey 流程。

實際落地時，企業管理員還需要先確認 Workspace settings 裡的 remote control 設定，以及哪些成員或角色可以使用相關能力。

對企業 Codex 使用方式的影響

這次更新把 Codex 往兩個方向推進。

第一，Codex 更適合長任務。以前長任務最大的問題是使用者要一直盯著，現在手機可以查看狀態和批准操作，Codex 可以更自然地跑在後台。

第二，Codex 更適合企業自動化。Access tokens 讓非互動式工作流有了更正式的身份方式，後續更容易接入內部 CI、程式碼審查、腳本和開發平台。

這兩個方向結合起來，意味著 Codex 不再只是「開發者手邊的 AI 助手」，而是在變成企業開發流程裡的一個可管理 agent。

仍然需要注意的邊界

這次更新很有用，但並不意味著 Codex 可以完全無人看管。

企業使用時仍然要注意：

哪些專案允許遠端控制。
哪些命令需要審批。
token 如何建立、輪換和撤銷。
mobile remote access 是否符合公司設備管理策略。
終端輸出、截圖和 diff 是否可能包含敏感資訊。
審計日誌和治理介面是否能滿足內部合規要求。

尤其是 access tokens，一旦進入自動化流程，就要像其他企業憑據一樣管理：最小權限、定期輪換、避免硬編碼、及時撤銷不用的 token。

總結

OpenAI 這次 Codex 更新的重點很集中：ChatGPT 移動端可以遠端存取 Codex 長任務，Enterprise 工作區可以用 Codex access tokens 支援受控自動化。

前者讓開發者不必一直守在電腦前，後者讓企業可以把 Codex 更正式地接入內部工作流。兩者合在一起，說明 Codex 正在從互動式編程助手，進一步走向可遠端管理、可審計、可自動化接入的企業 coding agent。

參考連結：

OpenAI Help Center：ChatGPT Enterprise & Edu - Release Notes

Codex 額度為什麼突然重置？Usage Limits 歷史與消息來源整理

Sun, 17 May 2026 08:36:15 +0800

Codex 使用者偶爾會遇到一種情況：明明還沒到自己的常規 reset 時間，usage limits 卻突然恢復了。這種「無預兆重置」不是第一次出現，也不一定代表額度規則永久變寬。它可能來自故障補償、產品活動、成長里程碑，也可能只是某個視窗或部分帳號狀態被後台重置。

這張截圖來自 OpenAI Codex 團隊負責人 Tibo Sottiaux（@thsottiaux）在 X 上發布的公告。對關注額度的使用者來說，最關鍵的一句不是模型細節，而是：他表示會在當晚 reset usage limits。截圖中的上下文說明，這次重置是一次補償性操作，而不是普通週期刷新。

先說結論

Codex 額度突然重置，大致可以分成幾類：

故障補償：模型或 Codex 服務異常導致使用者浪費額度，官方透過重置彌補。
發布或推廣活動：新模型、新客戶端、新功能上線時，臨時提高或重置額度。
成長里程碑：使用者規模達到某個節點後，官方用重置或提額鼓勵繼續使用。
後台策略調整：部分額度視窗、部分帳號狀態被重置，但 UI 不一定解釋清楚。

普通使用者最容易誤解的是：看到「重置」就以為所有視窗都恢復了。實際上，Codex 可能同時有短視窗、weekly limit、不同模型和不同方案限制。一次特殊重置可能只影響其中一部分。

這次截圖說明了什麼

截圖顯示，Tibo 在 2026 年 5 月 15 日發布更新，表示團隊會繼續監控，並在當晚重置 usage limits。它引用了前一條「正在調查部分使用者回報」的消息，因此這次重置更像一次服務波動後的補償。

對使用者來說，可以提煉出三點：

這不是使用者自己的常規週期到了，而是官方主動重置。
這次重置有明確事件背景，不是永久提額公告。
「usage limits」的具體覆蓋範圍仍要看實際帳號顯示，截圖本身沒有解釋 5 小時視窗、weekly limit 是否全部包含。

所以，如果你看到額度恢復，正確做法不是馬上推斷「以後都變寬了」，而是先把它當成一次特殊 reset event。

為什麼 Codex 會無預兆重置

Codex 的額度體系不是一個簡單的「每天幾點刷新」。使用者介面通常只顯示剩餘額度或百分比，但後台可能同時追蹤：

短時間視窗，例如幾小時內的使用量。
週額度或更長週期額度。
不同模型的消耗權重。
本地 Codex、Cloud Task、IDE/CLI 等不同入口。
Plus、Pro、Business、Team 等不同方案。
帳號是否符合某次特殊重置的後台條件。

當 OpenAI 做一次特殊重置時，使用者未必能看到「這是普通週期恢復，還是特殊補償」。如果只重置短視窗，使用者可能誤以為 weekly 也應該恢復；如果 weekly 沒變，就會懷疑重置失敗。

OpenAI 的 Codex GitHub issue 裡也有人專門回報過這個透明度問題：公開說 reset Codex rate limits，但產品 UI 沒有說明到底重置了哪些視窗、是否包含 weekly limit、是否所有付費方案都一致生效。這也是「無預兆重置」讓人困惑的核心原因。

歷史上的幾類重置

1. 2026 年 2 月：發布期與臨時加量

Codex 桌面應用和 GPT-5.3-Codex 推廣期間，社群使用者討論過 usage limit reset 和臨時 2x rate limits。Reddit 上有使用者提到 Codex app 剛發布時提供過限時 2x rate limits，並伴隨 usage limit reset。

這類重置更像發布期營運動作：讓更多使用者試用新客戶端、新模型或新工作流。

2. 2026 年 3 月：隨機重置與異常消耗討論

3 月前後，社群裡多次出現「random usage reset」「weekly limit reset daily」之類帖子。有使用者回報自己的 weekly limit 被提前恢復，也有人認為這和 Codex 新模型、新安全攔截、異常消耗或 bug 修復有關。

這些討論不等同於官方公告，但它們說明一件事：使用者側已經多次觀察到額度並非只按固定週期恢復。某些情況下，後台會因為問題修復或補償而觸發額外 reset。

3. 2026 年 4 月：成長里程碑與付費方案重置

4 月下旬，有公開報導提到 Codex 達到 300 萬週活躍使用者後，OpenAI 重置了 rate limits，並計畫在後續使用者成長里程碑繼續給使用者更多額度空間。

GitHub issue 中也引用過 Tibo 4 月 28 日的 X 公告：他提到曾為「good week」重置付費方案的 Codex rate limits，讓使用者可以更多使用 GPT-5.5。不過同一個 issue 也指出，實際產品 UI 沒有清楚說明到底哪些額度視窗被重置，weekly limit 是否全部包含。

這說明成長或活動型重置，往往也會帶來解釋成本：使用者聽到「all paid plans」，但帳號裡看到的結果未必完全一致。

4. 2026 年 5 月：故障補償型重置

這次截圖屬於更典型的故障補償型重置。Tibo 明確說團隊找到了問題並會在當晚 reset usage limits。OpenAI Status 也記錄過 2026 年 5 月 13 日 Codex 相關高錯誤率和延遲退化事件。

對普通使用者而言，這次重點不是某個模型是否變差，而是：當服務端問題讓使用者額度被異常消耗時，OpenAI 可能會透過特殊重置來補償。

使用者該怎麼判斷一次重置來自哪裡

遇到 Codex 額度突然恢復，可以按這個順序判斷：

先看自己的常規 reset 時間，排除普通週期恢復。
看 OpenAI Status 是否有 Codex、模型錯誤率、延遲或降級記錄。
看 Tibo、OpenAI 官方帳號、Codex GitHub issue 是否有說明。
看社群回饋是否集中出現「突然 reset」「額度燃燒異常」「weekly 沒恢復」等討論。
區分短視窗和 weekly limit，不要預設所有視窗都會一起恢復。

如果是官方事故補償，通常會伴隨狀態頁記錄、負責人公告或大量使用者集中回饋。如果只是後台部分視窗刷新，可能不會有明確公告。

消息來源怎麼分辨可靠性

這類消息最好分層看：

官方狀態頁：最適合確認是否有服務故障、錯誤率、延遲、恢復時間。
Tibo / OpenAI 官方帳號：適合確認是否有特殊 reset、補償或活動口徑。
OpenAI Codex GitHub issue：適合看使用者對 UI、額度視窗、實際行為的回饋。
社群 Reddit / X 討論：適合觀察使用者是否普遍遇到類似現象，但不能直接當成官方結論。
第三方新聞或部落格：適合補充時間線，但仍要回到官方和原始連結核對。

寫文章或做判斷時，最好把這些來源分開寫。比如「OpenAI Status 記錄了服務問題」是官方狀態；「Reddit 使用者回報隨機重置」是社群觀察；「GitHub issue 反映 UI 不透明」是使用者提交的問題描述。

總結

Codex 額度突然重置，通常不是一個單純的「系統送額度」。它可能來自故障補償、發布期推廣、成長活動或後台策略調整。真正容易造成誤解的地方在於：Codex 同時存在多個額度視窗，而特殊 reset 不一定覆蓋所有視窗，UI 也不一定清楚展示 reset scope。

所以，遇到無預兆重置時，最穩的判斷方式是：先看客戶端實際額度，再查 OpenAI Status、Tibo 公告、Codex GitHub issue 和社群回饋。不要只憑一次 reset 推斷長期額度規則，也不要預設 weekly limit、短視窗和所有方案都會同步恢復。

參考連結：

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 會明顯省時間。如果你只是偶爾上傳一份敏感文件問幾句，反而要更謹慎。

參考資料

GPT-5.5 Prompt 遷移指南：舊提示詞為什麼要先刪再改

Fri, 15 May 2026 01:25:27 +0800

OpenAI 在 API 文件裡更新了 GPT-5.5 prompting guide。這份文件最有價值的地方，不是又給了一套更長的提示詞模板，而是提醒開發者：遷移到 GPT-5.5 時，很多舊 prompt 反而應該變短。

官方文件地址：https://developers.openai.com/api/docs/guides/prompt-guidance

如果只看一句話，GPT-5.5 的提示詞方向是：少寫過程，多寫結果；少堆規則，多定義驗收；少用「永遠必須」，多寫清楚什麼時候停止、什麼時候驗證、什麼時候補證據。

舊 prompt 為什麼需要重寫

很多生產系統裡的 prompt 是一層層堆出來的。模型不穩定時，加一條規則；工具呼叫出錯時，再加一條禁止；輸出囉嗦時，再加一段格式要求。時間久了，系統 prompt 會變成一份厚重的操作手冊。

這種寫法在舊模型上有時有用，因為模型需要更多步驟約束才能不跑偏。但到了 GPT-5.5，OpenAI 的建議很明確：不要把舊 prompt stack 原樣搬過來。

原因很簡單。過度指定過程會帶來幾類副作用：

噪聲變多，模型要在大量舊規則裡找真正重要的約束。
搜尋空間變窄，模型不敢選擇更高效的解法。
輸出變機械，看起來像在執行腳本，而不是解決問題。
舊規則之間可能互相衝突，導致工具呼叫和最終回答都變笨。

GPT-5.5 更適合讓 prompt 描述目標狀態、約束、可用證據和最終輸出，而不是把每一步都寫死。

outcome-first：先定義什麼叫完成

官方文件反覆強調一個方向：GPT-5.5 最適合 outcome-first prompt。

也就是說，提示詞裡應該優先寫：

目標結果是什麼。
什麼條件算成功。
哪些約束不能突破。
目前可用上下文是什麼。
最終答案需要包含哪些欄位或部分。
證據不足時怎麼處理。

不太推薦的寫法是：

`1`	`先檢查 A，再檢查 B，然後比較所有欄位，再思考全部異常情況，再決定呼叫哪個工具，再呼叫工具，最後解釋完整過程。`

更適合 GPT-5.5 的寫法是：

解決使用者的問題。成功標準：
- 基於可用政策和帳戶資料完成判斷
- 如果允許執行操作，先完成操作再回覆
- 最終輸出包含 completed_actions、customer_message、blockers
- 如果缺少關鍵證據，只詢問最小必要欄位

這不是讓 prompt 變得含糊，而是把控制點從「過程順序」移到「結果和邊界」。模型可以自己選擇搜尋、推理和工具呼叫路徑，但必須對成功標準負責。

少用絕對規則，多寫決策規則

舊 prompt 裡常見大量 ALWAYS、NEVER、must、only。這些詞不是不能用，但應該只留給真正不可違反的約束，比如安全規則、必填欄位、禁止執行的動作。

對於「什麼時候搜尋」「什麼時候問使用者」「什麼時候繼續迭代」「什麼時候停止」這類判斷，GPT-5.5 更適合使用決策規則。

例如，不要只寫：

`1`	`永遠先搜尋三次。`

可以改成：

先做一次覆蓋核心問題的檢索。如果前幾個結果已經能支援關鍵事實，就停止檢索並作答。只有當證據衝突、缺失或不足以支撐結論時，才繼續搜尋。

這種寫法給了模型判斷空間，也給了它停止條件。對需要聯網、檢索、檔案搜尋或資料庫查詢的產品來說，這一點很關鍵，因為每多一輪工具呼叫都會帶來延遲和成本。

給檢索設定 retrieval budget

GPT-5.5 prompt 裡值得單獨加的一類規則是 retrieval budget。

它不是預算金額，而是檢索停止規則。它告訴模型：什麼時候證據已經足夠，什麼時候應該繼續找，什麼時候該承認缺證據。

一個實用寫法是：

普通問答先做一次寬檢索，關鍵詞要短且有區分度。如果前幾個結果已經能支援核心請求，就基於這些結果回答，不再繼續搜尋。只有當結果衝突、缺失關鍵事實或不能支援結論時，才追加檢索。

這類規則能減少兩種常見問題：

搜尋不夠，答案沒有證據。
搜尋過頭，模型在工具循環裡浪費時間。

更重要的是，文件還提醒：沒有搜到證據，不應該自動變成事實上的「否」。有時正確行為是說明證據不足，或者換一個更小的問題繼續查。

reasoning effort 不要一上來拉高

GPT-5.5 的推理效率更高，所以 OpenAI 建議重新評估 low 和 medium，不要一遇到品質問題就直接把 reasoning effort 往上加。

更穩的順序是：

先確認 prompt 是否寫清楚了目標、輸出格式和停止條件。
加上驗證循環，比如測試、引用、複核或渲染檢查。
為工具呼叫補上持久性規則和完成標準。
仍然不夠時，再提高 reasoning effort。

換句話說，reasoning.effort 更像最後的調參旋鈕，不應該替代清晰的 prompt 設計。

如果任務是短分類、欄位抽取、支援工單分流、格式轉換，可以先從低推理成本開始。如果是長文件綜合、多源衝突判斷、策略寫作、複雜研究，再考慮 medium 或更高。

text.verbosity 控制輸出，不等於控制思考

GPT-5.5 對輸出格式很可控。官方文件建議使用 text.verbosity 配合 prompt 裡的輸出要求。

預設 text.verbosity 是 medium。如果產品需要更短、更乾淨的回覆，可以使用 low。但這不意味著所有內容都要變短。

一個典型做法是：

面向使用者的狀態更新和最終總結保持簡短。
程式碼、配置、結構化結果需要清楚時，仍然要求可讀性。
不要為了「簡短」犧牲欄位完整性、引用和必要 caveat。

這對程式碼類產品尤其有用。可以讓聊天回覆短一點，但要求生成的程式碼保持可讀變數名、清楚結構和必要註釋。

preamble 和 phase：讓長任務更可感知

GPT-5.5 在複雜任務中可能先做推理、計畫或準備工具呼叫，然後才輸出可見文字。對流式產品來說，使用者會明顯感知首 token 等待時間。

官方建議是：對多步驟、工具密集或長時間執行的任務，讓模型先發一個短 preamble。它不需要解釋完整計畫，只要告訴使用者「我會先做什麼」。

例如：

`1`	`我會先檢查相關檔案和現有配置，然後再給出修改方案。`

在 Responses API 的長任務或工具密集工作流裡，還要注意 assistant item 的 phase。如果應用使用 previous_response_id，API 會自動保留前序 assistant 狀態；如果應用手動回放 assistant 輸出，就要保留原來的 phase 值。

常見約定是：

phase: "commentary"：中間狀態更新。
phase: "final_answer"：最終答案。
不要給 user message 添加 phase。

這部分看起來像底層實作細節，但對有工具呼叫、狀態更新和最終回答的產品很重要。手動回放時弄丟 phase，容易讓模型分不清中間進度和最終結論。

提示模型檢查自己的工作

GPT-5.5 guide 裡還有一條非常實用：在可以驗證的任務裡，給模型驗證工具和驗證規則。

對程式碼 Agent，可以明確要求：

修改後執行相關單元測試。
必要時執行 type check 或 lint。
影響套件較大時跑 build。
全量驗證太貴時，至少做最小 smoke test。
如果驗證無法執行，要解釋原因和下一個最好檢查方式。

對視覺或頁面產物，可以要求先渲染再檢查布局、裁切、間距、缺失內容和視覺一致性。

對工程方案，可以要求計畫裡包含需求對應關係、涉及檔案/API/系統、狀態流轉、驗證命令、失敗行為、隱私和安全考量，以及真正影響實作的開放問題。

這類規則比「請認真一點」有效得多。它把「認真」落到了可執行檢查上。

一個更適合 GPT-5.5 的 prompt 骨架

OpenAI 文件給出的結構可以簡化成這樣：

Role:
你是什麼角色，要在什麼上下文裡工作。

# Personality
語氣、協作方式、是否需要溫度或觀點。

# Goal
使用者可見的目標結果。

# Success criteria
最終回答前必須滿足的條件。

# Constraints
安全、業務、證據、權限、成本和副作用邊界。

# Output
輸出結構、長度、語氣、欄位要求。

# Stop rules
什麼時候繼續、什麼時候重試、什麼時候降級、什麼時候詢問、什麼時候停止。

這個骨架的重點不是「每個 prompt 都要寫這麼多標題」。它真正想表達的是：複雜任務的 prompt 應該讓模型知道目的地、邊界和交付物，而不是把每一步都硬編碼進去。

遷移舊 prompt 的實際順序

如果你現在有一套 GPT-4.1、GPT-4o、GPT-5.2 或 GPT-5.4 的舊 prompt，不建議一次性大改。

更穩的遷移順序是：

先切模型，固定目前 reasoning effort 和輸出參數。
跑已有 eval 或真實樣例，找出行為變化。
刪除明顯過時、重複、互相衝突的過程規則。
把「步驟要求」改成「成功標準」和「停止條件」。
補上檢索預算、引用規則和缺證據行為。
為工具任務加驗證循環。
最後再調 reasoning.effort 和 text.verbosity。

如果沒有 eval，至少準備一組典型任務：簡單問答、複雜檢索、工具呼叫、格式化輸出、拒答/降級、長任務完成。不要只用一個 demo case 判斷 prompt 好壞。

一張舊 prompt 遷移清單

真正遷移舊 prompt 時，可以先按這張清單過一遍。它的目標不是把 prompt 改得更短，而是把無效約束刪掉，把關鍵約束改成更可驗證的形式。

檢查項	常見問題	建議處理
重複規則	同一件事在不同段落反覆出現，甚至措辭不一致	合併成一條清晰規則，只保留最終版本
絕對詞	到處都是 `ALWAYS`、`NEVER`、`must`、`only`	只給安全、合規、權限、必填欄位保留絕對約束
無停止條件	要求模型持續搜尋、持續分析、持續修復，但沒寫什麼時候停	增加 stop rules，例如證據足夠、驗證通過、達到輪次或成本上限
無驗證命令	只寫「確保正確」，沒有測試、lint、引用或檢查方式	改成具體檢查：執行測試、類型檢查、建置、引用來源或 smoke test
過程太細	把每一步都寫死，模型只能照流程走	改成目標、成功標準、邊界和輸出要求
舊模型補丁	為舊模型弱點寫的限制仍然保留	先刪除，再用 eval 判斷是否真的還需要
工具規則模糊	只寫「必要時使用工具」	寫清楚何時呼叫、何時停止、失敗時怎麼降級
輸出格式漂移	有格式要求，但沒有欄位完整性要求	明確必填欄位、可選欄位、缺證據時的占位或說明

如果你只能做一件事，優先檢查「無停止條件」和「無驗證命令」。這兩項最容易讓 GPT-5.5 在長任務裡變成無限工具循環，或者在沒有證據時給出看似完整但不可驗證的答案。

GPT-5.5 prompt 示例對比

下面這幾組不是完整系統 prompt，而是遷移時常見的局部改寫方式。

例子 1：檢索問答

舊寫法：

`1`	`回答前必須搜尋至少 3 次。必須閱讀所有相關結果。必須給出完整解釋。`

新寫法：

先做一次覆蓋核心問題的檢索。若前幾個結果已經能支援關鍵事實，停止檢索並回答。若結果衝突或缺少關鍵事實，再追加檢索。最終回答說明依據；證據不足時明確說證據不足。

區別在於，新寫法把「搜尋次數」改成了「證據是否足夠」。它給模型繼續查的理由，也給模型停下來的理由。

例子 2：程式碼修改

舊寫法：

`1`	`仔細修改程式碼。不要破壞現有邏輯。完成後告訴我改了什麼。`

新寫法：

完成使用者要求的最小必要程式碼修改。成功標準：
- 只修改與任務相關的檔案
- 保持現有公開接口相容，除非使用者明確要求變更
- 修改後執行相關單元測試；如果無法執行，說明原因和下一個最好驗證方式
- 最終總結改動、驗證結果和剩餘風險

區別在於，新寫法沒有泛泛要求「仔細」，而是把謹慎落到檔案範圍、接口相容、測試命令和風險說明上。

例子 3：結構化輸出

舊寫法：

`1`	`請輸出 JSON。不要輸出多餘內容。欄位要完整。`

新寫法：

輸出嚴格 JSON，不要添加 Markdown。必須包含：
- status: "ok" | "needs_more_info" | "blocked"
- answer: string
- evidence: string[]
- missing_info: string[]
如果證據不足，status 使用 "needs_more_info"，不要編造 evidence。

區別在於，新寫法不僅要求 JSON，還定義了缺證據時的合法輸出路徑。這樣模型不用在「必須完整」和「證據不足」之間硬編。

參數怎麼配

reasoning.effort 和 text.verbosity 不應該孤立看。前者影響模型投入多少推理，後者影響輸出有多詳細。一個常見誤區是：品質不夠就先把 reasoning.effort 拉高，輸出太長就把 prompt 寫得更凶。更穩的做法是按任務類型配。

場景	reasoning.effort	text.verbosity	說明
欄位抽取、分類、短格式轉換	`none` 或 `low`	`low`	追求低延遲，重點是輸出 schema 清楚
客服分流、簡單工具路由	`low`	`low` 或 `medium`	規則明確時不需要高推理，保留必要解釋即可
普通問答、輕量檢索總結	`low` 或 `medium`	`medium`	需要一點判斷，但不必預設高推理
多文件綜合、衝突判斷	`medium`	`medium`	先保證證據規則和引用，再考慮提高 effort
複雜程式碼修改、長任務 Agent	`medium` 或 `high`	使用者回覆 `low`，程式碼輸出要求清晰	聊天更新可以短，程式碼和 diff 要可讀
策略、方案、風險分析	`medium` 或 `high`	`medium` 或 `high`	需要解釋取捨、風險和假設

對大多數應用來說，可以先從 low 或 medium 開始。只有當 prompt 已經寫清楚成功標準、停止條件和驗證規則，模型仍然遺漏關鍵約束時，再提高 reasoning.effort。

text.verbosity 也不是越低越好。低 verbosity 適合狀態更新、客服短答、操作結果摘要；但對於程式碼、配置、遷移方案、審計說明，過低的輸出會讓結果難以審查。

哪些規則適合保留

遷移到 GPT-5.5 不是把舊 prompt 全部刪掉。下面這些規則通常應該保留，而且要寫得更明確。

安全規則：不能執行的動作、不能生成的內容、需要拒絕或降級的場景。
合規規則：行業政策、地區限制、年齡限制、審計要求、審批要求。
隱私規則：個人資訊處理、敏感資料脫敏、日誌記錄限制、資料不得外傳。
輸出欄位：API 回應、JSON schema、表格欄位、前端元件需要的固定結構。
業務邊界：退款規則、帳號權限、服務等級、合約範圍、人工客服升級條件。
工具權限邊界：哪些工具能呼叫、哪些工具必須先確認、哪些工具禁止呼叫。
引用和證據規則：什麼時候必須引用來源，證據衝突時怎麼處理。

這些規則不是舊包袱，而是產品契約。區別只在於，遷移時要把它們從長篇口號改成可執行約束。

例如：

`1`	`不要洩露使用者隱私。`

可以改成：

`1`	`不要在最終回答中輸出完整手機號、身分證號、access token、API key 或內部使用者 ID。需要引用時只顯示脫敏版本，例如手機號保留後 4 位。`

哪些內容不要誤刪

刪 prompt 時最危險的不是刪掉廢話，而是把真正的系統邊界一起刪掉。下面這些內容即使看起來「很老」，也不應該輕易刪除。

隱私與資料處理要求：尤其是日誌、匯出、跨系統傳輸、第三方工具呼叫相關規則。
安全和權限限制：刪除資料、轉帳、發郵件、改權限、執行 shell 命令等高風險動作的確認規則。
引用格式：如果產品依賴 citation、腳註、來源列表或審計鏈路，不要只因為它占空間就刪掉。
工具呼叫邊界：哪些工具唯讀、哪些工具可寫、哪些工具必須使用者確認。
失敗行為：API 超時、資料缺失、檢索失敗、權限不足時應該怎麼降級。
業務硬規則：價格、退款、封禁、風控、合規審核這類不能由模型自由發揮的規則。

一個簡單判斷方法是：如果刪掉某條規則只會讓輸出風格變一點，可以考慮刪；如果刪掉後可能導致越權、洩露、誤操作、錯誤承諾或審計斷鏈，就應該保留，並改寫得更精確。

總結

GPT-5.5 prompting guide 的核心不是「寫更高級的提示詞」，而是把舊 prompt 裡過度指定過程的部分刪掉。

更適合 GPT-5.5 的提示詞應該做到：

目標優先，而不是步驟優先。
成功標準明確，而不是泛泛要求「做好」。
有停止條件，而不是無限搜尋或無限工具循環。
有證據預算，而不是查不到就亂答或一直查。
有驗證規則，而不是只靠模型自覺。
參數調優靠後，而不是一上來拉高 reasoning effort。

如果你的舊系統 prompt 已經很長，遷移到 GPT-5.5 的第一步可能不是加內容，而是刪內容。把真正不可違反的規則留下，把過程細節改成結果、邊界和檢查項，通常比繼續堆提示詞更有效。

參考資料

OpenAI Prompt guidance：https://developers.openai.com/api/docs/guides/prompt-guidance
OpenAI Using GPT-5.5：https://developers.openai.com/api/docs/guides/latest-model

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

馬斯克訴 OpenAI 庭審焦點：非營利使命、控制權與 AI 競賽

Fri, 08 May 2026 23:37:37 +0800

馬斯克與 OpenAI、Sam Altman 之間的訴訟，表面上是一次舊合夥人之間的反目，深層則是 AI 產業最重要的結構性問題之一：當訓練先進模型需要巨額資本時，最初以公益、開放、安全為旗幟成立的組織，能否以及如何轉向更商業化的形態？

這場爭議之所以被持續放大，不只是因為雙方都是矽谷最有影響力的人物，也因為它把 OpenAI 的三個矛盾同時擺到了台前：非營利使命與商業融資、AI 安全敘事與市場競爭、創始人貢獻與後續控制權。

庭審真正爭什麼

從公開報導看，馬斯克一方的核心主張是：OpenAI 創立時具有明確的公益使命，馬斯克早期捐贈和參與是為了支持一個不為個人謀利、服務人類整體利益的 AI 組織；而 OpenAI 後來建立營利性實體、接受巨額投資並發展為高估值公司，已經背離了最初承諾。

OpenAI 一方的核心回應則是：馬斯克的捐贈並沒有附帶他所主張的永久性限制；OpenAI 之所以建立營利性結構，是為了獲得算力、人才和資本，繼續實現開發安全先進 AI 的使命；同時，OpenAI 認為馬斯克當年並非反對營利化本身，而是希望獲得控制權。

因此，這不是簡單的「非營利 vs 營利」二選一，而是一個更具體的問題：OpenAI 的原始使命到底具有怎樣的法律約束力？馬斯克的 3800 萬美元捐贈是普通捐贈，還是帶有可執行條件的慈善信託？OpenAI 後續結構變化是否仍在非營利控制之下？

馬斯克一方的敘事

馬斯克在庭審中強調，他當初參與 OpenAI，是為了建立一個防止 AI 被少數商業巨頭控制的公益機構。他將 OpenAI 的結構變化描述為對慈善機構的掠奪，並警告如果允許這種情況發生，會破壞美國慈善捐贈的基礎。

這一敘事的力量在於，它抓住了 OpenAI 早期形象與後來商業成功之間的反差。OpenAI 最初給外界的印象，是一個以安全、開放、公共利益為核心的非營利研究實驗室；而今天的 OpenAI 已經成為全球 AI 競賽中的關鍵商業實體，與 Microsoft 等巨頭深度綁定。

但馬斯克一方也面臨一個問題：他是否曾經接受過某種營利性安排？如果他當年也討論過建立營利性實體，只是要求保持非營利控制或獲得更大控制權，那麼案件就不再是「有沒有營利結構」，而是「誰控制這個結構」。

OpenAI 一方的敘事

OpenAI 的公開頁面和庭審辯護都把重點放在另一條線上：OpenAI 始終由非營利機構治理，建立營利性實體是為了籌集實現 AGI 使命所需的資源；馬斯克後來發起訴訟，是因為他未能取得控制權，又創辦了競爭對手 xAI。

OpenAI 還強調，馬斯克曾向 OpenAI 非營利機構捐贈 3800 萬美元，這筆錢已經用於公司使命；而馬斯克現在試圖把它重新解釋成投資，並據此主張對 OpenAI 的權益。OpenAI 的說法是，馬斯克當年希望獲得絕對控制權，甚至曾提出將 OpenAI 併入特斯拉，遭拒後離開。

這套敘事的重點，是把案件從「OpenAI 背叛公益使命」轉向「馬斯克沒有得到想要的控制權」。如果陪審團和法官接受這個框架，馬斯克的道德指控就會被削弱，案件會更像一場遲來的創始人權力爭奪。

為什麼非營利結構是關鍵

OpenAI 最複雜的地方，不是它有沒有商業收入，而是它的治理結構。它不是傳統意義上的純商業公司，也不是完全不參與市場競爭的研究機構。它試圖用非營利實體控制營利性子公司，透過資本市場獲取算力和人才，同時保留「造福全人類」的使命敘事。

這種結構本身有現實理由。訓練前沿模型需要資料中心、晶片、研究人員、安全評估和全球產品基礎設施。僅靠捐贈，很難長期支撐這種規模的投入。

但結構越複雜，信任成本也越高。外界會自然追問：非營利控制是否真的有效？商業合作是否改變了研發方向？安全承諾和產品增長發生衝突時，誰有最終決定權？這正是馬斯克訴 OpenAI 案能引發廣泛關注的原因。

庭審不等於 AI 安全公投

這場庭審裡會反覆出現 AI 安全、AGI 風險、開源承諾和公共利益等概念，但它本質上仍是一個法律案件。法院要處理的是捐贈性質、慈善信託、組織治理、控制權和不當得利等問題，而不是替全產業制定 AI 安全政策。

換句話說，即使馬斯克贏了，也不等於法院會直接給出一套 AI 安全治理方案；即使 OpenAI 贏了，也不等於所有關於商業化和使命漂移的質疑都會消失。

真正值得關注的是判決可能產生的治理信號：法院會如何看待 AI 機構早期公開承諾的約束力？創始人捐贈和後續商業化之間的邊界在哪裡？非營利控制營利性 AI 公司這種結構，是否需要更強的外部監督？

對 AI 產業的影響

這場訴訟給整個 AI 產業提供了一個提醒：宏大的公益敘事一旦和巨額資本綁定，就必須有足夠清晰的治理機制來支撐。否則，當公司成功後，早期使命、捐贈者期待、員工激勵、投資人回報和社會風險就會全部擠到同一個法律和輿論戰場上。

對其他 AI 公司來說，這意味著幾件事：

早期章程、使命聲明和捐贈協議必須寫得更清楚。
非營利與營利實體之間的權責邊界不能含糊。
安全承諾不能只停留在宣傳層面，需要可審計的治理機制。
創始人、投資人和公共利益之間的衝突，要在融資前就有制度安排。

OpenAI 的規模和影響力讓這些問題被放大，但它們並不只屬於 OpenAI。隨著 AI 公司繼續吸收資本、進入醫療、教育、國防、辦公和消費產品，這類治理衝突還會反覆出現。

總結

馬斯克訴 OpenAI 的核心，不只是「誰背叛了誰」，而是前沿 AI 組織在從研究實驗室走向超級平台時，如何證明自己仍然受使命約束。

馬斯克一方試圖證明 OpenAI 背離了最初的慈善使命；OpenAI 一方則試圖證明商業化是實現使命的必要路徑，並把馬斯克的訴訟解釋為控制權失敗後的反擊。最終法院如何判斷，還要看證據、捐贈文件、組織章程和雙方當年的溝通記錄。

無論結果如何，這場庭審都已經說明一件事：AI 公司不能只靠「為了全人類」的口號維持信任。越是接近通用人工智慧、越是掌握巨大商業價值，治理結構就越需要透明、可驗證、能經得起法庭和公眾同時審視。

參考連結：

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 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 不再只是「每次從零開始回答問題」的工具，而是在逐步變成能記住偏好、理解上下文、知道何時搜尋，並且讓使用者管理這些記憶來源的長期助手。

Codex App 保姆級上手：安裝、沙箱、並行任務、Skills 與 MCP

Wed, 06 May 2026 08:41:17 +0800

Codex App 可以理解成一個面向 AI 編程的任務工作台。它不是傳統 IDE，也不是單純聊天視窗，而是把多任務、專案管理、沙箱權限、Git、雲端執行、外掛、Skills、MCP 和自動化集中到一個介面裡。

如果你已經在用 Codex CLI、Claude Code、Cursor 或其他 coding agent，Codex App 最值得關注的地方，是它把「多個 agent 並行幹活」做成了更清楚的桌面工作流。

Codex App 適合做什麼

Codex App 的核心價值不是讓 AI 回答問題，而是讓 AI 在專案目錄裡持續執行任務：

修改程式碼、執行命令、啟動開發服務。
管理多個專案和多個任務。
在本地或雲端執行長任務。
呼叫外掛、Skills 和 MCP 擴展能力。
透過 Git、worktree 和 PR 管理改動。

OpenAI 官方也把 Codex App 定位成一個用於管理多個 coding agent 的介面。它適合需要同時推進多個程式碼任務的人，尤其適合前端頁面、腳本工具、小型應用、文件整理和自動化工作流。

安裝前準備

使用 Codex App 前，建議先準備好三個基礎工具：

Git
Node.js
VS Code 或你常用的 IDE

Codex App 支援 macOS 和 Windows。安裝後使用 ChatGPT 帳號登入，首次進入時可以選擇主要使用場景，例如編程或日常工作。Codex 會根據選擇預裝一部分外掛和 Skills，後續也可以在設定和外掛市場裡調整。

Windows 和 macOS 的主要功能大體一致，但部分電腦自動化能力可能依賴具體平台和外掛支援，實際以你目前版本顯示為準。

介面結構：專案、任務和對話

Codex App 是典型的三欄布局：

左側：專案、任務、歷史對話、外掛和自動化入口。
中間：目前對話視窗。
右側：檔案、瀏覽器、終端機、執行結果等多功能區域。

一個專案通常對應一個本地資料夾。你可以在同一個專案裡開多個對話，也可以同時打開多個專案，讓不同 agent 並行執行任務。

任務列表會顯示不同狀態：

正在執行：agent 仍在執行。
等待批准：需要你確認權限、連網、安裝依賴或執行高風險操作。
已完成：任務已經結束，可以查看結果或繼續追問。

這比在多個終端視窗裡來回切換更直觀，也更適合同時管理多個 AI 任務。

沙箱與權限控制

Codex App 的權限體系圍繞沙箱展開。預設情況下，目前專案資料夾會成為 agent 的主要工作範圍。

常見權限邊界包括：

可以讀取和修改專案目錄內的檔案。
預設不能隨意修改專案外檔案。
預設會限制連網或高風險命令。
需要越權時，會向使用者申請批准。

比較實用的模式是「自動審查」：低風險操作由系統自動放行，高風險操作再交給使用者確認。這樣既能減少頻繁彈窗，又能避免 agent 在不知情的情況下執行危險操作。

「完全存取」要謹慎開啟。它適合你明確知道 agent 要做什麼，並且專案已經有 Git 備份、重要檔案也有額外備份的場景。日常使用不建議長期保持完全存取。

上下文、模型和額度

Codex App 會顯示目前對話的上下文使用情況。對話越長，歷史內容越多，模型需要處理的上下文也越大。

實用建議是：

一個任務完成後，優先開新對話。
長對話可以手動壓縮，但不要把壓縮當成萬能記憶。
複雜任務先寫清楚目標、邊界和驗收標準。
不要把大量無關日誌、報錯和檔案一次性塞進對話。

模型選擇上，可以根據任務複雜度調整思考強度。簡單修改、文案整理、重複任務不一定需要最高規格模型；架構遷移、疑難 bug、跨檔案重構則更適合使用更強模型。

如果介面裡有快速模式，也要注意它通常會帶來更高的額度消耗。趕時間時可以開，日常不必預設開啟。

圖片生成與多模態輸入

Codex App 可以接收圖片和檔案作為上下文，也可以在合適場景中呼叫圖像生成能力。

這對前端和內容類專案很有用。例如你可以讓 Codex：

根據截圖修正頁面樣式。
替換網頁中的不合適配圖。
生成產品圖、輪播圖或頁面素材。
根據 UI 截圖指出需要修改的位置。

更高效的用法是：不要只說「改好看一點」，而是結合截圖指出具體問題，例如「這個卡片間距太大」「這裡的圖和服務場景不匹配」「把地圖區域做得更清楚」。

Steer：任務執行中及時糾偏

Steer 可以理解成「執行中接管方向」。當 agent 已經開始執行，但你發現它理解錯了方向，不應該等它全部跑完再改。

這時可以使用引導功能，把新的指令插入目前執行流程，讓 Codex 及時修正路線。

適合使用 Steer 的場景包括：

agent 誤解了需求。
生成的頁面風格明顯不對。
正在執行的方案成本太高。
你臨時補充了關鍵約束。

一般建議保留預設排隊行為，只在確實需要干預時手動使用 Steer。這樣既不會打亂正常任務，也能在關鍵時刻把方向拉回來。

計劃模式和內建瀏覽器

複雜任務建議先開計劃模式。計劃模式下，Codex 不會馬上改程式碼，而是先輸出方案，必要時還會用卡片形式追問關鍵選擇。

適合開計劃模式的任務：

框架遷移，例如從普通 React 專案遷到 Next.js。
大範圍重構。
涉及資料庫、認證、部署的功能。
你還沒想清楚技術路線的需求。

Codex App 的右側區域可以打開內建瀏覽器，用來預覽本地開發服務。你可以在頁面上做批註，讓 Codex 按具體 UI 位置修改問題。這種「看頁面、點位置、讓 AI 改」的流程，比純文字描述更適合前端除錯。

Git、IDE 和程式碼回滾

Codex App 不是完整 IDE。它可以查看程式碼、批註程式碼，但真正的手寫編輯仍然更適合交給 VS Code、Cursor、Windsurf 等 IDE。

建議每個 Codex 專案都盡早初始化 Git：

讓 Codex 建立或檢查 .gitignore。
在完成一個可用狀態後提交一次。
每次大改前確保有乾淨提交點。
不滿意時用 Git 回滾程式碼。

如果只回滾對話歷史，程式碼不會自動跟著回滾。比較穩的做法是：對話層面回到合適節點，程式碼層面用 Git commit hash 回到對應狀態。

Worktree：並行開發多個方向

git worktree 是 Codex App 裡非常適合並行 agent 的能力。

它的本質是：基於同一個倉庫建立多個獨立工作目錄，每個目錄對應不同分支。這樣你可以讓不同 agent 在不同資料夾裡同時開發，不互相覆蓋。

典型用法：

一個 worktree 優化客戶評價元件。
一個 worktree 調整門店資訊和地圖布局。
兩個任務完成後分別合併回主幹。
合併完成後刪除臨時 worktree。

這比在同一個目錄裡讓多個 agent 同時改程式碼穩得多。遇到衝突時，也可以按正常 Git 流程 review 和合併。

雲端執行環境

Codex 不只能在本機工作，也可以把任務委託到雲端環境執行。

雲端執行適合這些場景：

出門在外，手邊只有手機。
希望 agent 在背景跑長任務。
程式碼已經同步到 GitHub，需要讓 Codex 基於遠端倉庫修改。
希望透過 PR 形式審查和合併改動。

典型流程是：先把本地程式碼推到 GitHub，再讓 Codex 在雲端環境中拉取倉庫、執行任務、生成改動，最後以 PR 或 diff 的方式交給你審核。

本地繼續開發時，要記得把遠端最新改動同步回來。

記憶系統：寫好 AGENTS.md

新對話預設沒有完整歷史記憶。專案一複雜，如果每次都重新解釋背景，會很浪費。

最通用的做法，是在專案根目錄維護 AGENTS.md。這個檔案可以記錄：

專案目標和主要技術棧。
常用命令。
目錄結構說明。
程式碼風格和命名約定。
禁止事項，例如不要批量刪除檔案。
測試、建置和部署規則。

你也可以讓 Codex 先通讀專案，再生成一版 AGENTS.md，然後人工審一遍。複雜專案裡，這個檔案非常值得維護。

全域規則也要謹慎。適合寫入所有專案都通用的安全約束，例如「不要遞迴刪除目錄」「執行破壞性操作前必須確認」。不要把某個專案的細節寫進全域規則，否則會污染其他專案。

外掛和自動化

外掛用於把外部服務接入 Codex，例如 GitHub、Gmail、Google Drive、資料庫、部署平台等。

外掛的價值在於減少複製貼上。比如你可以讓 Codex：

查看某個 GitHub 倉庫的 star 趨勢。
整理郵件內容並發給自己。
定期執行某個檢查任務。
把結果寫成摘要。

自動化則適合重複任務。例如每週五下午檢查一次倉庫資料，並發送郵件報告。簡單自動化任務通常不需要最高規格模型，選擇較輕量的模型即可。

Skills：把工作流變成可複用能力

Skills 是 Codex 的「專業說明書」。它不是單次提示詞，而是把某類任務的流程、規範、腳本和注意事項沉澱下來，讓 Codex 後續穩定複用。

常見來源有三類：

官方 Skills。
第三方 Skills。
自己編寫的 Skills。

適合做成 Skill 的工作：

把字幕整理成圖文筆記。
按公司規範寫週報。
批量處理圖片或文件。
固定格式的程式碼審查。
特定框架的專案初始化。

如果某個提示詞你已經複製貼上了很多次，就值得考慮把它做成 Skill。

MCP：接入外部工具和資料庫

MCP 可以理解成給大模型使用的標準化工具協議。透過 MCP，Codex 可以呼叫外部服務完成更具體的任務。

例如接入 Supabase 後，可以讓 Codex：

建立資料表。
讀取資料庫結構。
修改後端接口。
把前端表單提交到資料庫。
根據資料庫狀態除錯問題。

這類能力很強，但也要注意權限邊界。資料庫、生產環境、部署平台、郵件帳號都屬於高風險資源。第一次接入時，最好使用測試專案和低權限帳號。

部署外掛

部署平台外掛可以讓 Codex 直接完成建置和發布，例如把前端專案部署到 Netlify 一類平台。

這類外掛適合小型網站、原型頁面、內部工具和展示專案。實際使用時建議注意：

部署前先跑本地建置。
環境變數不要直接寫進程式碼。
發布後檢查頁面是否能正常訪問。
生產專案要保留人工 review。

AI 可以幫你打通發布流程，但發布權限仍然要謹慎管理。

電腦自動化

在支援的平台和外掛環境裡，Codex 還可以操作瀏覽器或桌面應用，完成更接近 RPA 的任務。

例如：

打開聊天軟體並準備一條訊息。
瀏覽專案看板，彙總任務狀態。
生成英文簡報。
在你確認後發送給指定對象。
把這套流程做成定時自動化。

這類功能很有想像力，但也最需要安全邊界。凡是涉及發訊息、發郵件、提交表單、付款、刪除資料的操作，都應該保留人工確認。

使用建議

Codex App 的正確打開方式，不是讓它一次性全自動接管一切，而是把任務拆清楚，讓它在受控環境裡高效執行。

推薦習慣：

每個專案先初始化 Git。
複雜任務先開計劃模式。
並行任務優先用 worktree。
專案規則寫進 AGENTS.md。
高風險操作保留人工確認。
重複流程沉澱成 Skill 或自動化。
外掛和 MCP 先在測試環境驗證。

參考資料

小結

Codex App 的重點不是「多一個 AI 聊天視窗」，而是把 AI 編程變成一個可管理的工作台：本地專案、雲端任務、Git、worktree、外掛、Skills、MCP 和自動化都能串起來。

真正用好它的關鍵，是在「放權」和「控制」之間找到平衡。小任務可以大膽交給 Codex，複雜任務先讓它計劃，高風險動作必須確認。這樣它才會從一個會寫程式碼的助手，變成可以長期協作的工程工具。

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

誰把哥布林放進了 GPT-5.5？

Sat, 02 May 2026 11:02:16 +0800

OpenAI 最近復盤了一個很有意思的小問題：為什麼 GPT-5.5 在 Codex 裡會頻繁使用 goblin、gremlin 這類表達？

這不是普通的口頭禪問題。它暴露的是模型訓練中的一個常見現象：模型可能不是直接記住某個詞，而是在強化學習階段學到一種「更容易被獎勵」的表達風格。

現象是什麼

GPT-5.5 訓練後期，Codex 使用者開始發現模型在解釋程式碼問題、測試失敗或異常行為時，會偏愛一組帶有擬人化色彩的表達。

OpenAI 內部也觀察到類似現象：GPT-5.5 相比早期版本，更常在回應裡使用 goblin、gremlin 等詞。研究團隊把這個現象稱為一種「怪異人格特徵」，並嘗試追蹤它從哪裡來。

不是簡單的資料複讀

最直觀的猜測是：訓練資料裡這類表達變多了，模型只是學到了高頻詞。

OpenAI 檢查後發現，事情沒有這麼簡單。它們在預訓練語料中確實能找到相關詞，但數量不足以解釋模型後期行為變化。更關鍵的是，模型在強化學習前後表現差異明顯：後期訓練把這類風格放大了。

這說明問題不只是「資料裡有什麼」，還要看訓練過程獎勵了什麼。

強化學習放大了風格偏好

OpenAI 的分析裡，關鍵變化發生在強化學習階段。GPT-5.5 在訓練中學會了更活潑、更有辨識度、更像「有性格」的寫法，而某些帶有調侃意味的詞正好符合這種風格。

簡單說，模型可能發現：

更有個性的回答更容易被偏好。
用輕鬆比喻解釋技術問題，回饋可能更好。
某些詞在特定語境裡能增加「可愛」「機靈」「好玩」的感覺。
這些局部獎勵會被訓練過程放大。

最終結果就是，模型沒有被明確要求頻繁使用這些詞，卻在特定場景裡形成了穩定傾向。

源頭是 Nerdy 人格

順著資料回溯，OpenAI 很快定位到一個具體分支：個性化定製裡的 Nerdy 人格。

這個模式原本想把 AI 調成「書呆子導師」：熱情、機智、推崇知識和批判性思維，同時不要太一本正經。站在人類角度，這個要求很清楚：要有極客精神，也要有幽默感。

但模型不會真正理解「幽默」的邊界。它在強化學習回饋裡學到了一條捷徑：用 goblin 這類比喻，容易顯得俏皮、聰明、像個書呆子，於是更容易拿到高分。

資料也能說明問題。從 GPT-5.2 到 GPT-5.4，預設人格下 goblin 出現頻率變化只有 -3.2%；但在 Nerdy 人格下，這個數字暴漲了 3881.4%。更誇張的是，Nerdy 模式只佔 ChatGPT 總對話量的 2.5%，卻貢獻了 66.7% 的 goblin 用量。

所以問題不在某個詞本身，而在獎勵訊號把一種「看起來幽默」的表達方式推成了固定風格。

Codex 為什麼更明顯

Codex 場景放大了這個問題。因為程式碼任務經常涉及 bug、測試失敗、環境差異和邊界行為，模型很容易把這些問題擬人化。

當模型想用輕鬆方式解釋「這個錯誤很奇怪」「這個測試不穩定」「這個行為像在搗亂」時，就會更容易調用這類詞。久而久之，使用者會感覺模型有固定口癖。

OpenAI 後來在 Codex 的系統提示中加入了抑制指令，明確要求模型避免這類表達。這個做法不是重新訓練模型，而是在產品層面先把行為收住。

這件事說明什麼

這個案例的重點，不在某個詞本身，而在模型行為如何形成。

它至少說明瞭三點：

模型風格可能來自獎勵訊號，而不只是語料頻率。
小的偏好在訓練後期可能被放大成穩定人格特徵。
產品裡的系統提示可以緩解問題，但不等於從模型內部消除了傾向。

這也是大模型對齊裡很麻煩的一類問題：使用者喜歡「有趣」的回答，但過度追求有趣，可能讓模型在嚴肅任務裡顯得輕浮、重複或自帶口癖。

對使用者的啟發

如果你在使用 AI 程式設計工具時發現模型有固定話術，不一定是提示詞裡寫錯了，也可能來自模型本身的訓練偏好。

可以用幾種方式緩解：

在系統提示或專案規則裡寫明語氣要求。
要求模型避免擬人化、俚語化、過度調侃。
對技術任務指定「直接、簡潔、工程化」的回答風格。
如果某個詞反覆出現，可以明確列入禁止表達。

這類約束不能改變模型內部權重，但能在實際產品使用中減少幹擾。

小結

GPT-5.5 的 goblin 口癖不是一個孤立笑話。它展示了大模型訓練中更深的問題：獎勵訊號會塑造風格，風格會遷移到產品場景，最後變成使用者能感知到的人格特徵。

對模型廠商來說，這類問題需要在訓練、評測和產品提示三層同時處理。對普通使用者來說，最實用的做法是把期望風格寫清楚，讓模型少一點表演，多一點穩定。

參考：

https://openai.com/index/where-the-goblins-came-from/

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

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 作為工作執行層」的方向。

GPT Image 2 正式發布：從能生成到能商用的跨越

Wed, 22 Apr 2026 20:08:22 +0800

OpenAI 的下一代圖像生成模型 GPT Image 2 已經正式面向 ChatGPT 使用者開放。結合社群在洩露測試階段的回饋，以及公開可見的實際效果，這一代模型的變化不像一次常規迭代，更像是 AI 生圖從「能看」走向「能用」的一次明顯推進。

如果說上一階段的圖像模型，更多還是用來做靈感圖、概念圖和試玩性質的生成，那麼 GPT Image 2 最突出的地方，就是它開始接近生產級工具。無論是可讀文字、介面截圖、行銷海報，還是更逼真的商業攝影風格圖片，它都比過去更接近「直接拿去用」的狀態。

一、核心升級：五個最值得注意的點

1. 文字渲染終於進入可用區間

AI 生圖過去最難啃的一塊，就是文字。亂碼、拼寫錯誤、長文本崩壞、字體變形，這些幾乎是所有模型都會碰到的問題。

GPT Image 2 在這方面的提升非常明顯。它不僅能處理更清晰的英文和中文文字，還能應對更複雜的排版、更長的段落，以及一定程度上的多語言混排。這意味著很多原本必須靠後期修字的場景，現在可以直接在生成階段完成。

比較典型的用法包括：

海報
社群媒體封面
帶標題與說明文字的宣傳頁
PPT 配圖
帶真實文案和介面元素的 App 截圖

對實際工作流來說，這一步很重要。因為只要文字能穩定可讀，圖像生成就不再只是「出一張背景圖」，而開始具備承接行銷物料和產品展示圖的能力。

2. 照片級真實感明顯提升

從社群並排對比來看，GPT Image 2 的整體畫質更銳利，材質紋理更細，光線一致性也更強。過去最容易露出 AI 痕跡的人臉、手部、邊緣細節，這一代都明顯更穩定。

更準確地說，它不是完全沒有破綻，而是「AI 味」顯著下降。很多圖第一次看上去，已經會讓人直接把它當作真實照片、商業攝影樣片或者遊戲截圖。

這也是為什麼很多人對它的第一反應不再是「畫得不錯」，而是「這張圖已經很像真的了」。

3. 世界知識整合能力更強

這是一個沒那麼顯眼，但非常實用的升級。

GPT Image 2 給人的感覺，不只是會拼圖塊、湊風格，而是更像「知道自己在畫什麼」。原文裡提到的幾個方向很有代表性：

手錶表盤時間邏輯更合理
品牌細節和角色特徵還原更準確
Minecraft 這類遊戲截圖或軟體介面的邏輯結構更像真的

這意味著它在處理現實物體、數位介面、遊戲畫面這類需要常識和結構感的內容時，成功率更高。對使用者來說，這種提升往往比單純的「更高畫質」更有價值。

4. UI 與截圖生成能力很強

從洩露期到正式上線，GPT Image 2 最出圈的一個方向，就是生成軟體介面、網頁截圖和 App mockup。

這類任務過去很難做，因為它們同時要求：

文字清楚
佈局規整
按鈕、卡片、導覽列等元素對齊
配色和層級像真實產品

而這次模型在這些方面的表現已經相當成熟。對於產品經理、獨立開發者和設計師來說，這意味著可以更快做出高保真原型圖，用於提案、演示甚至使用者測試。

5. 局部編輯更接近實用工作流

按原文整理的資訊，GPT Image 2 支援更精準的局部編輯能力，也就是只修改畫面中的特定區域，而不是每次整張圖推倒重來。

這類能力對創意工作流非常關鍵。因為實際設計場景裡，很多時候不是「重做一張」，而是：

改一個按鈕
換一段文字
調整某個物體的位置
修一塊背景
替換局部元素

如果局部編輯夠穩定，AI 生圖的價值就不只是第一次出圖，而是能真正參與到反覆迭代中。

二、怎麼使用 GPT Image 2

在 ChatGPT 裡使用

目前 GPT Image 2 已經整合在 ChatGPT 裡，一般使用者可以直接透過圖像生成功能呼叫。

常見操作流程是：

打開 ChatGPT 網頁版或 App
在輸入框點擊 +
選擇「建立圖片」
輸入提示詞並提交
系統呼叫 GPT Image 2 生成結果

原文還提到，不同訂閱等級對應的可用額度不同，免費使用者和 Plus / Pro 使用者在生成次數上會有差別。具體額度規則建議以當時 ChatGPT 產品內顯示為準，因為這類限制後續可能調整。

在 API 中使用

如果是開發者場景，也可以透過 OpenAI API 呼叫圖像生成模型。原文裡提到的模型名寫法是 gpt-image-2，但實際接入時仍建議以官方文件中的最新名稱和參數為準。

文中列出的幾個常見解析度如下：

解析度	適用場景
`1024×1024`	通用方圖、頭像、社群媒體圖片
`1536×1024`	橫版封面、投影片、寬螢幕桌布
`1024×1536`	直版海報、手機桌布、故事配圖
`2048×2048`	高畫質印刷、大幅展示、精細插畫

三、幾個代表性使用場景

原文列了不少案例，這裡整理出最有代表性的幾類。

1. App 介面截圖

這一類提示詞非常適合產品原型、設計演示、需求討論。

示例特點通常是：

指定平台風格，例如 iOS
寫清頁面結構
列出核心資料卡片
指定底部導覽列
說明配色與字體風格
強調文字必須清晰、元素要對齊

這種寫法的重點不是「畫面好看」，而是盡量減少模型發揮空間，讓結果更像一個真的介面。

2. 電商產品圖

像香水、耳機、手錶、化妝品這類商品圖，很適合 GPT Image 2 發揮。

因為它現在對以下內容的處理已經更穩定：

玻璃、金屬、液體等材質質感
柔和陰影和反射
商業攝影常見的布光邏輯
簡潔背景下的高端展示感
少量品牌文字

如果生成結果穩定，很多電商詳情圖、行銷頁主圖、社群媒體產品視覺，都能把試錯成本壓低很多。

3. 文字海報

海報是最能體現這一代文字能力的場景之一。

原文給出的方向很典型：在一個黃昏城市剪影背景上，明確寫出主標題、時間地點、藝人名單，並要求：

文字清晰可讀
無拼寫錯誤
中英文混排穩定
風格統一

這類任務過去通常要先生成背景圖，再人工補字。現在如果模型能一次完成大部分工作，它的實用價值就會大很多。

4. 遊戲概念圖和「假截圖」

這是 GPT Image 2 在社群媒體上最容易傳播的一類內容。

比如第三人稱遊戲截圖、霓虹街道、雨後積水反射、景深、顆粒感、PS5 實機風格，這種提示詞組合出來的結果，很容易讓人第一眼誤判為遊戲洩露畫面。

從傳播角度看，這類圖很吸睛；從風險角度看，也說明以假亂真的門檻已經明顯下降，使用者對圖片真實性的判斷需要更謹慎。

5. 擬真人像與創意肖像

人像一直是 AI 圖像能力最直觀的測試題。

原文裡的示例聚焦在自然光、咖啡館、逆光邊緣、針織衫、暖色背景虛化這類細節組合。它們背後的重點其實是：

皮膚紋理自然
髮絲細節完整
手部結構不崩
光線邏輯合理
整體氛圍不帶明顯 AI 痕跡

如果這幾點能穩定做到，人像生成才算真正進入可用階段。

6. 美食攝影

原文還給了一個非常長的英文提示詞，用來生成高端餐廳風格的豚骨拉麵照片。這個例子說明了一個很現實的趨勢：當模型夠強時，提示詞可以寫得像攝影腳本。

這種寫法會細到：

菜品構成
餐具材質
湯底光澤
叉燒的脂肪層和焦邊
溏心蛋狀態
背景景深和散景
光源方向
鏡頭型號與光圈

對於餐飲品牌、菜單設計、外送平台主圖和社群媒體內容，這種生成能力已經非常接近商業攝影替代方案。

7. 教育插圖

另一個很有代表性的方向，是帶標註的科學教育圖。

原文示例是一張植物細胞剖面圖，要求模型同時處理：

結構正確
標籤位置準確
引導線清晰
字體統一
配色有層次
整體適合教材或課件使用

這說明 GPT Image 2 的價值不只是做「好看」的圖，還包括做「資訊型」的圖。

四、對一般使用者最實際的意義

GPT Image 2 真正值得關注的地方，不只是它又把畫質往前推了一步，而是它把 AI 生圖從娛樂型、試玩型工具，進一步推向了可商用、可交付的生產工具。

具體體現在幾個層面：

文字終於開始靠譜
介面和海報更像真實物料
商業攝影風格圖更可用
教育類、資訊類圖片也能做
局部編輯讓它更適合迭代

當然，這並不代表它已經完全取代設計師、攝影師或插畫師。真正的商業專案仍然需要審美判斷、品牌控制、版權意識和人工複核。

但至少從這次更新能看出來，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 額度怎麼算：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 額度現象。

如何在 VS Code 中使用 Codex（從安裝到高效實戰）

Fri, 20 Mar 2026 00:00:00 +0000

Codex 可以直接在 VS Code 側邊欄中協助你寫程式、改 Bug、解釋專案與執行命令。

1. 準備工作

開始前請確認：

VS Code 已更新到較新的穩定版本。
你可以正常訪問 OpenAI 網站。
專案程式碼已在本地開啟（建議使用 Git 倉庫）。

2. 安裝擴充套件

開啟 VS Code 的擴充套件市集（Extensions）。
搜尋並安裝：Codex - Codex - OpenAI's coding agent。
安裝完成後，依提示完成登入授權。

3. 開啟 Codex 側邊欄

你可以透過任一方式開啟：

在編輯器右上角點擊 Open Codex Sidebar。
使用命令面板（Ctrl + Shift + P）搜尋 Codex 並開啟。

開啟後，Codex 會讀取目前工作區上下文，進入可對話狀態。

4. 常見使用方式

4.1 讓它解釋程式碼

示例提示詞：

`1`	`請解釋這個檔案的核心邏輯，並指出最可能出錯的 3 個地方。`

適合你剛接手舊專案時快速建立全域理解。

4.2 讓它實作功能

示例提示詞：

1
2

在現有 API 裡新增一個 /healthz 健康檢查介面，
要求回傳版本號與資料庫連線狀態，並補上基礎測試。

建議把「輸入約束」與「驗收標準」一起寫清楚，產生結果會穩定很多。

4.3 讓它修復問題

示例提示詞：

1
2

這個介面在併發下偶發 500，請先定位根因，再給出最小改動修復方案，
最後列出回歸測試點。

先「定位」再「修復」，能減少誤改與過度重構。

5. 高品質提示詞模板

你可以直接複用下面這個結構：

背景：這是一個 <技術棧> 專案，目前目標是 <目標>
約束：不改動 <模組/介面>，相容 <版本/平台>
輸出：
1) 修改檔案列表
2) 關鍵程式碼說明
3) 驗證步驟
4) 風險與回滾方案

這個模板對「多人協作 + 大專案」非常有幫助。

6. 常見問題

6.1 關於免費額度

在對話框輸入 \，然後選擇「狀態」，會出現額度、重置時間等相關資訊。

6.2 改動不符合預期

修改完成後查看審核按鈕，檢查修改細節；不滿意可選擇撤銷按鈕以回退修改。在後續步驟中可以把需求拆小，分成多個步驟分別執行。使用 Git 等程式碼管理工具，保持小步提交（small commits），方便回滾。

OpenAI on KnightLi的博客

GPT-5.6 爆料：150 萬 token 上下文視窗意味著什麼

爆料裡提到哪些模型代號

150 萬 token 上下文為什麼重要

真實世界測試的訊號

前端介面生成能力也被提到

還提到了哪些競爭模型

我的判斷

OpenAI Symphony 是什麼？Codex 編排、Issue 驅動與 AI Agent 開發工作流

Symphony 解決的不是寫代碼，而是管理 Agent

為什麼是 issue tracker？

它的核心工作流

目標驅動，而不是死板狀態機

和普通 Codex 使用方式有什麼不同？

適合哪些場景？

風險和邊界

我對 Symphony 的理解

參考連結

AI 數學里程碑：OpenAI 推翻 Erdős 單位距離猜想意味著什麼

問題是什麼

證明過程為什麼特別

專家反應

這是否意味著 AI 替代數學家

對未來科研的影響

這和 IMO 解題有什麼不同

為什麼數學適合檢驗 AI 推理

AI 證明為什麼仍然需要人類數學家

這對 OpenAI 模型路線意味著什麼

普通讀者該怎麼看

結論

Cerebras IPO 大漲背後：晶圓級 AI 晶片能挑戰英偉達嗎

Cerebras 做的不是普通 GPU

為什麼市場會興奮

OpenAI 合作讓想像空間變大

客戶集中仍然是最大風險之一

技術路線的短板：記憶體容量

它會取代英偉達嗎

小結

參考資料

Codex 支援 ChatGPT 移動端遠端存取，Enterprise 工作區可用 Access Tokens

這次更新是什麼

移動端遠端存取解決什麼問題

這對開發者有什麼價值

Access Tokens 解決什麼問題

它不是普通 API key

安全預設值：Remote Control 預設關閉

使用前需要更新什麼

對企業 Codex 使用方式的影響

仍然需要注意的邊界

總結

Codex 額度為什麼突然重置？Usage Limits 歷史與消息來源整理

先說結論

這次截圖說明了什麼

為什麼 Codex 會無預兆重置

歷史上的幾類重置

1. 2026 年 2 月：發布期與臨時加量

2. 2026 年 3 月：隨機重置與異常消耗討論

3. 2026 年 4 月：成長里程碑與付費方案重置

4. 2026 年 5 月：故障補償型重置

使用者該怎麼判斷一次重置來自哪裡

消息來源怎麼分辨可靠性

總結

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

它能做什麼

使用前需要什麼

Codex 手機遠端存取的限制

怎麼連接

手機端適合做什麼

常見問題

適合哪些場景

我的判斷

參考資料

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

最新可用範圍

它會保存哪些文件

怎麼把文件加入新對話

怎麼查找和管理

各方案容量

單文件限制

刪除和下載