在騰訊做了一週"Skill作家"後，我發現AI愛看這樣的文章

上個星期五深夜，我望住螢幕上第14個啱啱生成好嘅Skill，突然覺得唔對路。

我花咗兩日時間，由公司知識庫度拎咗100篇遊戲技術文章，一篇一篇讀曬佢，試嚇將佢哋餵俾skill-creator，轉化成可以直接使用嘅Skill。簡單啲講，就係將人哋寫嘅經驗同方法論，變成一個AI可以理解、可以執行嘅「能力包」，你同佢講「幫我做個AI漫劇」，佢就會一步一步帶你由劇本寫到出片。

聽落好正，係咪？

但做到第14個嘅時候，我發現咗一個令我坐唔住嘅規律：唔係所有文章都可以變成好Skill，甚至大部分都唔得……但係我哋可以用一啲特定方法略施小計，化腐朽為神奇。呢個發現可能仲比「做出Skill」本身更有價值。所以今日呢篇隨筆，係我對Skill應用同轉化嘅一啲心得同發現。

01 唔好俾個名嚇親

好多人一聽「Skill」，又係咩「漸進式披露”、“腳本執行」……以為係啲好玄嘅嘢。其實冇咁複雜。

你可以當佢係一份俾AI睇嘅入職手冊。就好似你新加入一個項目組，leader俾你一份文檔，上面寫住「呢個項目嘅流程係點、注意事項有啲咩、遇到問題點算」，你照住做就可以上手。Skill做嘅就係呢件事，只不過「新人」變咗做AI。

「分析公司內部邊個嘅話語權最高？需要綜合考慮管理層級、薪資水平同任職時長。」

技術上嚟講，一個Skill就係一個文件夾，最核心嘅係一個叫SKILL.md嘅Markdown。佢話俾AI知「你係邊個、你可以做啲咩、遇到咩情況應該點樣做」。如果知識量比較大，仲可以將細節拆到references目錄下邊——AI按需要查閲，就好似你查項目wiki咁。

咁同直接問大模型有咩分別？分別就好似問路人「附近有咩好食」同問一個喺呢條街住咗十年嘅朋友。路人可能會推薦你大眾點評頭三位，但係作為地道嘅朋友先會話你知隱藏嘅寶藏小店。

Skill裏面裝嘅，就係經過過濾之後嘅經驗。

02 講嚇知識嘅分類

知識庫裏面嘅文章五花八門，但讀咗100篇之後，我發現佢哋基本上可以分成三大類——而且每一類轉化成Skill嘅「命運」完全唔同。

第一類：手把手教你做嘅「SOP型」文章。

呢類文章最典型嘅特徵係有明確嘅步驟——「先做A，再做B，注意C，最後得到D」。就好似一個食譜，你唔需要係大廚，照住做就可以整到一碟似樣嘅餸菜。

我做嘅第一個Skill就係嚟自呢類文章：一篇教你點樣用AI工具由零開始製作漫劇短視頻嘅文章。文章裏面嘅步驟非常清晰，先用大模型寫劇本，再用即夢生成分鏡圖，再用可靈將靜態圖變成動態視頻，最後用剪映合成。步驟之間有嚴格嘅先後順序，每一步都有具體嘅操作指引同參數建議。

轉化成Skill之後效果非常好。因為呢類文章嘅「骨架」天然就係一個工作流——你只需要將步驟提煉出嚟，將踩坑經驗標註好，將具體嘅案例內容剝走，一個用得嘅Skill就成型喇。

第二類：同你傾項目心得嘅「覆盤型」文章。

呢類文章通常係某個團隊做完一個項目之後寫嘅總結。你會讀到好多有價值嘅經驗——「我哋一開始遇到咩問題，試咗咩方案，最後發現咩方法有用」。

聽落都好有料，係咪？但轉化成Skill之後，我發現咗一個尷尬嘅問題：生成出嚟嘅Skill，同直接拎呢篇文章去問大模型，體感差別唔大。

例如我處理嘅一篇關於遊戲AI解說嘅文章。原文寫咗好多好嘢——點樣用RAG提升解說嘅專業性，點樣從主播語料中學習說話方式令AI更加似人，點樣建熱梗庫令解說更有趣。但呢啲知識同佢哋團隊用嘅特定技術棧（混元大模型、某個遊戲嘅Gamecore）綁得太實。將佢轉成Skill之後，AI的確可以將呢啲方法論複述俾你聽，但用戶嘅體感係「嘩，你講嘅我都明，但我冇用混元，我都冇你哋嘅數據㗎」。

第三類：橫向對比嘅「分析型」文章。

呢類文章最容易寫成「A公司做咗咩、B公司做咗咩、C公司做咗咩」嘅列舉——案例好豐富，對比維度都有，但係欠咗一個令讀者「攞嚟就用」嘅分析框架。

我處理嘅一篇關於遊戲AI商業化嘅文章就係呢種。佢對比咗六間遊戲公司嘅AI策略，分析咗唔同品類嘅商業化路徑，寫得幾全面。但轉化成Skill之後，你去問佢「我哋嘅SLG遊戲應該點樣做AI商業化」，佢俾嘅回答基本上就係將文章裏面嘅相關段落重新組織咗一次——同你直接搜文章、然後叫大模型幫你總結，冇本質分別。

呢個時候我意識到問題出喺邊度喇。

03 換皮測試

我後來諗通咗一件事，用一個方法就可以判斷一篇文章能唔能夠變成好Skill——我叫佢做「換皮測試」。

方法好簡單：將文章裏面所有嘅項目名、公司名、具體數據、技術棧名全部抺走。然後睇嚇剩下嘅部分，讀者仲可唔可以從中學到一套可以直接用嘅方法。

如果可以——恭喜你，呢篇文章嘅「骨架」係硬淨嘅，轉出嚟嘅Skill會好好用。

如果唔得——咁就說明呢篇文章嘅價值同佢嘅具體案例黐埋一齊，你將案例一拆，就乜都冇淨。

用煮飯嚟打個比方：好文章教嘅係「紅燒嘅方法」，換魚、換排骨、換豆腐都用到；唔夠好嘅文章教嘅係「紅燒呢條魚」，換個食材、甚至換條魚，你就唔知要落幾多醬油喇。

回頭睇我嗰三個知識分類就一目瞭然喇——

第一類（AI漫劇）教嘅係「由零到一做AI漫劇嘅通用流程」。你換成任何主題、任何風格，呢套流程都成立，先寫劇本、再生圖、再做視頻、最後剪輯。甚至你換成AI繪本、AI分鏡設計，大框架都可以重用。所以佢可以變成一個好Skill。

第二類（AI解說）雖然提出咗「專業性、擬人性、趣味性」三個維度嘅優化框架（呢個好好），但文章大部分篇幅都係講「我哋團隊喺呢個項目裏面係點樣做」。框架只佔兩成，案例佔八成。將案例抺走之後，骨架太薄喇。

第三類（AI商業化）嗰篇更加明顯——核心內容就係「呢六間公司分別做咗啲咩」。如果你問嘅啱好係文章裏面講到嘅公司，佢可以俾到好好嘅回答；如果你問一篇冇提及嘅公司或品類，佢就只能俾到泛泛嘅分析。因為佢欠咗一個「唔依賴具體案例都成立嘅分析框架」。

所以我得出嘅核心結論係：文章嘅「抽象層級」決定咗Skill嘅質量。抽象層級越高——提供嘅係方法論、框架、思維模式——Skill越好用、越通用。抽象層級越低——提供嘅係具體案例、特定數據——喺Skill加持下嘅agent就退化咗做一個低等嘅文章摘要機器人。

04 唔存在「壞」Skill，但存在「錯配」

講到呢度你可能會問：咁第二類、第三類文章就一文不值咩？

唔係嘅。更準確嘅講法係：佢哋唔適合轉成同一種Skill。

喺實際操作中，我發現Skill至少有三種形態，對應三種唔同嘅文章類型。

1. 工作流型（Workflow）： 適合「食譜型」文章。Skill嘅角色係「引導你一步步做」，用戶嘅觸發方式係「幫我做X」。呢種係體感最好嘅一種，因為佢真係幫你做嘢。

2. 能力參考型（Capabilities）： 適合「覆盤型」文章中方法論含量高嘅。Skill嘅角色係「你遇到問題時俾方案你參考」，用戶嘅觸發方式係「點樣做X」。佢更加似一個隨叫隨到嘅技術顧問。

3. 決策參考型（Reference）： 適合「分析型」文章。Skill嘅角色係「幫你梳理資訊、輔助決策」，用戶嘅觸發方式係「對比X同Y」。佢更加似一個資訊整理助手。

第一種嘅「驚豔感」最強——因為AI喺幫你做一件原本要花幾個鐘嘅事。後兩種嘅體感更加似「同一個比較識嘢嘅人傾偈」——有用，但唔夠「wow」。

不過呢個唔係Skill嘅問題，而係源文章嘅問題。一篇充滿具體操作步驟同踩坑經驗嘅好文章，天然就可以轉出一個好嘅工作流型Skill。而一篇案例豐富但方法論薄弱嘅文章，你再點樣轉化，佢嘅「天花板」就喺嗰度——因為AI嘅原料，就係嗰篇文章本身。

用一句話講就係：Skill嘅上限，唔取決於AI有幾聰明，而取決於嗰篇文章裏面藏咗幾多「可重用嘅嘢」。

05 授人以漁同魚

做完呢100篇嘅深度PoC之後，如果叫我俾所有寫技術文章嘅人一個建議，就係：寫嘅時候諗一諗：人哋讀完你篇文章，帶走嘅係「一個方法」定係「一個故事」。

故事會過期，方法唔會。

你喺項目裏面遇到嘅問題、你試過嘅方案、你踩過嘅坑——呢啲全部都好寶貴。但如果你只係跟住時間線將佢哋記錄低「我哋先做A，發現唔得，又試B，最後用咗C」，咁讀者學到嘅只係「嘩好勁，你哋做咗呢啲嘢」。

如果你可以向上抽一層——將「我哋做咗咩」變成「遇到呢類問題時可以點樣做」——你篇文章就由一個「故事」升級成咗一個「方法」。而呢個「方法」，就係AI可以真正學識、而且幫人哋重用嘅嘢。

我做呢個項目嘅過程中總結咗一個簡單嘅結構建議：問題 → 思路 → 框架 → 案例驗證。 注意，案例係最後用嚟驗證你嘅框架嘅；而唔係案例放前面，框架俾用戶/讀者自己總結。

呢個分別睇落好似好微妙，但對Skill轉化嘅效果影響好大。

06 呢個可愛嘅小東西會顛覆啲咩？

做完呢啲之後，我下意識開始用產品嘅腦去諗問題，Skill對「知識管理」呢個產品形態嚟講，到底意味住咩？

講真，我最初有一瞬間嘅興奮：係咪以後公司裏面所有嘅經驗文章都可以變成Skill？知識庫會唔會由一個「讀文章嘅地方」進化成一個「用能力嘅地方」？每個團隊嘅踩坑經驗、最佳實踐，全部變成AI可執行嘅能力包，新人入職直接一鍵繼承整個團隊嘅經驗值。

但冷靜落嚟之後，我覺得唔係咁樣嘅。至少而家唔係。

Skill更加似高鐵站嘅接駁車。 你坐高鐵由北京去深圳，呢個係技術嘅跨越、係範式嘅切換。但你由高鐵站去酒店，總唔可以又起條高鐵，你需要打的。佢唔型、唔顛覆，但佢將最後一公里嘅路駁返好。

知識管理嘅「高鐵」係咩？可能係未來某日，AI可以直接由你嘅代碼提交記錄、會議錄音、即時通訊度自動學習你嘅工作方法，完全唔需要你寫任何文章。嗰一日一定會嚟，但應該唔係今日。

今日嘅現實係，科技公司裏面有大量已經寫好、沉澱喺知識庫嘅經驗文章，但佢哋躺喺嗰度，俾人搜到嘅概率越來越低，俾無數AI賦能嘅造輪子浪潮淹沒，真正用得到嘅概率更低。任何一篇穿越返5年前都可能會係解決團隊難題嘅救命稻草、係職級晉升嘅快速通道，但係到咗今日變咗路邊一條。

另一邊，AI工具越來越勁，但佢唔知道你哋團隊踩過咩坑、你哋公司嘅流程有咩特別——佢只有通用知識，冇「你嘅知識」。Skill就係喺呢兩個現實之間起咗一條橋——將已經沉澱好嘅人類經驗，翻譯成AI可以理解嘅格式。 唔性感，但有用。

講到呢度，令我想起最近一個吵得好犀利嘅問題：未來嘅產品，到底仲係咪俾人類用嘅？

呢個爭論有好多個版本。有人話「界面正在退場」，以後用戶唔會再㩒掣，而係對住Agent講一句說話就搞掂一切。有人更加激進，話未來產品嘅「用戶」根本就唔係人，係Agent call Agent，人只負責喺最開頭講一聲「我要咩」。仲有人作咗個新詞叫AX（Agent Experience），話佢會取代UX成為產品設計嘅核心，以後我哋唔係為人設計互動，而係為AI設計接口。

坦白講，呢啲觀點都唔係亂噏，佢哋描述嘅技術趨勢係真實嘅。MCP、Agent互調、工具鏈自動化、鋪天蓋地嘅龍蝦熱潮——呢啲的確喺度發生緊。

但我反而更加肯定咗一件事：產品仍然係俾人做嘅。

道理好簡單。你睇嚇我做嘅嗰啲Skill——就算係最「AI化」嘅工作流型Skill，佢解決嘅問題仍然係「幫一個人更有效率咁做AI漫劇」。Agent喺中間跑嘅每一步——拆鏡頭、揀模型、調參數——本質上都係代替一個人原先要手動做嘅操作。如果呢個操作本身冇人類需求作為起點，Skill就毫無意義。

唔服務人類需求嘅產品，就係空中樓閣。你可以將棟樓起上雲端，Agent可以喺樓裏面跑得好快，但如果冇人需要呢棟樓——佢就只係一個精美嘅技術demo。

就好似自動駕駛咁。自動駕駛技術再勁，佢解決嘅仍然係「人要由A點去B點」呢個需求。你唔會因為車可以自己行，就話「未來嘅交通唔係服務人類嘅」。呔盤可以消失，司機可以消失，但乘客唔會消失，因為需求嘅起點同終點，永遠係人。

Skill呢件事令我對呢個辯論有一個好具體嘅感受：係嘅，產品嘅「操作層」正在由人類搬去AI——以前你手動搜知識庫、自己讀文章、自己總結重點，而家AI幫你做。但產品嘅「需求層」冇搬，亦唔會搬。你點解要用呢個Skill？因為你要做一個AI漫劇，因為你要寫一份方案，因為你要解決一個具體嘅工作問題——呢啲都係人類嘅需求，AI只係用另一種方式去滿足佢。

所以我唔覺得「產品唔再俾人做」係啱嘅。更準確嘅講法可能係：產品嘅「界面」喺度變，但產品嘅「朝向」冇變——佢永遠面向人。

從產品演進嘅角度嚟睇，我覺得知識管理呢件事大概係咁樣一條線：

最早嘅知識管理係「寫咗冇人睇」——文章寫完，掉入知識庫，自生自滅。後來進化到「寫咗搜得到」——有咗搜索、有咗標籤、有咗推薦，至少你想揾嘅時候揾到。再後來係「寫咗AI幫你讀」——大模型可以總結文章、回答問題，但佢只係幫你「讀」，唔係幫你「做」。

Skill嘅價值在於將條線推前咗一步：「寫咗AI幫你用」。 你寫嘅唔再只係俾人睇嘅文檔，而係AI嘅能力來源。

但請注意，佢推嘅只係「一步」，唔係一個時代。因為呢一步好依賴「人要寫出好文章」，我哋前面講嘅所有問題（抽象層級、換皮測試、框架 vs 案例）都說明，瓶頸唔喺AI嘅轉化能力度，瓶頸喺源頭嘅內容質量度。AI唔會變魔術，你俾佢一嚿漿糊，佢最多俾返一嚿整齊嘅漿糊你。

如果從更加技術嘅角度去睇呢件事，畫面會更加清醒。

Skill嘅技術本質，係一種「程序性知識」嘅標準化封裝格式。

呢個講法可能有啲抽象，展開講。知識分兩種：一種係「陳述性知識」——某條規定係咩、某個數據係幾多、某個概念點樣解釋；另一種係「程序性知識」——遇到呢類問題應該點樣做、呢件事嘅步驟係點、踩坑之後點樣繞過去。你去搜一個API嘅參數說明，嗰啲係陳述性知識；你讀一篇「點樣用呢個API起一個完整系統」嘅教學，嗰啲係程序性知識。

傳統嘅RAG擅長處理前者，你問佢一個事實，佢由文檔庫度揾出最相關嘅片段餵俾模型。但程序性知識唔係「片段」，佢係一套有邏輯、有先後、有條件判斷嘅完整流程，你拆散咗就冇用。Skill做嘅嘢，正正係將呢類知識完整咁、結構化咁交俾AI，唔係俾佢一個碎片叫佢估，而係俾佢一本完整嘅操作手冊叫佢照做。

從架構上睇，而家嘅AI工具鏈正在長出一個清晰嘅分層結構：底層係數據同API，中間係MCP呢啲標準化連接協議（負責令AI可以「掂到」外部工具），上層就係Skill（負責教AI「點樣用」呢啲工具）。MCP係AI嘅「手」，Skill係AI嘅「腦裏面嘅操作手冊」。 有手冇腦，你可以連到數據庫但唔知要查咩；有腦冇手，你知道要做咩但做唔到——兩者缺一不可，但解決嘅問題完全唔同。

所以Skill本質上係一份精心組織過嘅prompt，加上一啲參考文檔同可執行腳本。當你調用佢嘅時候，佢會被注入到大模型嘅上下文裏面。大模型讀咗呢啲內容之後，就可以按照你團隊嘅經驗去回答問題或執行任務。

講到尾，Skill做得到嘅嘢，唔會超越「一個聰明人讀完一份好文檔之後做得到嘅嘢」。 呢個就係佢嘅天花板，嗯，所以冇乜嘢。

呢個唔係貶低。呢個天花板其實已經好高——一個聰明人讀完一份好文檔，做得到嘅嘢相當多，我哋親愛嘅UCLA CS學生都知道，學寫程式就係讀文檔。但關鍵詞係「好文檔」。如果你俾呢個聰明人一份寫得好差嘅文檔，佢都讀唔出啲有用嘅嘢。呢個就係點解我一直強調文章質量——技術上講，Skill嘅上限完全取決於你塞咗啲咩入context。

而家流行一個詞叫「上下文工程」（Context Engineering），大意係話，喺大模型時代，真正嘅技術活唔係訓練模型，而係點樣將正確嘅資訊、喺正確嘅時機、用正確嘅格式餵俾模型。Skill就係上下文工程嘅一種具體實踐——佢將散落喺文章裏面嘅知識，重新組織成大模型更加容易「消化」嘅結構。

而且Skill喺工程上做咗一個好聰明嘅設計：漸進式披露。 佢將知識分成三層——最外層係一小段元數據摘要（大約100個token），話俾AI知「我係邊個、我可以做咩」；中間層係完整嘅操作指令（技能主體）；最裏層係參考文檔同可執行腳本。AI啓動時只讀最外層，判斷「呢個任務需要邊個Skill」，然後先按需要加載中間層同裏層。就好似你去圖書館唔會將所有書搬返屋企——你先睇目錄，揾到需要嗰本，然後先揭開具體嗰一章。傳統做法係將所有工具定義一嘢塞入上下文，輕輕鬆鬆食咗上萬token；Skill嘅做法係初始只消耗幾百token，其餘按需要加載。

但就算有呢個設計，上下文窗口仍然係有限嘅。 目前主流模型嘅窗口大約喺128K到200K token之間，一篇Skill嘅完整指令加上參考文檔，仍然會佔用相當嘅空間。呢個意味住Skill天然適合封裝嘅係「一個領域嘅一套方法論」，而唔係「一個領域嘅所有知識」。想用一個Skill解決所有問題，就好似想用一個工具箱裝曬成間五金舖，物理上唔容許。

仲有一個更深層嘅限制：Skill唔創造能力，佢只傳遞能力。 如果底層嘅大模型本身冇某種推理能力或領域理解——例如佢唔識某種程式語言嘅底層機制，或者佢對某個垂直行業嘅理解有硬傷——咁Skill再點樣精心編寫都補唔到呢個短板。就好似你俾一個唔識樂理嘅人一份鋼琴教程，佢可以讀明每個字，但彈唔出。Skill嘅下限，係底層模型嘅能力邊界。

所以從技術嘅角度睇，Skill嘅定位其實好明確：佢係大模型時代嘅「經驗壓縮包」——將人類嘅程序性知識壓縮成模型可以讀明嘅格式，令模型喺特定任務上表現得似一個「讀過相關操作手冊嘅專家」，而唔係一個「咩都識啲但冇樣精」嘅通才。 佢唔會令AI變得更聰明，但佢可以令AI嘅聰明用喺正確嘅地方。佢唔係RAG（嗰個係俾AI喂事實），唔係fine-tuning（嗰個係改造AI嘅大腦），而係遞咗本寫得好嘅工作指南俾AI。

呢個同產品側嘅判斷其實係一致嘅，技術唔玄，亦唔顛覆，但實實在在解決咗一個具體問題。

所以如果你問我「Skill會唔會改變知識管理」，我嘅回答係：會，但唔多。 佢改變嘅唔係知識管理嘅範式，而係令「寫好文章」呢件本來就應該做嘅事，多咗一個實在嘅回報，你嘅經驗唔止俾人讀到，仲可以俾AI用得到。呢個回報，或者可以反過來激勵人將文章寫得更好。

但如果你期待佢顛覆啲咩，唔好意思，接駁車唔係F1賽車。佢嘅最大價值，正正係令你由舊範式行到新範式嘅呢段路唔使淋雨。

07 我真正學到嘅嘢

坦白講，我一開始做呢個項目嘅時候，諗嘅係「點樣將文章變成好Skill」。但做嚇做嚇，我發現呢個項目其實喺度回答一個更加根本嘅問題：點樣嘅知識先至係真正可以重用嘅？

唔係所有寫低嘅嘢都係「可重用嘅知識」。有啲係記錄，有啲係感想，有啲係總結，有啲係工具——但只有嗰啲被抽象到一定高度、可以脱離具體場景獨立成立嘅內容，先至真正具備「可重用性」。

呢個判斷標準同Skill其實冇關係，喺Skill呢個載體出現之前，呢條規律就一直存在。一篇好嘅技術博客、一份好嘅內部文檔、一個好嘅知識庫條目，判斷標準都係一樣：人哋可唔可以用佢，喺自己嘅場景度直接用起嚟。

Skill只不過係將呢件事變得更加顯性，因為佢需要AI去「理解」你嘅知識同埋「執行」出嚟，所以知識係咪真係可重用，AI一跑就知。你呃唔到AI話你寫嘅係方法論，如果佢讀完只能複述案例——咁就係案例，唔係方法論。

由呢個角度睇，AI唔係取代人嘅知識，佢係幫人檢驗知識嘅質素。

兜咗咁大個圈講咗咁多，其實核心就三句嘢：文章教「方法」嘅部分先可以變成好Skill，教「故事」嘅部分只能變成摘要。睇嚇佢抺走具體案例之後，框架仲企唔企得穩。

寫文章嘅時候諗多一步：「如果有人要拎我嘅經驗去用，佢需要我寫成點樣？」——呢一步，就係由「記錄者」到「知識工程師」嘅跨越。

呢100篇文章教咗我好多嘢。但教得最多嘅，反而唔係嗰啲變成好Skill嘅——而係嗰啲「變唔出好Skill」嘅。

因為好知識嘅標準從來都唔係「你做咗咩」，而係「人哋讀完可以做咩」。

文章最後推介俾大家我哋嘅Skillhub，好嘢👍，

https://skillhub.tencent.com/

喺充分本地化之後展現出對中文用戶驚人嘅適配程度

上週五深夜，我盯着屏幕上第14個剛生成好的Skill，忽然覺得不對勁。

我花了兩天時間，從公司知識庫裏抓了100篇遊戲技術文章，一篇一篇讀過去，試着把它們餵給skill-creator，轉化成可以直接上手使用的Skill。簡單來說，就是把別人寫的經驗和方法論，變成一個AI能理解、能執行的"能力包"，你對它說"幫我做個AI漫劇"，它就真的能一步步帶你從劇本寫到出片。

聽起來很美好對吧？

但做到第14個的時候，我發現了一個讓我坐不住的規律：不是所有文章都能變成好Skill，甚至大部分都不行...但是我們卻可以用一些特定的方法略施小計，化腐朽為神奇。這個發現可能要比"做出Skill"本身更有價值。所以今天這篇隨筆，是我對於skill應用和轉化的一些心得和發現。

01 別被名字唬住

很多人一聽"Skill"，又是什麼“漸進式披露”、“腳本執行”......以為是什麼很玄乎的東西。其實沒那麼複雜。

你可以把它理解成一份給AI看的入職手冊。就像你新加入一個項目組，leader給你一份文檔，上面寫着"這個項目的流程是什麼、注意事項有哪些、遇到坑怎麼辦"，你照着做就能上手。Skill做的就是這件事，只不過"新人"變成了AI。

"分析公司內部誰的話語權最高？需要綜合考慮管理層級、薪資水平和任職時長。"

技術上說，一個Skill就是一個文件夾，裏面最核心的是一個叫SKILL.md的Markdown。它告訴AI"你是誰、你能做什麼、遇到什麼情況該怎麼做"。如果知識量比較大，還可以把細節拆到references目錄下——AI按需查閲，就像你翻查項目wiki一樣。

這和直接問大模型有什麼區別？區別就像問路人"附近有啥好吃的"和問一個在這條街住了十年的朋友。 路人可能給你推薦大眾點評排名前三，但作為當地人的朋友才會告訴你隱藏的寶藏小店。

Skill裏裝的，就是經過過濾之後的經驗。

02 論知識之分類

知識庫裏的文章五花八門，但讀了100篇之後，我發現它們基本可以分成三大類——而且每一類轉化成Skill的"命運"完全不同。

第一類：手把手教你做的"SOP型"文章。

這類文章最典型的特徵是有明確的步驟——"先做A，再做B，注意C，最後得到D"。就像一道菜譜，你不需要是大廚，照着做就能端出一盤差不多的菜。

我做的第一個Skill就來自這類文章：一篇教你如何用AI工具從零開始製作漫劇短視頻的文章。文章裏的步驟非常清晰，先用大模型寫劇本，再用即夢生成分鏡圖，再用可靈把靜態圖變成動態視頻，最後用剪映合成。步驟之間有嚴格的先後順序，每一步都有具體的操作指引和參數建議。

轉化成Skill之後效果非常好。因為這類文章的"骨架"天然就是一個工作流——你只需要把步驟提煉出來，把踩坑經驗標註好，把具體的案例內容剝掉，一個能用的Skill就成型了。

第二類：跟你聊項目心得的"覆盤型"文章。

這類文章通常是某個團隊做完一個項目之後寫的總結。你能讀到很多有價值的經驗——"我們一開始遇到了什麼問題，試了什麼方案，最後發現什麼方法管用"。

聽起來也很有料對吧？但轉化成Skill之後，我發現了一個尷尬的問題：生成出來的Skill，和直接拿這篇文章去問大模型，體感差別不大。

比如我處理的一篇關於遊戲AI解說的文章。原文寫了很多好東西——怎麼用RAG提升解說的專業性，怎麼從主播語料中學習說話方式讓AI更像人，怎麼建熱梗庫讓解說更有趣。但這些知識和他們團隊用的特定技術棧（混元大模型、某個遊戲的Gamecore）綁定太緊了。把它轉成Skill之後，AI確實能把這些方法論複述給你聽，但用戶的體感是"沃日，你說的我都懂，可我不用混元、我也沒有你們的數據啊"。

第三類：橫向對比的"分析型"文章。

這類文章最容易寫成"A公司做了什麼、B公司做了什麼、C公司做了什麼"的羅列——案例很豐富，對比維度也有，但缺少一個讓讀者"拿來就用"的分析框架。

我處理的一篇關於遊戲AI商業化的文章就是這種。它對比了六家遊戲公司的AI策略，分析了不同品類的商業化路徑，寫得挺全的。但轉化成Skill之後，你去問它"我們的SLG遊戲應該怎麼做AI商業化"，它給的回答基本就是把文章裏的相關段落重新組織了一遍——和你直接搜索文章、然後讓大模型幫你總結，沒有本質區別。

這時候我意識到問題出在哪了。

03 換皮測試

我後來想明白了一件事，用一個方法就能判斷一篇文章能不能變成好Skill——我管它叫"換皮測試"。

方法很簡單：把文章裏所有的項目名、公司名、具體數據、技術棧名字全部抹掉。然後看看剩下的部分，讀者還能不能從中學到一套可以直接用的方法。

如果能——恭喜你，這篇文章的"骨架"是硬的，轉出來的Skill會很好用。

如果不能——那說明這篇文章的價值和它的具體案例粘在了一起，你把案例一扒，就什麼都不剩了。

用做菜打個比方：好文章教的是"紅燒的方法"，換魚、換排骨、換豆腐都能用；不夠好的文章教的是"紅燒這條魚"，換個食材、甚至換條魚，你就不知道該放多少醬油了.

回頭看我那三個知識分類就一目瞭然了——

第一類（AI漫劇）教的是"從零到一做AI漫劇的通用流程"。你換成任何主題、任何風格，這套流程都成立，先寫劇本、再生圖、再做視頻、最後剪輯。甚至你換成AI繪本、AI分鏡設計，大框架都能複用。所以它能變成一個好Skill。

第二類（AI解說）雖然提出了"專業性、擬人性、趣味性"三個維度的優化框架（這個很好），但文章的大部分篇幅都在講"我們團隊在這個項目裏是怎麼做的"。框架只佔兩成，案例佔八成。把案例抹掉之後，骨架太薄了。

第三類（AI商業化）那篇更明顯——核心內容就是"這六家公司分別做了什麼"。你要是問的恰好是文章裏講到的公司，它能給你很好的回答；你要是問一個文章沒提到的公司或品類，它就只能給你泛泛的分析了。因為它缺少一個"不依賴具體案例也能成立的分析框架"。

所以我得出的核心結論是：文章的"抽象層級"決定了Skill的質量。 抽象層級越高——提供的是方法論、框架、思維模式——Skill越好用、越通用。抽象層級越低——提供的是具體案例、特定數據——在Skill加持下的agent就退化成了一個低等的文章摘要機器人。

04 不存在"壞"Skill，但存在"錯配"

說到這你可能會問：那第二類、第三類文章就一文不值了麼？

不是的。更準確的說法是：它們不適合轉成同一種Skill。

在實際操作中，我發現Skill至少有三種形態，對應三種不同的文章類型。

1. 工作流型（Workflow）： 適合"菜譜型"文章。Skill的角色是"引導你一步步做"，用戶的觸發方式是"幫我做X"。這是體感最好的一種，因為它真的在幫你幹活。

2. 能力參考型（Capabilities）： 適合"覆盤型"文章中那些方法論含量高的。Skill的角色是"你遇到問題時給你方案參考"，用戶的觸發方式是"怎麼做X"。它更像一個隨叫隨到的技術顧問。

3. 決策參考型（Reference）： 適合"分析型"文章。Skill的角色是"幫你梳理信息、輔助決策"，用戶的觸發方式是"對比X和Y"。它更像一個信息整理助手。

第一種的"驚豔感"最強——因為AI在幫你做一件原本要花幾小時的事。後兩種的體感更像"和一個比較懂行的人聊天"——有用，但不夠"wow"。

不過這不是Skill的問題，這是源文章的問題。 一篇充滿具體操作步驟和踩坑經驗的好文章，天然就能轉出一個好的工作流型Skill。而一篇案例豐富但方法論薄弱的文章，你再怎麼轉化，它的"天花板"就在那裏——因為AI的原料，就是那篇文章本身。

用一句話說就是：Skill的上限，不取決於AI有多聰明，而取決於那篇文章裏藏了多少"可複用的東西"。

05 授人以漁和魚

做完這100篇的深度PoC之後，如果讓我給所有寫技術文章的人提一個建議，那就是：寫的時候想一想：別人讀完你的文章，帶走的是"一個方法"還是"一個故事"。

故事會過期，方法不會。

你在項目裏遇到的那些問題、你試過的那些方案、你踩過的那些坑——這些都非常寶貴。但如果你只是按照時間線把它們記錄下來"我們先做了A，發現不行，又試了B，最後用了C"，那讀者學到的只是"哦牛批，你們做了這些"。

如果你能向上抽一層——把"我們做了什麼"變成"遇到這類問題時可以怎麼做"——你的文章就從一個"故事"升級成了一個"方法"。而這個"方法"，就是AI能真正學會、並且幫別人複用的東西。

我做這個項目的過程中總結了一個簡單的結構建議：問題 → 思路 → 框架 → 案例驗證。 注意，案例是在最後用來驗證你的框架的；而不是案例在前面，框架讓用戶/讀者自己總結。

這個區別看似微妙，但對Skill轉化的效果影響巨大。

06 這可愛的小東西會顛覆什麼嗎？

做完這些之後，我下意識地開始用產品的腦子想問題，Skill對"知識管理"這個產品形態來說，到底意味着什麼？

說實話，我最初有一瞬間的興奮：是不是以後公司裏所有的經驗文章都能變成Skill？知識庫會不會從一個"讀文章的地方"進化成一個"用能力的地方"？每個團隊的踩坑經驗、最佳實踐，全部變成AI可執行的能力包，新人入職直接一鍵繼承整個團隊的經驗值。

但冷靜下來之後，我覺得不是這樣的。至少現在不是。

Skill更像是高鐵站的擺渡車。 你坐高鐵從北京到深圳，那是技術的跨越、是範式的切換。但你從高鐵站到酒店，總不能也修一條高鐵，你需要打個車。它不酷，不顛覆，但它把最後三公里的路接上了。

知識管理的"高鐵"是什麼？可能是未來某一天，AI可以直接從你的代碼提交記錄、會議錄音、即時通訊裏自動學習你的工作方法，完全不需要你寫任何文章。那一天一定會來，但應該不是今天。

今天的現實是，科技公司裏有大量已經寫好的、沉澱在知識庫裏的經驗文章，但它們躺在那裏，被搜索到的概率越來越低，被無數AI賦能的造輪子浪潮所淹沒，被真正用起來的概率更低。任何一篇穿越到5年前都可能是解決團隊難題的救命稻草、是職級晉升的快速通道，但到了今天變成了路邊一條。

另一邊，AI工具越來越強，但它不知道你們團隊踩過什麼坑、你們公司的流程有什麼特殊的地方——它只有通用知識，沒有"你的知識"。Skill就是在這兩個現實之間架了一根橋——把已經沉澱好的人類經驗，翻譯成AI能理解的格式。 不性感，但管用。

說到這，讓我想到了最近一個吵得很兇的問題：未來的產品，到底還是不是給人類做的？

這個爭論有很多個版本。有人說"界面正在退場"，以後用戶不會再點按鈕，而是對着Agent說一句話就搞定一切。有人更激進，說未來產品的"用戶"根本就不是人，是Agent在調Agent，人只負責在最開頭說一聲"我要什麼"。還有人造了個新詞叫AX（Agent Experience），說它會取代UX成為產品設計的核心，以後我們不是在為人設計交互，而是在為AI設計接口。

坦白說，這些觀點都不是瞎說，它們描述的技術趨勢是真實的。MCP、Agent互調、工具鏈自動化、鋪天蓋地的龍蝦熱潮——這些確實在發生。

但我反而更篤定了一件事：產品仍然是給人做的。

道理很樸素。你去看我做的那些Skill——哪怕是最"AI化"的工作流型Skill，它解決的問題仍然是"幫一個人類更高效地做AI漫劇"。Agent在中間跑的每一步——拆分鏡、選模型、調參數——本質上都是在替代一個人類原本要手動做的操作。如果這個操作本身沒有人類需求作為起點，Skill就毫無意義。

不服務於人類需求的產品，就是空中樓閣。你可以把樓蓋到雲端，Agent可以在樓裏跑得飛快，但如果沒有人需要這棟樓——它就只是一個精美的技術demo。

這就像自動駕駛。自動駕駛技術再厲害，它解決的仍然是"人要從A點到B點"這個需求。你不會因為車能自己開了，就說"未來的交通不是給人類服務的"。方向盤可以消失，司機可以消失，但乘客不會消失，因為需求的起點和終點，永遠是人。

Skill 這件事讓我對這個辯論有了一個很具體的感受：是的，產品的"操作層"正在從人類遷移到AI——以前你手動搜知識庫、自己讀文章、自己總結要點，現在AI幫你做。但產品的"需求層"沒有遷移，也不會遷移。你為什麼要用這個Skill？因為你要做一個AI漫劇，因為你要寫一份方案，因為你在解決一個具體的工作問題——這些都是人類的需求，AI只是換了一種方式去滿足它。

所以我不覺得"產品不再給人做"是對的。更準確的說法可能是：產品的"界面"在變，但產品的"朝向"沒變——它永遠面向人。

從產品演進的角度看，我覺得知識管理這件事大概是這麼一條線：

最早的知識管理是"寫了沒人看"——文章寫完，丟進知識庫，自生自滅。後來進化到"寫了搜得到"——有了搜索、有了標籤、有了推薦，至少你想找的時候能找到。再後來是"寫了AI幫你讀"——大模型能總結文章、回答問題，但它只是在幫你"讀"，不是在幫你"做"。

Skill 的價值在於把這條線往前推了一步："寫了AI幫你用"。 你寫的不再只是給人看的文檔，而是AI的能力來源。

但請注意，它推的只是"一步"，不是一個時代。因為這一步嚴重依賴於"人先寫出好文章"，我們前面說的所有問題（抽象層級、換皮測試、框架 vs 案例）都說明，瓶頸不在AI的轉化能力上，瓶頸在源頭的內容質量上。AI不會變魔術，你給它一坨漿糊，它最多給你一坨整齊的漿糊。

如果從更技術的角度看這件事，畫面會更清醒。

Skill的技術本質，是一種"程序性知識"的標準化封裝格式。

這個說法可能有點抽象，展開講。知識分兩種：一種是"陳述性知識"——某條規定是什麼、某個數據是多少、某個概念怎麼解釋；另一種是"程序性知識"——遇到這類問題該怎麼做、這件事的步驟是什麼、踩坑之後怎麼繞過去。你去搜一個API的參數說明，那是陳述性知識；你讀一篇"怎麼用這個API搭建一個完整系統"的教程，那是程序性知識。

傳統的RAG擅長處理前者，你問它一個事實，它從文檔庫裏找到最相關的片段餵給模型。但程序性知識不是"片段"，它是一套有邏輯、有先後、有條件判斷的完整流程，你拆碎了它就沒用了。Skill乾的事情，恰恰是把這類知識完整地、結構化地交給AI，不是給它一個碎片讓它猜，而是給它一本完整的操作手冊讓它照着做。

從架構上看，現在的AI工具鏈正在長出一個清晰的分層結構：底層是數據和API，中間是MCP這樣的標準化連接協議（負責讓AI能"夠到"外部工具），上層就是Skill（負責教AI"怎麼用"這些工具）。MCP是AI的"手"，Skill是AI的"腦子裏的操作手冊"。 有手沒腦子，你能連上數據庫但不知道該查什麼；有腦子沒手，你知道該做什麼但做不了——兩者缺一不可，但解決的問題完全不同。

所以Skill本質上是一份精心組織過的prompt，加上一些參考文檔和可執行腳本。在你調用的時候，它被注入到大模型的上下文裏。大模型讀了這些內容之後，就能按照你團隊的經驗來回答問題或執行任務。

說白了，Skill能做的事，不會超過"一個聰明人讀完一份好文檔之後能做的事"。 這就是它的天花板，嗯，所以沒什麼東西。

這不是貶低。這個天花板其實已經很高了——一個聰明人讀完一份好文檔，能做的事相當多，我們親愛的UCLA CS學生都知道，編程學習就是讀文檔。但關鍵詞是"好文檔"。如果你給這個聰明人一份寫得稀爛的文檔，他也讀不出什麼有用的東西來。這就是為什麼我前面一直在強調文章質量——技術上說，Skill的上限完全取決於你往context裏塞了什麼。

現在流行一個詞叫"上下文工程"（Context Engineering），大意是說，在大模型時代，真正的技術活不是訓練模型，而是怎麼把正確的信息、在正確的時機、用正確的格式餵給模型。Skill就是上下文工程的一種具體實踐——它把散落在文章裏的知識，重新組織成大模型更容易"消化"的結構。

而且Skill在工程上做了一個很聰明的設計：漸進式披露。 它把知識分成三層——最外層是一小段元數據摘要（大約100個token），告訴AI"我是誰、我能幹什麼"；中間層是完整的操作指令（技能主體）；最裏層是參考文檔和可執行腳本。AI啓動時只讀最外層，判斷"這個任務需要哪個Skill"，然後才按需加載中間層和裏層。這就像你去圖書館不會把所有書搬回家——你先看目錄，找到需要的那本，再翻開具體那一章。傳統做法是把所有工具定義一股腦塞進上下文，輕輕鬆鬆吃掉上萬token；Skill的做法是初始只消耗幾百token，剩下的按需加載。

但即便有這個設計，上下文窗口仍然是有限的。 目前主流模型的窗口大約在128K到200K token之間，一篇Skill的完整指令加上參考文檔，還是會佔掉相當的空間。這意味着Skill天然適合封裝的是"一個領域的一套方法論"，而不是"一個領域的所有知識"。想用一個Skill解決所有問題，就像想用一個工具箱裝下整個五金店，物理上不允許。

還有一個更深層的限制：Skill不創造能力，它只傳遞能力。 如果底層的大模型本身不具備某種推理能力或領域理解——比如它不懂某種編程語言的底層機制，或者它對某個垂直行業的理解有硬傷——那Skill再怎麼精心編寫也補不上這個短板。就像你給一個不懂樂理的人一份鋼琴教程，他能讀懂每個字，但彈不出來。Skill的下限，是底層模型的能力邊界。

所以從技術的角度看，Skill的定位其實非常明確：它是大模型時代的"經驗壓縮包"——把人類的程序性知識壓縮成模型能讀懂的格式，讓模型在特定任務上表現得像一個"讀過對口操作手冊的專家"，而不是一個"什麼都知道一點但什麼都不精"的通才。 它不會讓AI變得更聰明，但它能讓AI的聰明用在正確的地方。它不是RAG（那是給AI喂事實），不是fine-tuning（那是改造AI的大腦），而是給AI遞了一本寫得好的工作指南。

這跟產品側的判斷其實是一致的，技術不玄，也不顛覆，但實打實地解決了一個具體問題。

所以如果你問我"Skill會改變知識管理嗎"，我的回答是：會，但不多。 它改變的不是知識管理的範式，而是讓"寫好文章"這件本來就該做的事，多了一個實實在在的回報，你的經驗不只是被人讀到，還能被AI用起來。這個回報，或許能反向激勵人把文章寫得更好。

但如果你期待它顛覆什麼，抱歉，擺渡車不是F1賽車。它的最大價值，恰恰是讓你從舊範式走到新範式的這段路不用淋雨。

07 我真正學到的東西

坦白說，我一開始做這個項目的時候，想的是"怎麼把文章變成好Skill"。但做着做着，我發現這個項目其實在回答一個更底層的問題：什麼樣的知識才是真正可複用的？

不是所有寫下來的東西都是"可複用的知識"。有些是記錄，有些是感想，有些是總結，有些是工具——但只有那些被抽象到一定高度的、能脱離具體場景獨立成立的內容，才真正具備"可複用性"。

這個判斷標準和Skill其實沒什麼關係，在Skill這個載體出現之前，這條規律就一直存在。一篇好的技術博客、一份好的內部文檔、一個好的知識庫條目，判斷標準都是一樣的：別人能不能拿着它，在自己的場景裏直接用起來。

Skill只不過是把這件事變得更加顯性了，因為它需要AI來"理解"你的知識並"執行"出來，所以知識是不是真的可複用，AI一跑就知道了。你沒法騙AI說你寫的是方法論，如果它讀完只能複述案例——那就是案例，不是方法論。

從這個角度說，AI不是在替代人的知識，它是在幫人檢驗知識的質量。

繞着圈子說了這麼多，其實核心就三句話：文章教"方法"的部分才能變成好Skill，教"故事"的部分只能變成摘要。看看它抹掉具體案例後，框架還能不能站住。

寫文章的時候多想一步："如果有人要拿我的經驗去用，他需要我寫成什麼樣？"——這一步，就是從"記錄者"到"知識工程師"的跨越。

這100篇文章教了我很多。但教得最多的，反而不是那些變成好Skill的——而是那些"變不出好Skill"的。

因為好知識的標準從來不是"你做了什麼"，而是"別人讀完能做什麼"。

文章最後給大家推薦俺們的Skillhub，夯👍，

https://skillhub.tencent.com/

在充分本地化之後展現出了對中文用戶驚人的適配程度