Anthropic 技術棧裡的「五宗罪」由何而來？

Anthropic 最近正面臨一種比跑分下滑還令人難堪的局面。旗下的 Claude 系列模型表面上仍在持續升級，各項評測成績也未見崩盤跡象，但愈來愈多使用者開始抱怨：這套模型怎麼愈來愈難用了？如果只是單一版本的表現不理想，或許還能歸因於訓練方向或評測重點的差異。然而這次的討論矛頭，指向的是比單一模型更上層的問題——Anthropic 整個技術棧長期累積下來的結構性缺陷。模型能力往往只是冰山一角，真正拖累使用體驗的，經常是藏在系統底層、不容易從外部評測看出來的工程問題。在這次被點名的「五宗罪」中，至少有三大項正在同時壓制 Claude 的實際表現，分別是程式碼低熵、上下文汙染，以及錯誤回灌。

這三個名詞聽起來相當技術性，但它們對日常使用體驗的殺傷力，其實遠比一次跑分數字的起伏更值得關注。所謂程式碼低熵，指的是程式碼庫內部的混亂程度偏高。熵在資訊科學中原本代表系統的無序程度；當一個大型專案的程式碼愈來愈複雜、依賴關係愈來愈糾結、歷史包袱愈來愈重時，工程師在維護與擴充功能時就必須付出更高成本。對 Anthropic 這類以快速迭代為核心的 AI 公司而言，這種混亂會直接反映在開發速度與產品穩定性上。每一次想修正一個小問題，都可能牽動大片既有程式，最後使得新功能的推出變得綁手綁腳，也讓潛在缺陷愈藏愈深。接著是上下文汙染。

對話式 AI 的核心價值之一，就是能夠記住並理解對話過程中出現過的資訊。但如果模型在處理每一次互動時，都會被不相干、過時、甚至已經被證明是錯誤的歷史內容所干擾，那麼原本應該建立在使用者意圖上的流暢對話，就會開始走樣。使用者的問題明明很單純，模型卻可能因為被舊資訊誤導，給出答非所問的回應。這種情況在長對話中尤其明顯，因為累積的干擾愈多，模型的判斷就愈容易偏離真正的焦點。更令人頭痛的是錯誤回灌。這個問題的機制，是指系統把過去產生的錯誤結果，重新當作輸入送到模型面前。

AI 系統在運作過程中，難免會產生錯誤輸出；問題在於，如果這些錯誤沒有被過濾或校正，反而被當作後續處理的依據，錯誤就會像滾雪球一樣不斷重演甚至放大。一次小小的判斷失誤，可能因此演變成連續性的錯誤回應，讓使用者感覺模型「講都講不聽」，明明已經發現不對勁的地方，下一次互動卻又出現同樣的毛病。這三項問題並非獨立存在，而是彼此交疊、相互加乘。程式碼低熵使得修正缺陷變得格外困難；因為修正困難，錯誤就更容易殘留在系統中；這些殘留的錯誤，又會透過上下文汙染與錯誤回灌的機制，滲入每一次實際的對話流程。

換句話說，Anthropic 的工程團隊面對的，不是「有一條蟲要抓」這種單點問題，而是一整個盤根錯節的技術債結構。這個現象也解釋了一個讓外界感到困惑的矛盾：為什麼 Claude 在新版本的跑分表現上仍能維持一定水準，使用者的實際感受卻在悄悄下滑？答案很可能就藏在評測方法與真實使用情境的差異之中。標準化跑分通常依賴固定題目與乾淨的測試環境，模型在不受干擾的條件下，確實能展現出不錯的單點能力；但真實世界中的使用者輸入往往雜亂、冗長，甚至是來回修正過多次的對話。在這種條件下，技術棧底層的缺陷會被無限放大，跑分捕捉不到這些日常場景中的失誤，自然也就無法反映使用者真正感受到的卡頓與挫折。

對於 Anthropic 而言，真正的警訊恐怕不是哪一次的評測分數掉了幾個百分點，而是使用者的集體感受已經開始比跑分更早發出警報。當模型明明還在升級、功能明明還在增加，使用者卻出現「愈改愈難用」的觀感時，這通常意味著問題不在前端的產品功能設計，而在後端整個資料處理鏈路與開發流程的品質控管。使用者不會看到程式碼庫的混亂程度，也不會知道每一次錯誤回灌背後的技術細節；他們只會感受到對話不再順暢、回應不再可靠，然後用一次次實際使用經驗做出最直接的判斷。這也解釋了輿論為何會悄悄轉向。

技術社群的討論，往往會從「模型跑分高不高」慢慢轉移到「實際用起來有沒有進步」，而 Anthropic 近期面對的，正是這種氛圍的轉變。新的能力確實不斷被加入，但那些沒有被有效清理的結構性問題，正在一點一點抵消新版本帶來的正面感受。久而久之，即使客觀數據仍算漂亮，主觀評價也會慢慢被負面體驗淹沒。要扭轉這種印象，恐怕不是靠推出下一個跑分更高的模型就能解決。Anthropic 需要做的，是回頭檢視開發流程與資料處理鏈路中那些被長期容忍的「原罪」——把程式碼庫的混亂程度降下來，把對話歷史的篩選與清洗機制建立起來，更重要的是，建立一套能阻止錯誤結果回流到模型輸入端的防護機制。

這是一項不討喜的工程，既難以對外宣傳，也無法在短期內帶來跑分成績的躍進，但它對使用者體驗的長期影響，遠比任何一次版本升級都更為深刻。AI 產業向來崇尚快速前進，但跑分與口碑之間的裂縫一旦出現，就代表技術債已經到了必須面對的時刻。Anthropic 的挑戰，不在於能不能追趕上競爭對手的模型能力，而在於願不願意停下來，先把自家技術棧裡那些不斷製造麻煩的結構性問題拆解乾淨。畢竟，使用者不會永遠為了漂亮的跑分買單；他們最終記住的，是每一次對話中的實際感受。