Fable 5 實測：/goal 並非萬靈丹
這次測試要解的是 KIRO 光纖網路設計：把 Grenoble、Nice、Paris 的節點排成冗餘迴路與短分支，在符合結構限制下壓低總纜線長度。作者用 30 分鐘預算比較 Claude Fable 5 與 GPT-5.6 Sol，並分成一般模式及原生 /goal 模式。結果 Fable 5 拿到最佳有效解 31,934，也展現較穩定的輸出；但 /goal 並不是單純讓模型「更努力」，而是延長控制迴圈，可能持續改進好策略，也可能把錯誤方向做得更深。
現實應用
這類能力適合網路佈建、物流路線、排程、設施選址等難以暴力窮舉的最佳化問題。企業內的 operations research 團隊、顧問與需要快速製作 solver 原型的工程師都用得上。不過這次測的是完整系統，包括模型、CLI、提示詞、執行環境與驗證框架，不能直接當成通用模型排行榜。
期望評估
我認為低標期望是：模型能在固定時間內產出可執行、通過驗證的啟發式解法，並留下可供人類工程師繼續調整的 solver。三組配對中，Fable 5 的一般模式平均 32,386，明顯優於 Sol 的 34,261，而且波動較小。
我猜高標期望是讓模型自動組合多種演算法、平行搜尋並持續淘汰差策略，成為最佳化團隊的探索助手。但 /goal 六次贏四次，兩款模型的平均分卻分別惡化 759、868，代表長時間自主運行仍需要停損、檢查點與外部評估器，不能只看勝率。
商業策略分析
我認為受影響最大的會是最佳化軟體商、技術顧問與雲端算力平台。模型若能快速逼近專家花數天建立的基準，商業價值在於縮短方案探索與原型時間，而不是立即取代專業求解器。
值得跟進的是「控制迴圈品質」：Claude Code 的 /goal 由獨立 evaluator 依對話判斷是否完成；Codex 則保存 goal 狀態，讓工作模型透過 lifecycle tools 管理完成與續跑。兩者都各有盲點。我會優先投資可驗證指標、資源上限與策略切換，而不是把 persistence 當成預設開關。
實作細節
作者已在 CLIArena 公開題目、wrapper、分析腳本與圖表工具，可用 Harbor 0.1.43、Docker 與訂閱驗證重跑。原始大型 job 目錄未進 Git；且容器實際提供八顆 CPU，可能偏袒 Fable 的平行 portfolio。樣本也只有 Fable、Sol 各三組乾淨配對，結論仍需更多任務驗證。