010. 導讀｜這不是「又一個模型跑分」，而是長任務交付能力展示
這篇導讀整理自 AI超元域的 YouTube 影片 Claude Opus 5 深度實測。影片主軸很單純：Anthropic 新釋出的 Claude Opus 5，能不能在更複雜的編程任務裡，接近甚至取代更高階的 Claude Fable 5？
背景上，Anthropic 官方在 2026 年 7 月 24 日發布 Claude Opus 5，官方新聞稿稱它強化了 coding、professional work 與 long-running agents，並維持與 Opus 4.8 相同的 API 定價：每百萬 input token 5 美元、每百萬 output token 25 美元。官方 system card 也把知識截止標成 2026 年 5 月。影片中的「價格與 Opus 4.8 持平」「知識截止是 2026 年 5 月」這兩點，和官方資料相符。
但影片真正值得看的是另一件事：講者不是只丟幾個簡短 LeetCode 題，而是把 Opus 5 放進一串「可視覺化、可互動、可運行」的任務裡。從一張室內平面圖生成可探索的 3D 住宅，到模擬黑洞、科幻飛船、SVG 動畫，再到 Claude Code 裡用 Godot 做沙盒遊戲、用原生 Android 技術棧做背單詞 App。這些任務測的不是單次答案漂亮不漂亮，而是模型能不能把規格翻成一個能跑、能點、能測的東西。
這裡要先保留編輯距離。影片展示的 demo 很強，但它不是可重現 benchmark，也沒有公開完整 prompt、程式碼、硬體環境、迭代次數與失敗樣本。因此本文會把這些結果寫成「講者展示」「影片中可看到」，而不是把它們當成魚塘自行驗證的普遍結論。真正可以拿走的，不是「Opus 5 一定超越 Fable 5」，而是：模型競爭正在從回答能力，轉向多模態理解、長任務執行、工具操作與自動測試的組合能力。
021. 視覺到 3D｜從平面圖生成可探索住宅，測的是空間理解和工程落地
影片第一個主測試，是把一張兩層樓的室內平面圖丟給 Claude Opus 5，要求它用 Three.js 做出真實、完整、可探索的 3D 住宅。講者的提示詞要求支援第一人稱視角，也支援俯視檢視，讓使用者可以在房屋裡移動、進出房間、看家具和空間配置。
這個測試有意思，因為它同時考三件事。第一是視覺理解：模型要從平面圖裡讀出房間、樓梯、窗戶、陽台與相對位置。第二是空間建模：不是把圖複製成 2D，而是把它轉成有高度、有牆、有通道的 3D 場景。第三是互動工程：使用者可以用滑鼠移動視角、雙擊進房間、切換視角，代表輸出不是靜態展示圖，而是可以操作的網頁專案。
影片中展示的結果確實完整：客廳、餐廳、廚房、浴室、臥室、書房、儲物空間、樓梯與陽台都被放進場景裡，還有家具、地板、窗外視野與光影效果。講者一路用第一人稱走進不同房間，再切到俯視角檢查整體結構，整體效果像簡化版的室內漫遊工具。
這種任務對 coding agent 的意義，比「能不能寫 Three.js」更大。過去模型常見問題是：能寫局部元件，卻不能把空間、互動、視角、效能與使用者操作整合成一個有體驗的原型。Opus 5 在影片裡呈現的是更接近「把設計材料變成交互 demo」的能力。
不過這也是最需要警覺的地方。視覺輸入轉 3D 很容易讓人被 demo 震到，但真正進產品時，還要看尺寸精度、無障礙動線、碰撞判定、設備相容、效能、材質授權與模型是否亂補細節。影片裡的結果可以說是很強的概念原型，但不能直接等同建築、室內設計或工程級重建。
032. 科幻場景與 SVG｜模型開始能把「物理感」做成可調參數的畫面
接著影片把難度拉高：先讓 Opus 5 生成接近《星際效應》觀感的黑洞模型，再讓它根據科幻小說《極光》還原極光號宇宙飛船，之後又拿一張旋轉重力飛船影像讓模型轉成可探索場景。
黑洞 demo 裡，講者展示了吸積盤、滑鼠拖動、右側參數調節等互動。這代表任務不只是「畫一個黑洞」，而是把視覺效果抽象成可調參數。飛船 demo 則更像世界觀建模：外部有推進、罐體、磁場裝置與旋轉艙室，內部可以進入不同艙室，看到草地、樹木、控制中心、螢幕與舷窗外星空。
這一組測試比較像在問：模型能不能把抽象文字、參考影像與科幻設定，整理成一個可互動的場景系統？如果只看程式語法，這不是最難的地方；真正困難的是模型要判斷哪些細節值得建模、哪些可以簡化，並讓使用者覺得這個世界是連貫的。
影片也穿插幾個 SVG/動畫測試。包含用鉛筆畫燈泡、三個角色在土星軌道上騎腳踏車比賽、複合弓拉弓射箭瞬間、農夫過河步驟動畫，以及 F-35 風洞效果。這些 demo 不是傳統 coding 題，而是把視覺敘事、動作分解與簡化物理效果混在一起。
這裡可看到新一代 coding model 的一個變化：它們不只在「寫出對的函式」，也開始在「做出可感知的互動結果」。對前端、遊戲、資料視覺化與教育內容來說，這很重要。很多產品雛形的價值，不在後端邏輯多複雜，而在使用者能不能立刻看懂、點到、感受到。Opus 5 在影片裡的強項，正是把 prompt 轉成可觀察介面的能力。
043. Claude Code + Godot｜一小時遊戲原型測的是長任務續航
影片後半進入 Claude Code。講者把模型切到 Claude Opus 5，第一個任務是使用 Godot 遊戲引擎做一款模仿 Minecraft 的第一人稱沙盒遊戲，背景設定在侏羅紀世界。提示詞要求世界裡有恐龍、飛行翼龍、手持加特林、可投擲手雷，也提供操作方式。講者表示，為避免平台誤判，他把中文提示詞翻成英文後送進 Claude Code。
這段最重要的數字不是模型跑分，而是「大概一小時左右」。一小時對 coding agent 來說是很長的任務窗。短任務裡，模型只要生成幾個檔案；長任務裡，它要規劃架構、建立專案、補資源、修錯、跑測、再回到使用體驗。影片中講者略過中間過程，直接展示完成品，所以我們不能判斷它修了幾次、遇到哪些錯。但從結果看，這是一個能實際遊玩的 Godot 原型。
demo 裡可以看到第一人稱視角、方塊化地形、恐龍與翼龍、射擊、投擲、爆炸、水下探索、魚、天氣變化、晝夜循環、雪地、冰原與持續生成地形。講者特別比較先前 Kimi K3 的測試，表示 Opus 5 做出的地圖可以持續探索，向前飛行時會繼續生成新的元素。
這個案例對工作流的啟發是：coding agent 的價值會在「能不能持續把任務做完」上放大。遊戲開發牽涉輸入控制、場景生成、資源組織、物理、UI、效能與測試。任何一個小地方失敗，都可能讓 demo 跑不起來。模型若能把多個系統黏成可玩的雛形，就表示它已經不只是 code completion，而更像一個原型工程師。
當然，遊戲 demo 也最容易高估。可玩原型和可維護遊戲之間差很遠。真正要進 production，還要檢查資源管理、架構邊界、性能、碰撞、狀態同步、可測性、平台打包與版權風險。影片證明的是 Opus 5 在長任務原型上很有潛力，不是證明它能一次生出可商用遊戲。
054. Android App｜真正關鍵是「邊開發邊自測」
最後一個重點測試，是原生 Android 背單詞 App。講者表示，這次他把以前用於 React 專案的背單詞提示詞，改成 Android 原生技術棧，要求 Opus 5 在 Claude Code 裡完成。影片中可看到 Claude Code 自動打開模擬器，啟動 App，滑動單詞卡片、點擊卡片，並進行操作測試。講者最後在 Android Studio 打開專案，展示亮色/暗色主題、開始學習、翻卡、收藏、練習測驗、答對答錯提示、進度、成就徽章與設定頁。
這段最值得看的是「開發加測試 26 分鐘 10 秒」。如果只生成 Android 專案，模型可能只是把 UI 檔案堆出來；但能自動開模擬器、操作 App、檢查流程，代表工作流往前走了一步：代理不只交 code，還要自己跑一遍。
對實務工程來說，這比單純「會寫 Kotlin」更重要。很多 AI 產出的 App 乍看完整，但一跑就 crash，或者某個按鈕沒接、狀態不保存、畫面在小螢幕爆版。讓 agent 在交付前用模擬器自測，能把一部分低階錯誤擋掉。這也是 Claude Code 這類工具真正的優勢：它不只調用模型，也能連動 shell、檔案系統、建置工具、模擬器與瀏覽器。
但 Android demo 也提醒另一個限制：因為講者把提示詞翻成英文，App UI 也被做成英文。這不是大問題，後續可以要求改成中文；但它說明模型會忠實延續 prompt 語言與上下文。想讓代理做出符合目標市場的產品，不能只丟功能清單，還要指定語言、文案、字體、平台慣例與地區用語。
所以這段的操作建議很清楚：如果要讓 coding agent 做 mobile app，不要只說「做一個 App」。請把測試標準也寫進 prompt：建置要過、模擬器要啟動、主要 user journey 要走完、每個畫面要截圖或列出結果、錯誤要修到能重跑。把驗收標準放進任務本身，模型才會把「能跑」當成交付的一部分。
065. 編輯判讀｜Opus 5 的亮點，是把多模態輸入變成可驗證輸出
如果把整支影片濃縮成一句話，我會說：Claude Opus 5 的亮點不只是會寫 code，而是能把多模態輸入、長提示詞、工具環境與互動測試，串成比較完整的交付流程。
這和傳統模型比較很不一樣。以前我們常問模型「哪個 benchmark 高」。但對 coding agent 來說，benchmark 只是底層能力的一部分。真正日常工作裡，你更在乎它能不能理解模糊需求、把需求拆成專案、遇到錯誤自己修、做出可互動結果，最後還能用瀏覽器或模擬器跑一遍。
影片裡的幾組任務剛好覆蓋這些面向。平面圖到 3D 住宅測視覺理解與場景建模；黑洞與飛船測抽象概念到互動畫面的轉換；SVG 測精細動畫與物理感；Godot 測長任務與遊戲系統整合；Android 測原生平台與自動化驗收。這些任務放在一起，比單一 coding 題更接近「AI 工程助理」會面對的工作。
不過，這種 demo 也有一個共同陷阱：越精彩，越需要問可重現性。影片沒有提供所有失敗樣本，也沒有展示完整中間過程。模型是不是一次成功？是否有人工修 prompt？生成的程式碼品質如何？專案結構能不能維護？是否有測試、型別、效能與安全檢查？這些都還需要另外驗證。
因此，比較成熟的結論不是「Opus 5 已經可以全面取代工程師」，也不是「Fable 5 從此不需要」。更合理的分工是：Opus 5 很適合高互動、高視覺、高原型密度的任務，尤其是需要長時間在 Claude Code 裡把 demo 跑出來的工作；而高風險架構決策、產品策略、資安邊界與 production review，仍然需要人類或更嚴格的多模型檢查來接住。
076. 給魚塘讀者的使用建議｜把 demo 變成自己的 agent 驗收表
這支影片最值得借的，不是照抄題目，而是把它變成自己的 coding agent 驗收表。
第一，要求「可運行」，不要只要求「寫完」。如果是前端，就要能開本機頁面；如果是遊戲，就要能啟動並操作；如果是 Android，就要能跑模擬器；如果是資料視覺化，就要有真資料或可檢查的 mock data。只有能跑，才有驗收。
第二，要求「可觀察」。像影片裡的 3D 住宅、黑洞、飛船、Godot 遊戲和 Android App，都能被人直接看見與操作。這讓模型輸出不只是一堆檔案，而是一個可以討論的介面。越可觀察，越容易發現模型亂補、漏接、跑偏或只做表面功夫。
第三，要求「自測」。Android 例子裡最關鍵的不是 App 有幾個畫面，而是 Claude Code 會自己開模擬器測流程。這件事應該變成 prompt 裡的固定條件：完成後請啟動、操作主要流程、修正錯誤，最後回報你實際驗證了什麼。
第四，保留「編輯距離」。影片裡的結論很鼓舞，但不要把單支影片的 demo 當成自己的專案保證。把 Opus 5 當成強力原型工具很合理，把它當成不需 review 的 production 工程師就太快了。越能生成完整專案的模型，越需要 branch、測試、權限邊界與人工 code review。
最後，如果 Claude Opus 5 的價格確實維持在 Opus 4.8 等級，而能力接近 Fable 5，那它對日常開發者最大的意義可能不是「最強」，而是「高階 coding agent 變得更常用」。當強模型的邊際成本下降，團隊會更願意把它放進長任務、原型、測試與 review 流程。真正的競爭點，也會從「我問它一句話」變成「我能不能設計一套讓它穩定交付的工作系統」。