Claude技能失效56%：一個工程師的靜默故障診斷

56%的調用失敗，系統卻毫無提示。這不是邊緣案例，是Vercel、Villega、Seleznov三項獨立研究共同指向的中位數。更麻煩的是，Claude不會報錯——它直接跳過技能，輸出看起來還像那么回事。

一位每天高頻使用Claude技能的開發者發現，自己"幾乎零故障"的秘密，不是運氣，是徹底換了一套寫法。他把技能從散文式描述，改成了12個生命周期指令，像Unix管道那樣編排工作流。

三個結構性傷口

原文作者花了大量時間排查，發現問題不在技能功能本身，而在三個隱蔽的設計缺陷。

第一個叫「靜默范圍衰減」。你用自然語言寫的約束條件，隨著上下文壓縮會被稀釋。架構邊界在不同會話間漂移，但沒有任何檢測機制告訴你這事發生了。

第二個是「判斷劇場」。你認真審閱AI輸出，但手邊沒有可核對的契約。審查動作看起來很專業，結構上卻是空的——你不知道該對照什么標準。

第三個最棘手：「觸發碰撞」。錯誤的技能被激活，或者該激活的沒激活，而失敗完全不可觀測。技能越多，歧義越多，問題疊加得越隱蔽。

三項研究的數據分布很說明問題：Vercel測出56%的非調用率，Villega報告50%成功率，Seleznov在650次樣本里看到77%的激活率——注意，77%激活意味著23%靜默失敗。區間跨度大，但共識明確：失敗是常態，且無聲無息。

從散文到管道

作者的解法很極端：停止用散文寫技能。

他構建了12個生命周期技能，不編碼領域知識，只治理工作本身的流程——規劃、執行、驗證、歸檔。領域知識被抽離到「契約」里，技能保持固定，契約持續累積。

核心循環是四步指令：

/plan-work → /proceed-work → /verify-work → /archive-work

每個驗證過的契約都成為可搜索的先驗知識，下次會話不必從零開始。搜索指令/search-kg把已驗證的模式反饋到規劃階段，形成閉環。

這12個技能已開源，MIT協議，Claude Code開箱即用。不需要基礎設施，不需要服務器，Git加文件系統就夠了。

安裝命令只有一行：npm i @gem_squared/tpmn-skill-install

倉庫地址：github.com/gem-squared/tpmn-skill

契約優先的工程邏輯

作者的設計哲學很清晰：技能負責流程，契約負責內容。契約是強類型的，格式為「A → B | P」——輸入A，在條件P下，必須輸出B。

這種分離解決了散文技能的致命傷。自然語言的約束會衰減，但類型化的契約可以被精確驗證。/verify-work步驟強制對照契約檢查輸出，不通過就重試，而不是讓Claude帶著錯誤繼續。

更關鍵的是可觀測性。每個單元都有明確的通過/失敗標準，不再是「感覺差不多」。作者提到，/proceed-work執行單個單元時，會內聯驗證、失敗即重試，這個設計把錯誤攔截在傳播之前。

12個技能的完整清單包括：搜索知識圖譜、規劃工作、執行工作、驗證工作、歸檔工作，以及支撐這些的輔助指令。它們不隨項目變化，像Unix工具那樣組合使用。

為什么是現在

Claude技能上線后，很多開發者第一反應是寫一段漂亮的自然語言描述，期待AI按需調用。但三項獨立研究的56%、50%、23%失敗率，暴露了這個假設的脆弱。

語言模型的上下文壓縮機制，決定了散文約束必然衰減。你寫的「始終檢查X」在第十輪對話后，可能只剩殘影。而技能觸發依賴的語義匹配，在技能數量增加時，碰撞概率指數上升。

作者的方案本質上是一次工程化回退：用顯式的類型契約替代隱式的語義理解，用固定的流程技能替代靈活的領域技能。這不是更聰明，是更可靠。

數據收束：56%非調用、50%成功率、77%激活率——三個數字指向同一個結論。當AI系統的故障靜默發生時，唯一可靠的防御是結構化的驗證機制，而不是更用心的提示詞工程。