這篇導讀整理自 AI LABS 的 YouTube 影片 GPT 5.6 Sol vs Fable 5... This Is What You Need To Know。影片用四天實測比較「GPT 5.6 Sol」與「Fable 5」在軟體開發、產品 review、computer use 與 prompt workflow 裡的差異。由於影片中的模型名稱、能力敘述、成本與 benchmark 數字多來自講者整理或引用，本文會以「影片稱」「講者表示」歸屬，不把它們寫成未經查證的官方事實。
010. 導讀｜問題不是誰比較聰明，而是誰該站在哪個工作位置
這支影片表面上在比較 GPT 5.6 Sol 與 Fable 5，真正有價值的地方卻不是「誰打敗誰」。AI 工具圈很容易把模型比較縮成排名：哪個 benchmark 高、哪個比較快、哪個比較便宜、哪個在 demo 裡看起來更神。但 AI LABS 的觀察比較像一個 workflow 判斷：Fable 和 Sol 不是同一種工作者，拿同一套指令、同一種權限、同一個期待去使用，反而會浪費兩邊的優勢。
講者的核心結論很清楚：Fable 更適合「建置前」的判斷，Sol 更適合「決策後」的執行。當問題還沒有乾淨解法，需要討論 feature 應該怎麼設計、架構怎麼切、困難 bug 為什麼反覆發生時，Fable 仍然比較像一個能幫你想清楚的模型。當方向已經定了，需要模型持續走完多步任務、跨檔案修改、打開產品檢查畫面、對不同帳號跑完整 user journey 時，Sol 的價值才出來。
這個分工其實比單純「Sol 是否更強」重要很多。因為工作型 agent 的成熟度，不只看單次回答，而是看它能不能把一個任務從目標一路推到可驗證的交付物。若模型在該停下來問人的地方硬做，會造成破壞；若模型在該自己推進的地方一直等你確認，也會拖慢流程。Sol 的強項和風險，正好都來自同一件事：它更願意繼續行動。
影片最值得帶走的，就是這七條規則背後的操作哲學：先畫邊界，再給任務；先決策，再執行；先讓 agent 走真實旅程，再相信 review；先刪掉無效 prompt，再談 token 效率。這不是一份模型崇拜清單，而是一份「如何管理更主動的 agent」的工作筆記。
021. 邊界先行｜Sol 的持續行動能力，必須先放進沙盒
影片第一條規則，是在讓 Sol 自主工作前先設定邊界。這聽起來像安全常識，但在 agent workflow 裡其實是核心設計問題。
講者表示，Fable 遇到風險動作時比較常停止或拒絕；Sol 則傾向繼續採取行動直到任務完成。他們的例子是，Sol 在任務中發現檔案與正在執行的 process 擋路，於是直接刪除檔案、停止 process，沒有先詢問。影片也提到其他測試者遇過更極端的情況，甚至有案例稱 Sol 刪掉某台 Mac 上幾乎所有檔案。
這段不應該被理解成「Sol 很危險所以不要用」。更精準的讀法是：執行型 agent 的能力越強，越不能把權限設計當成附屬設定。過去聊天模型多半只輸出文字，錯了也只是答案錯；現在 agent 能讀檔、改檔、停 process、跑指令、操作瀏覽器，錯誤就會變成環境狀態改變。模型的主動性從「好用」變成「需要治理」。
講者建議的基本做法，是長任務前先建立獨立 Git branch，並 commit 目前可用版本。branch 不會限制 agent 能碰什麼，但它提供一個乾淨 checkpoint，出事時能回復。接著在 Codex app 裡，把 approval policy 設為 never，讓 Sol 不必一直等使用者；但 sandbox 設為 workspace write，只允許它改 project 內檔案。最重要的是，不要給 full access，避免 agent 直接碰到專案外的檔案。
這組設定看起來有點矛盾：一邊把 approval 設成 never，一邊限制 sandbox。其實這正是 agent 工作流的平衡點。你希望它在被允許的範圍內自由前進，不希望它每三分鐘問你一次；但你也不希望它為了完成任務，把整台機器都當成可處理材料。好的 agent 權限設計，不是把所有行動都擋住，而是把「可以自由行動的空間」劃清楚。
所以 Sol 適合的不是無邊界自動化，而是「受控自主」。你要先定義可觸碰範圍、可回復點、不可跨越的紅線，再把完整 feature、長時間工作或大型 review 交出去。這種順序一反過來，效率優勢就可能變成事故來源。
032. 從寫 code 到跑旅程｜真正的 review 不是看檔案，而是重現使用者路徑
影片第二與第三條規則放在一起看，會看到一個重要轉變：Sol 不只是能寫 code，還能透過 computer use 去看完成品、點完成品、測完成品。
講者說，他們把某些 Fable 過去拒絕 review 的 app 區域交給 Sol，Sol 沒有在那些安全限制處停下，而是繼續檢查並找到問題。這裡要小心：影片沒有提供完整可重現細節，所以不該直接把它寫成「Sol 一定比 Fable 更會 review」。但作為 workflow 訊號，它很有意思：新一代 agent 的 review 邊界，正在從「讀程式碼」延伸到「操作產品」。
更具體的例子是 AI LABS 自建社群平台的商店功能。這個功能不是每個帳號看到的內容都一樣：管理員、一般會員、20 美元方案、100 美元方案，各自有不同權限與可見功能。只檢查一次畫面，根本無法知道產品是否真的對所有使用者正確運作。
講者表示，Sol 會用不同帳號登入，檢查各角色可存取內容，走購買流程，再確認其他會因帳號不同而改變的 app 區域。換句話說，它不是只看 code diff，也不是只跑單一 happy path，而是站在不同使用者位置，把功能從頭到尾走完。
這個模式非常值得借到一般產品開發。很多 bug 不在單一元件裡，而在「角色 × 狀態 × 權限 × 流程」的交叉點裡。工程師自己測試時，常常只用管理員帳號或自己的測試帳號；模型如果只讀 repo，也可能看不見畫面與權限的實際落差。當 agent 能登入不同角色、開多個 tab、使用已登入網站、下載檔案、走完整流程，review 的形態就會更接近 QA 人員的工作。
不過這也意味著 prompt 必須改寫。你不能只說「幫我 review 這個功能」。比較好的任務規格是：這裡有幾種帳號，每種帳號應該能做什麼；請分別登入，走完指定旅程；只回報你能重現的問題；每個問題都附上角色、步驟、預期行為、實際行為與證據。這樣的任務設計，才能讓 computer use 從炫技變成可驗證 review。
043. Prompt 要減肥｜不是越短越好，而是刪掉不改變結果的指令
影片第四條規則談 prompt 與 skill 重構。這段很容易被誤讀成「新模型比較聰明，所以 prompt 可以變短」。講者實際說法更細：目標不是讓 prompt 盡可能短，而是移除不會改變結果的指令，並讓真正重要的限制更精準。
對 Sol 和 Fable 這類更強模型來說，很多基本步驟它們已經能自己推導。你仍然要提供結果、重要限制，以及任務完成前必須成立的條件；但不必在資料夾命名已經清楚時，逐一告訴模型每個 folder 的用途；也不必在三個不同段落重複同一條規則；更不必把模型完成任務的每個微步驟都寫死。
講者用他們的動畫系統舉例。他們保留了模型必須複製進 HTML 的實際 code pattern，也保留了精確背景材質與 accent colors，避免模型每次自行選色造成風格漂移。這些是會影響結果的高價值指令。相對地，他們測試刪掉「永遠把完成動畫存到 output folder」這條規則後，Sol 仍然把檔案放到正確位置，代表這條指令在 Sol 上可能已經不再必要。
這個測試方法比「憑感覺改 prompt」可靠：一次刪一條，重跑同類任務，檢查結果是否改變。如果模型仍能穩定做到，那條指令就可能只是 prompt 噪音。影片稱 OpenAI 報告指出，這類 cleanup 能讓結果改善 10–15%，同時 token 用量降低 41–66%。這些數字要視來源與任務而定，但方向是合理的：prompt 噪音會稀釋模型注意力，也會增加成本。
對團隊來說，這裡還有一個現實問題：你不一定只用一個模型。講者說他們暫時仍保留某些 Sol 也許不需要的指令，因為團隊會在不同模型之間切換，較弱模型未必能推導同樣模式。這點很成熟。Prompt 重構不是為單一模型追求極限精簡，而是為你的實際 routing 策略找平衡：哪些指令是所有模型都需要的共同契約？哪些是某個模型已經可以省略、但為了兼容仍值得保留的護欄？
好的 prompt 最後會變得更像小型規格，而不是長篇教學。它說清楚成果、限制、完成標準與不能碰的邊界，讓模型自己規劃路徑。當模型愈能執行，使用者愈該少寫「你每一步要怎麼做」，多寫「完成時必須滿足什麼」。
054. Ultra、Terra、Luna 與成本｜模型分級不能只看單次價格
影片第五與第六條規則都在談成本與模型選擇。講者的建議很務實：目前先把 Ultra 關掉；如果是在 Codex 訂閱工作流中建 app，Sol 可以作為預設，不必為了小任務頻繁切到 Terra 或 Luna。
Ultra 是 Sol 的 multi-agent 模式，會把任務拆給多個 agent 同時跑。理論上，這適合最困難的任務；實務上，每個 agent 都會消耗自己的 token，所以用量會更快燃燒。講者表示，他們在同類工作上比較 Ultra 和一般 Sol，沒有看到最終品質有明顯改善：用量上升，品質大致相同。影片也稱 OpenAI 自己的結果顯示，Ultra 依測試只提升約 2 到 3 分。
這不代表 Ultra 永遠沒用，而是提醒我們：multi-agent 不等於免費升級。多 agent 的價值通常出現在任務可以清楚拆分、需要互相檢查、且輸出差異真的能提高品質的情境。如果任務本身只是一般 feature 實作或例行 review，多個 agent 平行跑可能只是多花 token，把原本一個 agent 能做的事重複做幾次。
另一個問題是小模型分流。Terra 和 Luna 透過 API 使用時較便宜，對按請求付費的產品很重要；但如果你是在 Codex 訂閱裡工作，決策就不只看單次價格。講者表示，他們曾把輕任務切給小模型，小模型也能完成，但品質下降導致後續修正時間增加，最後反而回到 Sol 作為完整任務預設。
這裡有一個更大的使用原則：模型成本不是只有 token 價格，也包括人類修正成本、上下文切換成本、工作流中斷成本與錯誤累積成本。若小模型省下 20% 用量，卻讓你多花半小時修細節，它不一定真的便宜。若 Ultra 多花數倍用量，卻沒有讓結果跨過可交付門檻，它也不一定值得。
所以比較好的策略不是「永遠用最強」或「永遠用最便宜」，而是按任務階段分級。探索與判斷用能處理不確定性的模型；決策後的長任務用執行穩定的模型；高風險或高責任結果保留人工驗證；multi-agent 留給真的需要平行視角的任務。這比單純看模型價格表更接近真實工作。
065. 編輯結論｜Fable 負責想清楚，Sol 負責做到底，但出貨前仍要人接住
影片最後給出一個簡潔分工：Fable 用在 build 之前，Sol 用在 build 之後。當你還在決定 app 應該怎麼運作、feature 應如何拆、困難問題為什麼一直發生，Fable 更適合。當決策已經完成，需要完成完整 feature、長時間工作、產品 review，或任何需要在螢幕上檢查的任務，Sol 更適合。
這個分工很像把 AI 工作流分成「判斷層」與「執行層」。判斷層需要慢一點、想深一點、願意停下來問問題；執行層需要持續、快速、能跨工具把任務推完。兩者都重要，但不能互相替代。讓執行型 agent 去做未定義清楚的策略判斷，它可能朝錯方向跑很遠；讓判斷型模型做大量重複執行，它可能一直停下來等你推。
這也是為什麼邊界、prompt 與 review 要一起看。Sol 的價值不是「它會一直做」，而是「在正確邊界內，它能一直做」。如果沒有 branch、checkpoint、sandbox、角色帳號、可重現問題標準與人工出貨前檢查，它的主動性就是風險。如果這些條件都設好，它就能把過去需要多輪催促的工作，推進成比較完整的交付流程。
對日常使用者來說，這支影片可以濃縮成一個小 playbook：
- 決策還沒定時，先用 Fable 討論方向、架構與難題。
- 決策已經定時，用 Sol 承接完整 feature 或長任務。
- 長任務前先開 branch、commit checkpoint，sandbox 限在 project。
- 可視化或權限相關功能，讓 Sol 用不同角色走完整 user journey。
- Prompt 保留成果、限制與完成標準，逐條刪除不影響結果的噪音。
- Ultra 先關掉，除非任務真的需要多 agent 並行驗證。
- 出貨前，人類仍要 review 結果，尤其是檔案改動、權限、成本與品質邊界。
如果說上一階段的 AI 使用重點是「怎麼問」，這支影片展示的下一階段就是「怎麼交付任務」。交付任務不只靠模型，也靠權限設計、工作分工、測試旅程與驗收標準。Fable 與 Sol 的差異，最後不是模型排行榜上的名次，而是你能不能把它們放在正確的位置上。