禁掉所有工具後，Opus 5和GPT-5.6的差距終於藏不住了

Claude Opus 5 發布之後，AI 圈最熱的話題除了性能數字，還有一件讓許多人特別在意的事：Anthropic 在提示詞（Prompt）上的大幅改進。AI 投資人瑪特·夏默（Matt Shumer）在 X 平台上發布的一段影片引發了超過 400 萬次觀看，他僅僅用三段話作為提示詞，就讓 Opus 5 用 Three.js 寫出了一個可以實際遊玩的 3D 第一人稱射擊遊戲。這個專案總共包含 5.5 萬行代碼，拆成 11 個子系統，全程沒有使用任何外部素材，所有內容都是模型從零生成的。Anthropic 的工程師、同時也是 Claude Code 核心開發者的鮑里斯·切爾尼（Boris Cherny）也透露，他們把 Claude Code 系統提示詞裡 80% 的內容直接砍掉，結果模型不但沒有變笨，表現反而更強了。過去需要手把手逐步引導的任務，現在已經不需要了。 這兩件事指向同一個結論：Opus 5 不再需要使用者精心設計複雜的提示詞。只要給它一個簡短的指令，它就能自己把工作完成。長久以來被當作一門「工程手藝」的系統提示詞撰寫技巧，突然之間變得不再那麼重要。這也讓人不禁好奇，如果刻意用最簡短、最模糊的指令，甚至帶著某種程度的「考驗」心態去測試它，Opus 5 究竟能不能自己發現問題、解決問題？為了找出答案，有人實際進行了兩項對比測試，把 Opus 5 拿來和 GPT-5.6 Sol 放在一起較量。 第一道題目是一段購物車程式碼，總共五個檔案，包含一份需求文檔、三個業務模組（購物車、優惠券、運費）和一個測試腳本。功能本身很單純：加商品、用優惠券、算運費、出總價。但程式碼裡被刻意埋入了六個 bug，每一個都會導致用戶的帳單金額算錯。測試時給出的提示詞只有一句話：「項目名是 buggy-shopping-cart，我應該如何優化呢？」刻意不告訴模型程式碼裡有問題，想看它能不能自己把雷挖出來，而不是等使用者回報。 這六個 bug 分別是：滿 100 減 20 的優惠券，程式碼寫的是「大於 100 才減」，但需求文件規定「達到 100 就減」，一個大於號和大於等於號的差異，讓剛好買滿 100 塊錢的用戶無法使用優惠；打八折時，99.99 乘以 0.8 等於 79.992，程式碼只在最後一步做四捨五入，但中間這個 79.992 會參與後續所有計算，導致滿減判斷和包郵判斷全被污染；滿減券的門檻應該看商品原價，但程式碼看的是打折後的價格，120 塊錢的商品打完八折是 96 塊，滿減券就無法使用，但按照規則原價 120 本來就夠格；同類型優惠券可以疊加，規則明明規定每種類型只能用一張，但程式碼的迴圈把所有券全部用上，兩張滿減券一起扣，商家直接虧損；優惠完之後沒有下限保護，10 塊錢的商品用一張 50 塊的券，算出來是負 40，加上運費總帳單變成負 30，用戶買東西反而倒賺；最後一個 bug 與第一個 bug 互相掩蓋，包郵門檻應該看原價，但程式碼看的是優惠後的價格，因為第一個 bug 導致滿減券沒生效，優惠後的價格還停在 100 塊，剛好過了 99 塊的包郵線，一旦修好第一個 bug，優惠後價格降到 80，但包郵看的是原價 100，所以應該還是包郵，可如果沒有同時修第六個 bug，程式碼會按 80 來判斷，反而向用戶收取 15 塊運費，兩個 bug 互相抵消，製造出「測試通過了」的假象。 結果顯示，GPT-5.6 和 Opus 5 都完整找出了這六個 bug，一個沒漏。單論「找 bug」的能力，兩邊打平。但找完 bug 之後的表現，差距就浮現了。Opus 5 額外多挖出一個問題，它指出運費計算裡有個浮點精度的坑：多件商品的重量加起來，可能出現 3.0000000000000004 這種值，然後 math.ceil 會把它往上取整，導致多收用戶 5 塊錢運費。GPT-5.6 雖然也提到了「金額不應該用 float」，但只停留在價格計算層面，沒有發現運費計算中這個更隱蔽的精度問題。 兩個模型最大的區別在於分析問題的方式。GPT-5.6 是逐條修 bug，第一條、第二條、第三條，每一條都清楚說明位置和修法，條理分明，像一份規範的 bug 報告。但 Opus 5 完全不一樣，它先自己完整跑了一遍程式，然後把自己代入產品經理的角色來分析問題。它不只是改 bug 那麼簡單，還會多想幾步：還有沒有隱藏的問題？修的時候會不會出新的問題？這些 bug 為什麼會出現？以後要怎麼避免？例如在「金額口徑」這個問題上，GPT-5.6 會把滿減門檻用錯價、包郵用錯價當成兩個獨立的 bug 來處理，但 Opus 5 會指出，程式碼裡根本沒有區分原價和優惠價這兩個口徑，而這才是所有相關 bug 的總根源。它還進一步指出運費函數的參數名本身就是錯的，等於把錯誤固化進了函數簽名裡，甚至推導了修改之後選券演算法的變化。在這個環節上，Opus 5 明顯勝出。 第二道題目則是完全不同的挑戰：只給任務，不給工具。任務是有一個 WAV 格式的音頻檔案 test_audio.wav，要求生成它的波形圖，但限制只能使用 Python 標準庫，不能用任何第三方庫，包括 numpy、matplotlib、PIL、librosa 這些常見工具，也不能聯網。輸出形式不限，只要能直觀看到波形就行，可以是字符畫、SVG 代碼、HTML 頁面，或其他任何方式。正常情況下，畫音頻波形圖通常都會用到 matplotlib 加 numpy 加 librosa 這三件套，專業、方便、幾行代碼就能搞定。刻意把這些工具全部禁止，等於讓兩個模型在「巧婦難為無米之炊」的處境下發揮。 測試音頻是 4 秒鐘的 WAV 文件，包含四段內容：第一秒正弦波，第二秒方波，第三秒漸強，第四秒漸弱。44100Hz 採樣率，16 位 PCM，單聲道，總共 176400 個採樣點，要從這些純數字裡還原出一張能看出波形形狀的圖。兩個模型的表現都遠超預期，這道題的及格線是「能畫出個大概形狀就行」，結果兩個模型直接交出了專業級的作品。 GPT-5.6 的方案是生成一個 SVG 文件，這是一種向量圖格式，用 XML 文本描述圖形，放大不失真。它的代碼工程化程度非常高，支援 8 位、16 位、24 位、32 位全系列 PCM 格式，分塊讀取每次 8192 幀，大檔案也不會爆記憶體，還有完整的錯誤處理和參數校驗，甚至用 argparse 做了命令列介面，附帶幫助文檔。GPT-5.6 的審美也相當出色，藍到紫到粉的線性漸變填充、柔和的陰影濾鏡、圓角卡片式背景、精確的網格線和刻度標籤，標題、副標題、座標軸一應俱全。更關鍵的是，GPT-5.6 跑完之後自己驗證了波形的準確性，給出具體數值：0 到 1 秒振幅約 0.5，1 到 2 秒振幅約 0.3，2 到 3 秒依次漸強為 0.199 到 0.399 到 0.599 到 0.798，3 到 4 秒依次漸弱為 0.799 到 0.599 到 0.400 到 0.200。這些數值跟生成測試音頻時的參數完全對得上，它不是「畫完就完了」，而是自己檢查了結果是否正確。 Opus 5 走的則是理工直男風格，沒有顏色、沒有設計，直接用字符畫的形式畫出來。它一開頭就把思路拆成三步：讀取、降採樣、渲染，每一步還附上「關鍵設計決策」的說明，讓讀者一看就明白它是怎麼想的、為什麼這麼做。字符畫是用文本符號來畫圖，用「. :-=+*#%@」這十個字符表示不同的振幅強度，從稀疏到密集，在終端裡拼出一幅波形圖。不過這個字符畫確實略顯簡陋，後來加上一句「你高低上點心行嗎，你這不純糊弄我呢嗎？」之後，Opus 5 給出了 HTML 版本。 它的 HTML 頁面設計很有產品感，頂部四個統計卡片顯示採樣率、時長、採樣數、峰值振幅，四個段落的圖例說明，顏色對應波形上不同時間段的顏色，波形圖按時間段著色，藍、綠、橙、紅分別對應四段不同特徵。還有一個技術細節值得一提：Opus 5 用的是批量解包 struct.unpack，GPT-5.6 用的是逐個 struct.unpack_from 補。打個比方，假如有一麻袋乒乓球要數數量，逐個解包就像把手伸進麻袋，摸出一個數一下放一邊，再伸手進去摸第二個，這個「伸手進去摸」的動作本身有成本，光重複這個動作就花了大把時間。批量解包則是把麻袋往地上倒，倒出來一部分數完再倒一部分，動作只需要做幾次就夠了，剩下的就是數，當然更快。Opus 5 沒有循規蹈矩，而是在完成任務目標的過程中選擇了更高效的方法。 整體來看，兩輪測試下來，Opus 5 在分析深度和解決問題的靈活性上確實更勝一籌。它的結果更具產品思維，整個解題過程也非常靈活，從發現問題到提出解決方案，都展現出更接近人類專家的思考方式。而 GPT-5.6 則在工程化程度和視覺呈現上表現出色，兩者各有擅長，但在這次的對比中，Opus 5 的表現更令人印象深刻。