GPT-5.5「Spud」查核：未見官方確認，長上下文可靠性仍未證實

先說結論：在這組來源裡，沒有找到 OpenAI 官方確認 GPT-5.5「Spud」已公開發布，也沒有找到 Spud 專屬的長上下文可靠性或指令保留基準。已審閱的 OpenAI API 指南、API changelog 與 GPT release notes 指向的是「Latest: GPT-5.4」，而不是公開的 GPT-5.5 Spud 模型 。

這不等於證明 OpenAI 內部一定沒有任何代號叫 Spud；它只表示，關於 Spud 的發布日期、API 可用性、定價、記憶能力或長上下文可靠性，目前不能用這組公開官方資料證實。

查核結果

說法	狀態	證據能支持到哪裡
GPT-5.5 Spud 是 OpenAI 官方公開模型	未獲證實	已審閱的 OpenAI API 指南、changelog 與 GPT release-note 材料指向 GPT-5.4，而非公開的 GPT-5.5 Spud 模型 。
OpenAI 已發布 GPT-5.5 Spud 的日期、模型卡、API 頁面或定價	未在已審閱官方來源找到	有非官方頁面討論時程與能力，但這組官方 OpenAI 資料記載的是 GPT-5.4 。
OpenAI 已公開測試 Spud 的長上下文指令保留能力	未獲證實	這組來源中，已審閱的官方材料沒有 Spud 專屬系統卡或長上下文基準 。
OpenAI 有發布 GPT-5.4 Thinking 的長程操作相關證據	有，但只限 GPT-5.4 Thinking	OpenAI 表示 GPT-5.4 Thinking 在具挑戰性的長程操作軌跡上，追蹤與回復操作的表現比早期模型好得多；同頁也把 CoT-Control 描述為含超過 13,000 項任務的評估套件 。

為什麼 Spud 傳聞不能等同於正式發布

Spud 這個名字確實在網路上流傳。相關討論出現在 Facebook、Reddit、X、YouTube 影片，以及非官方文章中，內容包括可能發布時間、預訓練、多模態與能力猜測 。這些資料能證明「有人在談 Spud」，但不能證明 OpenAI 已發布這個模型。

如果要確認一個模型真的可用，通常需要更強的第一手證據，例如 OpenAI 的 API 頁面、changelog 條目、release note、官方公告、系統卡或可重現的基準測試。這組資料中，這類主要材料目前明確指向或描述的是 GPT-5.4 。

對開發者、產品團隊與採購決策者來說，這個差別很實際：模型暱稱不是基準測試，傳聞中的更大上下文視窗也不會自動證明模型能在冗長、跨工具、跨文件的工作流程中穩定遵守指令。

官方資料真正支持的是什麼

目前最強的官方模型證據集中在 GPT-5.4。OpenAI 的 API 指南標題是 Using GPT-5.4，API changelog 與 GPT release-note 材料也把讀者導向 Latest: GPT-5.4 。

OpenAI 的 GPT-5.4 發布文章表示，該模型整合 GPT-5.3-Codex 的程式能力，並改善模型在工具、軟體環境、試算表、簡報與文件等專業工作中的表現 。同篇文章也稱 GPT-5.4 在 GDPval 比較中達到 83.0%，高於 GPT-5.2 的 70.9%；OpenAI 將 GDPval 描述為測試代理完成明確規格知識工作的能力，涵蓋 44 種職業 。

最接近「長工作流程可靠性」問題的官方資料，是 GPT-5.4 Thinking，不是 Spud。OpenAI 的 GPT-5.4 Thinking system card 說，GPT-5.4 Thinking 在具挑戰性的長程操作軌跡上，能更好地追蹤與回復自己的操作，同時保留使用者既有工作；該頁也說 CoT-Control 是一套超過 13,000 項任務的評估套件 。這是 GPT-5.4 Thinking 的說法，不能拿來證明 GPT-5.5 Spud 已發布或通過同等測試。

長上下文不只是「塞得下更多字」

長上下文可靠性不等於單次提示能容納更多 token。真實工作中，模型可能要把很早之前的限制保留下來、跨多輪或多個工作階段維持狀態、在多個工具之間選對工具、在修改舊內容時不破壞使用者既有成果，還要讓多檔案或多文件輸出保持一致。

研究界仍把這些問題視為需要評估與工程化處理的難題。近年的綜述持續討論延長上下文、長上下文建模、架構改造、工作流程方法與 context engineering，而不是把長上下文指令遵循視為已經解決 。也有系統性評估研究針對長上下文模型的最佳化技術進行基準測試，涵蓋模型處理與保留大量資訊的情境 。

更重要的是，指令保留正被直接量測。LongAlign 提出 LongBench-Chat，用於評估長上下文中的指令遵循 。LifBench 提出 Long-context Instruction Following Benchmark，聚焦長上下文情境下的指令遵循表現與穩定性 。LocoBench 則面向複雜軟體工程工作流程，包含 Multi-Session Memory Retention 與多工作階段開發流程 。

評估長工作流程可靠性的六個檢查點

OpenAI 的評估建議強調貼近正式環境的 eval，並特別點出工具選擇；文件也提醒，當單一代理架構加入更多工具與任務時，模型可能更難遵守指令或選對工具 。OpenAI 另有長時間 Codex 任務的開發者指南，顯示長程、多步驟工作確實是產品情境，但那不是 Spud 的基準證據 。

實務上，團隊至少應測這六件事：

1. 指令能否跨距離存活。 把關鍵要求放在長上下文的開頭、中段與結尾，再檢查最終輸出是否全部遵守。LongAlign 與 LifBench 都與長上下文指令遵循有關 。
2. 多工作階段狀態保留。 模擬多次工作階段，包含決策、限制與反悔修正，再確認模型是否能從正確狀態接續。LocoBench 的 Multi-Session Memory Retention 框架與此直接相關 。
3. 高負載下的工具選擇。 提供多個看似可用的工具，檢查模型是否選對工具並填入正確輸入。OpenAI 把工具選擇列為評估目標，也提醒複雜度會讓指令遵循與工具選擇變難 。
4. 回復與修補。 要求模型撤銷長任務中的一部分，但不能破壞無關的使用者工作。這對應到 OpenAI 對 GPT-5.4 Thinking 所描述的長程操作追蹤與回復能力 。
5. 跨檔案與跨文件一致性。 對程式碼、試算表、簡報與文件，檢查模型是否維持整體限制，而不是只優化最新一輪對話。GPT-5.4 的官方定位包含工具、軟體環境、試算表、簡報與文件；LocoBench 則聚焦複雜軟體工程工作流程 。
6. 提示與輸出控制。 用範例和明確要求指定格式、長度與風格。OpenAI 的可靠性指南討論了提示層級技巧，但這些技巧應補足、而不是取代工作流程層級的 eval 。

什麼證據會改變結論

若要改變這次查核結果，需要更強的第一手資料：OpenAI API 或模型頁面明確命名 GPT-5.5 或 Spud、changelog 或 release-note 條目、OpenAI 官方公告、模型卡或系統卡，或可重現的長上下文評估結果，且測到指令遵循、多工作階段記憶、工具選擇、回復修補與產物一致性 。

在那之前，最安全的說法是：GPT-5.5「Spud」未在這組已審閱的 OpenAI 官方資料中獲得公開證實；其長上下文可靠性也沒有被現有證據建立。若要做產品或技術決策，請基準測試實際可用的模型，並把未經官方文件確認的模型暱稱先當成傳聞。