萬字長文：做了些爆款 Skills 以後，我對 Skills 的看法
整理版優先睇
Agent 唔係抹平能力差距，而係放大差距；Skill 係將專家經驗封裝成可複用能力單元，係彌合呢個差距嘅關鍵。
呢篇文章出自一位做過多個爆款 Skills 嘅創作者，佢分享咗自己對 Skills 嘅深刻理解同實戰經驗。作者發現，大眾對 Agent 嘅理解仲停留喺「聊天框」，但頭部用戶已經喺搭系統；Agent 唔係抹平能力差距，反而係放大差距——目標清晰、品味好嘅人會被放大，混亂嘅人亦會被放大混亂。
為咗彌合呢個差距，作者提出 Skill 係能力商品，唔係單純嘅提示詞。Skill 將提示詞、流程、工具調用、模板、腳本同經驗打包成可安裝、可調用、可迭代嘅能力單元。佢用自己嘅 PPT Skill、社交媒體卡片 Skill、Logo Generator Skill 同 AI Desk Card 做例子，說明 Skill 嘅核心係「人把咩經驗變成可調用嘅能力」。好 Skill 嘅架構係「中心短，輻射厚」：SKILL.md 只放高信號流程，詳細材料放 references/、scripts/、assets/ 按需加載。
作者強調，Skill 嘅質量要好似代碼質量咁維護，要基於真實失敗寫 gotchas，而且設計類 Skill 嘅本質係將品味變成約束——排除醜嘅選項，保護輸出下限。最後佢展望 Skill 生態，認為平台要做好基礎體驗同內容分發，而創作者要透過內容飛輪互相餵養。Skill 係 Agent 生態入面真正嘅大機會。
- Agent 唔係抹平能力差距，而係放大差距；Skill 係彌合呢個差距嘅關鍵能力單元。
- Skill 係能力商品，將專家經驗、工作流、品味同工具調用封裝成可複用、可分發嘅包，唔係單純嘅提示詞。
- 好 Skill 嘅架構係「中心短，輻射厚」：SKILL.md 只放高信號流程，其他材料放子目錄按需加載，避免塞滿上下文。
- 設計類 Skill 嘅核心係將專業品味變成模型可執行嘅約束，例如排除純黑純白、限制色板、後驗檢查，保護輸出下限。
- Skill 嘅生命週期由真實需求開始，經過高質量產物、抽象流程、工程化模板，再透過內容分發同反饋持續迭代。
認知割裂：Agent 放大咗能力差距
作者發現一個好大嘅認知割裂：頭部用戶已經喺度搭系統，普通用戶仲喺度問聊天框。大眾以為 AI 會帶嚟平權，但實際上，Agent 唔係抹平能力差距，而係放大差距。目標清晰、上下文好、品味同判斷強嘅人會被放大；目標混亂、冇文檔、冇判斷嘅人亦會被放大混亂。
去年仲可以靠產品設計同用戶教育降低門檻，但今年已經好難靠簡單嘅 UX 彌合呢個差距。而 Skill 就係一個關鍵解決方案，佢可以將專家經驗封裝成可複用嘅能力單元，等普通用戶都可以用到頭部用戶驗證過嘅能力。
Skill：能力商品，唔止係提示詞
作者對 Skill 嘅定義係：將專家經驗、工作流、品味同工具調用封裝成可分發、可複用、可迭代嘅 Agent 能力單元。Prompt 本身好難成為產品，因為容易複製、難以分發、冇版本管理；而 Skill 將提示詞、規則、示例、工具調用、文件結構、腳本同使用說明打包，變成一個可以安裝、調用、迭代嘅能力包。
好多任務唔係一句提示詞解決嘅，例如 PPT Skill 嘅流程：讀取材料、分析需求、選擇模板、調用工具、生成產物、驗證結果、修復問題、導出文件。呢啲背後真正有價值嘅，係人嘅演示經驗被外化咗。
- PPT Skill：唔係「生成 PPT」咁簡單，而要處理主題、頁數、配圖、版式、後驗檢查、修正溢出同節奏重複等問題。
- 社交媒體卡片 Skill：處理11類內容、兩套視覺系統、28個版式骨架，優先真實圖片，規避 AI 圖限流。
- Logo Generator Skill：先生成 SVG 變體，再展示圖同 WebGL 背景，將 Logo 本體、展示場景、交互背景拆開處理。
- AI Desk Card：讓 Agent 接管屏幕邊緣物理信息位，包括固件燒錄、Wi-Fi 配置、信息推送、定時任務等。
好 Skill 嘅架構：中心短，輻射厚
作者指出，好嘅 Skill 唔止係一個 SKILL.md 文件，而係一個目錄。SKILL.md 只係入口，旁邊仲可以有 scripts/、references/、assets/、模板、schema、配置文件等。文件系統本身就係一種上下文工程，可以避免將複雜內容一次過塞俾模型。
Skill 嘅 quality 要好似代碼 quality 咁維護。一個可靠嘅生命週期包括：先用冇 Skill 嘅 Agent 跑真實任務揾錯處；基於真實 query 寫 eval；先調 description 確保該加載時加載；寫主體時刪除顯而易見嘅內容，只保留會改變模型行為嘅判斷；將失敗案例追加到 gotchas；再做跨模型測試。每個 Skill 都係一種税，所以每一句都要問：冇呢句，Agent 會唔會做錯？如果唔會，就刪。
設計 Skill 嘅本質：將品味變成約束
設計類 Skill 唔係簡單嘅「AI 會畫圖」，而係要解決模型不穩定、圖像限流、文字唔鋭利、排版不可控等問題。作者認為，設計 Skill 嘅核心係將專業品味變成模型可執行嘅限制。模型默認會收斂到平庸模式（Tailwind 大色塊、紫色漸變、emoji 堆砌），所以需要主觀但明確嘅約束。
- 1 唔使用純白同純黑，降低刺眼同廉價感。
- 2 唔畀用戶任意輸入 hex，只提供經過驗證嘅主題色板。
- 3 唔用紫色多彩漸變、發光同大面積 blur 作為主視覺捷徑。
- 4 動畫只喺必要時使用，而且只鬱 transform 同 opacity。
- 5 圖文卡片優先真實攝影同截圖美化，AI 生圖只係兜底。
- 6 文字必須根據圖像主體、明度同可讀區域自適應落點、字色、遮罩同斷行。
呢啲規則看似限制自由，實際係喺保護輸出下限。好看唔係玄學，而係可拆解、可編碼、可檢查嘅行業常識。PPT Skill 同社交媒體卡片 Skill 嘅共同方法係將 AI 嘅任務從「自由設計」降級成「喺高質量骨架裏面填充」。
Skill 生態：內容飛輪同平台建議
作者觀察到，Skill 嘅生態唔應該只係一個倉庫列表。每個 Skill 都應該有說明頁，講清楚解決咩問題、適合咩場景、輸入輸出係咩、典型提示詞、結果截圖、用家評價、常見失敗情況同安裝方法。GitHub 適合做基礎分發同跨平台覆蓋，小紅書適合做視覺內容同使用案例分發，應用商店式分發則有精準推薦同商業轉化潛力。
內容 Skill 嘅路線好有趣：先做出一個能用嘅 Skill，再將製作過程、設計判斷同使用場景寫成傳播內容。文章、產品、案例、開源倉庫、社交反饋會互相餵養，形成複利飛輪。作者認為，用戶唔關心概念，只關心結果，所以產品層唔應該堆術語。
如果睇唔曬嘅話，可以幫手點個讚，收藏咗之後再睇，多謝。
我最近幾次傾Skills，有一個越嚟越明確嘅判斷：
大家而家都喺度講Agent，但係大多數人其實仲未真正理解Agent。
大眾理解入面嘅Agent，好多時都仲係一個傾偈框。
你輸入一句話，佢回答一段文字；你再輸入一句，佢繼續回答。
呢個視角之下，AI好似天然會帶嚟一種平權：以前唔識寫code嘅人可以寫code，唔識做PPT嘅人可以做PPT，唔識剪片嘅人可以剪片。
只要模型夠強，大家嘅能力差距就會被抹平。
但我越嚟越覺得，呢個判斷係錯嘅。Agent唔係簡單抹平能力差距，而係放大能力差距。
頭部用戶已經預設理解Agent嘅組成：
文檔、規則、memory、loop、MCP、CLI、工具調用、權限、安全沙箱、上下文工程、定時任務、心跳、文件系統、代碼執行同Skill。
但普通用戶淨係知"Agent可以寫code""Agent可以調用Skill"，並唔知Agent嘅上限從邊度嚟，亦唔知自己應該點樣組織目標、資料同流程，先至可以令Agent真正工作。
Agent：呢度指嘅唔止係傾偈機械人，而係能理解目標、規劃步驟、調用工具同持續執行任務嘅AI系統。
Memory：Agent用嚟保存長期偏好、項目狀態同歷史決策嘅外部記憶，唔等同於模型訓練記憶。
Loop：Agent反覆"思考、調工具、觀察結果、再決定下一步"嘅執行循環。
呢度就出現咗一個好大嘅認知割裂：頭部用戶已經喺度搭系統，普通用戶仲喺度問傾偈框。
目標清晰、上下文好、品味同判斷強嘅人，會被Agent放大；目標混亂、冇文檔、冇判斷嘅人，亦會被Agent放大混亂。
所以用戶會出現K型分化。舊年仲可以靠產品設計、交互設計同用戶教育降低一啲門檻，今年我覺得已經好難靠簡單UX彌合呢個差距。
Skill就可以彌合Agent使用能力差距。
Skill係能力商品，唔止係提示詞
我而家對Skill嘅一句話定義係：
Skill係將專家經驗、工作流、品味同工具調用封裝成可分發、可複用、可迭代嘅Agent能力單元。
Skill：將提示詞、流程、工具調用、模板、腳本、邊界同經驗打包起嚟嘅可複用能力單元。
佢唔係單純嘅提示詞，亦唔係傳統意義上嘅App。
佢更似Agent時代嘅"能力商品"。用戶唔需要理解底層嘅MCP、CLI、workflow、memory、loop、模型選擇、代碼執行同上下文工程，只需要知道：
佢解決咩問題，產出咩結果，點樣使用，人哋用成點。
提示詞本身好難成為產品。佢容易俾人複製，難分發，冇版本管理，亦缺少安裝同調用語義。
Skill將提示詞、規則、示例、工具調用、文件結構、腳本、依賴同使用說明打包起嚟，令佢變成一個可以安裝、調用、迭代同傳播嘅能力包。
所以Skill同Prompt本質上並非完全唔同，但Skill嘅調用效率更高，分發同理解成本更低，亦可以承載更多工程化內容。
更重要嘅係，好多任務唔係一句提示詞可以解決嘅。
佢哋係一組穩定流程：讀取材料，分析需求，選擇模板，調用工具，生成產物，驗證結果，修復問題，導出文件。
Skill將呢套流程從一次性對話中抽返出嚟，變成可以反覆調用嘅工作流。
比如 PPT Skill嘅流程唔係"生成PPT"咁簡單。
佢要讀取文章或大綱，詢問主題、頁數同配圖，選擇主題、顏色同版式，生成HTML PPT，自動後驗檢查常見問題，再修正缺屬性、未居中、溢出、圖片裁切、節奏重複等問題，必要時仲要調用圖像模型生成配圖，最後輸出可演示、可分享嘅文件。
呢個背後真正有價值嘅，係Skill將人嘅演示經驗外化咗。
Skill嘅核心，係將人嘅經驗外化
我做嘅設計類Skill好能說明呢一點。
真正有價值嘅部分係將人嘅審美、版式判斷、設計系統經驗、模板選擇、圖片裁切規則、明暗遮罩規則、字體同顏色規則固化入去。
呢個要求創作者同時識三件事：傳統專業知識，AI嘅上下限，以及產品化思維。
傳統專業知識決定你知道咩結果算好。例如設計、剪片、寫作、健身、法律、商業化投放，每個行業都有大量隱性判斷。AI嘅上下限決定你知道模型咩可以做、咩做得唔穩、咩必須工程化兜底。
產品化思維決定你知道用戶場景、使用門檻、反饋路徑同穩定性要求。
呢個亦係我做幾個Skill時最深嘅體會。
PPT Skill最開始唔係為咗"做一個Skill"，而係因為我真係要做一場分享。
第一版基本成型之後，我透過五六輪對話調整間距、字號、字體、顏色、配圖、重複內容、WebGL背景等問題。
講完之後發現大家最關心嘅唔係分享本身，而係PPT點樣做，於是先將呢套模板同流程沉澱成Skill。
社交媒體卡片Skill 亦唔係憑空抽象出嚟嘅。佢嚟自非常具體嘅內容分發需求：
3:4豎版圖文卡片，適配小紅書、公眾號、Twitter等唔同場景。佢要處理11類內容，兩套視覺系統，28個版式骨架，真實圖片+Coding排版，仲要規避AI圖限流、文字唔鋭利、平台風格唔匹配等問題。
Logo Generator Skill 亦係同一邏輯。佢冇直接俾圖像模型一把梭生成Logo，因為圖片模型嘅文字、結構同可編輯性唔穩定。
佢選擇先生成SVG Logo變體，再生成展示圖同WebGL背景，將Logo本體、展示場景同交互背景拆成唔同層，分別用最適合嘅技術處理。
AI Desk Card 則說明Skill嘅邊界可以擴展到物理環境。
佢令Agent接管屏幕邊緣嘅物理信息位：固件燒錄、Wi-Fi配置、信息推送、定時任務、memory、todo、日曆、GitHub展示、墨水屏刷新，都可以被封裝成一套Skill。
呢啲案例共同說明：Skill嘅核心係"人將咩經驗變成了可調用嘅能力"。
用戶唔關心概念，用戶關心結果
對普通用戶嚟講，Skill、MCP、CLI、Plugin叫咩名唔重要。
佢哋關心嘅係：呢個功能解決咩問題，適合咩場景，我㩒一下用唔用到，需要輸入咩材料，結果係點樣，人哋用成點。
MCP：Model Context Protocol，可以理解為讓AI以統一方式連接外部工具、數據源同服務嘅協議。
CLI：Command Line Interface，命令行工具；對Agent嚟講，佢通常係比圖形界面更穩定、更容易自動化嘅操作入口。
因此，面向用戶嘅產品層唔應該堆術語。Codex將好多嘢統一叫插件，我覺得就係一個正確方向：弱化概念，強調功能。
底層可以係Skill、MCP、CLI或原生Plugin；用戶只需要知道佢做到啲咩。
但對產品同創作者嚟講，呢啲底層形態嘅區別又很重要。
Skill適合承載相對垂直、可描述、可複用嘅工作，例如PPT、社交媒體卡片、文章配圖、寫作潤色、視頻包裝、簡歷優化、數據可視化、某個行業SOP。
MCP更適合Agent架構中嘅原子服務同上下文連接，例如地圖、瀏覽器、網盤、設計稿、數據庫、企業API。
CLI就係目前好現實嘅通用Plugin形態：命令行、代碼、Skill都可以封裝入去，亦唔綁定單一Agent平台。
飛書CLI就係一個好好嘅例子。用戶唔使理解200幾條命令，亦唔使知道背後係邊個API。
佢只需要話"幫我將今日嘅智能紀要拉到筆記度"，Agent背後可以搜索雲文檔、讀取妙記、下載逐句轉寫、寫入本地Markdown、建立反向連結。
用戶見到嘅係結果，Agent用嘅係工具，Skill封裝嘅係流程。
呢個亦係點解Skill、CLI同MCP嘅關係唔可以只從技術概念上理解。
佢哋最終都要落到一個問題：點樣令普通用戶用得上頭部用戶已經驗證過嘅能力。
好Skill嘅架構：中心短，輻射厚
好多人會將Skill理解成一個SKILL.md文件，呢個只係講啱一半。
SKILL.md：好多Skill嘅入口說明文件，用嚟話俾Agent知幾時加載呢個能力、跟咩流程執行、邊啲坑唔可以踩。
好嘅Skill往往係一個目錄。SKILL.md只係入口，旁邊仲可以有scripts/、references/、assets/、模板、schema、配置文件、子Skill同特殊案例。
複雜Skill唔怕有複雜內容，怕嘅係將複雜內容一次性塞俾模型。文件系統本身就係一種上下文工程。
上下文窗口：AI一次可以"睇到"同處理嘅信息範圍，文檔、代碼、聊天記錄同工具說明都會佔用佢。
好Skill嘅信息架構應該係"中心短，輻射厚"。
SKILL.md只放高信號流程同判斷；references/放重文檔同領域材料，按條件讀取；scripts/放確定性邏輯，令Agent調用而唔係重寫；assets/放模板、schema、示例、字體、主題同版式骨架；配置文件或穩定數據目錄放首次配置、偏好同歷史記錄。
呢度有個好關鍵嘅點：Skill嘅description唔係宣傳語，亦唔係功能摘要，係路由觸發器。
好嘅description應該描述用戶幾時需要佢，最好嚟自真實用戶表達；壞嘅description只係解釋"呢個Skill做咩"。
例如一個PPT Skill，唔應該寫"呢個Skill可以生成靚PPT"。
佢應該寫"當用戶需要將文章、大綱或演講內容轉成可演示HTML PPT時加載"。前者係廣告，後者係Agent嘅判斷條件。
呢個可以解釋點解"將所有能力塞入一個大Agent"唔係好方向。
大而全嘅harness會將工具定義、協議細節同長文檔塞滿上下文，帶嚟更高延遲、更高token成本同更多誤用。
反過來，薄harness只提供最小運行環境，Skill作為按需加載嘅能力包，先可以令系統長期複利。
Harness：運行Agent嘅外層程序，負責模型循環、文件讀寫、上下文管理同安全邊界。
更穩嘅架構係Thin Harness, Fat Skills：harness保持薄，負責跑模型循環、讀寫文件、管理上下文、執行權限同安全邊界；
Skill變厚，承載流程、判斷、領域知識、模板、腳本、資產、gotchas同eval；
確定性工具下沉俾CLI、scripts或API；模型留喺理解、判斷、綜合、取捨同表達呢啲更適合佢嘅部分。
Thin Harness, Fat Skills：令Agent底層運行環境保持輕，將具體流程、領域知識、模板、腳本同失敗經驗放入按需加載嘅Skill裏面。
Skill質量要似代碼質量咁維護
好Skill唔係一次寫完。佢需要維護，而且要似代碼質量咁維護。
一個比較可靠嘅生命週期係：
先用冇Skill嘅Agent跑真實任務，揾到佢會錯喺邊度；
基於真實query寫eval，包括正例、反例同forbidden load；
先調description，確保該加載時加載，唔該加載時唔加載；
寫主體時刪除顯而易見嘅內容，只保留會改變模型行為嘅判斷；
將失敗案例追加到gotchas，而唔係不斷加長主流程；改description或路由邊界時補eval；
再做跨模型測試，睇唔同編排模型對Skill觸發同執行嘅差異。
Eval：用一組真實或模擬任務測試Skill係咪按預期觸發、執行同交付結果。
Gotchas：從真實失敗入面總結出嚟嘅"唔好咁做"清單，往往比正向說明更能提升Skill穩定性。
每個Skill都係一種税。
佢進入索引之後，每個會話、每個用戶都為佢嘅name同description付上下文成本；
佢被加載之後，後續對話都為主體內容付成本。
所以每一句都要問：冇呢句，Agent會唔會做錯？如果唔會，就刪。
gotchas係最高價值內容，因為佢哋嚟自真實失敗。
正向原則往往模型已經知道，負面邊界先係專家經驗。
設計Skill中"唔好純白純黑""連續三頁相同節奏係P0錯誤""文字唔可以壓塊面""AI圖只係冇合適真實圖時使用"，都屬於gotchas或強約束。
呢個亦解釋咗點解完全自動生成Skill只可以做初稿。
模型可以幫你起草結構，但佢冇辦法憑空擁有你嘅失敗樣本、審美判斷、行業邊界同用戶反饋。
真正有價值嘅係人將經驗注入入去，再透過eval同gotchas令佢持續變厚。
設計Skill嘅本質：將品味變成約束
設計類Skill唔係簡單嘅"AI會畫圖"。
佢需要解決模型唔穩定、圖像限流、文字唔鋭利、排版唔可控、風格一致性難判斷等問題。
設計Skill嘅核心係將專業品味變成模型可執行嘅限制。
模型默認會收斂到一啲平庸模式：
Tailwind大色塊、紫色漸變、emoji堆砌、Inter字體、發光、過度圓角、冇意義動效、信息密度失控。呢個唔係模型冇審美素材，而係冇穩定嘅取捨原則。
所以設計Skill入面最有價值嘅係主觀但明確嘅約束：
唔用純白同純黑，降低刺眼同廉價感；
唔俾用戶任意輸入hex，只提供經過驗證嘅主題色板；
唔用紫色多彩漸變、發光同大面積blur作為主視覺捷徑；
動畫只在必要時使用，而且只鬱transform同opacity；
圖文卡片優先真實攝影同截圖美化，AI生圖只係兜底；
版式骨架先俾人工驗證，AI負責填充、組合同微調；
文字必須根據圖像主體、明度同可讀區域自適應落點、字色、遮罩同斷行。
呢啲規則睇起嚟限制自由，實際係保護輸出下限。設計類Skill嘅質量嚟自"替用戶排除絕大多數會變醜嘅選項"。
好睇唔係玄學，而係可拆解、可編碼、可檢查嘅行業常識。
Skill嘅價值，就係將呢啲常識壓入SKILL.md、模板、checklist、主題變量同後驗檢查裏面。
PPT Skill同社交媒體卡片Skill嘅一個共同方法，係將AI嘅任務從"自由設計"降級成"喺高質量骨架裏面填充"。
PPT Skill裏面，10種頁面佈局、5套主題色、字體三級分工、7:5 / 6:6 / 8:4網格、hero同non-hero嘅節奏交替，構成咗一個穩定嘅演示系統。AI唔需要從零發明版式，只需要根據內容選擇合適頁面類型並填落去。
社交媒體卡片Skill進一步將場景校準到手機信息流：
3:4係主戰場，1秒決定停唔停低。佢唔係將PPT截圖成豎圖，而係重新定義咗圖文品類、版式比例、斷行規則同素材優先級。
11個內容品類、兩套視覺系統、28個版式骨架、截圖美化、地圖組件、真實圖庫同剋制AI生圖，共同構成咗"內容平台視覺Skill"。
Logo Generator Skill亦係同一邏輯：
唔直接俾圖像模型一把梭生成Logo，因為圖片模型嘅文字、結構同可編輯性唔穩定；
佢係先生成SVG變體，再做展示圖同WebGL背景。呢度將Logo本體、展示場景、交互背景拆成唔同層，分別用最適合嘅技術處理。
人工沉澱審美系統，模型理解內容同語義，代碼負責穩定排版同導出，圖像模型只處理適合佢嘅視覺部分。
呢個比單純"俾AI畫一張圖"更慢啲，但可控、可改、可複用，亦更適合內容創作者長期使用。
Skill生態唔可以做成倉庫列表
如果一個Skill可以被圖文、案例、評價、使用數據、作者、應用場景反向連結起嚟，佢就唔只係一個工具，而係一個社區節點。
反向連結：從使用案例、文章、圖文或項目頁面反過來連結到某個Skill，令人可以見到佢俾邊個用、點用、效果如何。
目前好多Skill展示嘅問題係：
列表好長，似GitHub倉庫名；圖標都一樣；冇結果展示；冇評價指標；
多模態Skill都只係用文本展示；用戶唔知邊個適合自己。
推薦10個或20個精選Skill，並講清楚點用，遠好過俾用戶幾千個列表。
每個Skill都應該似一個軟件功能頁。頁面應該說明：
佢解決咩問題，適合咩場景，需要輸入咩，輸出係點樣，典型提示詞係咩，生成結果截圖或視頻，邊個用過、點評價，有邊啲常見失敗情況，點樣安裝同修改。
呢個本質上需要強運營。
唔係將名列曬出來，而係一個一個揀、一個一個寫介紹、展示結果，最好仲有視頻講解。
GitHub係代碼型Skill嘅天然託管地，因為Skill往往包含代碼，需要版本管理；
GitHub有生態位、版權聲明同分發基礎；AI亦熟悉Git同GitHub操作；開源仲可以覆蓋所有Agent平台，唔綁定單一產品。
但小紅書適合做視覺內容同使用案例分發。
小紅書嘅優勢係內容感知、視覺展示、用戶審美同評論體系。
PPT Skill同社交媒體卡片Skill都已經喺小紅書之外嘅人羣中傳播，例如咖啡館主理人、數碼測評、活動策劃、餐廳、三線城市分享場景。呢個說明Skill可以跨出AI圈。
應用商店式Skill分發都有潛力：更精準推薦、更低使用門檻、可能俾創作者分成。
但對創作者嚟講，如果只係喺一個平台上架，就等於押注呢個平台可以做好產品、生態、分發同市場佔領。
更穩嘅策略可能係：GitHub做基礎分發同跨平台覆蓋，平台Skillhub / 應用商店做體驗優化、運營推薦同商業轉化。
未來嘅Skill平台，本質上會同時係App Store、GitHub、社區種草頁、評價系統同Agent工具層。
普通用戶真正卡喺邊度
AI圈外嘅人唔係用唔到Skill。
實際觀察中，咖啡館主理人、數碼測評、活動策劃、健身教練等都可以用出好結果。
真正卡點係交互心智。
好多人仍然用傳統軟件思維，以為一次生成就應該完成：
唔習慣透過chat連續調整；唔知可以要求AI改顏色、改字、修溢出、換圖；唔知點樣提供上下文同素材；亦唔知點樣從自己嘅工作流中抽出Skill。
因此，Skill產品唔只係要提供安裝，仲要提供使用教育。
行業Skill會係一個好重要嘅方向。好多行業有好嘅經驗同客戶洞察：
健身、法律、餐飲、活動策劃、教育、商業化投放等。但行業專家唔一定知道點樣做Skill，亦擔心分享之後俾人盜用。
呢度嘅關鍵唔係將Skill作為服務添加項。
健身教練可以用Agent維護會員飲食、訓練、有氧、提醒同反饋，提高客戶粘性同服務效率。
法律從業者可以將瑣碎文本處理、條文審查、格式檢查做成輔助Skill，但核心判斷仍然由人完成。
餐飲同活動行業可以用圖文Skill將真實圖片同故事包裝成可傳播內容。
AI唔可以替代線下履約，但可以提高獲客、溝通、維護同複用效率。
呢類行業用戶只需要基礎啟蒙：帶佢做一次需求分析，落地成一個Skill，佢就知道邊界喺邊度。
每個行業都有先鋒用戶：有創造力、有好奇心、想用AI獲得競爭優勢。先服務呢班人。
內容Skill：文章、產品同案例互相餵養
從我已有文章睇，我正形成一條好清晰嘅內容Skill路線：
唔係為某個抽象AI概念寫文章，係先做出一個用得嘅Skill，再將製作過程、設計判斷同使用場景寫成傳播內容。
呢類內容有幾個特點。
PPT Skill最初嚟自一次AI同組織分享，觀眾問得最多嘅係PPT點樣做，於是從一次交付沉澱成開源Skill。呢個係副產品變主產品。
文章本身似說明書，但唔係README。
佢要講清楚點解咁設計、適合邊個、邊界喺邊、真實效果如何，降低用戶理解門檻。
產品演示本身就係內容資產。PPT截圖、圖文卡片、Logo展示圖、Desk Card場景圖，都可以成為傳播素材。
Skill反過來亦提升寫作效率。社交卡片Skill可以將文章段落直接轉成更適合小紅書、公眾號或Twitter嘅視覺卡片。
每篇文章都喺度擴展Skill嘅語義邊界。
PPT係演示，Social Card係內容分發，Logo係項目品牌資產，Desk Card係硬件同環境UI，夜巡錄則指向遊戲demo工作流。
呢個說明Skill唔只係"工具產品"，亦係內容創作者嘅表達基礎設施。
過去文章同產品係分開嘅：先做產品，再寫推廣。而家Skill、文章、案例、開源倉庫、社交反饋會互相餵養。
呢個就係個人產品喺Agent時代嘅複利飛輪。
Skill嘅邊界會繼續擴大
過去"插件"通常意味著軟件入面嘅一個按鈕。而家Skill嘅邊界可以明顯更大。
瀏覽器Skill會係消費者入口。Tabbit Browser一類產品說明，Skills可以進入瀏覽器場景，變成普通用戶喺網頁、資料、腳本同自動化之間嘅入口。
瀏覽器係大眾最熟悉嘅工作環境，如果Skill可以"現成腳本 / 使用案例 / 一鍵執行"嘅方式出現，會比裸露CLI或GitHub倉庫更容易被理解。
硬件Skill則說明AI可以接管環境UI。
AI Desk Card嘅價值在於佢將Agent嘅能力延伸咗到物理環境：
安裝固件、配置Wi-Fi、寫cron、讀取Memory、選擇widget、刷新墨水屏，全流程由AI引導。用戶唔再面對App設置頁，AI本身就係設置頁。
遊戲Skill代表更長鏈路嘅創作流程。
夜巡錄開發手記入面提到嘅"獨立遊戲demo Skill"，從玩法母題、原型、素材採集、綠幕摳圖、contact sheet、視頻生成、音樂、Electron打包、GitHub Actions到Release。
封裝係一套跨程序員、美術、動畫、作曲同運維嘅生產流水線。佢嘅價值係將"做個原型"同"獨立交付完整作品"之間嘅牆變薄。
Skill嘅未來唔只會侷限喺傾偈框入面，佢會擴展到瀏覽器、桌面、本地文件、硬件、內容平台、遊戲引擎同真實工作環境。
Skill同Gene：手寫經驗同自動進化嘅邊界
仲有一個值得保留但需要謹慎使用嘅對比：Agent Skill同GEP Gene。
Skill更似人類預先沉澱嘅能力包：有明確創建者、明確邊界、明確流程同版本。
Gene / Capsule呢類概念強調運行中從成功經驗入面自動長出能力：帶成功率、變異歷史、適用上下文同自動修復機制。
Gene / Capsule：呢度指從Agent反覆執行中嘅成功路徑入面沉澱出嘅可複用經驗單元，強調自動演化而唔係人工手寫。
呢兩者唔係簡單替代關係，係唔同嘅層級。
Skill適合承載人嘅專家經驗、審美、行業SOP、工具不變式同明確交付標準；
Gene適合從重複執行中捕捉成功路徑，將臨時試錯變成可複用經驗；Capsule類似將多個Gene組合成更長工作流。
從當前產品現實睇，Skill仍然係更可落地嘅單位，因為佢可以被寫、被審、被發布、被解釋、被傳播。
但長期睇，自動沉澱Skill / Gene化經驗會成為方向：Agent先用通用工具試錯，成功後將路徑寫返入Skill或生成新嘅子能力。
呢個亦回應咗"自動沉澱Skill"嘅討論。系統可以自動發現重複流程，但係咪值得沉澱、點樣命名、邊界喺邊度、邊啲失敗要寫入gotchas，仍然需要人嘅判斷。
真正理想嘅形態唔係完全自動，亦唔係完全手寫，而係人定義品味同邊界，Agent負責收集證據、提出改動、補充eval同維護長尾經驗。
盜用唔係靠收埋，防禦方式係持續分發
Skill好難靠閉源防盜。就算唔開源，只要見到產出結果，試用幾次，都可能俾人複刻。
所以防禦方式唔係"收埋"，而係開源覆蓋更多平台，用影響力威懾過分盜用者，做自媒體令用戶知道源頭係邊個，用持續迭代建立領先，用社區案例同評價體系形成品牌資產。
喺產品壁壘降低嘅時代，個人產品如果冇渠道、資源同營銷，就必須自己做宣發。以前自媒體係可選項，而家係基礎設施。
平台真正應該做咩
如果要整Skill平台，唔可以只押注Skill。用戶下載獨立端嘅理由，首先係Agent基礎體驗夠好：
靚仔好用嘅客戶端，多模型支持，尤其國產模型；文件、項目、memory、CLI、MCP、Skill管理；
權限同安全沙箱；長程任務同狀態延續；多設備流轉，手機控制桌面，桌面反向控制手機；官方高質量插件開箱即用。
Workbody嘅啟發係，佢冇做特別獨特嘅嘢，只係將應有嘅基礎體驗做齊曬。好多國內產品連呢一點都未做好。
一啲高頻、必須、常見嘅能力應該內置並打磨好，唔好俾用戶自己折騰安裝。
官方插件強，會形成壁壘。多設備、雲端同本地互控，亦會形成壁壘。
Skill同本地環境強相關時，移動端需要遙控PC。
Skill可以跨端通用，但依賴本地文件、腳本、瀏覽器、CLI嘅Skill喺移動端好難直接行。
移動端適合輕量級從0到1創作；桌面端適合重任務同本地環境調用。
自動沉澱Skill係長期方向，但好Skill仍然需要人。Dumate等產品提出"自動沉澱Skill"：從用戶重複工作中自動總結流程。
呢個方向成立，但好Skill仍然需要業務SOP、品味、測試同迭代。自動生成可以做初版，真正可以穩定交付嘅Skill需要打磨。
一個完整Skill生命週期
如果將前面嘅判斷收束成一條路徑，一個完整Skill生命週期大概係咁樣。
先發現真實需求，從自己或行業用戶嘅重複工作開始。
再做一次高質量產物，唔好先抽象，先用Agent解決真實任務。
然後抽象流程，識別可複用步驟、輸入、輸出、約束同工具。
接着工程化模板，將審美、版式、調用、驗證同修復機制固化。
再做跨模型測試，好模型睇上限，差模型保下限。
之後先係封裝發布，GitHub託管，配README、示例同安裝方式。
再做內容分發，用小紅書、Twitter、公眾號、視頻展示結果。
然後收集反饋，從issue、評論區、用戶案例同平台數據入面揾真實問題。反饋仲要篩選，只吸收可以提升泛化同穩定性嘅部分。
呢條路睇起嚟長，但佢嘅本質好簡單：
每一次真實任務，都唔只係完成任務，而係積累下一次可以調用嘅能力資產。
Agent時代最稀缺嘅係可複用嘅能力組織方式。
Skill之所以重要，係因為佢第一次令人嘅經驗、工作流同品味，有機會變成一種可以分發、調用、評價同持續迭代嘅商品。
呢個可能先係Agent生態入面真正嘅大機會。
好，今日嘅內容就到呢度。如果你覺得有幫助，歡迎幫我點個讚，或者轉發俾你需要嘅朋友。
✦
如果看不完的話，可以先幫忙點個贊，收藏一下以後看，感謝。
我最近幾次聊 Skills，有一個越來越明確的判斷：
大家現在都在說 Agent，但大多數人其實還沒有真正理解 Agent。
大眾理解裏的 Agent，往往還是一個聊天框。
你輸入一句話，它回答一段文字；你再輸入一句，它繼續回答。
這個視角下，AI 好像天然會帶來一種平權：以前不會寫代碼的人可以寫代碼，不會做 PPT 的人可以做 PPT，不會剪視頻的人可以剪視頻。
只要模型足夠強，大家的能力差距就會被抹平。
但我越來越覺得，這個判斷是錯的。Agent 不是簡單抹平能力差距，而是在放大能力差距。
頭部用戶已經默認理解 Agent 的組成：
文檔、規則、memory、loop、MCP、CLI、工具調用、權限、安全沙箱、上下文工程、定時任務、心跳、文件系統、代碼執行和 Skill。
但普通用戶只知道"Agent 能寫代碼""Agent 可以調用 Skill"，並不知道 Agent 的上限從哪裏來，也不知道自己應該如何組織目標、資料和流程，才能讓 Agent 真正工作。
Agent：這裏指的不只是聊天機器人，而是能理解目標、規劃步驟、調用工具並持續執行任務的 AI 系統。
Memory：Agent 用來保存長期偏好、項目狀態和歷史決策的外部記憶，不等同於模型訓練記憶。
Loop：Agent 反覆"思考、調工具、觀察結果、再決定下一步"的執行循環。
這裏就出現了一個很大的認知割裂：頭部用戶已經在搭系統，普通用戶還在問聊天框。
目標清晰、上下文好、品味和判斷強的人，會被 Agent 放大；目標混亂、沒有文檔、沒有判斷的人，也會被 Agent 放大混亂。
所以用戶會出現 K 型分化。去年還可以靠產品設計、交互設計和用戶教育降低一些門檻，今年我覺得已經很難靠簡單 UX 彌合這個差距。
Skill 則可以彌合 Agent 使用能力差距。
Skill 是能力商品，不只是提示詞
我現在對 Skill 的一句話定義是：
Skill 是把專家經驗、工作流、品味和工具調用封裝成可分發、可複用、可迭代的 Agent 能力單元。
Skill：把提示詞、流程、工具調用、模板、腳本、邊界和經驗打包起來的可複用能力單元。
它不是單純的提示詞，也不是傳統意義上的 App。
它更像 Agent 時代的"能力商品"。用戶不需要理解底層的 MCP、CLI、workflow、memory、loop、模型選擇、代碼執行和上下文工程，只需要知道：
它解決什麼問題，產出什麼結果，怎麼使用，別人用得怎麼樣。
提示詞本身很難成為產品。它容易被複制，難以分發，沒有版本管理，也缺少安裝和調用語義。
Skill 把提示詞、規則、示例、工具調用、文件結構、腳本、依賴和使用說明打包起來，讓它變成一個可以安裝、調用、迭代和傳播的能力包。
所以 Skill 和 Prompt 本質上並非完全不同，但 Skill 的調用效率更高，分發和理解成本更低，也能承載更多工程化內容。
更重要的是，很多任務並不是一句提示詞能解決的。
它們是一組穩定流程：讀取材料，分析需求，選擇模板，調用工具，生成產物，驗證結果，修復問題，導出文件。
Skill 把這套流程從一次性對話中抽出來，變成可以反覆調用的工作流。
比如 PPT Skill 的流程不是"生成 PPT"這麼簡單。
它要讀取文章或大綱，詢問主題、頁數和配圖，選擇主題、顏色和版式，生成 HTML PPT，自動後驗檢查常見問題，再修正缺屬性、未居中、溢出、圖片裁切、節奏重複等問題，必要時還要調用圖像模型生成配圖，最後輸出可演示、可分享的文件。
這背後真正有價值的，是 Skill 把人的演示經驗被外化了。
Skill 的核心，是把人的經驗外化
我做的設計類 Skill 很能說明這一點。
真正有價值的部分是把人的審美、版式判斷、設計系統經驗、模板選擇、圖片裁切規則、明暗遮罩規則、字體和顏色規則固化進去。
這要求創作者同時懂三件事：傳統專業知識，AI 的上下限，以及產品化思維。
傳統專業知識決定你知道什麼結果算好。比如設計、剪輯、寫作、健身、法律、商業化投放，每個行業都有大量隱性判斷。AI 的上下限決定你知道模型什麼能做、什麼做不穩、什麼必須工程化兜底。
產品化思維決定你知道用戶場景、使用門檻、反饋路徑和穩定性要求。
這也是我做幾個 Skill 時最深的體會。
PPT Skill 最開始不是為了"做一個 Skill"，是因為我真的要做一場分享。
第一版基本成型後，我通過五六輪對話調整間距、字號、字體、顏色、配圖、重複內容、WebGL 背景等問題。
講完之後發現大家最關心的不是分享本身，而是 PPT 怎麼做，於是才把這套模板和流程沉澱成 Skill。
社交媒體卡片 Skill 也不是憑空抽象出來的。它來自非常具體的內容分發需求：
3:4 豎版圖文卡片，適配小紅書、公眾號、Twitter 等不同場景。它要處理 11 類內容，兩套視覺系統，28 個版式骨架，真實圖片 + Coding 排版，還要規避 AI 圖限流、文字不鋭利、平台風格不匹配等問題。
Logo Generator Skill 也是同一邏輯。它沒有直接讓圖像模型一把梭生成 Logo，因為圖片模型的文字、結構和可編輯性不穩定。
它選擇先生成 SVG Logo 變體，再生成展示圖和 WebGL 背景，把 Logo 本體、展示場景和交互背景拆成不同層，分別用最適合的技術處理。
AI Desk Card 則說明 Skill 的邊界可以擴展到物理環境。
它讓 Agent 接管屏幕邊緣的物理信息位：固件燒錄、Wi-Fi 配置、信息推送、定時任務、memory、todo、日曆、GitHub 展示、墨水屏刷新，都可以被封裝成一套 Skill。
這些案例共同說明：Skill 的核心是"人把什麼經驗變成了可調用的能力"。
用戶不關心概念，用戶關心結果
對普通用戶來說，Skill、MCP、CLI、Plugin 叫什麼並不重要。
他們關心的是：這個功能能解決什麼問題，適合什麼場景，我點一下能不能用，需要輸入什麼材料，結果長什麼樣，別人用得怎麼樣。
MCP：Model Context Protocol，可以理解為讓 AI 以統一方式連接外部工具、數據源和服務的協議。
CLI：Command Line Interface，命令行工具；對 Agent 來說，它常常是比圖形界面更穩定、更容易自動化的操作入口。
因此，面向用戶的產品層不應該堆術語。Codex 把很多東西統一叫插件，我覺得就是一個正確方向：弱化概念，強調功能。
底層可以是 Skill、MCP、CLI 或原生 Plugin；用戶只需要知道它能幹什麼。
但對產品和創作者來說，這些底層形態的區別又很重要。
Skill 適合承載相對垂直、可描述、可複用的工作，比如 PPT、社交媒體卡片、文章配圖、寫作潤色、視頻包裝、簡歷優化、數據可視化、某個行業 SOP。
MCP 更適合 Agent 架構中的原子服務和上下文連接，比如地圖、瀏覽器、網盤、設計稿、數據庫、企業 API。
CLI 則是目前很現實的通用 Plugin 形態：命令行、代碼、Skill 都可以封裝進去，也不綁定單一 Agent 平台。
飛書 CLI 就是一個很好的例子。用戶不用理解 200 多條命令，也不用知道背後是哪個 API。
他只需要說"幫我把今天的智能紀要拉到筆記裏"，Agent 背後可以搜索雲文檔、讀取妙記、下載逐句轉寫、寫入本地 Markdown、建立反向連結。
用戶看到的是結果，Agent 用的是工具，Skill 封裝的是流程。
這也是為什麼 Skill、CLI 和 MCP 的關係不能只從技術概念上理解。
它們最終都要落到一個問題：怎麼讓普通用戶用上頭部用戶已經驗證過的能力。
好 Skill 的架構：中心短，輻射厚
很多人會把 Skill 理解成一個 SKILL.md 文件，這隻說對了一半。
SKILL.md：很多 Skill 的入口說明文件，用來告訴 Agent 什麼時候加載這個能力、按什麼流程執行、哪些坑不能踩。
好的 Skill 往往是一個目錄。SKILL.md 只是入口，旁邊還可以有 scripts/、references/、assets/、模板、schema、配置文件、子 Skill 和特殊案例。
複雜 Skill 不怕有複雜內容，怕的是把複雜內容一次性塞給模型。文件系統本身就是一種上下文工程。
上下文窗口：AI 一次能"看見"和處理的信息範圍，文檔、代碼、聊天記錄和工具說明都會佔用它。
好 Skill 的信息架構應該是"中心短，輻射厚"。
SKILL.md 只放高信號流程和判斷；references/ 放重文檔和領域材料，按條件讀取；scripts/ 放確定性邏輯，讓 Agent 調用而不是重寫；assets/ 放模板、schema、示例、字體、主題和版式骨架；配置文件或穩定數據目錄放首次配置、偏好和歷史記錄。
這裏有個很關鍵的點：Skill 的 description 不是宣傳語，也不是功能摘要，是路由觸發器。
好的 description 應該描述用戶什麼時候需要它，最好來自真實用戶表達；壞的 description 只是解釋"這個 Skill 做什麼"。
比如一個 PPT Skill，不應該寫"這個 Skill 可以生成漂亮 PPT"。
它應該寫"當用戶需要把文章、大綱或演講內容轉成可演示 HTML PPT 時加載"。前者是廣告，後者是 Agent 的判斷條件。
這能解釋為什麼"把所有能力塞進一個大 Agent"不是好方向。
大而全的 harness 會把工具定義、協議細節和長文檔塞滿上下文，帶來更高延遲、更高 token 成本和更多誤用。
反過來，薄 harness 只提供最小運行環境，Skill 作為按需加載的能力包，才能讓系統長期複利。
Harness：運行 Agent 的外層程序，負責模型循環、文件讀寫、上下文管理和安全邊界。
更穩的架構是 Thin Harness, Fat Skills：harness 保持薄，負責跑模型循環、讀寫文件、管理上下文、執行權限和安全邊界；
Skill 變厚，承載流程、判斷、領域知識、模板、腳本、資產、gotchas 和 eval；
確定性工具下沉給 CLI、scripts 或 API；模型留在理解、判斷、綜合、取捨和表達這些更適合它的部分。
Thin Harness, Fat Skills：讓 Agent 底層運行環境保持輕，把具體流程、領域知識、模板、腳本和失敗經驗放進按需加載的 Skill 裏。
Skill 質量要像代碼質量一樣維護
好 Skill 不是一次寫完。它需要維護，而且要像代碼質量一樣維護。
一個比較可靠的生命週期是：
先用無 Skill 的 Agent 跑真實任務，找到它會錯在哪裏；
基於真實 query 寫 eval，包括正例、反例和 forbidden load；
先調 description，確保該加載時加載，不該加載時不加載；
寫主體時刪除顯而易見的內容，只保留會改變模型行為的判斷；
把失敗案例追加到 gotchas，而不是不斷加長主流程；改 description 或路由邊界時補 eval；
再做跨模型測試，看不同編排模型對 Skill 觸發和執行的差異。
Eval：用一組真實或模擬任務測試 Skill 是否按預期觸發、執行和交付結果。
Gotchas：從真實失敗裏總結出來的"別這麼做"清單，往往比正向說明更能提升 Skill 穩定性。
每個 Skill 都是一種税。
它進入索引後，每個會話、每個用戶都在為它的 name 和 description 付上下文成本；
它被加載後，後續對話都在為主體內容付成本。
所以每一句都要問：沒有這句，Agent 會不會做錯？如果不會，就刪。
gotchas 是最高價值內容，因為它們來自真實失敗。
正向原則往往模型已經知道，負面邊界才是專家經驗。
設計 Skill 中"不要純白純黑""連續三頁相同節奏是 P0 錯誤""文字不能壓臉""AI 圖只在無合適真實圖時使用"，都屬於 gotchas 或強約束。
這也解釋了為什麼完全自動生成 Skill 只能做初稿。
模型可以幫你起草結構，但它無法憑空擁有你的失敗樣本、審美判斷、行業邊界和用戶反饋。
真正有價值的是人把經驗注入進去，再通過 eval 和 gotchas 讓它持續變厚。
設計 Skill 的本質：把品味變成約束
設計類 Skill 不是簡單的"AI 會畫圖"。
它需要解決模型不穩定、圖像限流、文字不鋭利、排版不可控、風格一致性難判斷等問題。
設計 Skill 的核心是把專業品味變成模型可執行的限制。
模型默認會收斂到一些平庸模式：
Tailwind 大色塊、紫色漸變、emoji 堆砌、Inter 字體、發光、過度圓角、無意義動效、信息密度失控。這不是模型沒有審美素材，而是沒有穩定的取捨原則。
所以設計 Skill 裏最有價值的是主觀但明確的約束：
不使用純白和純黑，降低刺眼和廉價感；
不讓用戶任意輸入 hex，只提供經過驗證的主題色板；
不用紫色多彩漸變、發光和大面積 blur 作為主視覺捷徑；
動畫只在必要時使用，且只動 transform 和 opacity；
圖文卡片優先真實攝影和截圖美化，AI 生圖只是兜底；
版式骨架先被人工驗證，AI 負責填充、組合和微調；
文字必須根據圖像主體、明度和可讀區域自適應落點、字色、遮罩和斷行。
這些規則看起來限制自由，實際是在保護輸出下限。設計類 Skill 的質量來自"替用戶排除絕大多數會變醜的選項"。
好看不是玄學，而是可拆解、可編碼、可檢查的行業常識。
Skill 的價值，就是把這些常識壓進 SKILL.md、模板、checklist、主題變量和後驗檢查裏。
PPT Skill 和社交媒體卡片 Skill 的一個共同方法，是把 AI 的任務從"自由設計"降級成"在高質量骨架裏填充"。
PPT Skill 裏，10 種頁面佈局、5 套主題色、字體三級分工、7:5 / 6:6 / 8:4 網格、hero 與 non-hero 的節奏交替，構成了一個穩定的演示系統。AI 不需要從零發明版式，只需要根據內容選擇合適頁面類型並填進去。
社交媒體卡片 Skill 進一步把場景校準到手機信息流：
3:4 是主戰場，1 秒決定停不停下。它不是把 PPT 截圖成豎圖，而是重新定義了圖文品類、版式比例、斷行規則和素材優先級。
11 個內容品類、兩套視覺系統、28 個版式骨架、截圖美化、地圖組件、真實圖庫和剋制 AI 生圖，共同構成了"內容平台視覺 Skill"。
Logo Generator Skill 也是同一邏輯：
不直接讓圖像模型一把梭生成 Logo，因為圖片模型的文字、結構和可編輯性不穩定；
它是先生成 SVG 變體，再做展示圖和 WebGL 背景。這裏把 Logo 本體、展示場景、交互背景拆成不同層，分別用最適合的技術處理。
人工沉澱審美系統，模型理解內容和語義，代碼負責穩定排版和導出，圖像模型只處理適合它的視覺部分。
這比單純"讓 AI 畫一張圖"更慢一點，但可控、可改、可複用，也更適合內容創作者長期使用。
Skill 生態不能做成倉庫列表
如果一個 Skill 能被圖文、案例、評價、使用數據、作者、應用場景反向連結起來，它就不只是一個工具，而是一個社區節點。
反向連結：從使用案例、文章、圖文或項目頁面反過來連結到某個 Skill，讓人能看到它被誰用、怎麼用、效果如何。
當前很多 Skill 展示的問題是：
列表很長，像 GitHub 倉庫名；圖標都一樣；沒有結果展示；沒有評價指標；
多模態 Skill 也只用文本展示；用戶不知道哪個適合自己。
推薦 10 個或 20 個精選 Skill，並講清楚怎麼用，遠好過給用戶幾千個列表。
每個 Skill 都應該像一個軟件功能頁。頁面應該說明：
它解決什麼問題，適合什麼場景，需要輸入什麼，輸出長什麼樣，典型提示詞是什麼，生成結果截圖或視頻，誰用過、怎麼評價，有哪些常見失敗情況，如何安裝和修改。
這本質上需要強運營。
不是把名字列出來，而是一個一個挑、一個一個寫介紹、展示結果，最好還有視頻講解。
GitHub 是代碼型 Skill 的天然託管地，因為 Skill 往往包含代碼，需要版本管理；
GitHub 有生態位、版權聲明和分發基礎；AI 也熟悉 Git 和 GitHub 操作；開源還能覆蓋所有 Agent 平台，不綁定單一產品。
但小紅書適合做視覺內容和使用案例分發。
小紅書的優勢是內容感知、視覺展示、用戶審美和評論體系。
PPT Skill 和社交媒體卡片 Skill 都已經在小紅書之外的人羣中傳播，比如咖啡館主理人、數碼測評、活動策劃、餐廳、三線城市分享場景。這說明 Skill 能跨出 AI 圈。
應用商店式 Skill 分發也有潛力：更精準推薦、更低使用門檻、可能給創作者分成。
但對創作者來說，如果只在一個平台上架，就等於押注這個平台能做好產品、生態、分發和市場佔領。
更穩的策略可能是：GitHub 做基礎分發和跨平台覆蓋，平台 Skillhub / 應用商店做體驗優化、運營推薦和商業轉化。
未來的 Skill 平台，本質上會同時是 App Store、GitHub、社區種草頁、評價系統和 Agent 工具層。
普通用戶真正卡在哪裏
AI 圈外的人並非不能用 Skill。
實際觀察中，咖啡館主理人、數碼測評、活動策劃、健身教練等都能用出好結果。
真正卡點是交互心智。
很多人仍然用傳統軟件思維，以為一次生成就該完成：
不習慣通過 chat 連續調整；不知道可以要求 AI 改顏色、改字、修溢出、換圖；不知道如何提供上下文和素材；也不知道如何從自己的工作流中抽 Skill。
因此，Skill 產品不僅要提供安裝，還要提供使用教育。
行業 Skill 會是一個很重要的方向。很多行業有非常好的經驗和客戶洞察：
健身、法律、餐飲、活動策劃、教育、商業化投放等。但行業專家不一定知道如何做 Skill，也擔心分享後被盜。
這裏的關鍵不是把 Skill 作為服務添加項。
健身教練可以用 Agent 維護會員飲食、訓練、有氧、提醒和反饋，提高客戶粘性和服務效率。
法律從業者可以把瑣碎文本處理、條文審查、格式檢查做成輔助 Skill，但核心判斷仍由人完成。
餐飲和活動行業可以用圖文 Skill 把真實圖片和故事包裝成可傳播內容。
AI 不能替代線下履約，但可以提高獲客、溝通、維護和複用效率。
這類行業用戶只需要基礎啓蒙：帶他做一次需求分析，落地成一個 Skill，他就知道邊界在哪裏。
每個行業都有先鋒用戶：有創造力、有好奇心、想用 AI 獲得競爭優勢。先服務這些人。
內容 Skill：文章、產品和案例互相餵養
從我已有文章看，我正在形成一條很清晰的內容 Skill 路線：
不是為某個抽象 AI 概念寫文章，是先做出一個能用的 Skill，再把製作過程、設計判斷和使用場景寫成傳播內容。
這類內容有幾個特點。
PPT Skill 最初來自一次 AI 和組織分享，觀眾問得最多的是 PPT 怎麼做，於是從一次交付沉澱成開源 Skill。這是副產品變主產品。
文章本身像說明書，但不是 README。
它要講清楚為什麼這樣設計、適合誰、邊界在哪、真實效果如何，降低用戶理解門檻。
產品演示本身就是內容資產。PPT 截圖、圖文卡片、Logo 展示圖、Desk Card 場景圖，都可以成為傳播素材。
Skill 反過來也提升寫作效率。社交卡片 Skill 可以把文章段落直接轉成更適合小紅書、公眾號或 Twitter 的視覺卡片。
每篇文章都在擴展 Skill 的語義邊界。
PPT 是演示，Social Card 是內容分發，Logo 是項目品牌資產，Desk Card 是硬件和環境 UI，夜巡錄則指向遊戲 demo 工作流。
這說明 Skill 不只是"工具產品"，也是內容創作者的表達基礎設施。
過去文章和產品是分開的：先做產品，再寫推廣。現在 Skill、文章、案例、開源倉庫、社交反饋會互相餵養。
這就是個人產品在 Agent 時代的複利飛輪。
Skill 的邊界會繼續擴大
過去"插件"通常意味着軟件裏的一個按鈕。現在 Skill 的邊界可以明顯更大。
瀏覽器 Skill 會是消費者入口。Tabbit Browser 一類產品說明，Skills 可以進入瀏覽器場景，變成普通用戶在網頁、資料、腳本和自動化之間的入口。
瀏覽器是大眾最熟悉的工作環境，如果 Skill 能以"現成腳本 / 使用案例 / 一鍵執行"的方式出現，會比裸露 CLI 或 GitHub 倉庫更容易被理解。
硬件 Skill 則說明 AI 可以接管環境 UI。
AI Desk Card 的價值在於它把 Agent 的能力延伸到了物理環境：
安裝固件、配置 Wi-Fi、寫 cron、讀取 Memory、選擇 widget、刷新墨水屏，全流程由 AI 引導。用戶不再面對 App 設置頁，AI 本身就是設置頁。
遊戲 Skill 代表更長鏈路的創作流程。
夜巡錄開發手記裏提到的"獨立遊戲 demo Skill"，從玩法母題、原型、素材採集、綠幕摳圖、contact sheet、視頻生成、音樂、Electron 打包、GitHub Actions 到 Release。
封裝是一套跨程序員、美術、動畫、作曲和運維的生產流水線。它的價值是把"做個原型"和"獨立交付完整作品"之間的牆變薄。
Skill 的未來不只會侷限在聊天框裏，它會擴展到瀏覽器、桌面、本地文件、硬件、內容平台、遊戲引擎和真實工作環境。
Skill 與 Gene：手寫經驗和自動進化的邊界
還有一個值得保留但需要謹慎使用的對比：Agent Skill 與 GEP Gene。
Skill 更像人類預先沉澱的能力包：有明確創建者、明確邊界、明確流程和版本。
Gene / Capsule 這類概念強調運行中從成功經驗裏自動長出能力：帶成功率、變異歷史、適用上下文和自動修復機制。
Gene / Capsule：這裏指從 Agent 反覆執行中的成功路徑裏沉澱出的可複用經驗單元，強調自動演化而不是人工手寫。
這兩者不是簡單替代關係，是不同的層級。
Skill 適合承載人的專家經驗、審美、行業 SOP、工具不變式和明確交付標準；
Gene 適合從重複執行中捕捉成功路徑，把臨時試錯變成可複用經驗；Capsule 類似把多個 Gene 組合成更長工作流。
從當前產品現實看，Skill 仍是更可落地的單位，因為它能被寫、被審、被髮布、被解釋、被傳播。
但長期看，自動沉澱 Skill / Gene 化經驗會成為方向：Agent 先用通用工具試錯，成功後把路徑寫回 Skill 或生成新的子能力。
這也回應了"自動沉澱 Skill"的討論。系統可以自動發現重複流程，但是否值得沉澱、如何命名、邊界在哪裏、哪些失敗要寫進 gotchas，仍然需要人的判斷。
真正理想的形態不是完全自動，也不是完全手寫，而是人定義品味和邊界，Agent 負責收集證據、提出改動、補充 eval 和維護長尾經驗。
盜用不是靠藏，防禦方式是持續分發
Skill 很難靠閉源防盜。即便不開源，只要看到產出結果，試用幾次，也可能被複刻。
所以防禦方式不是"藏起來"，而是開源覆蓋更多平台，用影響力威懾過分盜用者，做自媒體讓用戶知道源頭是誰，用持續迭代建立領先，用社區案例和評價體系形成品牌資產。
在產品壁壘降低的時代，個人產品如果沒有渠道、資源和營銷，就必須自己做宣發。以前自媒體是可選項，現在是基礎設施。
平台真正該做什麼
如果要做 Skill 平台，不能只押 Skill。用戶下載獨立端的理由，首先是 Agent 基礎體驗足夠好：
漂亮好用的客戶端，多模型支持，尤其國產模型；文件、項目、memory、CLI、MCP、Skill 管理；
權限和安全沙箱；長程任務和狀態延續；多設備流轉，手機控制桌面，桌面反向控制手機；官方高質量插件開箱即用。
Workbody 的啓發是，它沒有做特別獨特的東西，只是把該有的基礎體驗做齊了。很多國內產品連這一點還沒做好。
一些高頻、必須、常見的能力應該內置並打磨好，不要讓用戶自己折騰安裝。
官方插件強，會形成壁壘。多設備、雲端和本地互控，也會形成壁壘。
Skill 與本地環境強相關時，移動端需要遙控 PC。
Skill 可跨端通用，但依賴本地文件、腳本、瀏覽器、CLI 的 Skill 在移動端很難直接跑。
移動端適合輕量級從 0 到 1 創作；桌面端適合重任務和本地環境調用。
自動沉澱 Skill 是長期方向，但好 Skill 仍需要人。Dumate 等產品提出"自動沉澱 Skill"：從用戶重複工作中自動總結流程。
這個方向成立，但好 Skill 仍需要業務 SOP、品味、測試和迭代。自動生成可以做初版，真正能穩定交付的 Skill 需要打磨。
一個完整 Skill 生命週期
如果把前面的判斷收束成一條路徑，一個完整 Skill 生命週期大概是這樣的。
先發現真實需求，從自己或行業用戶的重複工作開始。
再做一次高質量產物，不要先抽象，先用 Agent 解決真實任務。
然後抽象流程，識別可複用步驟、輸入、輸出、約束和工具。
接着工程化模板，把審美、版式、調用、驗證和修復機制固化。
再做跨模型測試，好模型看上限，差模型保下限。
之後才是封裝發佈，GitHub 託管，配 README、示例和安裝方式。
再做內容分發，用小紅書、Twitter、公眾號、視頻展示結果。
然後收集反饋，從 issue、評論區、用戶案例和平台數據裏找真實問題。反饋還要篩選，只吸收能提升泛化和穩定性的部分。
這條路看起來長，但它的本質很簡單：
每一次真實任務，都不只是在完成任務，而是在積累下一次能調用的能力資產。
Agent 時代最稀缺的是可複用的能力組織方式。
Skill 之所以重要，是因為它第一次讓人的經驗、工作流和品味，有機會變成一種可以分發、調用、評價和持續迭代的商品。
這可能才是 Agent 生態裏真正的大機會。
好，今天的內容就到這裏。如果你覺得有幫助，歡迎幫我點個贊，或者轉發給你需要的朋友。
✦