現在很多人都在用 AI，但多數人的使用方式，仍然停留在「每次重新下 Prompt、每次重新交代需求」的階段。這種方式雖然能解決單次問題，但只要任務是重複性的，你很快就會發現：真正花時間的，不是 AI 不夠強，而是你一直在重複做同樣的事。

這也是為什麼「Skill」這個概念越來越重要。

Skill 的價值，不只是讓 AI 回答得更好，而是把一整套你已經熟悉、常常重複的工作流程，變成 AI 可以直接接手執行的標準作業方式。原本要花 30 分鐘、40 分鐘，甚至 1 小時的任務，最後可能只需要一句話就能啟動。

這篇文章會從最基礎的觀念開始，帶你理解什麼是 Skill、為什麼要做 Skill、該怎麼從零開始做出第一個可用的 Skill，以及實際製作過程中最常遇到的問題與調整方式。就算你完全不會寫程式，也能照著這個思路開始做。

什麼是 Skill？為什麼它會讓 AI 真的「變能幹」

先用最簡單的方式理解：

Skill 就是給 AI 的工作手冊。

如果把 AI 想像成一位很聰明、學得很快、反應也很快的助理，那麼它最大的問題通常不是能力不足，而是不知道你要它怎麼做，做到什麼程度，最後要長成什麼樣子。

這時候，Skill 的作用就出現了。

它像是一份事先寫好的操作說明，讓 AI 知道：

  • 遇到什麼情境時要啟動這個 Skill
  • 啟動之後要依照什麼流程做事
  • 哪些資訊該抓、哪些該忽略
  • 最後要用什麼格式輸出
  • 是否需要再呼叫其他工具、腳本或參考資料

你可以把它想成菜譜。

一位廚師本來就會切菜、會炒菜、會掌握火候，但如果你要他穩定做出某一道特定料理，還是需要一份菜譜告訴他：食材怎麼準備、順序怎麼排、味道要往哪個方向調整。

AI 也是一樣。它本身很有能力，但沒有 Skill 時，它往往只能「臨場發揮」；有了 Skill，它就能「照著成熟流程穩定執行」。

Skill 的基本結構其實很簡單

很多人聽到要做 Skill，第一反應是覺得這應該很技術、很像在開發某種功能。但實際上，Skill 的核心通常沒有那麼複雜。

一個 Skill 資料夾，常見結構大致像這樣：

my-skill/
├── SKILL.md
├── scripts/
└── references/

 

其中最重要的，就是 SKILL.md。

也就是說，很多 Skill 的核心，真的就是一份 Markdown 文件。

SKILL.md 通常包含什麼

這份文件通常可以分成兩個層次來看。

第一個層次，是它的基本資訊，也就是讓系統先知道「這個 Skill 是做什麼的」。例如：

  • 名稱
  • Description
  • 適用情境
  • 觸發方式

第二個層次，才是具體操作流程，也就是：

  • AI 要怎麼執行這件事
  • 順序是什麼
  • 需要注意哪些判斷
  • 輸出格式怎麼寫
  • 有沒有其他腳本或參考文件要搭配使用

換句話說，SKILL.md 不是只是「介紹這個 Skill」，它更像是把一套工作流程，整理成 AI 看得懂、能照做的規則。

Description 為什麼特別重要

很多人在設計 Skill 時，會把重心全部放在後面的流程說明，反而忽略前面的 Description。但實際上，Description 常常是整個 Skill 能不能被正確使用的關鍵。

原因很簡單：

AI 並不是先完整讀完所有 Skill，再決定要不要用。它通常會先看描述，覺得符合，才進一步載入細節。

所以 Description 的功能很像是 Skill 的門面，也像是搜尋時的標題與摘要。

如果你把它寫得太模糊，例如：

  • 幫助處理很多事情
  • 一個很有用的工具
  • 自動化助手

這種寫法雖然看起來什麼都能包，但實際上反而會讓系統不知道什麼時候該用它。

反過來說，如果寫得太窄，也可能有問題。比如只寫單一觸發詞，或寫得過於侷限，導致明明可以適用的任務，系統卻沒有匹配到。

比較理想的 Description，通常有三個特徵：

  • 簡短
  • 具體
  • 一眼就知道用途

像是「聚合 20+ AI 資訊來源，生成每日 AI 日報」這種描述就很好，因為它同時說清楚了資料來源類型、任務內容與最終輸出。

為什麼你需要做自己的 Skill

真正適合做成 Skill 的，不是那些偶爾做一次的事情，而是你已經做了很多次、而且每次流程都差不多的工作。

例如：

  • 每天整理新聞
  • 固定把文章改寫成某種格式
  • 幫文章配圖
  • 做固定類型的研究摘要
  • 蒐集特定網站資訊並分類
  • 生成每週工作報告
  • 整理產品比較表

這類任務有一個共同點：
它們需要判斷，但流程高度重複。

這種工作最適合交給 Skill，因為它不是單純機械複製，也不是每次都完全不同，而是介於兩者之間。你已經知道怎麼做，只是一直重複做很浪費時間。

原始內容裡提到的案例很典型：每天早上要從 20 多個網站抓 AI 新聞、整理、分類、寫成日報，整套流程大約要 40 分鐘。後來做成一個 AI 日報 Skill，只要一句話就可以觸發整套流程。

這就是 Skill 最有價值的地方：

它不是讓 AI 幫你「回答一下」，而是讓 AI 幫你「持續接手一整段工作」。

從 0 到 1 做出第一個 Skill 的 5 個步驟

接下來是最重要的實作部分。你可以把這 5 步當成一個通用框架。只要是重複性任務，基本上都能套用。

第一步：先找到你的重複勞動

做 Skill 的起點，不是「我想做個很酷的功能」，而是「我到底哪件事一直重複做到很煩」。

這個順序很重要。

因為真正好用的 Skill，不是為了展示，而是為了解決一個你很熟悉、很常遇到，而且很明顯可以標準化的問題。

你可以用下面這幾個問題檢查：

  • 這件事我是不是做過很多次？
  • 每次流程是不是差不多？
  • 有沒有固定的輸入、固定的判斷方式、固定的輸出？
  • 這件事是不是讓我覺得「又要來一次」？

如果答案多半是是，那就很適合做成 Skill。

原始案例中，AI 日報 Skill 的起點就是：每天打開十幾個甚至二十多個網站，反覆檢查、篩選、彙整，做了兩個月之後終於受不了。這種情況其實就是最標準的 Skill 候選任務。

第二步：先手動完整做一遍

這一步非常重要，也是最容易被跳過的一步。

很多人會直接告訴 AI：「幫我做一個 Skill」，但自己其實沒有把整個流程走清楚。結果就是第一版常常很空泛，或是少了很多真正重要的細節。

比較好的做法是：

先不要急著做 Skill，自己完整手動做一次，把任務拆解出來。

你可以記錄這些東西：

  • 第一步做什麼
  • 第二步做什麼
  • 哪些來源值得保留
  • 哪些要排除
  • 哪些條件才算通過
  • 哪些輸出格式比較好用
  • 哪些地方最容易出錯

這份手動流程，其實就是你後面做 Skill 時最珍貴的素材。

因為 Skill 並不是憑空生成的，它是把你原本的工作方式，轉譯成 AI 可執行的版本。你手動跑得越清楚，後面做出來的 Skill 就越穩。

原始內容也明確提到，AI 日報 Skill 一開始效果不好，原因就是太早讓 AI 去做，自己還沒把完整流程梳理清楚。哪些資訊源該抓、哪些該捨棄、最後怎麼輸出，這些事情如果沒有先手動跑過，很難一次講清楚。

第三步：用自然語言把需求交給 AI

等你手動跑過一遍之後，就可以開始把這件事交給 AI。

這裡很多人會有一個誤解，以為必須會寫程式，或者要很正式地寫規格文件。其實不需要。

你只要像在跟同事交代工作一樣，把需求說清楚就行。

例如你可以這樣說：

  • 幫我建立一個 Skill，每天從多個 AI 資訊來源抓新聞
  • 幫我把內容按分類整理
  • 最後輸出成一份可閱讀的日報
  • 如果有需要，順便轉成適合社群發布的圖片格式

當你說完之後，AI 通常會開始追問細節，例如：

  • 觸發詞是什麼？
  • 需要抓哪些網站？
  • 輸出要 Markdown 還是 HTML？
  • 需要做圖片嗎？
  • 圖片是一張長圖還是多張分類圖？
  • 如何判斷內容是不是相關？

這些追問不是麻煩，而是很有價值，因為它會逼你把原本模糊的需求講清楚。

當你把這些問題一一回答完，AI 才有機會替你生成一份真正可用的 SKILL.md。

第四步：先跑起來，再慢慢改

Skill 做完之後，第一件事不是拿去炫耀，而是要實跑。

第一次跑的結果，大概率不會完美，這是正常的。

可能出現的狀況包括：

  • 抓到太多雜訊
  • 分類不準
  • 輸出太冗長
  • 排版不好讀
  • 有些來源不穩定
  • 判斷邏輯不夠成熟

真正實用的 Skill，幾乎都是一輪一輪改出來的，而不是一次成型。

比較常見的迭代節奏是：

第一輪先修大的問題。
例如流程跑不通、關鍵步驟漏掉、結果偏差太大。

第二輪修內容品質。
例如加強篩選、優化分類邏輯、補充判斷條件。

第三輪開始調細節。
例如語氣、格式、欄位順序、版面輸出方式。

原始內容也提到，通常改個 2 到 3 輪之後，Skill 的穩定度就會大幅提升。

第五步：穩定後再考慮分享

當你的 Skill 已經夠穩定、自己用得很順，你可以選擇分享出去，讓別人也能使用。

例如：

  • 放到 GitHub
  • 分享到 Skill 社群或平台
  • 做成自己的團隊工具

但這一步不是必要條件。

很多時候，一個 Skill 光是能幫你自己節省時間，就已經很有價值了。

實戰案例一：AI 日報 Skill 是怎麼做出來的

為了讓你更容易理解，我們來看原始內容中的第一個案例。

這個 Skill 解決了什麼問題

原本的工作流程是：

  • 打開 20 多個 AI 資訊來源
  • 看標題與內容
  • 篩掉沒價值的資訊
  • 按主題分類
  • 整理成日報格式
  • 再進一步做成適合發布的內容

這些來源包含科技媒體、官方部落格、研究平台、GitHub 等，例如 VentureBeat、TechCrunch、The Verge、OpenAI Blog、Anthropic Blog、HuggingFace Papers、GitHub Trending 等。

這種工作本身不難，但非常耗時間，而且每天都做幾乎一模一樣的事。

做成 Skill 之後，流程怎麼變

現在只要輸入一句「AI 日報」，整個流程就會自動展開：

  • 並發抓取 20+ 來源資料
  • 用多個 subagent 分工處理不同分類
  • 整理成 Markdown 形式的日報
  • 渲染成 Newsletter 風格的 HTML
  • 自動截圖
  • 依分類切成多張圖片

也就是說，原本需要人工不停切換網站、手動判斷與整理的工作，變成一句話就能觸發整套自動化流程。

這個案例給我們的啟示

最有價值的，不是它用了很多來源，也不是它最後能輸出圖片，而是它證明了一件事：

Skill 不是只能處理單一步驟，它可以接手一整段完整流程。

只要你能把工作拆清楚，Skill 不只是幫你生成內容，而是能串起資料抓取、判斷、彙整、轉換與輸出。

做 Skill 會踩到哪些坑？這個案例裡的三個典型問題

原始內容特別有價值的地方，是它沒有把 Skill 說得很完美，而是提到很多實際踩過的坑。這些經驗非常值得參考。

坑一：資料來源太多，不代表品質更好

一開始把 Hacker News 也納入資料源，直覺上好像很合理，因為 HN 有很多技術內容。但實際跑幾天之後發現，它的 AI 相關內容比例並不高，很多不相關資訊也被混進日報裡。

這裡的重點是：

做 Skill 時，不要迷信「來源越多越完整」。
很多時候，真正重要的是來源是否穩定、主題是否聚焦，而不是數量。

如果某個來源一直帶來噪音，與其花很多力氣優化過濾規則，不如直接移除。

坑二：輸出形式會影響最終實用性

原本日報做成一張很長的圖，但實際發布到社群之後發現，閱讀體驗很差，特別是在手機或通訊軟體裡，長圖通常不好讀。

後來改成按照大標題切圖，例如：

  • 今日頭條一張
  • 重大发布一張
  • 研究論文一張

這個調整本身沒有改變內容，但大幅提升了輸出的可用性。

這提醒我們：
Skill 不只要能做完任務，還要考慮結果是不是方便被真正使用。

坑三：判斷條件太單薄會影響品質

以 GitHub Trending 為例，如果只看專案名稱和簡介，很容易誤判一個專案是不是 AI 相關。後來增加了一層檢查，會進一步閱讀 README，再判斷是否真的相關，不相關的就直接排除。

這是一個很關鍵的設計思路：

當某個判斷容易失真時，不要只停在第一層訊號，而要補第二層驗證。

很多 Skill 做不好，不是因為 AI 能力不夠，而是因為你提供給它的判斷條件太淺。

實戰案例二：不是所有 Skill 都要從零開始

第二個案例是文章配圖 Skill，而這次不是自己完全重做，而是站在別人的基礎上改。

這個思路其實很重要，因為很多人一想到要做 Skill，就覺得一定要從空白開始設計。但現實中，最快、最有效率的方式，常常不是「完全自創」，而是「先找一個合理的基底，再改成自己的版本」。

原始內容提到，是先找到寶玉開源的文章配圖 Skill，發現其中有幾個地方做得很好：

  • 提示詞非常結構化
  • 不同類型的配圖，有對應的 prompt 模板
  • 配圖類型與文章內容之間，有明確匹配規則
  • 整體工作流很完整，從分析文章到插入圖片都串好了

例如文章中如果出現數據與指標，就偏向 infographic；如果是步驟與流程，就偏向 flowchart；如果是對比型內容，就偏向 comparison；如果是架構解說，就偏向 framework。

這種設計的好處是：
它不是讓 AI 憑感覺配圖，而是根據文章訊號做出較一致的判斷。

這個案例真正改了什麼

作者沒有重做整套流程，而是針對一個自己不認同的點做調整：固定視覺風格。

原版本把配圖風格鎖得很死，這樣雖然穩定，但所有文章的圖都容易長得很像。技術文、敘事文、教學文，最後可能都套同一種視覺語言。

後來的改法是：

  • 保留一些底線規則，例如乾淨背景、扁平向量、資訊優先、主色不超過 3 個
  • 但把「具體視覺風格」交給 AI 根據文章內容判斷

這樣一來：

  • 技術文章可以更有科技感
  • 敘事文章可以偏暖色或更柔和
  • 教學文章可以偏卡片式步驟結構

也就是說，它沒有把所有東西推翻，而是保留成熟的骨架，只改最關鍵的策略點。

這個案例告訴我們：

做 Skill 最快的方式，很多時候不是從零做，而是從可用版本出發，調整成自己的工作方式。

做 Skill 時最重要的四個原則

綜合前面的案例，可以整理出幾個很實用的原則。

原則一：Description 一定要寫準

這個前面已經提過，但真的值得再講一次。

Description 不是裝飾，它是 Skill 是否會被正確使用的入口。

你可以把它當成一句電梯簡報：
在最短的字數裡，說清楚這個 Skill 處理什麼任務。

太空泛，AI 不知道何時啟動。
太侷限，該啟動時又不會啟動。

原則二：一定要先手動跑流程

如果你自己都還沒搞清楚這件事怎麼做，就急著讓 AI 封裝成 Skill，最後只會得到一個看似完整、其實不耐用的東西。

Skill 的本質不是魔法，而是把你已經理解的流程，整理成可重複使用的形式。

所以，先做一次、看清楚問題、記下步驟，再交給 AI。

原則三：一個 Skill 解決一個核心問題

很多人剛開始做 Skill 時，很容易貪心，想把很多事情都塞在同一個 Skill 裡面。結果就是整體變得很肥大，判斷複雜，而且每個部分都不夠穩。

比較好的做法是：

  • 日報是日報的 Skill
  • 配圖是配圖的 Skill
  • 排版是排版的 Skill
  • 審稿是審稿的 Skill

每個 Skill 都有明確邊界，才能各自優化、各自迭代。

原則四：用迭代心態看待 Skill

第一版不好，很正常。

真正要避免的不是做不好，而是做一次之後就不改了。

Skill 最常見的成熟路徑不是「一開始就完美」，而是：

  • 先能用
  • 再變準
  • 再變穩
  • 最後才變漂亮

只要你願意多跑幾輪，每一輪修一點點，它很快就會變成你真正離不開的工具。

三個值得優先安裝的輔助 Skills

原始內容最後也提到三個很值得裝的輔助 Skill，它們本身不是為了完成某一項業務任務，而是為了讓你更容易找到 Skill、做 Skill、檢查 Skill。

1. find-skills：幫你先找現成解法

現在 Skill 生態越來越大，平台上的 Skill 數量很多，不可能靠手動一個一個翻。

這時候 find-skills 的作用，就是當你說出一個需求時，它先幫你找：

  • 有沒有現成可用的 Skill
  • 哪些方案比較接近你的需求
  • 哪些值得參考甚至直接安裝

這樣你就不用每次都從零開始。

2. skill-creator：把自然語言需求轉成 Skill

如果沒有找到合適的現成方案，就可以交給 skill-creator。

你只要用自然語言說明需求，它就能幫你生成標準格式的 SKILL.md。這相當於把「需求轉規格」這件事標準化了。

3. skill-vetter：安裝前先做安全檢查

這點很容易被忽略，但很重要。

因為第三方 Skill 不一定都安全，尤其如果裡面涉及外部呼叫、命令執行、權限操作，風險會更高。

skill-vetter 的作用就是在安裝前先幫你檢查：

  • 有沒有異常權限請求
  • 有沒有可疑指令
  • 有沒有不明外部呼叫

原始內容甚至提到社群曾出現過供應鏈攻擊事件，惡意 Skill 會修改使用者配置。這也提醒我們：
不是只要功能好用就好，安全性也必須納入考量。

最後總結：Skill 的本質，不是炫技，而是把工作流程留下來

很多人第一次接觸 Skill，會把焦點放在「這是不是很進階」、「這是不是工程師才會做的事」。但其實真正重要的，不是技術門檻，而是你有沒有把自己的工作方法整理清楚。

Skill 的本質很簡單：

把你已經熟悉的一套重複流程，整理成 AI 能讀、能用、能重複執行的手冊。

它不是要你突然變成開發者，而是讓你把原本腦中的工作步驟，慢慢變成一個可複用的系統。

從這個角度看，Skill 最有價值的地方不只是省時間，而是它會逼你重新理解自己的工作：

  • 哪些步驟是必要的
  • 哪些判斷其實可以標準化
  • 哪些地方最容易出錯
  • 哪些輸出才是真正有用的

當你開始累積一個又一個 Skill，你得到的不只是幾個方便的小工具，而是一套越來越成熟的 AI 工作系統。

原本每次都要重新做的事，會慢慢變成可複製、可優化、可擴充的流程。等到那時候，你會發現自己不是在「偶爾用 AI 幫忙」，而是真的開始建立一個能長期協作的 AI 助理體系。

本文參考自 实战教学:从0到1写出一个你自己的Skill