最近科技圈流傳著一種很極端的畫面：有工程師把整臺電腦幾乎交給完全自主運作的 AI 代理人，讓它自己讀信、自己寫程式、自己部署上線。但這跟多數人的日常還有一段距離，我們真正在用的，還是開一個聊天視窗、把來龍去脈講清楚的對話式 AI。而就在這個大部分人每天都在用的世界裡，最近冒出了一個新關鍵字 Skill：它本質上只是一個資料夾、一份說明書，卻在短短幾個月長成跨 Claude、ChatGPT、Gemini 都能採用的開放格式。

數位時代創新長黃亮崢 James 邀請 AWS 社群英雄蔣鐙緯 Ernest，一起拆解 Skill 到底是什麼、要去哪裡裝、非工程師怎麼從零開始寫，以及安裝別人的 Skill 時，有哪些不能不注意的風險。

聽完這集你可學到

1.Skill 的本質是一份 SOP 說明書 Skill 中文叫「技能」，實務上就是放在 AI 軟體指定位置的一個資料夾，裡面至少有一個 SKILL.md，交代這個技能叫什麼名字、什麼時候該被觸發、第一步做什麼、第二步做什麼。會議記錄範本、參考資料、要呼叫的程式，都能一起包進同一個資料夾。

2.它和 Prompt、Project 差在哪 提示詞每次對話都得重貼一次；Project 或 Gems 雖然存得起來，仍需你多做一次設定。Skill 則是設定一次之後，AI 會依照你寫好的觸發條件自行判斷該不該把這份 SOP 拿出來用，而且你隨時可以回頭修改步驟，不必重複再教它一遍。

3.觸發關鍵字寫不好，後面白寫 觸發分成人類自己記得去呼叫，以及由 AI 判斷要不要呼叫兩種。難處在於必須用 AI 語境裡真的會出現的字眼來命名與設定條件。若寫成「肚子餓就觸發」，但對話中從沒出現這三個字，這個技能就永遠不會被叫出來。步驟寫得再完整，沒觸發等於零。

4.非工程師的起手式：重複三次以上 財務、HR、招募、法務、行銷背景的人都已經在寫自己的 Skill。不必一開始就挑大題目，回頭看看上禮拜做過的事，只要是重複三次以上、做起來有點無聊、有點像機器人的任務，就是好題目。直接找 AI 說你想把這件事做成 Skill，它會反過來訪談你。

5.顆粒度怎麼抓，兩種寫法都行 一種是全部寫在同一本 SKILL.md，細節流程外掛到 reference 目錄的小檔案；另一種是依動作拆成多支 Skill，再加一支中控來串聯。前者好維護但只有一個觸發點，後者彈性高卻要同時維護好幾本說明書，可以先試第一種，跑不順再拆。

6.裝別人的 Skill，先請 AI 逐行看過 Skill 資料夾裡除了文字範本，其實可以放程式碼並執行，這是最需要警覺的地方。拿到第三方的 Skill，先請你的 AI 檢查裡面有沒有程式碼、逐行解釋執行邏輯，你自己看不懂沒關係，讓 AI 幫你看懂，確認過再裝進去。

7.技能不是多多益善 裝太多會出現三種副作用：有些技能再也沒被觸發過、不同來源的技能用了相同觸發條件互相打架，以及每個 Skill 開頭那段描述都會被吃進提示詞，數量一多就墊高 input token。比較務實的做法是依當下任務把用不到的技能先關掉。

Ernest 最後把 Skill 拉回一個很人性的比喻：想學畫畫，在沒有 AI 的年代我們會找老師、找教材，工作上不會做的事就找前輩教，而過程中做的筆記，某種程度就是給人類自己看的 Skill。現在只是這件事重複到有點煩了，於是把它交給 AI 去完成。所以他的判斷標準很簡單：第一，只要是重複性的，就一定要把它記下來；第二，老師或前輩教的方法不必死守，隨著環境參數改變、材料與做法更新，你可以留著舊版本，重新寫一份屬於自己的。久了之後，Skill 加上你累積的實作經驗，會真正對準你的實務痛點，而不是跟著媒體說哪個很熱就一定要用。真正好用的 Skill 都是從真實操作裡長出來的：抄來不會馬上就能用，你一定會改，也一定會邀請 AI 陪你一起改。

James 在收尾時則把這件事和二十年前應用程式商店出現的那一刻並置。相似的是，只要有了開放標準與格式，生態系就會快速長出來，官方之外還冒出各種第三方技能市集，看得人眼花撩亂；不一樣的是，這一次官方沒有給出統一的守門人資格，也沒有相對應的審查機制。把關的責任因此回到使用者自己手上：這也是為什麼 Ernest 一再提醒，裝每一份技能檔案之前，只要有看不懂的地方，就先請你的對話式 AI 幫你把它解釋清楚。

Powered by Firstory Hosting