職業.Skill，一個 Skill 包攬你的工作
整理版優先睇
職業.Skill：用職業框架系統化製作AI Skill，覆蓋所有工作場景
呢篇文章嘅作者係一位產品經理，佢積累咗超過100個Skill，用嚟處理工作入面嘅畫原型、寫文檔、分析數據等任務。佢發現製作有效嘅Skill需要做好兩方面：製作同管理，而製作嘅關鍵係從已有經驗出發。佢提出四種方法：樣板法（用最滿意嘅交付物做模板）、流程法（將固定步驟輸入輸出串成自動化）、歸納法（從聊天記錄整理反覆做嘅嘢）、經驗法（將隱性知識寫入文檔）。
但係呢啲方法有個漏洞：低頻工作場景好容易遺漏，例如問卷調研、競品分析、埋點方案等，到要做嘅時候先發現冇Skill，臨時整又手忙腳亂。為咗解決呢個問題，作者設計咗一個叫「職業.skill」嘅工具——只要講低你嘅職業，佢就會幫你拆出呢個職業應該有嘅Skill，每個Skill附有可以直接用嘅提示詞，複製畀Agent就生成到。呢個工具用職業做框架，唔容易遺漏亦唔會重複，因為每個職業嘅工作內容本身係一張相對確定嘅清單。
作者用呢個工具幫自己增加咗十幾個新Skill，將產品工作從頭捋咗一遍，總共13個Skill，例如pm-review-board模擬六個角色評審PRD、pm-analytics由數據跌嘅起點走完整分析鏈路、pm-image2proto截圖轉HTML原型。佢嘅感受係：Skill用得多，反而覺得呢啲細粒度嘅嘢終有一日會被大模型進化掉，變成更大嘅能力單元；但而家模型仲未夠強，寫清指令同工作流仍然值得做。
- 四種製作Skill方法：樣板法、流程法、歸納法、經驗法，全部都係從已有經驗出發。
- 低頻工作場景容易遺漏Skill，用職業框架拆解可以系統化覆蓋所有使用場景。
- 職業.skill工具一鍵輸出職業相關嘅Skill製作指南，附提示詞可直接複製用。
- 產品經理13個Skill示例包括pm-review-board（模擬六角色評審）、pm-analytics（數據分析鏈路）、pm-image2proto（截圖轉原型）。
- 作者認為細粒度Skill終會被模型內化，但現階段仍需明確指令同工作流來保證穩定輸出。
職業.Skill GitHub 倉庫
主倉庫，安裝後可以按職業拆解Skill。
產品經理 13 個 Skill 完整列表
包含 pm-review-board、pm-analytics、pm-image2proto 等 Skill 嘅倉庫。
pm-review-board
模擬產品、研發、測試、設計、運營、法務六角色評審 PRD，輸出阻斷項/重要項/建議項。
pm-analytics
從「數據跌咗」起點走完整分析鏈路：健康體檢→指標拆解→現象定位→假設推斷→行動建議。
從經驗提煉 Skill：四種實戰方法
作者分享咗四種製作 Skill 嘅方法，全部都係由已有經驗出發：你做過嘅事、踩過嘅坑、積累嘅模板，先至有得提煉。
- 樣板法：攞最滿意嘅交付物做模板，叫AI從入面提煉標準封裝成 Skill。
- 流程法：將固定工作步驟嘅輸入輸出寫清楚，串成自動化 Skill。
- 歸納法：回看聊天記錄，找出反覆叫AI做嘅嘢，補成 Skill。
- 經驗法：將腦入面「只可意會」嘅隱性知識寫成文檔綁入 Skill。
樣板法係最快嘅入門方式，因為你手頭實有舊文件。
流程法適合重複性高、步驟固定嘅工作。
職業框架：一次過拆曬所有場景
平時做嘅少嘅工作場景，例如問卷調研、競品分析、埋點方案、項目覆盤，好容易漏咗 Skill。作者試過寫完需求文檔評審通過先發現漏咗埋點，要返轉頭加，浪費時間。最佳嘅梳理方式係按職業嚟拆——職業係一個天然嘅需求收集器，每個職業有固定工作流、反覆輸出物同永遠踩唔完嘅坑。
職業.skill 呢個工具就係為咗解決呢個問題而設計。
用法好直接：喺 Claude Code 或任意 coding Agent 輸入「我係xxx（職業名），幫我拆 Skill」，佢就會輸出 8 個 Skill 嘅製作指南，包括材料、提示詞同內部邏輯。你可以直接複製描述，叫 Agent 幫你製作，再測試效果。
如果講「運營」，佢會問你負責邊個方向（內容/用戶/活動/增長），確保拆得準。
產品經理嘅13個Skill實例
作者用職業.skill 幫自己增加咗十幾個新 Skill，將產品工作從頭捋咗一遍：需求來源、點寫清楚、點過評審、數據分析、實驗設計、覆盤，每個環節一個 Skill，總共13個。
- pm-analytics：由「數據跌咗」走完整分析鏈路，健康體檢→指標拆解→現象定位→假設推斷→行動建議，強制區分相關性與因果，結論標註可信度，輸出 HTML 報告。
- pm-image2proto：截圖傳入輸出可運行 HTML 原型，有學習記憶機制，第一次確認配色同組件風格後，後續可以複用。
pm-review-board 輸出三級分類（阻斷項/重要項/建議項），好清晰。
pm-analytics 所有結論都標註可信度，避免亂猜。
Skill嘅未來：細粒度會被更大能力單元取代
作者發現自己將上百個 Skill 分成幾類，對應唔同職業需求，呢種形式其實可以融入模型入面。如果模型可以加載一個角色（例如設計、測試、產品經理），就能將呢啲 Skill 能力籠攬曬，對企業同個人價值更大。
Claude Cowork 嘅插件方向同作者不謀而合：安裝插件就擁有職業專家能力。
佢認為兩條路最終可能走到同一個地方：隨住模型能力變強，越嚟越多人直接安裝職業能力包就得，細粒度 Skill 會慢慢融合成更大嘅能力單元，變成感知唔到嘅嘢。但而家模型仲需要明確指令、清晰工作流同檢查清單，Skill 本質上就係將呢啲寫清固定落嚟嘅方式。
我累積咗100幾個Skill，但要用得好，只需要做好兩方面：製作嘅Skill要有效，管理Skill都要有效。我已經喺社羣分享咗好多跨電腦、跨工具、跨網絡管理Skill嘅方法。
今日呢篇文章就講下Skill嘅製作，點樣整出有效嘅Skill。
1 樣板法：用最滿意嘅交付物做模板，叫 AI 提煉標準封裝成 Skill。
2 流程法將固定工作步驟嘅輸入輸出寫清楚，串成自動化 Skill。
3 歸納法翻睇聊天記錄，揾出成日叫 AI 做嘅嘢，補返做 Skill。
4 經驗法將腦入面「只可意會」嘅隱性知識寫成文檔綁入 Skill。
呢四個方法有一個共通點：都係由已有經驗出發。你做過嘅嘢、踩過嘅坑、累積嘅模板，有咗先可以提煉。
但問題係，好多工作場景你平時好少做，諗唔到自然就冇 Skill。
好似我作為產品經理，有啲嘢一定要做但唔係成日做：問卷調查、競品分析、埋點方案、項目覆盤等。等到要做嘅時候先發現冇 Skill，臨時寫就好匆忙又無從入手。
我成日寫完需求文檔，評審通過咗，先發現埋點、數據指標相關嘅工作都漏咗，呢個時候仲要加返，好浪費心機同時間。
所以最好嘅 Skill 梳理方式係按職業去分，唔好漏咗任何一個使用場景。
職業係一個天然嘅需求收集器。每個職業都有自己固定嘅工作流程、成日出現嘅輸出物、幾個永遠踩唔完嘅坑。用職業做框架去拆解，唔易漏，亦唔易重複，因為一個職業應該做啲乜，本身已經係一張相對確定嘅清單。
於是我整咗個叫「職業.skill」嘅嘢。
一句講曬：同佢講你嘅職業，佢幫你拆出呢個職業應該做邊啲 Skill，每個 Skill 嘅提示詞直接複製畀 Agent 就可以生成。
用法好直接。喺 Claude Code 或者任何 coding Agent 度講「我係xxx（講你嘅職業名），幫我拆 Skill」，佢會輸出 8 個 Skill 嘅製作指南，包括每個 Skill 需要提供咩材料、可以直接用嘅提示詞、Skill 內部嘅執行邏輯。
最後輸出嘅係一個 Skill 嘅製作清單，你可以直接複製每個 Skill 嘅描述，好似上面紅框框住嘅內容，複製之後，同你個 Agent 講：「幫我整呢個 Skill」等佢製作完成，自己測試下效果，如果可以按要求提供一啲例子內容，效果會更加好。
有一個細節：唔同公司對同一職業嘅定義差好遠。講「運營」，佢唔會直接輸出，而係問一個問題：「你主要負責邊個方向？內容運營 / 用戶運營 / 活動運營 / 增長運營？」揀完先開始拆。咁樣拆出嚟嘅清單準確度高好多。
GitHub 倉庫喺呢度：https://github.com/zephyrwang6/career.skill
複製上面條link，直接發畀你嘅 Claude codeh 或者龍蝦話：幫我安裝呢個 Skill，就可以用。
我用呢個職業.skill，幫自己嘅工作加咗十幾個新 Skill。
佢將產品工作由頭梳咗一次：需求從邊度嚟、點樣寫清楚、點樣過評審、數據點樣睇、實驗點樣設計、結果出咗點樣覆盤，每個環節都做咗一個 Skill，總共 13 個。
講幾個用落效果比較好嘅：
pm-review-board，模擬產品、研發、測試、設計、運營、法務六個角色同時評審一份 PRD，按阻斷項 / 重要項 / 建議項三級分類輸出意見。評審會上俾人鬧通常唔係因為需求真係差，而係某個角色嘅疑慮冇事先諗到。呢個 Skill 令問題喺開會前就曝露。
地址：https://github.com/zephyrwang6/pm-skills/tree/main/pm-review-board
pm-analytics，由「數據跌咗」呢個起點走完整個分析路徑：數據健康檢查 → 指標拆解 → 現象定位 → 假設推斷 → 行動建議。強制區分相關性同疑似因果，所有結論標註可信度。輸出係單一 HTML 報告，畀老細睇唔駛再整理格式。
地址：https://github.com/zephyrwang6/pm-skills/tree/main/pm-analytics
pm-image2proto，截圖傳入去，輸出一個可以運行嘅 HTML 原型。做咗學習記憶機制，第一次確認咗配色同元件風格之後，之後每次話「呢個都係一樣」就可以重用，唔使每次重新描述。
地址：https://github.com/zephyrwang6/pm-skills/tree/main/pm-url2proto
13 個 Skill 嘅完整列表喺呢度：https://github.com/zephyrwang6/pm-skills
Skill 用得越多越覺得 Skill 會被大模型進化淘汰。
我將上百個 Skill 分咗幾個類型，呢幾個類型我發現佢哋都係對應返職業嘅需求。
呢種形式其實可以整喺模型入面，如果模型突然可以加載一個譬如話設計、測試、產品經理咁嘅角色，就可以將呢啲 Skill 嘅能力全部包曬。咁樣對於企業、對於個人嚟講，佢嘅價值會更大，亦都更容易模塊化交付。
另一件事係，最近留意到 Claude Cowork 嘅產品。推出咗一種插件嘅能力，安裝咗某個插件，Claude 就會擁有嗰個職業嘅專家能力，產品經理插件裝上，佢會幫你做產品相關嘅工作。
呢個方向同我想做嘅嘢不謀而合。
呢兩條路最終可能會行到同一個地方。隨住模型能力越來越強，可能越來越多人唔需要仔細做好每一個 Skill，直接安裝某個職業嘅能力包就夠。細粒度嘅 Skill 會慢慢融合落更大嘅能力單元入面，變成一種人感知唔到嘅嘢。
但而家仲未係嗰個時候。
而家嘅模型需要明確嘅指令、清晰嘅工作流程、具體嘅檢查清單，先可以穩定輸出有價值嘅嘢。Skill 本質上係將呢啲嘢寫清楚、固化落嚟嘅一種方式。
喺模型仲未勁到「乜都識、乜都曉」之前，呢件事仍然值得做。
職業.skill 就係將更多職業嘅拆解整出嚟，令唔同職業嘅人都可以輕鬆用上 Skill。
關於 Skill 嘅製作，有興趣嘅可以訂閲我嘅 AI 生產力專欄，加入社羣，同更多朋友一齊用 AI 提高生產力。
我積累 100 多個 Skill，但要把它用好，就只需要做好兩方面工作，製作的 Skill 是有效的，管理skill 是有效的，我已經在社羣分享了很多跨電腦，跨工具，跨網絡管理 skill 的方法。
今天，這篇文章聊聊 Skill 的製作，如何製作有效的 Skill。
1 樣板法：拿最滿意的交付物當模板，讓 AI 提煉標準封裝成 Skill
2 流程法：把固定工作步驟的輸入輸出寫清楚，串成自動化 Skill
3 歸納法：回看聊天記錄，找出反覆讓 AI 做的事，補成 Skill
4 經驗法：把腦子裏"只可意會"的隱性知識寫成文檔綁進 Skill
這四個方法有一個共同點：都是從已有經驗出發的。你做過的事、踩過的坑、積累的模板，有了才能提煉。
但問題是，很多工作場景你平時做的少，想不到自然也就沒有 Skill。
比如我作為產品經理，有些事必須做但頻率不高：問卷調研、競品分析、埋點方案、項目覆盤等。等到要做的時候才發現沒有 Skill，臨時寫倉促又無從下手。
我經常在寫完需求文檔，評審通過了，才發現埋點、數據指標相關工作都遺漏了，這個時候還要去加，很浪費精力和時間。
所以最好的 Skill 梳理方式是按職業來，不遺漏一個使用場景。
職業是一個天然的需求收集器。每個職業都有自己固定的工作流、反覆出現的輸出物、幾個永遠踩不完的坑。用職業做框架去拆，不容易遺漏，也不容易重複，因為一個職業該做什麼事，本身就是一張相對確定的清單。
於是我做了一個叫"職業.skill"的東西。
一句話：告訴它你的職業，它幫你拆出這個職業該做哪些 Skill，每個 Skill 的提示詞直接複製發給 Agent 就能生成。
用法很直接。在 Claude Code或任意 coding Agent 裏說"我是xxx（說你的職業名稱），幫我拆 Skill"，它會輸出 8 個 Skill 的製作指南，包括每個 Skill 需要提供什麼材料、可以直接用的提示詞、Skill 內部的執行邏輯。
最後輸出的是一個Skill 的製作清單，你可以直接複製每個 Skill 的描述，如上面紅框框選內容，複製後，告訴你的 Agent 說，幫我製作這個 Skill，等待制作完成，自己測試下效果，如果能按要求提供一些示例內容，效果會更好。
有一個細節：不同公司對同一職業的定義差很多。說"運營"，它不會直接輸出，而是問一個問題："你主要負責哪個方向？內容運營 / 用戶運營 / 活動運營 / 增長運營？"選完才開始拆。這樣拆出來的清單準確度高很多。
GitHub 倉庫在這裏：https://github.com/zephyrwang6/career.skill
複製上面連結，直接發給你的 Claude codeh 或龍蝦說：幫我安裝這個 Skill，就能使用了。
我用這個職業.skill，給自己的工作又增加了 十幾個新的 Skill。
它把產品工作從頭捋了一遍：需求從哪裏來、怎麼寫清楚、怎麼過評審、數據怎麼看、實驗怎麼設計、結果出來怎麼覆盤，每一個環節都做了一個 Skill，一共 13 個。
說幾個用下來效果比較好的：
pm-review-board，模擬產品、研發、測試、設計、運營、法務六個角色同時評審一份 PRD，按阻斷項 / 重要項 / 建議項三級分類輸出意見。評審會上被噴通常不是因為需求真的差，而是某個角色的顧慮沒被提前考慮到。這個 Skill 讓問題在會之前就暴露。
地址：https://github.com/zephyrwang6/pm-skills/tree/main/pm-review-board
pm-analytics，從"數據跌了"這個起點走完整個分析鏈路：數據健康體檢 → 指標拆解 → 現象定位 → 假設推斷 → 行動建議。強制區分相關性和疑似因果，所有結論標註可信度。輸出是單文件 HTML 報告，發給老闆不用再整理格式。
地址：https://github.com/zephyrwang6/pm-skills/tree/main/pm-analytics
pm-image2proto，截圖傳進去，輸出一個可以跑起來的 HTML 原型。做了學習記憶機制，第一次確認了配色和組件風格之後，後續每次說"這個也一樣"就能複用，不用每次重新描述。
地址：https://github.com/zephyrwang6/pm-skills/tree/main/pm-url2proto
13 個 Skill 的完整列表在這裏：https://github.com/zephyrwang6/pm-skills
skill 用的越多越覺得 skill 會被大模型進化掉
我把上百個 skill 給分成了幾個類型，這幾個類型我發現它們都是對應到了職業的需求。
這種形式其實可以做在模型裏面，如果模型突然可以加載一個比方說設計、測試、產品經理這樣的一個角色，就能把這些 skill 能力都籠攬了，這樣子對於企業，對於個人來說，它的價值會更大，也更容易模塊化交付。
另一件事是，最近注意到 Claude Cowork的產品。推出一種插件的能力，安裝了某個插件，Claude 就會擁有那個職業的專家能力，產品經理插件裝上，它會替你做產品相關的工作。
這個方向跟我想做的事不謀而合。
這兩條路最終可能走到同一個地方。隨着模型能力越來越強，可能越來越多人不需要精細化地做每一個 Skill，直接安裝某個職業的能力包就夠了。細粒度的 Skill 會慢慢融合進更大的能力單元裏，變成一種人們感知不到的東西。
但現在還不是那個時候。
現在的模型需要明確的指令、清晰的工作流、具體的檢查清單，才能穩定地輸出有價值的東西。Skill 本質上是把這些東西寫清楚、固化下來的一種方式。
在模型還沒強到"什麼都懂、什麼都會"之前，這件事仍然值得做。
職業.skill 就是把更多職業的拆解做出來，讓不同職業的人都能輕鬆用上Skill。
關於 Skill 的製作，感興趣的可以訂閲我的 AI 生產力專欄，加入社羣，和更多小夥伴一起用 AI 提高生產力。