AI 不只是模型變強，而是正在改寫我們與 AI 共事的方式

這幾週的 AI 圈，又出現了一種久違的資訊爆量感。

Claude 推出 Opus 5.5 後，社群很快出現大量測試與應用案例；另一邊，OpenAI 也在短時間內陸續推出 GPT-6 Astra、GPT-6 Sol／Luna，以及後續的 GPT-6.1 Sol／Luna。模型選單越拉越長，新功能也幾乎一波接著一波。

但如果只把這些更新拆成單一產品來看，很容易掉進另一個問題：每天都在比較哪個模型更強，卻反而更難看懂這些產品究竟想把 AI 帶往什麼方向。

在 OpenAI DevDay 2026 上，Sam Altman 用了「Renaissance（文藝復興）」這個詞來描述這一階段的 AI 發展。先不論這個說法是否過於宏大，我認為這次發布真正值得注意的，並不只是又多了幾個模型或功能，而是 OpenAI 正在試圖改變一件更根本的事：

我們把工作交給 AI 的方式，正在開始轉變。

從「叫一次、做一次」，走向能持續推進工作的 AI

過去我們熟悉的生成式 AI，大多還是一種單次任務工具。

你下一個提示，AI 完成一輪工作；如果後續資料有變、需求被修改，或你想繼續往下做，就得再次回到對話裡補充背景、重新交代內容、確認目前進度。

即使現在的模型已經能完成相當複雜的工作，人實際上仍經常扮演那個負責「一直顧著 AI」的角色。

例如整理客戶回饋，過去我們可能會直接說：「幫我整理這批回饋。」

AI 完成之後，這一輪任務基本上也就結束了。等到下週又出現新的客訴，我們仍然得重新整理資料，再執行一次。

但 OpenAI 這次想推動的，更接近另一種工作方式。

你交付的不再只是某一次性的任務，而是一個需要持續追蹤的工作目標，例如：

「幫我持續追蹤這個產品的客戶回饋，如果出現重複問題就整理出來，並準備改善方案讓我確認。」

兩者真正的差異，不只是提示詞變長。

更關鍵的是：連「什麼時候該再做一次」這件事，也開始能交由 AI 判斷。

Dots：連「追進度」都開始可以交給 AI

這也是這次 DevDay 中，Dots 最值得關注的地方之一。

OpenAI 將 Dots 定位成可以持續運作的 Agent。它有自己的雲端電腦，也能使用你授權連接的工具繼續處理工作。使用者不需要一直守在對話視窗前等待每一個步驟完成，而是可以先把一個專案或工作目標交出去，再回來查看進度、處理問題，或做最後決策。

這和我們現在使用 ChatGPT 最大的差異，在於人的角色正在逐步改變。

以前，我們比較像是在「操作 AI」：下一步該做什麼、什麼時候繼續、資料更新後要不要重跑，通常都由人負責推進。

如果持續運作的 Agent 真正成熟，人的工作就可能逐漸轉向：設定目標、調整方向，以及處理真正需要人類判斷的部分。

AI 則負責中間大量的追蹤、整理、執行與回報。

Space：AI 如果要長期參與工作，就需要一個共同空間

但當 AI 開始跨時間持續執行任務後，下一個問題很快就會浮現：

成果到底要放在哪裡？

這也是 ChatGPT Space 想處理的事情。

Space 不只是要解決「AI 幫我完成某一個步驟」，而是希望讓人、ChatGPT、Codex 與 Dot 可以在同一個空間裡，共享專案資料、目前成果與工作內容。

其中包含類似文件協作的 Page、簡報編輯的 Slides，以及試算表、圖表等不同工作形式。

乍看之下，這好像只是把更多辦公工具搬進 ChatGPT，但如果和持續運作的 Agent 一起看，意義就完全不同。

真正重要的問題會變成：

資料更新之後，原本的分析能不能同步更新？同事修改需求之後，AI 能不能直接接著處理？隔幾天再回來時，是否可以從目前的專案狀態繼續，而不用重新開一個對話、再次說明全部背景？

當這些環節被串接起來，AI 才有可能從「幫忙完成單一步驟的工具」，進一步變成「可以長期參與同一個專案的協作者」。

AI 開始持續工作之後，成本就變成不能忽略的問題

只是，一旦 AI 不再只是偶爾回答問題，而是開始持續讀文件、呼叫工具、操作電腦、修改程式、做判斷，另一個非常現實的問題就會立刻出現。

那就是成本。

這也讓 GPT-6.1 Sol 的定位更容易被理解。

如果只是偶爾問幾個問題，單次使用稍微貴一點，可能還沒有那麼明顯。但對 Agent 來說，一個任務背後往往包含很多輪模型判斷。

它需要讀取目前狀態、決定下一步、操作工具、檢查結果，再依據新的結果判斷是否繼續。

當每個專案都開始累積大量這類循環，「每一輪思考究竟要花多少」就會直接影響我們到底願不願意把更多工作交給 AI。

OpenAI 對 GPT-6.1 Sol 的定位，就是試圖在專業能力與成本之間重新取得平衡。官方主張它在程式開發、電腦操作與專業工作上的能力接近 Astra，但標準 API 的輸入、輸出成本只占 Astra 的一部分。

另一邊推出的 Ultrafast，則走向另一個方向：投入更多算力，換取更高的執行速度。

一邊壓低成本，一邊願意用成本換時間。

這其實也代表一件事：模型競爭已經越來越難只用「誰最強」來理解。

同一個模型，會因為速度、價格與任務型態不同，而呈現完全不同的使用價值。

Decisions API：不是每個步驟都需要動用最強模型

這種思路在 Decisions API 上又更加明顯。

很多 AI 系統真正需要的，其實不是每次都生成完整答案。

例如客服系統收到一封客訴之後，第一步可能只是判斷：「這是退款、產品故障，還是物流問題？」

此時真正需要的是一個可供系統使用的選擇，而不是一整篇文字說明。

Decisions API 讓開發者先定義問題與有限選項，再提供文字或圖片情境，由較低成本的 Luna 判斷應該選擇哪個結果，並直接交由後續程式使用。

這背後的設計邏輯其實很重要。

過去我們很容易把大型語言模型當成萬用工具，不管任務大小，都先請模型生成大量內容，再讓另一段程式從裡面抽出真正需要的答案。

但當 Agent 的工作流程越來越長，這種做法的浪費也會被放大。

有些步驟需要深度推理，有些只需要分類；有些值得用 Astra，有些可能 Luna 就已經足夠。

未來的 AI 工作流，需要的可能不是一個永遠使用最強模型的系統，而是一個知道「哪個環節該派誰上場」的系統。

Codex Cloud 與 Plugin：讓 AI 工作不再綁在眼前這台電腦

相同方向也能在 Codex Cloud 上看到。

過去使用 AI 開發時，即使模型本身已經很強，很多工作仍然綁定在使用者眼前的電腦與當下工作階段。Codex Cloud 則讓雲端任務擁有自己的工作空間，即使本機休眠，工作仍然可以持續執行，專案使用的工具與環境設定也能再次沿用。

之後，使用者再從網頁、手機或桌面裝置回來查看成果。

另一方面，Plugin 也開始從「替 ChatGPT 加上一項外部能力」，逐步走向「把外部的工作環境直接帶進 ChatGPT」。

透過 Plugin Extensions，開發者可以建立側邊欄入口、對話旁的互動面板，以及自己的檔案檢視與編輯介面。搭配 MCP Events，系統甚至能針對指定事件進行監控，並在事件發生後啟動對應工作。

如果把 Dots、Space、Codex Cloud、Plugin 與 MCP Events 放在一起看，就會比較清楚 OpenAI 想拼出的整體輪廓。

AI 有可以使用的工具、有能持續存在的資料、有共同修改成果的空間，也有離開使用者電腦之後仍能繼續工作的執行環境。

到了這一步，ChatGPT 就不再只是單純的「輸入問題、等待回答」介面。

模型越來越多，「找最強的」反而變得沒那麼實用

這個產品方向，也剛好能解釋為什麼最近模型選單開始變得如此複雜。

GPT-6 Astra、GPT-6 Sol、GPT-6.1 Sol、Luna，再加上 Claude Sonnet 5.5、Opus 5.5，每個模型都有不同能力、速度、額度與成本。

如果還是只問「哪個模型最強」，很快就會進入每推出一個新模型，排名就重新洗一次的循環。

所以我最近自己的選擇方式，反而越來越單純：

先看眼前到底要完成什麼工作，再決定要叫哪個模型。

以程式開發為例，我目前會優先考慮 GPT-6.1 Sol 來處理大量實作。

從我自己的使用經驗，以及近期看到的社群回饋來看，6.1 Sol 相較 6 Sol，在程式開發品質上有明顯改善，而且額度消耗也比較低。當工作需要長時間執行，或一次修改大量檔案時，這種差異會變得很實際。

代價則是速度。

目前針對 6.1 Sol 最常出現的抱怨之一，就是「慢」。尤其需要頻繁來回修改時，等待感會變得很強。

所以如果任務不急，我會更願意讓 6.1 Sol 慢慢完成；但如果情境要求快速實作、快速迭代，它可能就不是最合適的選項。

Astra 不一定要每次上場，但很適合拿來解卡關問題

那 GPT-6 Astra 還有沒有存在價值？

我認為有，只是它現在比較不像「所有工作都預設交給它」，而更像是一個在必要時才登場的高階救援角色。

例如遇到難解的 bug、其他模型反覆卡在同一個問題，或完成大型修改之後，希望再找另一個模型檢查一次成果，Astra 都會比較有使用理由。

但模型能力越強，也不代表每次修改就一定更精準。

目前也有一些使用回報提到，Astra 有時可能會做得太多、擴大原本的修改範圍，甚至在錯誤方向上持續深入。

再把額度問題考慮進去，我目前比較傾向把它放在第二線：

先讓 6.1 Sol 處理主要開發內容，真的遇到瓶頸，再把問題交給 Astra。

至少對每個月預算有限的 Plus 使用者來說，這種配置比較符合實際使用情境。

舊模型其實不需要因為新模型推出就馬上淘汰

這也是為什麼，我目前不會因為有新模型出現，就立刻把 GPT-5.6 Sol 從工作流程裡移除。

如果某些寫作、整理、文書工作，本來用 5.6 Sol 就已經可以穩定完成，那更換模型之後真正該問的，不是「它是不是更新」，而是：

它有沒有實際讓我少改幾輪？有沒有真的節省時間？

如果答案並不明顯，那原本穩定的工作流程，沒有必要為了追新而強制更換。

相較之下，GPT-6 Sol 目前的位置確實顯得比較尷尬。至少在我目前接觸到的 Codex 開發任務裡，除了速度以外，6.1 Sol 整體更符合我的使用需求。

如果真的非常在意速度，但又不希望額度快速消耗，我反而可能先回到已經熟悉的 5.6 Sol。

Claude 也再次回到第一線開發模型的競爭

另一邊，Claude 的 Opus 5.5 與 Sonnet 5.5，也讓現在的開發模型選擇變得更加有趣。

就目前蒐集到的回饋來看，我還不會直接認為 Opus 5.5 已經全面超過 GPT-6.1 Sol。比較像是兩邊都重新進入值得優先測試的第一線開發選項。

Opus 5.5 目前比較吸引我的地方，是困難程式開發、大型專案，以及需求沒有完全定義、需要模型自行判斷方向的工作。

Sonnet 5.5 則比較像日常開發型模型。當需求清楚、完成標準也明確時，可以先交給 Sonnet；如果任務逐漸變得模糊、複雜，再考慮切換到 Opus。

所以如果現在真的只想先知道「我到底該開誰」，我的暫時選法會是：

• 大量程式實作：先試 GPT-6.1 Sol
• 難解 bug、反覆卡關、檢查成果：GPT-6 Astra
• 想跨模型比較複雜開發成果：可以加入 Claude Opus 5.5
• Claude 日常開發、需求清楚：先試 Sonnet 5.5
• 原本 GPT-5.6 Sol 就能穩定完成的工作：暫時維持原流程

這不是一份模型排名，而只是一個「先從誰開始測」的參考。

下一階段真正重要的，可能不再只是「哪個模型最強」

如果把 DevDay 的產品更新和這一輪模型競爭放在一起看，我認為背後其實指向同一個方向。

以前我們使用 AI，最常問的是：

「哪個模型最強？」

但當 AI 開始轉向長時間執行任務的 Agent，這個問題的重要性可能會慢慢下降。

未來更實際的問題，很可能變成：

這個工作應該交給哪個模型？哪一段需要深度推理？哪些判斷其實可以交給便宜模型？什麼情況值得用更多算力換速度？什麼時候應該讓 AI 自己持續追蹤，而不是由人一直回來補提示？

也就是說，模型能力依然重要，但「怎麼配置模型、工具與整個工作流程」的重要性也會越來越高。

這或許才是我認為這次 OpenAI 所謂「文藝復興」真正值得觀察的地方。

它想改變的不只是 AI 可以做什麼，而是我們究竟要怎麼和 AI 一起工作。

AI 不再只是被叫來「完成一件事」的工具，而正在往一個可以被交付一連串任務、持續參與同一個專案的協作者發展。

只是這條路，目前依然建立在大量算力、訂閱費與 API 成本之上。

所以像我這種每個月只有 20 美元預算的玩沙小朋友，現階段大概還是先蹲在旁邊，看著這些高級 Agent 努力上班。

等哪天成本真的降下來、功能逐漸普及，再看看有沒有機會摸到一點邊邊角角吧。🤡