Skill Debt 是什麼？為什麼你寫下來的 Agent Skill，最後會變成屎山
重點摘要 – Skill Debt 是 Agent Skill 長期補丁化後，變得難理解、難刪除、難複用的狀態。 – 你以為保存的是能力，很多時候其實只是保存了上次成功的條件。 – 真正昂貴的不只是 Token，而是維護一堆沒人知道為什麼存在的 Skill。 – Human in the Loop（人在迴圈中）不等於 Governance Loop（治理迴圈）。 人可以不逐步操作，但不能退出刪除、退役、重寫與權限收斂。
結論 屎山 Skill 不是 Prompt 太長，而是 AI Agent 的操作層長期補丁化。你以為自己保存了一個能力，其實常常只是保存了上次剛好成功的條件。如果不定期清理 Yes 負債，Agent 跑得越久，債台通常也會越高。這可以從三個不同角度看到：Orchestration Tax 描述了協調成本的膨脹機制，[5] Intent Debt 解釋了設計意圖的流失，[6] Galileo 的 AI 治理框架則提供了系統層面的觀察。[11]
先把名詞講清楚：Skill Debt、屎山 Skill、Prompt 有什麼不同？
坊間談 AI 代理（AI Agent）操作問題，常見兩個太表面的框架：要嘛怪提示詞（Prompt）太長，要嘛怪模型不夠聰明。但 Skill Debt 既不只是 Prompt 問題，也不只是模型問題。它是整個操作層長期補丁化之後的維護狀態。
Skill Debt 是什麼？
什麼是 Skill Debt？ Skill Debt 是 AI Agent 系統中的一種技術債（Technical Debt）。它不是單純指 Prompt 很長，也不是指某一篇指令文案寫得難看，而是指一個代理技能在長期使用中，累積了太多補丁、例外、工具假設與歷史條件。
更具體來說，它通常包含：
- 補丁
- 例外
- 過時規則
- 工具假設
- 臨時繞路
- 不再清楚來源的決策
- 不敢刪除的歷史條件
最後導致的狀態是：Skill 雖然還能跑，但沒有人知道它為什麼還能跑，也沒有人敢改。 這種債務會跟著 Agent Loop、記憶、批准規則與工具規則一起沉積，所以它比一般人直覺以為的 Prompt 問題，更接近整個 AI Agent 操作層的維護問題。有效代理的討論提醒我們，能力要可組合、可重用；[4] 決策治理分析則說明，流程如果缺少決策理由，後面就很難判斷；[9] 代理式技術債與批准治理的討論，也把問題指向整個系統如何被保存、組合與維護。[10][16]
屎山 Skill 是什麼？
屎山 Skill 是 Skill Debt 的中文口語說法。它對應 Developer 世界的「屎山代碼」：
- 屎山代碼：程式碼長期補丁化、責任混雜、沒人敢改。
- 屎山 Skill：Agent Skill、Prompt、記憶、工具規則、批准規則長期補丁化，最後變成難以維護的 AI 操作層。
所以屎山 Skill 不是在講某一段 Prompt 很醜，而是在講整個 AI 工作流（AI Workflow）已經慢慢長成一片沒人敢碰的地層。這也是為什麼這篇文章會優先建立 Skill Debt 這個概念，而不是只停在「Prompt Debt（提示詞債）」或「Context Rot（上下文腐化）」這些局部病徵。當設計意圖流失，系統只剩行為不剩理由；[6] 當決策脈絡不足，治理難度會上升；[9] 當補丁又長期累積，問題就會從局部寫法變成可維護性問題。[10][12]
Skill 和 Prompt 有什麼不同？
提示詞工程（Prompt Engineering）常常關心單次指令怎樣寫得更好；但在這篇文章裡，Prompt 通常是一段一次性的指令，Skill 則應該是一種可重用的操作能力。
| 對比 | 好的 Skill 保存能力 | 壞的 Skill 保存條件 |
|---|---|---|
| 目的 | 任務目的 | 上次怎樣勉強成功 |
| 邊界 | 適用條件與不適用情境 | 上次哪個工具版本剛好可用 |
| 判斷 | 關鍵取捨與決策理由 | 上次哪個錯誤要避開 |
| 驗證 | 驗證出口與成功標準 | 上次補過哪條規則 |
| 結果 | 下次可複用流程 | 下次仍要重新善後 |
這個分界很重要。因為 做成 Skill 的意義，不是把昨天記下來，而是讓明天不用重來。 如果你想先理解為什麼 Codex 這類工具不再只是 Coding Agent，而是逐漸變成通用 AI Agent，這篇可以先一起看： Codex：從 Coding Agent 到通用 AI Agent
如果你正在比較不同 AI Agent 的適用場景，也可以延伸看這篇：香港用 AI Agent 點揀？
講完名詞，真正要跨過去的不是「它叫什麼」，而是「它為什麼會變成這樣」。所以接下來要問的，不是你有沒有把方法記下來，而是：你記下來的到底是能力，還是條件。
換句話說，定義只是入口，真正的問題在入口之後。
大家期待 Skill 是經驗累積
人為什麼要寫 Skill？因為大家對 Agent Skill 的期待，本來就很合理：你做過一次任務，把方法抽出來，之後應該更快、更準、更穩。
理想中的 Skill，應該像一位熟手同事。合作越久，默契越深；做過一次的事情，下一次不只更快，還更懂你的標準、語氣、驗收方式與邊界。這也是 Hermes Agent 一直強調的口號：the agent that grows with you，意思是「會跟你一起成長的代理」。但問題是，Agent 不會因為「被用過」就自動成長；如果 Skill 保存的是條件而不是能力，它成長的可能只是債務。Agent Skills 的討論把 Skill 放在可反覆調用的能力單元來看；[3] 長期運作代理提醒我們，持續運作會帶來狀態與維護問題；[2] 有效代理框架則提醒，真正值得保存的是可重用能力，不只是上次成功的記錄。[4]
換句話說，大家願意花時間整理 Prompt、建立 Agent Skill、接上工具、加上記憶、設計 Agent Loop，並不是因為喜歡做文書，而是因為希望這些東西真的能把工作沉澱下來。從這個角度看，Skill 的價值從來都不是「有存檔」而已，而是「能不能穩定複用」。如果你想先理解 AI Agent 為什麼會忘記、為什麼會把成本燒在重複理解上，可以先看這篇：AI Agent Memory：為什麼 AI 會忘記，還會燒錢
理想中的 Skill，不像備忘錄，比較像手藝。備忘錄只是把事情記住；手藝則是做過一次之後，身體真的更熟，判斷真的更準，下次真的更有把握。也正因為大家對 Skill 的期待，本來就不是收藏紀錄，而是累積能力，所以一旦現實走向相反方向，挫敗感才會特別強。你不是失望它不夠完整，而是失望它根本沒有學會。
現實常常不是能力累積，而是事故累積
可惜很多時候，現實正好相反。
很多 Skill 並沒有真正學會任務。它只是記住上次如何勉強完成。於是任務雖然做過一次、方法雖然寫下來、Skill 檔雖然存在，但當你下次重開，整件事仍然可能接不起來。這就是整篇的核心：
很多 Skill 並沒有把工作沉澱成能力，只是把一次成功保存成一組下次未必仍然成立的條件。
這裡最容易讓新手一眼明白的比喻，不是工具，而是事故。
- 理想中的 Skill 像經驗。 做過一次，下次更成熟。
- 現實中的很多 Skill 像事故紀錄。 出過一次事，就補一條規則；再出一次事，再補一條規則。
經驗的特徵是：做過一次，下次更會做。事故紀錄的特徵則是：做過一次，下次只是更知道上次在哪裡爆掉。
Addy Osmani 講的 orchestration tax，本質上指向系統表面上看似更能跑，實際上協調成本卻在膨脹；[5] Intent Debt 則指出你遲早會忘記當初為什麼這樣設計；[6] 代理式程式碼審查又從另一個方向說明了審查成本如何累積。[8] 這和代理式系統技術債的研究互相呼應：如果每次出事都只留下補丁，而沒有抽出判斷與邊界，累積的就會是系統層負債，而不是能力。[10]
問題從來不只是這次有沒有成功，而是：這次成功，有沒有變成下次還用得上的能力。 如果答案是否定的，那你累積的就不是 Skill，而是殘骸。
Skill 不是在累積經驗，而是在累積殘骸
同一個起點，為什麼走著走著，走向了截然不同的終點？
理想路徑是這樣的：你做過一次任務，抽出方法，寫成 Skill，下次複用——更快、更準、更穩。這條路的邏輯很明瞭，也是所有人最初寫 Skill 時想像的樣子：一次經驗，變成下一次的資本。
現實中更常見的路徑則是：你也做過一次任務，也寫成了 Skill——但下次接不起來。於是你補規則、補臨時繞路，Skill 越來越肥，人越來越不敢刪，最後越用越廢。這條路的邏輯同樣清楚，只是方向完全相反：每一次成功保存下來的，不是能力，而是條件。
兩條路徑的起點一模一樣，分歧卻只發生在一個關鍵問題上：這次成功，有沒有變成下次還用得上的能力？ 如果答案是否定的，那你累積的就不是 Skill，而是殘骸。這個對比直接指向那個最痛的斷點：下一次根本接不起來。很多人以為問題出在規則太多、Prompt 太長、工具太雜，但之後所有補丁、審查、治理、批准與重試成本，其實都是從這個斷點長出來的。因為設計理由會在追加中流失，斷點會越來越難修；[6] 人也會在反覆補救中慢慢放棄判斷；[7] 最後治理缺口會把單點斷裂放大成整體維護成本。[11]
Skill 為什麼會越用越廢？
下面把「越用越廢」這個過程拆開，一層一層交代它到底怎麼發生的。
它記住的是繞路，不是原理
好的 Skill 應該把任務抽象成可重用能力：什麼目標、什麼判斷、什麼驗證、什麼邊界。這種 Skill 即使換了模型、換了工具、換了上下文，仍然有很高機率能被重用。
壞的 Skill 則只記住上次怎樣繞過問題。它記住的是臨時繞路，而不是原理；記住的是上次哪個按鈕要多按一次、哪個工具版本暫時可用、哪條規則是為了避開某個舊錯誤。這種 Skill 看起來很實用，實際上卻很脆弱，因為它大部分內容都跟「那次怎樣勉強撐過去」綁死了。只留下做法、不留下理由，會讓後人不知道該保留還是刪除；[6] 這也和「Skill 應該是能力單元，而不是臨時繞路記錄」的討論一致。[3][4]
它累積的是補丁，不是抽象
很多 Skill 腐化的方式，並不是突然寫壞，而是慢慢補壞：
- 這次失敗 → 補一條規則
- 下次成功 → 也保留一條補丁
- 工具不穩 → 就加備援
- 怕模型漏掉 → 就再加一層提示
久而久之，Skill 存下來的不是抽象能力，而是補丁集合。補丁一多，協調成本會浮現；[5] 原本為什麼這樣設計也會被忘記；[6] 代理式工程的技術債討論，正是把這種補丁化收束成可維護性問題。[12]
這也解釋了為什麼 Prompt Debt（提示詞債）、Context Rot（上下文腐化）、Workflow Drift（工作流漂移）、Model Routing Debt（模型路由債）這些詞雖然都重要，卻不能單獨概括整件事。
它們描述的是局部病徵；Skill Debt 描述的則是整個 Agent Skill 已經從能力模組，慢慢變成補丁容器。
它只會追加，不會退役
新增規則很容易，刪除規則很困難。 因為新增通常可逆，刪除卻要承擔風險。
這裡最適合新手的比喻，是衣櫃：
- 增加衣服很容易，丟衣服很困難
- 加進去通常只是塞一下，丟掉卻要重新判斷：還會不會穿？刪了會不會後悔？
Skill 也是一樣。新增一條規則很容易，刪除一條規則卻要判斷：它是不是還在主流程？會不會影響別的任務？
當沒有人願意承擔這個判斷成本時，Skill 就會只增不減。它會膨脹，但不會自然收斂。Orchestration Tax 從協調成本角度說明了為什麼只追加不刪除是膨脹的根源；[5] ElixirData 的治理框架指出決策治理的缺失如何放大這個問題；[9] arXiv 論文提供了系統層面的分析；[10] Galileo 的框架則從生產環境角度給出了治理補強。[11]
人以為在教 Agent，其實只是在替它善後
很多人以為自己在訓練 Agent，實際上只是一次次替一個沒有真正學會的 Skill 善後。你以為在建立能力，實際上卻是在——
- 補 Prompt
- 補例外
- 補路由規則
- 補批准條件
- 補記憶
- 補一個下次未必還成立的臨時繞路
Cognitive surrender 講的是人如何慢慢把判斷權交出去；[7] 那篇 agent-human interaction 的研究則更直接指出，很多風險其實不是模型單點失誤，而是人與 agent 的互動機制本身有缺口。[13] HITL 成本文再補上一層：這種善後不是免費的，它有明確的人力與認知成本。[15]
這不是 skill growth，而是 maintenance growth。也因為這樣，真正該問的就不是成本先上升在哪裡，而是：Skill 為什麼沒有學會？
一旦你接受「問題不是長度，而是學不會」這個前提，下一個問題自然就會出現：這到底只是我的工作流太亂，還是公開世界也在發生同樣的事？
這不是空想。如果真的是 Skill 的結構性問題，那它應該不只出現在你桌上。
GitHub 公開世界也看得到相同訊號
先回答一個很實際的質疑：這是不是只是作者自己工作流太亂？
答案是：不是，但也不能寫得過頭。
先講清楚邊界：這是公開 repo 中的可觀察公共訊號，而不是完整 GitHub 普查。依照本文研究樣本（詳見資料來源 [21]），盤點了二十個 repo、七十六份 instruction / skill 檔案；其中同時帶有多重責任的檔案比例很高，SKILL.md 在長尾裡尤其明顯，最長樣本超過一萬五千行。
迪迪：這裡看的是公共訊號，不是全 GitHub 普查。
把問題攤開來看：不單是檔案變長，而是一份 SKILL.md 的肚子裡，開始同時管政策、管命令、管排錯、管流程——同一份檔案替太多種責任做決定。公開 repo 確實常見兩極：一邊是很短的分派檔，一邊是兼管一切的操作手冊型 Skill 檔。arXiv 論文在代理系統的技術債分析中，也觀察到了類似的責任混雜現象。[10]
這個樣本不能證明「所有 Agent Skill 都一定會變屎山」，但已足夠支持一個保守、也很重要的觀察：
instruction 檔肥胖化、責任混雜、Skill 檔 operating-manual 化，並不是私人幻覺。 這是一個可以從公共訊號中讀到的趨勢。arXiv 論文提供了系統層面的學術觀察，[10] Port 的寫法則是從工程實務角度的補強。[12]
這代表問題不是「有人不會寫 Skill」，而是 Skill 本身很容易沿著事故手冊化的方向演化。 而一旦它開始事故手冊化，成本問題就不再只是模型費，而是整個維護帳單。
那維護帳單到底從哪裡開始算？很多人反射性先看 Token 用量，但那是後果，不是根源。
真正浪費的不是 Token，而是沒有學會
先把 Token 成本的性質講清楚：它不是起點，而是後果。真正的問題是：Skill 沒有變成能力。 一旦它沒有變成能力，前面講的事故、補丁、例外與條件，就會一起改寫成維護帳單。
簡單說，成本不是另一道題，而是同一道題的下場。當它沒有變成能力，帳單就會一筆一筆來：
- 重試成本
- 人工補救成本
- 審查成本
- 批准成本
- 治理成本
- 重做同一件事的成本
所以真正該看的，不是單次呼叫成本，而是成功完成一件事的總成本。但如果用白話來講，意思其實很簡單：
一次 AI 呼叫便宜，不代表把事情做成便宜。
如果一個 Agent Skill 每次都要你重看、重跑、重批、重補、重驗證，那就算模型本身很便宜，總帳也未必便宜。HITL 成本文指出，很多團隊低估的不是模型費，而是人類被拉回來做審查、核對、重試時的認知稅。[15] 企業成本分析也有同一個提醒：只盯著 Token 成本，會漏掉任務完成、治理與維護這些真正會燒錢的部分。[17][20] 市場討論則把這種隱性維護成本，放回 AI Agent 技術債的語境裡。[18][19]
當你開始把帳算到「成功完成任務」而不是「這次呼叫花多少」時，就會發現另一個放大器：
Loop 越長，沉積越厚。
也就是說，問題不是 loop 本身有罪，而是 一個沒有學會的 Skill，會在 loop 裡被放大。
當 Skill 沒有學會，迴圈只會放大沉積
Addy Osmani 用 Loop Engineering（迴圈工程） 這個框架，來描述 AI Agent 使用方式正從單次 Prompt 走向可持續工作的系統：人不再只是逐步餵 Prompt，而是開始設計會自己運作的迴圈。這個框架很有價值，也很符合今天的 AI Workflow 現實。[1]
但放回本文主線，Loop 不是主角，而是放大器。真正的主角仍然是前面那句：
保存下來的不是能力，而是條件。
一旦保存的是條件，不是能力，loop 只會讓這些條件沉得更深、更難刪。
當你把 AI Agent 接上連接器、記憶、子代理、批准規則、工具規則、路由與外部狀態，整個系統的狀態面就會變厚。狀態一厚，Agent 雖然更能工作，Skill Debt 也更容易積下來。
長期運作的迴圈會留下記憶、權限、批准、規則與工作區殘留；如果沒有明確的退役與刪除紀律，系統就很容易走向「保留並補丁」。Orchestration Tax 從協調成本說明了追加機制的代價；[5] Intent Debt 從意圖流失角度提供了分析；[6] Addy Osmani 的長期運作代理討論點出了狀態累積的風險；[2] Anthropic 的有效代理框架說明了為什麼可組合性比記憶更關鍵；[4] OpenAI Codex 的批准文檔則是治理層面的實務參考。[16]
所以嚴格來說，Loop Engineering（迴圈工程）在這篇文章裡不是主角，它只是放大器：
如果 Skill 儲存的是能力，loop 放大的是能力；如果 Skill 儲存的是條件，loop 放大的是沉積。
這可以從多個角度看到：Anthropic 的框架是能力方向的定義來源；[4] ElixirData 的決策治理分析是治理補強；[9] arXiv 論文提供了系統層面的學術觀察；[10] Galileo 的框架則從生產環境角度做了補強。[11]
放大的東西多了，就需要有人負責刪。於是問題變成：人到底應該站在 loop 的哪裡？這就是治理工程（Governance Engineering）要處理的範圍。
Human in the Loop 不等於 Governance Loop
很多人以為只要 Human in the Loop（人在迴圈中），整件事就安全。但研究與實踐已經指出：形式上有人審查、有人批准，實際上演變成 Yes、Yes、Yes 的快速追認（Rubber-stamping），並不是有效監督。
這個問題來自多個角度。Orchestration Tax 說明了協調成本如何隨著迴圈增長而膨脹；[5] Cognitive Surrender 解釋了人如何不自覺地交出判斷權；[7] Agentic Code Review 則從程式碼審查的具體場景說明了形式審查的陷阱。[8] 更深層的結構問題，可以從人與代理互動論文看到：很多風險不是模型單點失誤，而是互動機制本身的缺口；[13] 測量依賴的框架則提供了另一種評估角度；[14] HITL 成本文補上了認知稅的計算；[15] OpenAI Codex 的批准文檔則是實務治理的參考。[16]
這裡最值得記住的一句話是：
人不一定要留在執行迴圈，但必須留在 Governance Loop（治理迴圈）。
人未必要卡在每一步執行裡，卻必須守在刪除、退役、重寫、權限收斂、重新驗證這些治理責任上。
對 Agent 來說，形式在場、精神不在場的狀態，比完全自動更危險，因為它製造假的安心感：表面上有人批准，實際上沒有人真正理解。這不是有效的 Human Oversight（Human Oversight，人類監督），也不是可靠的 AI Automation（AI Automation，AI 自動化）。測量依賴的框架說明了形式在場不等於有效監督；[14] 人與代理互動研究則從互動機制角度做了補強；[13] OpenAI Codex 的批准文檔則是具體的治理參考。[16]
迪迪：人在 loop 裡，不等於真的有人在治理。
而一旦批准只剩形式，所有 Yes 都會開始失去價格感——這直接通往下一個問題：Yes 可以先給，但帳要不要回來清？
Yes 可以給，但 Yes 負債要清
Agent 世界有一個很容易被低估的成本：Yes 負債。
每次批准以下事情，看起來都只是一次 Yes：
- 新增規則
- 新增記憶
- 新增連接器
- 新增臨時繞路
- 新增 Skill
但每一個 Yes，都會變成未來要維護的負債。當下看起來是通過，未來看起來就是負責。
這個結構本身就是一種債務累積機制：每一個 Yes 當下都像「又能跑」，系統繼續動了，問題暫時消失了。但帳上多了一筆未清項目——短期看起來沒事，長期卻會累積成逾期負債、維護帳單，最後連帳本持有人都記不清哪些是核心結構、哪些只是補丁。這也是代理治理（Agent Governance）和審查容量（Review Bandwidth）要一起看的原因。
最適合新手的比喻仍然是信用卡。AI Agent 像信用卡，今天可以先刷，但帳單不會自己消失。Yes 是可以給的，因為現實中你不可能每次都先做完完美治理才開始工作；但如果一直不清帳、不對帳、不刪帳，最後就會分不出哪些是肥肉，哪些是根骨。Orchestration Tax 說明了為什麼追加比刪除更容易；[5] Intent Debt 解釋了為什麼設計意圖會在追加中流失；[6] Galileo 的治理框架從生產環境角度提供了觀察；[11] HITL 成本文則補上了認知稅的計算。[15]
注意： Approval Debt 本身可以是另一篇文章的主題；這裡聚焦它只作為 Skill Debt 的累積機制，不展開成獨立治理議題。
所以最重要的一句不是「不要新增」，而是：
換句話說：Yes 是可以的，但要清 Yes 負債。
迪迪：每一次 Approved，都應該有人知道未來要不要清帳。
問題不是 Yes。問題是 Yes 從來沒有被清帳。當 Yes 不再被清理，系統就不會自然成熟，只會自然沉積。也就是說，文章真正的收尾不應該停在批判，而應該回到維護紀律。
沒有維護紀律的 Agent，不會自然成熟，只會自然沉積
很多人管理 Agent Skill 的方式，還停留在蓋建築物的想像：蓋好之後，只要能站著就算完成。但 Skill 比較像花園，不像建築物。 花園的自然狀態不是整齊，而是亂生；植物會橫向長、會長死枝、會搶養分、會彼此纏住。這類長期運作代理（Long-running Agents）尤其需要維護週期。
Skill 也是一樣。它不會因為你曾經寫好一次，就自動保持健康。沒有維護，它不會自然成熟，只會自然沉積。Addy Osmani 的長期運作代理討論點出了持續運行的維護需求；[2] Anthropic 的框架說明了有效代理需要設計維護週期；[4] arXiv 論文從系統層面提供了治理角度的分析；[10] Galileo 的框架則從生產環境角度做了觀察。[11]
所以如果你真的把 Agent Skill 當成營運資產，而不是一次性文案，維護紀律至少要包括：
- 定期修剪
- 移除死枝
- 清理過時規則
- 合併重複標準
- 退役不再使用的 Skill
- 在必要時重寫，而不是繼續補丁
- 用 Artifact-first（工件優先）保存可驗證的決策與產出
實務判斷： 如果你已經分不清哪些是根骨、哪些是肥肉，就不要再補規則。那通常不是維護，而是重建。
這裡還有一個最後的比喻，值得放在結尾前：根骨與肥肉。
在早期，你通常還看得出哪些是根骨、哪些是肥肉；但補丁一多，會彼此依賴、彼此引用，最後連補丁都會長成結構。當你已經分不清哪些是肥肉、哪些是根骨，問題就不再只是維護，而是重建。Intent Debt 從意圖流失角度解釋了根骨與肥肉難以分辨的根源；[6] ElixirData 的治理框架和 arXiv 論文則說明了這個階段的治理難度。[9][10]
而真正危險的 Agent，不是失敗的 Agent，而是它仍然成功，但已經沒有人知道為什麼。
給一人公司與獨立工作者的誠實建議：先從自己最常重做的那三件任務開始檢查。如果每次開工都需要重新補東西，那不是 Skill 的起點，而是殘骸的起點。
如果你已經開始留意自己的 Skill 是否也在悄悄累積補丁，接下來大概會冒出幾個自然疑問：這跟一般講的 prompt 太長有什麼不同？Skill 一直追加卻不敢退役，究竟是系統限制，還是治理出了問題？下面整理的常見問答，就是把正文為了節奏沒有展開的邊界與反例補上，方便你對照自己的實際情況判斷。
常見問題 FAQ
▎概念定義
Skill Debt 和 Prompt Debt 有什麼不同？
Prompt Debt（提示詞債）比較像一段指令本身變得過長、過於依賴特定措辭，或修改一次就容易牽一髮動全身。Skill Debt 則更大，它不只包含 Prompt，還包含記憶、工具規則、路由、批准規則、驗證出口與歷史臨時繞路。換句話說，Prompt Debt 是局部病灶，Skill Debt 比較像整個 Agent 操作層的慢性病。你可以有一段不太理想的 Prompt，卻仍然沒有 Skill Debt；但只要整個操作層開始補丁化、責任混雜、沒人敢刪，就已經很接近 Skill Debt。
Skill Debt 是不是只是 Prompt 太長？
不是。Prompt 太長通常只是表面症狀之一。真正的問題是，這個 Skill 保存下來的到底是任務目的、適用邊界、關鍵判斷與驗證出口，還是上次怎樣勉強成功的殘骸。若只是把事故處理痕跡越補越厚，就算字數不算誇張，也一樣可能已經很難維護。相反地，一份長但結構清楚、邊界清楚、驗證清楚的 Skill，不一定有 Skill Debt。
有保存 Skill，為什麼還不等於 Agent 學會？
因為「保存方法」和「形成能力」是兩件不同的事。保存方法只是把曾經發生過的流程留下來；形成能力，則意味著這個流程能跨不同上下文、不同工具狀態、不同版本條件被穩定重用。如果一個 Skill 只能在非常特定的工具版本、特定順序、特定補丁條件下勉強成立，那它保存下來的其實不是能力，而是條件。真正的學會，應該反映在下次更穩、更快、更少人工補救，而不是下次還要重新善後。
為什麼 Skill 會越用越廢？
因為它常常只會追加，不會退役；只會補丁，不會抽象化；只會保留臨時繞路，不會抽出原理。這種累積方式看似務實，因為每次都像是在解眼前問題，但長期結果是，Skill 會越來越像事故手冊，而不像能力模組。當新增變得容易、刪除變得困難，系統就不會自然收斂，而會自然膨脹。
Loop Engineering 和 Skill Debt 有什麼關係？
Loop Engineering（迴圈工程）是 Skill Debt 的放大器——如果 Skill 儲存的是能力，迴圈放大能力；如果 Skill 儲存的是條件，迴圈放大沉積。一旦系統開始持續工作，連接器、記憶、子代理、批准規則與工具規則也會一起增加，狀態面就會變厚。狀態一厚，沉積就更容易發生，Skill Debt 也更容易累積。所以 Loop Engineering 本身不是壞事，但它會放大維護與治理問題，迫使你從「會不會工作」走向「一年後還能不能維持可信地工作」。
什麼是 Yes 負債？
Yes 負債指的是，你每次對新規則、新記憶、新連接器、新臨時繞路、新 Skill 說 Yes，都在替未來增加一筆維護責任。當下看起來只是通過，未來卻變成要理解、要驗證、要決定敢不敢刪的成本。這就是為什麼「先加再說」常常會變成後期最昂貴的路線：因為新增的東西未必會自己消失，但清理卻一定要有人承擔。
▎證據與邊界
GitHub 公開樣本能證明什麼，不能證明什麼？
它能證明在高可見度公開 repo 中，確實能看到指令肥胖化、責任混雜、SKILL 檔變成操作手冊的公共訊號。它也能讓我們比較安心地說，這不是某一個人本地工作流特有的幻覺。但它不能證明整個 GitHub 都是這樣，更不能證明所有 Agent Skill 最後都會變成屎山。最安全的用法，是把它當作公共訊號，而不是全體普查。
資料來源：arXiv 提供代理式系統技術債的分析框架，不代表本文樣本可推論整個 GitHub。[10] 這裡只把公開 repo 取樣當公共訊號。
▎治理與維護
Human in the Loop 為什麼不一定安全？
因為形式上的人在場，不等於有效監督。研究與實務都指出，在高輸出量、高審批量的情況下，人很容易退化成快速追認：看起來有審查、有批准，實際上只是快速追認。這種狀態特別危險，因為表面上系統像是有保險，但實際上保險已經失效。真正要防的，不只是 Agent 自動化過頭，而是人類的注意力與治理能力撐不住輸出量。
人不在執行迴圈，是不是代表完全放手？
不是。人可以不在每一步執行迴圈裡，但不能退出治理迴圈。也就是說，人未必要手動執行每個步驟，卻必須保留對 Skill lifecycle、權限、例外規則、退役、重寫與驗證出口的最終治理權。如果連這層也放手，系統就會只剩執行能力在擴張，治理能力卻在縮水。那時問題就不是效率，而是失控。
什麼叫 Governance Loop？
意思是人不一定逐步操作 Agent，但必須保留對整個系統的治理責任：哪些規則應該保留、哪些臨時繞路應該清掉、哪些 Skill 應該退役、哪些權限應該收斂、哪些成果必須重新驗證。這和單純在最後按一個批准鍵很不一樣。後者只是形式上的在場，前者才是真正對系統負責。當 Agent 越來越能做事，這個治理角色反而越重要。
什麼時候應該維護，什麼時候其實要重建？
當你仍然看得出哪些是根骨、哪些是肥肉，維護通常還便宜。這表示雖然系統有負債，但結構尚可辨識，還能透過修剪、重寫局部、退役舊規則來收斂。可是一旦補丁開始彼此依賴、彼此引用，連你自己都分不清哪些是核心能力、哪些只是事故遺留，那往往就更接近重建，而不是維護。因為那已經不是清理枝葉，而是整個骨架都被債務改寫了。
如何避免 Skill 變成屎山？
關鍵不是完全不新增，而是建立生命週期。你需要版本化、修剪、退役、驗證出口、最小權限、artifact-first，並在必要時選擇重寫而不是一直補丁。更重要的是，要定期問：這條規則仍然是能力的一部分，還是只是某次事故留下來的殘骸？只要這個問題長期沒人問，Skill 幾乎一定會往屎山方向長。
這對一人公司、內容創作者、非技術背景 AI 使用者有什麼意義？
意義很直接：你不一定會先輸在模型能力，反而更可能先輸在自己建立的工作系統久了以後變得不可維護。對一人公司來說，這尤其危險，因為你沒有專門團隊替你治理那些越長越厚的 Skill。越早建立清理、退役、驗證與治理紀律，未來越不容易被自己的 Agent 系統反噬。
名詞解釋 Glossary
Skill Debt
AI Agent 系統中的一種技術債，指的是 Skill 在長期使用後累積了太多補丁、例外與歷史條件，變得難以理解、難以刪除、難以重用。它不是單一 Prompt 問題，而是整個操作層逐漸補丁化之後的維護負債。屎山代碼
軟體工程圈常見的網路說法，英文語境最接近 spaghetti code，也帶有 legacy code、patchwork code 那種「長年修補後變得難讀、難改、難維護」的意思。它往往不是一開始就爛，而是經過多年補丁與特例一路堆上去，最後變成一坨沒人敢清、但又不敢亂動的舊系統。本文用它作為「屎山 Skill」的對應參照。屎山 Skill
Skill Debt 的中文口語說法，對應開發者熟悉的「屎山代碼」。它強調的不是文字不好看，而是 Agent Skill 已經變成一套沒人敢改、也說不清為什麼還能跑的殘骸系統。AI Agent
不只會回答問題，而是能拆解任務、調用工具、執行多步驟工作的 AI 系統。重點不在會不會說，而在能不能動手把事情做完。AI Workflow
用 AI 完成工作的整體流程設計，包含輸入、工具、驗證、人類介入與產出交付。很多人以為只要模型夠強就夠，但真正影響穩定性的，往往是工作流本身怎樣被拆、怎樣被接、怎樣被驗。Agent Skill
給 AI Agent 重用的一種操作能力模組。理想狀態下，它應該保存任務目的、邊界、判斷與驗證方式，而不是只保存一次成功當下的工具條件。Hermes Agent
由 Nous Research 建構的自進化 AI 代理，內建學習閉環：能從經驗建立技能、在使用中改進技能、持久化知識，並跨會話累積對使用者的理解。它可在 VPS、GPU 叢集或 Serverless 基礎設施上運行，也可透過 Telegram 與雲端 VM 互動。Prompt Engineering
設計提示詞、結構、上下文與指令方式，讓模型更容易產出想要結果的方法。它很重要，但如果把整個 Agent 問題都縮成 Prompt 問題，就會看不到 Skill、工具、記憶與治理層面的負債。AI Automation
讓 AI 在較少人工逐步操作下，自動完成部分工作。很多人對 AI Automation 的期待，是省時間；但如果自動化背後堆滿臨時繞路與例外規則，省下的執行時間，最後可能會在維護時全部吐回去。Prompt Debt
指令本身因為過度依賴特定措辭、補丁太多、修改牽連太廣而形成的局部負債。它是 Skill Debt 的一部分，但不是全部。Context Rot
上下文逐漸失真、過時或互相污染的狀態。常見表現是：模型表面上還在延續任務，實際上已經開始建立在過期資訊上工作。Workflow Drift
原本設計好的工作流在多次修改、加例外、改順序之後，慢慢偏離最初目的的現象。流程還在走，但已經不再可預測。Loop Engineering
把 AI 從單次 Prompt 互動，推向可持續工作系統的一種框架。重點是設計迴圈，而不是每一步都人工餵指令。當 Skill 儲存的是條件而非能力時，迴圈會放大沉積而非效率。Agent Loop
AI Agent 接到目標後，會持續觀察、規劃、執行、檢查，再決定下一步的循環機制。迴圈越長、越能自己跑，代表能力可能更強；但也代表狀態更厚、沉積更快、治理更難。Governance Engineering
讓 AI 長期保持可信、可控、可修的設計方法——關心權限、批准、退役、驗證與維護紀律，是維持 Skill 不腐化的關鍵配套，但不是 Skill Debt 問題本身。Human in the Loop
指人在 AI 流程中保留參與或批准位置。但它不自動等於安全，因為形式上的在場，並不保證有效監督。Human Oversight
人類對 AI 輸出、決策與權限保留可檢查、可糾正、可叫停的能力；對 Skill Debt 管理而言，它比形式批准更關鍵，但本身不是 Skill Debt 的成因，而是其治理配套。Governance Loop
人類不一定要待在每一步執行裡，但必須待在刪除、退役、重寫、權限收斂、重新驗證這些治理責任裡。這才是讓 Agent 長期可控的核心位置。Technical Debt
為了先把事情做成，而留下來的未來維護成本。放在 Agent 世界裡，它不只出現在程式碼，也會出現在 Prompt、Skill、工具接法、記憶、權限與審查流程。Approval Debt
每一次新增規則、記憶、權限、連接器時，看起來只是一次批准；但這些批准都會變成未來要理解、維護、決定敢不敢刪的負債。這裡只把它作為 Skill Debt 的累積通道，不展開為獨立主題。Review Bandwidth
人類真正有能力仔細檢查、理解與判斷輸出的容量。AI 可以擴張輸出量，但審查容量不會跟著線性擴張。Agent Governance
管理 AI Agent 的權限、流程、批准、驗證、退役與責任分工的方法。這是防止 Skill 自然沉積的關鍵紀律，而非 Skill Debt 問題本身。Rubber-stamping
形式上有審查或批准，實際上卻只是在快速追認。這是很多 Human in the Loop 設計最容易出現的失效方式。Intent Debt
任務目標、限制、判斷標準沒有被清楚寫下，導致系統後來只剩行為，不剩理由的一種債。它讓 Agent 看似還在工作，實際上卻很難知道它是不是仍然朝原本的目標前進。Long-running Agents
能持續運作數小時、數天，甚至更長時間的 Agent 系統。這類系統尤其容易累積狀態、權限、記憶與維護負債，因此比單次工具更需要治理。Artifact-first
把意圖、限制、決策理由與可驗證輸出寫成檔案或工件，而不是只留在聊天上下文或人的短期記憶裡。這是降低 Skill 腐化的重要方式。資料來源
Addy Osmani, Loop Engineering — 定義 AI Agent 從單次 Prompt 走向可持續工作系統的分析框架。 ↑ ↑
Addy Osmani, Long-Running Agents — 解釋長期運作 Agent 的狀態累積與維護需求。 ↑ ↑ ↑ ↑ ↑
Addy Osmani, Agent Skills — 定義 Skill 作為可重用能力單元的設計原則。 ↑ ↑ ↑ ↑
Anthropic, Building Effective Agents — 本文對 effective agents 與可組合 Skill 的核心框架定義來源。 ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑
Addy Osmani, Orchestration Tax — 描述系統複雜化後協調成本的膨脹機制。 ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑
Addy Osmani, Intent Debt — 解釋設計意圖流失如何導致系統只剩行為不剩理由。 ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑
Addy Osmani, Cognitive Surrender — 說明人如何在不自覺中將判斷權交給 Agent。 ↑ ↑ ↑ ↑
Addy Osmani, Agentic Code Review — 討論 agentic 環境下 code review 的形式審查風險。 ↑ ↑ ↑
ElixirData, Context Engineering Lacks Decision Governance for AI Agents — 從決策治理角度分析 Agent Skill 的維護問題。 ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑
arXiv, Governing Technical Debt in Agentic AI Systems — 對 agentic AI 系統中技術債治理的學術層面系統分析。 ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑
Galileo, AI Governance Framework for Production Agents — 提供生產環境中 AI 治理的框架參考。 ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑
Port.io, The Hidden Technical Debt of Agentic Engineering — 從工程實務角度將零散現象收束為可維護性問題。 ↑ ↑ ↑
arXiv, Reframing LLM Agent Security as an Agent-Human Interaction Problem — 從互動機制角度指出風險不只是模型單點失誤。 ↑ ↑ ↑ ↑ ↑ ↑
arXiv, A Framework for Measuring Appropriate Reliance on Set-Valued AI Advice — 提供評估形式在場與有效監督差異的框架。 ↑ ↑ ↑ ↑
Innovate 24-7, The Hidden Cost of Human-in-the-Loop (HITL) & How to Fix It — 說明 HITL 的人力與認知成本結構。 ↑ ↑ ↑ ↑ ↑ ↑
OpenAI Developers, Agent approvals & security – Codex — Codex 在 approvals 與安全治理上的實務參考文檔。 ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑
EY, Agentic AI Enterprise Token Cost — 從企業規模提醒 token cost 不該是唯一成本指標。 ↑
AI Weekly, Microsoft Data Shows AI Agents Cost More Than Human Workers — 市場討論方向的參考來源。 ↑
GoPenAI, Why AI Agents Are the Quiet Technical Debt No One Talks About — 市場語言中對 AI Agent 技術債的討論。 ↑
Zartis, AI Agent Cost Optimisation: Why Token Cost Is the Wrong Number to Optimise — 直接指出優化 token cost 可能優化錯 KPI。 ↑ ↑
本文作者 GitHub 公開樣本手工盤點：高可見度公開 repo 二十個、instruction / skill 檔案七十六份；用作公共訊號，不作 GitHub 普查結論。 ↑
迪迪小結：工具會一直換，骨架才是你的資產。先用最便宜那層把流程跑通，確定值得，再升級。
