靜態技能就是死亡技能

昨晚我為Claude Code指南發佈了一個設定參考章節。十五筆條目。每條引用都以行號為基準用grep驗證過。在批評循環回饋乾淨之後,我憑著信念交付了它。等到我正在提交那個.md檔案時,我就已經知道自己會需要v3版本——不是因為我做錯了什麼,而是因為指南會變、底層產品會變、使用者查詢會轉變,而我剛交付的這個章節,從我離開它的那一刻起就會開始漂移。

一個技能,不論它是一段Markdown參考章節還是.claude/skills/裡的代理技能定義,只有在有人盯著它的軌跡時才是活的。一旦你不再盯著,它就變成靜態的。靜態技能會就地衰退。

Ma、Yang、Ji、Wang與Wang發表在arxiv上的一篇新論文(〈SkillClaw: Let Skills Evolve Collectively with Agentic Evolver〉,2026年4月)在研究層面將這個問題形式化了。¹他們的開場論述,直接引述如下:「大型語言模型(LLM)代理例如OpenClaw依賴可重複使用的技能來執行複雜任務,然而這些技能在部署後大多保持靜態。結果是相似的工作流程、工具使用模式與失敗模式在不同使用者之間反覆被重新發現,使系統無法透過經驗而持續改進。」¹

這個失敗模式我已經親身經歷數月之久。如果你正在為任何代理框架打造技能,你也一樣。

TL;DR

代理技能一經交付就停止進步。使用者各自獨立地發現相同的失敗模式,卻從未將這些發現回饋到技能本身。Ma等人將此框架為一個集體智慧問題:跨使用者與跨時間的互動是技能何時有效或失敗的訊號,但目前並不存在生態系層級的機制來將它們彙整成技能更新。他們的SkillClaw框架提出將彙整的軌跡視為演化訊號,並運行一個自主演化器,用來辨識反覆出現的行為模式,並將其轉化為精煉或能力擴充。¹摘要中以「OpenClaw」作為使用可重用技能的LLM代理範例——僅憑摘要我無法確認OpenClaw是哪一個具體出貨產品,因此我不會在本文中對它進行臆測。但我要主張的是:論文所描述的結構性問題,也映射到任何為Claude Code、Codex、Cursor或自家框架打造技能的人身上。結論:如果你的技能庫沒有持續從真實使用中吸納軌跡,它從交付那天起就是死的。

關鍵要點

• 技能作者:工作不會在技能交付時結束。工作要到你建立起一個循環——它盯著技能如何被使用、捕捉反覆出現的失敗模式,並將它們回饋進技能定義——之後才算完成。交付是技能生命的開始,不是終點。
• 框架建構者:記錄每一次技能呼叫的完整軌跡——輸入、工具呼叫、輸出、錯誤狀態。那份日誌就是演化訊號。如果你沒有在記錄它,你就不是在改進你的技能;你只是在維護它們。
• 抱持Jiro精神的實踐者:SkillClaw論文是Shokunin模式應用於技能的學術語言版本。技能是手藝。軌跡是練習。演化是對匠道的追求。靜態=死亡。

論文究竟說了什麼

我會謹慎地逐項解讀摘要中的主張,然後清楚標明我在哪裡延伸了這個論述框架。

問題陳述(出自摘要)。LLM代理依賴可重用的技能來執行複雜任務。這些技能在部署後大多保持靜態。相似的工作流程、工具使用模式與失敗模式在不同使用者之間反覆被重新發現。系統無法透過經驗而改進。¹

這是關於特定失敗模式的主張,而不是主張所有技能都會衰退。從未被呼叫的技能不會衰退。只有一位從不回報問題的使用者呼叫的技能,也不會明顯衰退。衰退會在你擁有多位使用者、每個人各自遭遇同一個失敗的不同版本、而系統沒有辦法將這些遭遇彙整成單一更新時顯現出來。(最後這句話是我的論述,不是論文的。)

現有的缺口(出自摘要)。摘要指出,雖然跨使用者互動「提供了關於技能何時有效或失敗的互補訊號,但現有系統缺乏將這種異質經驗轉換為可靠技能更新的機制。」¹這是承重的主張。並不是說沒人想過技能改進。而是說沒有任何生態系層級的機制會彙整軌跡、辨識反覆出現的模式,並將其轉化為更新。

SkillClaw流程(出自摘要)。摘要描述了一條連續的流程:SkillClaw「彙整使用期間產生的軌跡,並由自主演化器處理,該演化器辨識反覆出現的行為模式,並透過精煉既有技能或以新能力擴充技能,將其轉化為對技能集合的更新。」¹更新後的技能維護在共享儲存庫中並在使用者之間同步,因此在某一情境下發現的改進能在不需要使用者付出任何心力的情況下在全系統傳播。¹

評估(出自摘要)。論文使用Qwen3-Max作為底層模型,在一個名為WildClawBench的基準上評估SkillClaw。摘要在發表版本中的措辭在文法上是破碎的:「在WildClawBench上的實驗表明有限的互動與回饋,它在真實世界代理情境中顯著提升了Qwen3-Max的效能。」¹我解讀為:在有限互動與回饋的情況下,SkillClaw相對於基準仍能產生顯著的效能提升。摘要並未公布具體數字——完整論文想必有。

這就是摘要所描述的論文內容。作者主張,擁有共享技能的多使用者代理生態系可以從自動化的軌跡彙整餵入自動化的技能更新中獲益,而他們報告其實作在有限回饋條件下顯著改善了Qwen3-Max的效能。

論文沒說的,以及我在補充的

摘要以「OpenClaw」作為一個範例(「例如OpenClaw的LLM代理」),說明這是一個使用可重用技能的代理。僅憑摘要我不知道OpenClaw是什麼——我無法很快將它辨識為某個具體出貨產品。論文的框架(SkillClaw)是作為多使用者代理生態系的通用解決方案提出的,不是專門為OpenClaw提出的,因此「OpenClaw是什麼」這個問題基本上與論證無關。我特別標示這一點,是為了讓沒有人讀完這篇文章後走開時以為這篇論文是關於Claude Code的。它不是。它將OpenClaw作為範例列舉,並將SkillClaw作為一種通用機制提出。

我所主張的——獨立於論文之外——是論文描述的結構性問題映射到我一直在Claude Code技能生態系中親身經歷的真實問題。那個主張是我的,不是論文的。以下是我認為它為何映射得上的理由。

Claude Code生態系中的技能是作為靜態產物交付的。一個技能就是一份SKILL.md檔案(或一組支援檔案的組合),描述一項任務該如何執行。你寫一次。你提交。你以斜線命令或@skill-name自動補全來引用它。一旦交付,它就是一個靜態產物。沒有任何自動機制會盯著這個技能在實務中如何被使用,並根據什麼有效、什麼失敗來更新技能定義。

不同的使用者各自獨立遇到相同的失敗模式。我交付過的每一個技能至少有一個只在特定條件下才會出現的反覆失敗模式。有人用我沒預料到的輸入呼叫這個技能、撞上邊界情況、手動繞過、繼續前行。另一個人,在其他地方,撞上同一個邊界情況,做了自己的繞過。技能本身卻毫無改變。

彙整後的訊號是真實的,卻未被使用。如果我能看到我交付的每個技能每一次呼叫的每一條軌跡,我一個下午就能辨識出反覆出現的失敗模式。那個訊號是存在的——它就在每位使用者個別的會話歷史中。只是它沒有被彙整在任何地方,所以沒有人依此行動。

修正不是手動的,就是缺席的。目前,唯一的技能改進機制就是我在自己的使用中注意到問題、或是有人提交了一個issue、或是有人開了一個PR。這些都是需要使用者付出心力的路徑。SkillClaw論文的核心洞見——軌跡資料已經存在,應該自動地被轉換成技能更新——正是我們所缺少的那個機制。

這就是我對於論文的論述框架如何適用於Claude Code的主張。這不是論文說的。這是我對照自己的工作來閱讀論文的方式。

Shokunin模式,套用於技能

當我思考手藝時,有一個框架我一直會回到。壽司大師小野二郎就是典型範例。六十年做同一件事。每天,盯著吧台前發生的一切,調整技術、精煉米飯溫度、刀工角度、醋飯的時機。工作本身就是訓練訊號。實踐者就是彙整者。

我之前寫過Shokunin/品質循環的論述框架。核心觀念:手藝就是回饋循環。你做事,你看著自己做的事,你注意到什麼壞了,你調整,你再做一次。一遍又一遍。精通存在於「你本來打算做的」與「實際發生的」之間的差距中,以及你願意把那個差距帶進下一次嘗試的意願中。

靜態技能打破那個循環。你交付技能。你不再盯著。技能本來的意圖與實際發生的結果之間的差距,累積在一百個你從未看到的會話中。技能沒有變得更好,因為匠人不在吧台前。

SkillClaw論文提出了一個自動化彙整器——不是取代人類,而是一個機制,盯著所有軌跡、注意到跨會話間什麼壞了、並向技能定義提出更新建議。那不是瘋狂的野心。它其實是一個技能若要在部署後存活下來的最低標準。

這在實務上長什麼樣子

如果我想針對自己今天在維護的Claude Code技能建構SkillClaw模式,以下是我所需要的:

1. 每一次技能呼叫的軌跡日誌。每次技能執行時的輸入、它發出的工具呼叫、輸出、錯誤狀態與最終處置(使用者接受結果了嗎?還原了嗎?改寫了嗎?)。這在Claude Code中的會話層級已經存在——問題在於它是否被跨會話彙整、並提取給技能擁有者。

2. 一個模式偵測器。讀取軌跡日誌並辨識反覆模式:同一類輸入導致同一種失敗、同一個工具呼叫以同樣方式失敗、同一個邊界情況在不同使用者情境下出現。這不是通用人工智慧——它是在結構化軌跡資料上的分群。

3. 一個提案生成器。給定一個偵測到的模式,草擬對技能的候選更新:一條新的處理分支、一個額外的範例、SKILL.md正文中的一條額外約束。該更新是一份提案,不是已交付的變更。

4. 一道關卡。每一個提議的更新都要經過人工審閱、事實驗證(與我套用在其他所有事物上的同一道硬關卡),以及批評循環後才能交付。自動化負責彙整,不負責交付。

5. 散播。當一個提議的更新被接受時,它會傳播到該技能的每一位使用者。在集中式生態系中這是微不足道的(更新標準技能,大家拉取)。在分散式生態系中就比較困難。

其中大部分在Claude Code中已經存在——會話日誌存在、技能定義有版本、批評循環可運作——缺少的拼圖是連接會話軌跡到技能更新的彙整與模式偵測層。

令人不安的蘊含

我過去六個月交付的每一個技能,都以SkillClaw論文所描述的意義上是死的。我寫技能。我自己使用它。我注意到問題。我修正我自己使用的技能中的問題。技能對我而言變得更好。它們對其他任何人都不會變得更好,除非那個人獨立地注意到同一個問題並回報某種東西。

昨晚我在設定參考上所做的工作,正是這個模式。Claude Code指南是一個共享產物。使用者在上面查詢特定的設定鍵。我可以看到GSC資料告訴我哪些設定鍵被搜尋。那就是彙整後的軌跡資料——它實際上在告訴我指南中的哪些技能正在被呼叫、結果落在何處。而在我去查看那些資料之前,這份指南是靜態的。它已經靜態數週了。不是因為沒人在盯著軌跡,而是因為我是唯一能盯著它們的人,而我有別的事要做。

SkillClaw論文是這個問題的學術形式化。實務上的機制更簡單:如果你沒有一條從軌跡資料到技能更新的自動管線,你的技能就在原地衰老。它們或許在某些條件下仍能對某些使用者有效。但它們沒有在變得更好。

唯一的問題是,你是接受你的技能在交付那一刻就已經死亡,還是你要建立那個讓它們持續活著的守望者。

最小可行彙整器

在我開始寫這篇文章之前,我對自己的技能沒有任何軌跡彙整。完全沒有。我有可以手動閱讀的會話歷史,但沒有任何東西能在跨會話間顯現模式。那正是論文描述的靜態技能病症,而我正在經歷它。

這是我現在、今天就能對此交付的最小具體事物:一個單一的文字檔,以附加方式記錄我自己所有會話中每一次技能呼叫,包含時間戳記+技能名稱+輸入形狀+最終處置(接受/修改/還原)。沒有模式偵測器。沒有自主演化器。只有日誌。

那個檔案就是最小可行彙整器。它不是SkillClaw。它是SkillClaw若存在會需要的輸入層,也是我在甚至能夠看見我的技能是否有反覆失敗模式之前所需要的輸入層。少了它,我只是在猜。有了它,我至少可以在檢視一個技能時用手掃過日誌並問:這東西這個月是否以同樣方式壞掉了三次?

這就是承諾。一個檔案。只附加。每次呼叫記錄。在檢視技能時一併檢視。

如果這有效,下一層就是模式偵測器。如果模式偵測器有效,下一層就是提案生成器。論文的野心是一個完整的自主演化器,在多使用者生態系中運行。我的野心則是不要在黑暗中盲目運行。

常見問題

論文中的「OpenClaw」與Claude Code是一樣的東西嗎?

不是,而且我也無法告訴你OpenClaw是什麼。摘要提到「例如OpenClaw的LLM代理」作為一個使用可重用技能的代理範例,但沒有定義它。僅憑摘要我無法很快將它辨識為某個具體的出貨產品。重要的是,論文的SkillClaw框架是作為多使用者代理生態系的通用解決方案提出的,而不是專門針對OpenClaw或Claude Code的解決方案。不論OpenClaw是什麼,這篇論文都不是一篇關於Claude Code的論文,而我在本文中對Claude Code的主張都是我自己的,不是論文的。¹

論文實際的新穎貢獻是什麼?

根據摘要:一個用於多使用者代理生態系中集體技能演化的框架,它(1)跨使用者與時間彙整軌跡,(2)運行一個自主演化器以偵測反覆出現的模式,並(3)將模式轉化為對共享儲存庫中技能的更新,並在使用者之間同步。¹新穎性不在於「技能可以被改進」——那是顯而易見的。新穎性在於主張改進循環應該是自主的、由軌跡驅動的,而不是由人驅動的。

論文有報告具體的改進數字嗎?

摘要將改進描述為在一個名為WildClawBench的基準上、使用Qwen3-Max、在有限回饋條件下「顯著」,但沒有公布具體數字。¹要看數字,完整論文才是來源。

這與對技能定義發起一個git pull request有何不同?

一個PR是人為啟動的機制。有人必須注意到問題、寫出修正、提交PR、審閱、合併。每一步都需要人力。論文提出的SkillClaw框架是自主彙整——系統跨多位使用者注意到模式,自行提出修正,並在無需任何單一使用者提交任何東西的情況下同步更新。¹至於該自主版本對於任何特定生態系是否可取或安全,是另一個問題。論文的貢獻在於證明它在技術上是連貫的。

這適用於我的自訂Claude Code技能嗎?

論文並未對任何特定的Claude Code技能生態系提出主張。我的主張——獨立於論文之外——是結構性問題(技能作為靜態產物交付、失敗模式被每位使用者各自獨立地重新發現、沒有彙整機制)確實適用於Claude Code技能,而任何為Claude Code或任何類似框架打造技能的人,都應該思考如何建構一個由軌跡驅動的改進循環。那是我的意見,不是論文的發現。

Shokunin關連在哪?

Shokunin/品質循環的論述框架主張精通來自於「你本來打算做的」與「實際發生的」之間的差距,並被帶進下一次嘗試。靜態技能打破這個循環,因為差距累積在匠人從未看到的會話中。SkillClaw是閉合那個循環的學術版本——自動化差距的收集並將其餵回技能中。紀律是相同的;機制是不同的。

參考資料