1. 當Skill變成員工的“職業(yè)技能證書”最近半年我一直在折騰一個方向把AI從“一個能聊天的模型”改造成“一個能干活的下屬”。標題里的“裝了30多個Skill給AI安排了8個崗位”就是這次折騰的階段性成果。所謂Skill你可以理解為給AI額外安裝的“職業(yè)技能包”。就像給員工發(fā)一本崗位說明書加一套工具清單你告訴AI“你現(xiàn)在的角色是代碼審查官你需要先把diff拉出來再按這5個維度逐條檢查發(fā)現(xiàn)問題要給出修改建議而不是只丟一句‘看起來不錯’”。裝完Skill之后AI在對應場景里的輸出質量跟我裸用默認模型完全是兩個水平。為什么非要這樣干原因很簡單默認的AI是“通才”什么都懂一點但不會主動按你的規(guī)范去執(zhí)行。你讓它審查代碼它可能只掃一眼語法你讓它寫專利交底書它可能給你編出一堆不符合格式要求的“技術方案”。而Skill做的事情就是把“行業(yè)規(guī)范團隊SOP個人偏好”固化成模型能直接調用的指令資產。裝30多個Skill本質上是在給AI構建一套“崗位能力矩陣”。這篇文章就圍繞這套實踐來寫重點拆解三件事一是8個崗位到底怎么劃分、每個崗位掛載了哪些Skill二是Skill安裝、配置、管理的完整實操過程三是調試過程中踩過的坑怎么排查。適合正在玩Claude Code、Codex、Cursor等AI編程工具想把AI從“玩具”變成“生產力工具”的同學參考。2. 從“會聊天”到“有崗位編制”思路轉變是關鍵2.1 一門手藝一個SkillAI能力的顆粒度游戲剛開始玩Skill的時候我犯過一個挺典型的錯誤想搞一個“萬能Skill”把所有需求都塞進去。結果就是這個Skill的指令文件超過500行模型加載之后反而變得遲鈍遇到具體任務不知道該調哪條規(guī)則。后來我換了個思路按“手藝”拆分不按“崗位”合并。做飯的歸做飯擺盤的歸擺盤切菜的歸切菜。每個Skill只負責一件非常具體的事描述寫得精準觸發(fā)條件寫得清晰剩下的交給模型自己去組合調用。舉個例子同樣是在“代碼審查”這個崗位上我裝了三個Skill各管一段diff-review只分析git diff檢查改動本身有沒有引入bug、風格是否統(tǒng)一。security-scan專注安全漏洞比如SQL注入、越權、敏感信息硬編碼。architecture-check站在全局視角看這次改動是否破壞了原有架構邊界。這三個Skill分開裝工作時可以按需調用也可以組合起來一起跑。效果就是AI審查同一段代碼能從三個完全不同的角度輸出意見覆蓋面比單人審查還全。2.2 30多個Skill怎么管理沒有目錄結構一定會翻車裝了30多個Skill之后第一個現(xiàn)實問題就是找不到、分不清、改不動。我的解決方案是建立明確的目錄分類絕對不能把所有Skill平鋪在一個文件夾里。目前我的Skill倉庫長這樣skills/ ├── 01-code/ # 編程開發(fā)類 ├── 02-docs/ # 文檔撰寫類 ├── 03-review/ # 審查評審類 ├── 04-data/ # 數(shù)據(jù)分析類 ├── 05-patent/ # 專利與知識產權 ├── 06-test/ # 測試與質量保障 ├── 07-devops/ # 運維與部署 └── 08-creative/ # 創(chuàng)意與內容生成分類的邏輯跟公司組織架構對齊——“8個崗位”就是8個一級分類。每個分類下面掛3到5個Skill對應崗位的具體技能。這樣無論是手動管理還是寫腳本批量檢查都非常方便。2.3 Skill和Agent的區(qū)別一個像“技能”一個像“人”這個話題在網上討論得很多我說說我自己的理解。Skill是“能力包”它定義了AI能做什么、按什么流程做Agent是“執(zhí)行體”它決定AI什么時候調用什么能力、任務進行中如何決策。打個比方Agent是員工Skill是員工手里的工具箱。員工決定“這個任務需要扳手還是螺絲刀”然后從工具箱里取用。如果只有Agent沒有Skill員工就只能赤手空拳上陣如果只有Skill沒有Agent工具擺了一地但沒人知道該用哪個。在實際落地中我通常用Agent來定義一個崗位角色比如“后端開發(fā)專家”然后在Agent的配置里掛載對應的一組Skill比如python-dev、api-design、performance-tune。這樣分工清晰職責明確也方便做權限控制。3. 8個崗位的崗位說明書Skill組合實戰(zhàn)拆解3.1 崗位一代碼審查官Code Reviewer這套崗位是ROI最高的。以前我?guī)F隊做Code Review最耗時的就是逐行過diff現(xiàn)在這部分基本交給了AI預審。掛載SkillSkill名稱職責說明觸發(fā)場景diff-review分析git diff檢測邏輯錯誤、遺漏邊界條件提交PR/MR時security-scan檢測常見安全漏洞給出修復建議涉及用戶輸入、權限、加密的改動style-enforcer檢查代碼風格是否匹配團隊規(guī)則合并前最終檢查這套組合跑下來AI會先輸出一份帶風險等級標注的審查清單標注每個問題的文件位置、行號、問題類型、修改建議。最明顯的改善就是團隊里那種“低級錯誤合并進主干”的情況基本絕跡了因為AI審查的重點恰恰是“語法沒問題但邏輯有坑”的隱性錯誤。3.2 崗位二技術方案架構師Solution Architect這個崗位解決的是“拿到需求不知道從哪下手”的問題。掛載的Skill偏向分析和方案設計requirement-analyzer把模糊的需求描述拆解成功能點、邊界條件、非功能需求。tech-selector根據(jù)技術棧、團隊規(guī)模、維護成本給出選型建議。api-designer設計RESTful API的路徑、參數(shù)、響應結構直接輸出OpenAPI規(guī)范。我常用的工作流是這樣接一個需求之后先讓requirement-analyzer跑一遍產出一頁紙的需求分析再讓tech-selector給出技術選型的對比表最后讓api-designer生成接口草案。這三步跑完需求評審會的底稿基本就有了開發(fā)團隊拿到就能開工。3.3 崗位三自動化測試工程師QA Engineer這個崗位幫我補了不少測試覆蓋率上的空白。掛載的Skill有test-case-generator根據(jù)代碼函數(shù)自動生成邊界值測試用例。selenium-writer生成端到端測試腳本輸出可直接運行的Python代碼。coverage-analyzer分析測試覆蓋報告定位未被覆蓋的關鍵路徑。實際操作中test-case-generator跑一遍能覆蓋我自己寫用例時經常會漏掉的空指針、越界、參數(shù)為空等場景。測試用例生成完之后我只需要做兩件事去重、調節(jié)期望結果。省的時間非?？捎^。3.4 崗位四專利與知識產權專員IP Specialist這個崗位比較小眾但價值極高。我在科技企業(yè)做過專利挖掘最大的痛點就是發(fā)明人描述技術方案時要么太抽象要么太細節(jié)永遠不符合專利代理人的撰寫格式。我自定義了一個patent-draftSkill內置了一套專利交底書的標準框架技術領域、背景技術、發(fā)明內容、技術方案、有益效果、具體實施方式。同時用Few-shot把兩個歷史專利作為參考案例寫進Skill里。這樣AI在生成交底書時格式和描述口徑高度統(tǒng)一代理人拿過去能直接改不用推翻重寫。另配一個patent-searchSkill輔助做前案檢索分析列出潛在對比文件的關鍵特征幫發(fā)明人初步判斷新穎性。3.5 崗位五文檔工程師Technical Writer程序員討厭寫文檔但文檔又是剛需。這個崗位的Skill組合如下readme-generator掃描項目代碼生成結構清晰的README。api-doc-formatter根據(jù)代碼注釋或OpenAPI文件生成接口文檔。changelog-writer對比git commit記錄自動生成版本更新日志。changelog-writer是最省心的一個每次發(fā)版前跑一條命令AI把commit message歸類整理成“新增/修復/優(yōu)化/破壞性變更”的結構化日志。以前這個活要花半個多小時手敲現(xiàn)在20秒搞定。3.6 崗位六數(shù)據(jù)分析師Data Analyst分析類的Skill重點在于“把臟數(shù)據(jù)整理成清晰結論”。我掛了這幾個>--- name: sql-writer description: 根據(jù)自然語言需求生成SQL查詢要求附帶解釋和邊界條件提示。 version: 1.2.0 author: your-name tags: [sql, database, analysis] --- # SQL Writer ## 功能 將用戶的自然語言問題轉換為可執(zhí)行的SQL查詢并輸出執(zhí)行計劃說明。 ## 使用時機 - 用戶希望通過數(shù)據(jù)分析回答業(yè)務問題時 - 用戶需要快速獲取某個數(shù)據(jù)指標時 ## 執(zhí)行步驟 1. 明確用戶的業(yè)務問題和數(shù)據(jù)口徑時間范圍、指標定義、維度拆分。 2. 查看數(shù)據(jù)庫Schema確認涉及的表和字段。 3. 生成SQL注意 - 使用JOIN時明確關聯(lián)鍵 - 涉及聚合時按業(yè)務口徑正確使用GROUP BY - 時間字段先明確時區(qū) 4. 輸出格式 - SQL代碼塊 - 執(zhí)行邏輯說明 - 潛在坑位提示如NULL值處理 ## 禁止事項 - 禁止在未確認Schema的情況下直接生成SQL - 禁止將生產庫表直接暴露在輸出中重點說一下YAML front-matter里的description字段這個字段非常關鍵——模型靠它來判斷“當前這個Skill該不該觸發(fā)”。如果description寫得太泛比如“處理各種問題”那模型在幾乎所有任務里都會嘗試加載這個Skill既費token又容易干擾主任務如果寫得太窄則容易漏觸發(fā)。我吃過的虧是description寫得太長模型無法快速抓取要點后來統(tǒng)一格式改成“做什么什么時候用”匹配率提升非常明顯。4.3 在Claude Code中安裝并運行Skill真實命令全流程以用戶級目錄的安裝為例完整流程如下# 1. 創(chuàng)建用戶級Skill目錄 mkdir -p ~/.claude/skills # 2. 將Skill文件復制到目錄中 cp -r /path/to/downloaded/sql-writer ~/.claude/skills/ # 3. 檢查目錄結構是否正確 tree ~/.claude/skills/sql-writer # 確認存在 SKILL.md 文件 # 4. 在當前項目中測試Skill是否被加載 cd /your/project claude # 然后在對話中輸入 # /skill list如果在對話中執(zhí)行/skill list能看到sql-writer說明加載成功。接下來可以直接提一個需求測試效果比如“統(tǒng)計上周每天的新增用戶數(shù)按渠道拆分”看輸出的SQL是否符合預期。4.4 在Codex中配置Skill同樣是用目錄掃描機制Codex這邊的配置邏輯類似但目錄名是skills位置略有差異# Codex全局Skill目錄 mkdir -p ~/.codex/skills # 復制Skill cp -r sql-writer ~/.codex/skills/ # 在項目里啟用 cd /your/project codex # 在對話中可以直接描述任務模型會根據(jù)description自動加載對應Skill提示如果你同時在用Claude Code和Codex建議維護一份Skill源倉庫然后通過符號鏈接symlink或者拷貝腳本同步到兩個工具的目錄里避免兩邊手動維護造成版本不一致。5. 開發(fā)自定義Skill把“知其所以然”變成AI的肌肉記憶5.1 提煉SOP而不是堆砌規(guī)則寫自定義Skill最核心的不是會YAML語法而是能把日常工作流程“結構化”。我開發(fā)patent-draft這個Skill的過程值得展開講講。第一步我找了一份已經授權的高質量專利交底書逐段拆解它的結構標注出每個段落的意圖和常見寫法。第二步把公司研發(fā)團隊描述技術方案的常見混亂點列出來比如“把背景技術寫成產品宣傳”“把發(fā)明點堆在具體實施方式里”。第三步把這兩部分整理成“結構模板正誤對比補充提示”寫入SKILL.md。這樣AI拿到一份研發(fā)人員自述能自動按專利交底書框架重新組織語言把“這個技術通過一個模塊實現(xiàn)”改寫成“一種xxx方法其特征在于包括步驟一……步驟二……”。寫出來的初稿基本達到了能交給代理人改稿的級別。5.2 用Few-shot讓Skill“一次就懂”Skill里的reference目錄就是用來放Few-shot樣例的。我給大多數(shù)Skill都配了1到3個參考案例每個案例包括“輸入-輸出”對照。以changelog-writer為例我在reference里放了三種commit風格的輸入以及對應的changelog條目寫法。這樣模型生成的日志風格穩(wěn)定不會出現(xiàn)“修復了一個問題”這種模糊表達而是“修復訂單模塊在并發(fā)場景下重復創(chuàng)建記錄的競態(tài)條件”。5.3 版本控制與變更記錄Skill也是代碼嚴重建議給每個Skill加version字段并且用git管理整個Skill倉庫。我踩過的一個坑有一次給security-scan更新了檢測規(guī)則結果發(fā)現(xiàn)某些正常代碼被誤報為“潛在注入風險”捉了半天才發(fā)現(xiàn)是規(guī)則寫得太激進。后來回滾版本就恢復正常。有了git歷史每次改完Skill都能做對比測試確認沒引入回歸再發(fā)布。6. 常見問題速查表與排查心法6.1 典型問題一覽沒生效、亂觸發(fā)、上下文爆掉問題現(xiàn)象可能原因解決方法Skill裝了但沒反應目錄路徑不對或SKILL.md缺失用/skill list檢查加載狀態(tài)確認文件在正確目錄模型不按Skill流程執(zhí)行description寫得太泛或太窄重寫description明確觸發(fā)場景和預期輸出多個Skill同時被觸發(fā)description重疊嚴重重新界定各Skill的邊界用否定句式排除生成內容質量不如預期缺少Few-shot參考樣例在reference目錄添加1到3個高質量示例上下文窗口不夠用每個Skill都被加載token開銷大精簡SKILL.md把詳細內容移到reference按需讀取生產環(huán)境執(zhí)行了錯誤操作Skill缺少安全護欄在配置文件里加“禁止事項”列表并增加二次確認流程6.2 排查Skill不生效的三個步驟步驟一確認Skill真的被加載。用命令/skill list或者查看對話啟動日志看有沒有“Loaded skill: xxx”的記錄。如果沒加載九成是目錄放錯或者文件名不對。步驟二確認模型讀取到了SKILL.md。把Skill里的description原樣復制到對話里問“你覺得這個描述適合觸發(fā)嗎”看模型是否理解正確。如果模型答非所問大概率是front-matter格式有誤重點檢查YAML縮進和冒號。步驟三確認執(zhí)行路徑有沒有被用戶指令覆蓋。有時候用戶直接給了一個非常具體的指令優(yōu)先級高于Skill的默認流程。這種情況下Skill里的規(guī)則會被“繞過”。解決辦法是在Skill里寫明“即使收到其他指令也務必保留以下環(huán)節(jié)”。6.3 上下文爆炸問題Skill是耗token大戶Skill加載本身就要消耗至少幾百個token如果每個任務都把所有Skill加載一遍上下文很快就會被撐爆。我的經驗是按崗位啟用同一個會話只加載一個崗位的Skill集合不要跨崗位混用。比如“今天只做代碼審查”就只帶代碼審查相關的Skill。善用reference目錄SKILL.md只保留指令概要長文檔放reference里模型按需讀取。定期清理每次會話結束時看一眼加載了哪些Skill如果某個Skill從來沒有真正被用到就檢查它的description是不是形同虛設。7. 一套可以“直接抄作業(yè)”的Skill管理清單折騰了幾個月之后我把這套流程沉淀成了一份清單分享出來供大家參考。7.1 安裝新Skill前的檢查清單這個Skill解決的是不是一個“重復出現(xiàn)3次以上”的問題它的邊界是否與已有Skill重疊description是否按“做什么何時用”格式寫清楚reference目錄是否放了至少1個高質量樣例是否加上了version和author元信息放在項目級還是用戶級目錄7.2 引入團隊協(xié)作時的注意事項如果要把這套玩法推廣給團隊有幾個坑一定要提前避人員培訓成本不是所有人都習慣“用指令跟AI協(xié)作”先挑兩三個對AI工具熟悉的同事做試點。Skill的版權與保密如果Skill里內置了公司內部的最佳實踐切記不要直接推到公開倉庫自建私有倉庫管理。質量回退機制每個Skill發(fā)布之前用一套固定的測試用例做回歸防止“升級反而變笨”。7.3 Skill后續(xù)還能怎么擴展目前我在嘗試的方向是把團隊歷史代碼評審記錄清洗成數(shù)據(jù)集微調一個針對性的審查偏好注入到Skill里。另外也在研究如何讓Skill自動調用外部API比如通過scripts/目錄里的Python腳本拉取監(jiān)控數(shù)據(jù)再基于數(shù)據(jù)生成分析報告——這一步能做通的話“AI員工”就能從“靠腦子干活”升級成“手腳并用”干活了。