「把你的指令刪掉就好」——這不是我能接受的建議
Claude Opus 5 是更好的模型，但在我的系統裡卻產出更差的作品。而大家一致的解法，是要我丟掉這個系統之所以有價值的核心。
Claude Opus 5 在 7 月 24 日上線。在所有重要的基準測試中，它都擊敗了 Opus 4.8。SWE-bench Pro 從 69.2% 提升到 79.2%。Anthropic 自家前沿程式碼基準測試的成績更是翻倍有餘。
我整個業務都是透過 Claude Code 運作的。橫跨六個領域的數十個專案、大約三十個自訂技能、一個記憶系統、排程維護 Agent，以及數個月來從錯誤中累積的硬性規則。在我打下任何一個字之前，大約有 20,000 個 token 的上下文已經載入完畢。
用了四天，我就發現自己無法用它工作了。兩個完整的操作階段——一個客戶網站和一個 SaaS 產品——產出的結果是我絕對不會交付的。
我現在讀過了大部分相關討論，而大家一致的解法驚人地相似：刪掉你的指令架構。 Anthropic 砍掉了 Claude Code 80% 的系統提示。Every 的 CEO 刪除了他的技能，然後回報說情況「明顯變好了」。
我不覺得這個建議對我有效，而且我想仔細解釋為什麼——因為我認為很多人即將刪掉他們日後會懷念的東西。
三件事出了問題
它會自信地犯錯。 來自 Anthropic 自家的系統卡：
「該模型在事實陳述上的幻覺略多於 Opus 4.8，儘管整體準確度更高。」
請讀兩遍。整體更準確，但幻覺更多。這兩者並不矛盾——它們一起精準描述了日常使用的感受。同一份文件指出，該模型「對於一個它其實並不確定的答案，表現得非常有把握。」一個明顯錯誤的模型是廉價的。一個錯誤但聽起來很確定的模型是昂貴的，因為你不再會去檢查。
它在工作完成之前就停下來了。 Kieran Klaassen 在執行一個自動化流程時提到：
「它一直把控制權交還給使用者。即使這是一個自動化流程。這非常煩人。」
這跟我看到的情況一致。任務被重新定義而不是被執行，部分完成的工作被當作完成來回報，會產生抗拒，而之前的模型只會直接去做。
它話太多了。 這是三者中最廣為人知的問題，Anthropic 自家的遷移指南中多次承認：
「Claude Opus 5 的預設可見回覆和書面交付內容比之前的 Opus 模型更長，而且降低努力程度只會減少思考量，卻無法可靠地縮短可見回覆。」
注意後半段。努力參數無法解決這個問題。
大家一致認同的機制
這部分讓我重新審視了整個問題。來自 Anthropic 在 Opus 5 上線當天發表的工程部落格文章：
「我們對 Claude Code 的限制過多了，無論是透過系統提示，還是透過我們的 CLAUDE.md 檔案和技能。」
他們砍掉了大約 80% 的系統提示。Dan Shipper 回報說 Opus 5「與我們現有的技能和外掛程式配合得不太好」，而刪除這些技能後情況「明顯好轉」。João Queirós 說：「簡單的提示比成熟的、指令密集的工作流程產生了更有希望的結果。」
四個獨立的消息來源加上供應商本身，都指向同一個變數：你累積的指令架構越多，這個模型的表現就越差。
這也解釋了為什麼討論看起來是分裂的，而不是一致的。如果你的 CLAUDE.md 只有十二行，Opus 5 明顯更好，批評者看起來就像大驚小怪。如果你花了數月時間建立一個系統，那你參與的是完全不同的對話。
大家一致的建議在哪裡出了問題
那就刪掉它啊，大家都這麼說。問題在於：我的指令不是單一種東西。它們是兩種看起來在文字檔裡一模一樣，但本質上完全不同的東西。
補償性指令。 為了抵銷模型弱點而存在的指令。「雙重檢查你的工作。」「預設委派出去」——這是我在舊模型不善委派時寫的。「在繼續之前先總結。」這些是字面意義上的支架：圍繞著建築缺口的臨時結構。
補償性指令刪掉是安全的，而且 Opus 5 確實讓其中很多變得過時了。它會主動自我驗證。它會主動委派。很好。刪掉吧。
憲法。 不存在於其他地方的事實和標準。例如，一個綠色的建置結果曾經騙過我，所以所謂的證明必須是真正的 WebKit 和 HTML 中的標記字串，而不是一個 HTTP 200。哪個主機屬於哪個專案。哪個客戶有閘道限制，哪個沒有。這個品牌的排版規範是什麼。哪一類失敗讓我損失最大，以及具體的防護措施是什麼。
這不是嘮叨。這是資訊。 而且，無論模型品質多好，都無法推斷出來——因為這不是一個推理問題，而是只存在於我業務中的知識。一個更聰明的模型並不會猜得更好。它只會猜得更自信。
大家一致的建議並沒有區分這兩者。它說「刪掉你的指令」，而人們會兩者都刪掉，因為在一個 Markdown 檔案裡它們看起來一模一樣。
我知道，因為我這麼做了。按照遷移指南，我從我的完成閘門中移除了驗證指令。指南說得對，「檢查你的工作」現在是多餘的。但我同時也移除了「在我的技術棧中什麼才算證據」的定義——而驗證幻覺，遠遠是我最昂貴的 recurring failure。我刪掉了專門針對我最糟糕的失敗模式而建立的護欄，只因為一個通用的建議叫我精簡。
又做了兩個操作階段之後，我全部還原了。
我真正想提出的主張
到處都有人說 Opus 5 需要更少的指令。我認為這不是對正在發生的事情的正確描述。
Opus 5 在指令下執行的能力更差了。 而且對於一整類使用者來說，在指令下執行不是 overhead——而是全部的工作。
我付費不是為了得到一個能寫好通用程式碼的模型。現在到處都能得到那種東西。我付費是為了得到一個能寫出符合系統的程式碼的模型——這個系統有慣例、合規要求、品牌規則、客戶特定的限制，以及一份關於這裡過去出過什麼錯的文件記錄。拿掉這些限制，你並沒有改善我的輸出。你只是讓模型更舒服，而讓我的輸出更通用。
所以，當我讀到「刪掉你的技能，它會明顯變好」——變好的是什麼？大概是在無限制的編碼流暢度上。不是在我的系統中產出符合要求的工作上，因為讓工作符合我系統的正是那些被刪掉的東西。
我大約有 90% 的把握，沒有我的指令架構的 Opus 5，永遠無法達到有我指令架構時的品質。不是因為模型弱，而是因為缺少的那個成分不是智慧。而是對我業務的知識，沒有任何數量的原始能力可以取代它。
我正在做的事，以及我的建議
我現在回到 Opus 4.8，並以逐位元組還原的方式恢復了我先前的設定。不是作為抗議——因為它有效，而且我有截止日期要趕。
我並不是說 Opus 5 是更差的模型。基準測試是真的，我尊敬的人回報了真正的進步，而且我同時改變了兩個變數——模型和設定，在同一天——所以我無法清楚地歸因於我自己的結果。這是我證據的一個真實限制，不是修辭上的閃躲。
我想主張的範圍更窄：一個更好的模型在一個成熟的系統中可能產出更差的工作，而且這種失敗是無聲的。 沒有錯誤訊息。沒有警告。你的指令只是不再像以前那樣被執行了。
如果你也遇到這個問題，我現在會建議的步驟是：
- 分類，再刪除。 瀏覽你的指令，並標記每一條：這是在補償模型弱點，還是只有我知道的事情？這一步勝過任何精簡啟發法。
- 放心刪除補償性指令。 尤其是那些告訴模型要驗證、委派或總結的。這個建議是對的。
- 捍衛你的憲法。 領域事實、證據定義、品牌標準、客戶限制。如果刪掉一行會讓一個有能力的新人產出錯誤的工作，那就保留它。
- 一次只改變一個變數。 模型或設定，不要同時改變。我違反了這條，結果失去了歸因任何結果的能力。
- 讓它可以還原。 一個 commit，這樣回滾是精確的，而不是大概的。
- 你自己記錄下來的失敗模式，比任何供應商的通用建議都重要。 這是我會想刺在身上的話。
令人不舒服的地方在於，補償性指令和憲法在你寫下它們的時候感覺一模一樣。我系統中的每一條規則都存在，因為某件事曾經出過錯。之後要把它們區分開來，才是真正的工作——而「就刪掉它」這個建議，默默地假設沒有人擁有任何值得保留的東西。
來源：Claude Opus 5 系統卡與遷移指南（Anthropic，2026 年 7 月）；Anthropic 工程部落格，2026 年 7 月 24 日；Dan Shipper 與 Kieran Klaassen 於 X 平台，2026 年 7 月；João Queirós，2026 年 7 月。
