GPT-5.4 與 GPT-5.3：可能真正改變的是什麼
GPT-5.4 洩漏訊號暗示推理速度更快及視覺功能升級。以下是它對開發者而言可能與 GPT-5.3 有何不同。
嗨，我是 Dora。我發現自己竟然在「陪跑」一個長時間執行的 agent 迴圈。不是什麼大事，只是那種緩慢、令人焦躁的感覺——模型一直要求再呼叫一個工具，然後又一個。這讓我想起我有多少工作時間是耗在邊緣地帶：那些停頓、重試、「它到底有沒有讀那份文件？」的時刻。
於是我花了一個下午重新整理對 GPT-5.3 的筆記，然後快速瀏覽了早期關於 GPT-5.4 的討論。圍繞模型架構和延遲提示的早期洩漏討論，可以在這篇 GPT-5.4 洩漏 分析中找到摘要。我並非在追逐下一個大事件，更多是想回答一個小問題：這些改進能否減少我工作流程中那些令人焦躁的部分？這是我關於 GPT 5.4 vs GPT 5.3 的持續記錄，包含我實際測量的結果、看起來可信的說法，以及我仍然存疑的地方。
GPT-5.3 的能力：現行基準
推理與工具使用表現
自 2026 年 1 月中旬以來，我一直在將 GPT-5.3 用於三項固定工作：彙整產品研究、分類處理支援工單，以及搭建小型腳本框架。簡而言之：只要我給它清晰的結構，它就能很好地處理多步驟推理。 當我明確說明角色、狀態和終止條件時，它能貫徹執行而不會偏離。
在工具使用方面，函式呼叫一直很穩定。我依賴 OpenAI 的函式呼叫模式和標準工具 schema，沒有意外。使用定義明確的工具（搜尋、檢索、簡單的向量查找），5.3 的呼叫保持整潔。在一次處理 20 封電子郵件的分類任務中，每個工單平均呼叫 1.7 次工具，比我舊的設定減少了 2.4 次。這消除了小小的「接下來怎麼辦？」停頓。問題在於：如果我的工具描述模糊，它會嘗試用更多次呼叫來補償。
我最明顯感受到的是它對部分上下文的容忍度。如果我只傳入相關片段和精簡的狀態摘要，它仍然能正常推理。但如果我加入大量鬆散相關的筆記，它就開始模稜兩可。
程式碼撰寫與 agent 工作流程支援
在程式碼方面，5.3 在中小型重構上表現穩定。它擅長生成附有清晰說明的 diff，並且在我提供簡短風格指南的情況下能保持一致的風格。它的瓶頸在於需要緊密依賴關係感知的跨檔案修改。我通常會切換到兩步驟模式：第一步請它概述編輯內容，第二步再逐檔案套用。這能防止它過度自信地觸碰不該動的部分。
在 agent 工作流程中，當我限制遞迴深度並記錄每個決策時，5.3 表現最佳。我已固定採用三步驟迴圈：計畫 → 呼叫工具 → 反思。超過這個數量它就會變得囉唆。我也會提示它輸出緊湊的 JSON 作為狀態，這能減少解析錯誤。這些都不是什麼魔法，只是讓迴圈減少依賴的護欄。
已知限制
- 當我將系統規則與冗長的使用者任務混在一起時，它可能會重複處理指令：我已學會在提示末尾重申關鍵限制條件。
- 它有時堅持重新摘要我已經摘要過的輸入，這會浪費 token 和時間。
- 在視覺任務（截圖、UI 模型）上，它還算能標記和描述，但會漏掉小字和細緻的排版邏輯。它不止一次把切換開關誤認為按鈕。
- 在壓力下（token 緊張），它傾向於用安全的概括說法取代精確的細節。我在評估錯誤日誌時會看到這種情況：它指出可能的原因，但在沒有更多上下文的情況下不願意明確表態。
這是我對 5.3 的工作評估：在我明確表達時可靠，在我不夠明確時略顯焦慮。
GPT-5.4 的訊號暗示了哪些改變
截至 2026 年 3 月 5 日，我尚未直接使用過 5.4。以下內容來自早期洩漏討論、私人論壇中一些可信的開發者筆記，以及我在模型家族小幅推進時學到的觀察規律。我會將每個觀點標記為：可觀察到的、基於洩漏的，或推測性的。
推理速度與快速模式的意涵
基於洩漏：多個來源提及一種「快速模式」或短形式推理的低延遲層級。如果屬實，這與其說關乎原始吞吐量，不如說關乎 agent 的節奏。首個 token 延遲降低 20-30% 會讓迴圈的感覺從笨重變得靈活。對比 GPT-5 與 DeepSeek、GLM 等模型的基準測試顯示了延遲和成本在實際開發工作流程中的影響有多大。在我的 5.3 設定中，平均提示的首個 token 延遲約在 600-900 ms 之間：即使縮短 150-200 ms 也能讓工具鏈減少那種走走停停的感覺。我預期這種快速模式會犧牲一些深度，適用於路由、分類，或在更深入處理之前的快速驗證。
可觀察到的：如果 5.4 真的增加了速度層級，我可能會拆分工作流程：快速分類 → 路由 → 深度處理。這已經是一種常見模式；速度的提升只會讓它更流暢。
視覺輸入處理改善
基於洩漏：更好的小字 OCR 和更穩定的排版推理。提示指向對低對比度 UI 文字識別的改善以及更精細的邊界框邏輯。如果準確，這將修復我在 5.3 上的兩個痛點：截圖中的小字，以及區分 UI 控制元件。
可觀察到的：這將省去我在驗證介面線框圖時來回折騰的麻煩。目前，當 5.3 表現不佳時，我會另外執行截圖的 OCR 步驟。如果 5.4 減少了這些繞路，我就能從工具鏈中移除一個工具。
潛在的上下文視窗擴展
推測性的：可用上下文小幅增加，或在長提示中有更好的記憶保留。我說的不是標題數字，而是長對話後半段的實際記憶效果。如果 5.4 能在不需要我重述的情況下更穩固地保持任務限制，它將改變我建構狀態的方式。更少的提醒，更少的 token 消耗。如果只是原始視窗增加而沒有更好的記憶保留，好處就比較有限。
等我看到執行後期出現更少「重新詮釋」的情況再相信這一點。在此之前，我持謹慎態度。
並排比較表
我傾向於把我實際測量到的與我只是聽說的分開。以下是三個簡短的表格，每次使用相同的視角。
已確認的能力
| 領域 | GPT-5.3 | GPT-5.4 |
|---|---|---|
| 工具使用 / 函式呼叫 | 使用清晰 schema 時穩定：我的測試中每個任務通常 1-3 次呼叫 | 未確認 |
| 在 token 壓力下推理 | 退化為概括說法：從重申限制條件中獲益 | 未確認 |
| 視覺（UI 截圖） | 漏掉小字：混淆部分控制元件 | 未確認 |
| Agent 迴圈行為 | 搭配 2-3 步驟迴圈和明確停止條件時效果最佳 | 未確認 |
| 跨檔案程式碼撰寫 | 安全起見需要兩步驟策略：diff 說明良好 | 未確認 |
參考資料：我遵循 OpenAI 函式呼叫文件和 API 參考中的工具定義模式。如果你有興趣，官方文件是很好的參照：OpenAI API：函式呼叫 和工具使用。
基於洩漏的訊號
| 領域 | GPT-5.3 | GPT-5.4（基於洩漏） |
|---|---|---|
| 推理速度層級 | 僅標準模式 | 新增更快、更淺層的低延遲回應層級 |
| 視覺 OCR | 尚可，難以處理細小/低對比度文字 | 小字準確度和排版處理有所改善 |
| 每 token 成本 | 目前公布的費率 | 快速層級略有降低（未經驗證） |
來源品質：參差不齊。部分細節與先前版本的規律吻合；均未經確認。
| 領域 | GPT-5.3 | GPT-5.4（推測性） |
|---|---|---|
| 上下文記憶保留 | 需要頻繁提醒限制條件 | 減少重述即可更長時間保持限制條件 |
| 工具使用效率 | schema 模糊時有時過度呼叫 | 在相似提示下呼叫更為精簡 |
| 長期規劃 | 超過 3-4 步驟後猶豫不決 | 多步驟規劃略為更穩定 |
推測性改善
這些改變對開發者為何重要
對 agent 迴圈設計的影響
如果「快速模式」真的存在，我會重新設計迴圈，在前端加入成本低廉的確定性判斷。快速分類，然後分支：簡單任務在快速模式中完成；複雜任務升級到全深度模型。 光是這樣就能減少人工陪跑。在我目前的 5.3 架構中，我花了不少精力防止迴圈失控。速度層級可以將這些精力轉移到更清晰的路由設計上。
更好的視覺處理將簡化我的 UI 分析管道。目前，我對模型圖使用三步驟鏈：基本描述 → OCR 處理 → 排版檢查。如果 5.4 合併了前兩步，我就能退掉 OCR 這一跳，只保留排版驗證器。這樣少了一個工具需要維護，也少了一些出錯的地方。
如果上下文記憶保留有所改善，我會減少提示中那些一再重複的提醒。我會保留一個小而不可變的規則區塊，並信任模型能在執行過程中將其帶得更遠。更少的鷹架，更少的 token，同樣的結果。
成本與效能的取捨
速度層級通常伴隨著品質上的代價。我把這視為一個特性，而非缺陷。適合用於：
- 路由和輕量驗證（我們有沒有正確解析日期，是或否？），
- 提前退出（這是已知的常見問題嗎？），
- 對已檢索上下文的健康檢查（這個片段有沒有提到該實體？）。
對於其他所有事情——塑造輸出的推理——你得為深度付費。如果 5.4 的快速層級每個 token 更便宜，我預期在高流量任務中能節省一些費用，但真正的收益是延遲。每個任務的成本可能略有下降；感知速度則可能大幅提升。
如果定價沒有任何變化，我仍然會拆分工作。即使使用 5.3，將較小/較便宜的模型用於路由通常也很值得。原生快速層級只是減少了黏合程式碼。
遷移注意事項
- 從影子測試開始。將相同的提示同時跑過 5.3 和 5.4（當可用時），並比較結果差異。在看過幾十個邊緣案例之前，不要切換正式路徑。
- 保持工具 schema 嚴格。模糊的描述會在 5.3 上增加呼叫次數；在 5.4 上無論快速與否可能也是如此。
- 記錄 token 壓力。許多「退步」只是提示太緊。追蹤視窗使用情況並刪減樣板文字。
- 對提示進行版本控制。我在系統訊息中保留一個小型變更日誌。如果 5.4 在提示更精簡時表現更好，你會需要一份關於你刪除了什麼的記錄。
- 安靜地觀察視覺效果。如果你依賴截圖，請使用低對比度文字、擁擠的 UI 和奇特字體進行測試。一套好的測試集勝過十幾個個案。
如果你是小型團隊，最安全的做法是分階段進行：先在一個範圍較窄的工作流程（路由、分類）上試行，然後再擴展。
對於獨立開發者，我建議嘗試改變一個習慣：在提示鏈的頂部加入一個「快速還是完整？」的判斷閘。即使 5.4 沒有推出快速模式，這種紀律本身也很有幫助。
重要說明（比較基於洩漏訊號）
在官方發布或文件出現之前，這裡所有關於 GPT-5.4 的內容都是二手資訊。5.4 的部分是基於洩漏訊號和從過往更新中謹慎推測的混合體。如果 5.4 正式推出，我會重新執行相同的任務並更新這篇文章。現在，請把這視為一張用鉛筆而非墨水畫的地圖。
最後一個想法：即使是小小的速度提升也能讓工作流程鬆弛下來。 如果這就是 5.4 帶來的全部，我也欣然接受。
