「Opus 規劃，GPT-5.5 執行」：開發者正在重組 AI 工作流

本文整理自 The AI Daily Brief 2026 年 4 月 27 日播出的單集〈What I Learned Testing GPT-5.5〉。

{{< youtube jblguhXunZs >}}

{{< spotify "episode/16Ni0K3i8M8kiXdxMo99NK" >}}

{{< apple-podcast "tw/podcast/what-i-learned-testing-gpt-5-5/id1680633614?i=1000763457037" >}}

---

GPT-5.5（OpenAI 內部代號 Spud）四月底上市那個週末，X 上一個有趣的現象是：原本被認為是「Anthropic 死忠」的開發者開始大量分享 GPT-5.5 的測試心得；但同一群人裡，幾乎沒有人說要把 Claude Code 從工具列移掉。一個共同的詞被反覆使用：「分工」。

這個分工有個快速被市場接受的版本，由 Runway 共同創辦人 Siki Chen 提出：「Opus 4.7 開到 extra-high 來規劃，GPT-5.5 開到 high 來執行，這就是最佳組合。」AI Daily Brief 主持人 Nathaniel Whittemore（NLW）在 4 月 27 日的單集裡花了大段時間講這件事，他自己跑了約十個實測，最後接受這個結論：經過六個月把 Opus 當主力的時間，Opus 接下來至少要跟 Codex 上的 GPT-5.5「共用桌面」。

這篇文章拆解這個雙模型工作流的三個面向：GPT-5.5 強在哪、Opus 4.7 為什麼還守得住規劃位、以及為何「模型 + 鷹架（harness）」這個新框架，會讓單模型評測變得越來越不可靠。

GPT-5.5 強在哪：執行力的飛躍

過去半年 Opus 4.7 之所以能成為很多重度使用者的預設選項，原因是它在程式撰寫任務上「能聽得懂」加「設計品味好」。但 GPT-5.5 上市後，第一波回饋集中在一件事：執行力。

執行力具體拆開有兩層意義。第一層是長時間自主任務的可靠度。Arena.ai 的 Peter Gostev 在 X 上寫：「我有一個資料庫遷移任務跑了七個多小時，這以前根本不可能發生。」更誇張的是 OpenAI 自家的 Adam McLaughlin：星期五口述了一個強化學習實驗讓模型去跑，週一回辦公室發現一個工業規模的訓練流程已經連續跑了 31 個小時。在 GPT-5.5 之前，再好的模型，自主任務跑三十分鐘到兩三個小時就會開始崩，連續喊它撐到四五個小時是極限。從幾小時到 31 小時，這不是線性進步，這是斷層。

第二層是指令遵循的精準度。CodeRabbit 的內部測試顯示，GPT-5.5 對程式碼問題的偵測率從原本基線的 58.3% 拉到 79.2%；Bindu Reddy、Flavio Adamo 等多位重度使用者的回饋集中在另一個更難量化的特性：「不過度設計」。如果你跟 Opus 4.7 說「請幫我修這個 bug 不要動其他地方」，它有不小機率還是順手把整個檔案重構一遍；GPT-5.5 是第一個能真正聽懂這種限制的模型。Adamo 的描述被引用最多：「一個模型可以很聰明，但用起來很累。GPT-5.5 用起來不那麼累了。」

「不那麼累」這四個字是這次質感變化的最佳濃縮。它代表一件事：你可以給 GPT-5.5 一個大目標，回家睡覺，第二天看結果。在 AI 寫程式這件事的歷史上，這是第一次。

Opus 4.7 為什麼還守得住規劃位

雖然 GPT-5.5 在執行力上拉開明顯差距，但它沒贏 Opus 4.7 的兩塊地：規劃跟設計美感。為什麼？

規劃這件事的核心，是把模糊任務拆成具體可執行的工程清單。當你跟模型說「請幫我做一個訂閱型 SaaS 的後台」，好的規劃會告訴你：先要設計資料庫 schema、然後是身份驗證、然後是訂閱狀態機、然後是 webhook 接收、然後是後台介面，每一步要做什麼、預期會踩什麼坑、彼此的依賴關係是什麼。多位重度使用者跑下來的結論一致：Opus 4.7 在 extra-high 推理層級下，產出的計畫品質仍然勝過 GPT-5.5。

設計美感則是另一回事。NLW 自己跑了一個直接的對照測試：他請 GPT-5.5 幫 AI Daily Brief 重做媒體 Kit 的視覺，產出的版面比原本的還要差；但有趣的是，同一個任務，GPT-5.5 寫出來的贊助商提案文字反而比原本的更好。這個對照讓他意識到：設計品味跟文字能力是兩件不同的事，模型的「眼睛」還是 Opus 4.7 比較準。Every 雜誌的 Vibe Check 評測得到一致的結論。

這兩塊地為什麼 GPT-5.5 一時還拿不下？目前最可信的解釋是訓練資料的偏向。Anthropic 從 Claude 3 開始就特別在「設計感」、「品味」這類偏主觀的領域投入額外的後訓練資料；OpenAI 這次的 GPT-5.5 雖然能力全面提升，但這兩塊不是它的訓練重點。短期內這個差距不會被快速抹平，這也是雙模型工作流會延續好幾個月的結構性原因。

Siki Chen 的雙模型 SOP，與其他人的驗證

Siki Chen 提出的版本是最簡潔的：Opus 4.7 extra-high 規劃 + GPT-5.5 high 執行。但這套 SOP 真正的價值不在這句話本身，而在它被多位獨立使用者驗證之後變成業界共識。

Every 雜誌的 Vibe Check 是最有系統的一份。他們挑了三個典型專案：一個前端介面重構、一個 API 整合任務、一個資料分析腳本。每個專案都跑兩個流程：一個是純 Opus 4.7、一個是 Opus 規劃加 GPT-5.5 執行。結果三個專案中有兩個是雙模型版本明顯較好（前端介面重構、API 整合），一個是平手（資料分析）。最關鍵的觀察是：雙模型版本的「總時間」並沒有比純 Opus 多，因為規劃階段不長，但執行階段的速度跟可靠度差距很明顯。

NLW 自己的工作流則是另一個更貼近實戰的例子。他在 Codex 上跑一個 AIDB（AI Daily Brief 自家招聘平台）的後端，整個任務的規劃階段是丟給 Claude Code 配合 Opus 4.7：列出資料模型、辨識邊緣情況、設計 OpenAI 與 Anthropic 兩個模型互相辯論的候選人篩選邏輯。規劃確認之後，整份規劃文件丟進 Codex，由 GPT-5.5 一條條實作。這個流程他跑下來，發現 GPT-5.5 在「按表操課」這件事上比 Opus 穩得多，比較不會半路自己加新功能。

對企業裡負責 AI 工具採購的人，這個訊號很清楚：兩家的訂閱接下來都得簽，不能單押其中一家。對個人開發者，建議是：建立兩個分開的工作環境，一個是 Claude Code 配 Opus 用來想，一個是 Codex 配 GPT-5.5 用來做。這個切分本身會逼著你在動手前先想清楚。

「模型 + 鷹架」時代：為什麼單模型評測越來越不可靠

雙模型工作流帶出一個更大的觀察。NLW 在實測完之後丟出一句被反覆引用的話：「我們現在正式進入一個時代，你做的任何事都是模型加鷹架（harness）的組合。所以對我來說，知道 GPT-5.5 能多好地利用一個 Skill，比知道它原生能做什麼更實用。」

這句話的脈絡是：當代沒有人是直接拿模型的原生輸出在用。Codex 的 Skills 系統（OpenAI 的外掛機制）、Claude Code 的工具鏈、公司內部自建的提示模板，這些都是「鷹架」。模型在這套外殼裡的表現，跟它在裸 API 上的表現可能差到一個量級。NLW 自己跑前端時就有體感：原生的 GPT-5.5 設計力中等，但加上 Codex 的 Skill 之後，產出的介面品質明顯往上跳一階。

另一個值得注意的新模式叫「Monothread」。傳統用法是把不同主題切成不同對話：策略一個、寫作一個、產品一個。但 GPT-5.5 在 Codex 裡的脈絡壓縮（compaction）能力大幅提升之後，有人開始反向操作，用一條永遠不關閉的對話串持續迭代所有大方向工作。這條對話會記住你過去所有的脈絡，可以隨時拉回來繼續推。NLW 自己的計畫是先讓 Codex 採訪他一遍，建立一份個人加事業的脈絡基底，再以此為起點開始 Monothread 流程。

把模型加鷹架放在一起看，「分工」這件事的意義就更清楚：你選的不是模型，而是模型加上鷹架加上工作流的組合。Opus 4.7 加 Claude Code 加 extended thinking 加深度規劃流程，是一個組合。GPT-5.5 加 Codex 加 Skills 加 Monothread，是另一個組合。兩個組合分頭跑，比硬要單押其中一個都好。

結語：選工具不再是站隊

GPT-5.5 上市最大的一個訊號，不是「OpenAI 又重回王者」這種敘事，而是 AI 工具市場的成熟度終於追上了使用者的成熟度。多模型工作流變成務實選擇，「站隊」變成過時觀念。

對個人開發者，眼前可以做的具體動作有三：第一，把 Opus 4.7 配 Claude Code 留在規劃流程裡；第二，把 Codex 配 GPT-5.5 拉進執行流程；第三，開始實驗 Monothread 模式，看自己的工作型態適不適合一條長線串到底。對企業而言，採購決策必須包含整個工作流評估，不只是模型本身。OpenAI 總裁 Greg Brockman 對記者說 GPT-5.5「不是終點，是起點」這句話如果是真的，下半年的工作流還會再洗一輪。