1. 從官方文檔里挖出的三個Skill改進思路先交代一下背景。最近Anthropic官方放出了一份關(guān)于Skill編寫的實踐建議主題是“讓你的Skill工作流變得更好用”。我仔細讀完之后最大的感受是官方文檔沒有教你怎么寫一個能跑的Skill——那太基礎(chǔ)了——它真正在講的是怎么把一個“勉強能用”的Skill打磨成一個“真正順手”的Skill。這里先給還不熟悉Skill的讀者補個底。所謂Skill在Anthropic的語境里就是一組結(jié)構(gòu)化的指令包通常包含技能描述、觸發(fā)條件、使用步驟、示例和輸出規(guī)范。你可以把它理解成給AI寫的一本“操作手冊”告訴它什么時候該用這個技能、具體怎么用、輸出長什么樣。跟普通Prompt相比Skill最大的區(qū)別在于它是可復用、可組合、可版本化的——你不需要每次都在對話里重復一大堆背景說明而是把它封裝成一個獨立單元隨取隨用。我自己在過去幾個月里用Claude的Agent SDK和Skill機制做了不少實際項目從小的文檔處理腳本到多步驟的調(diào)研工作流都試過。踩過不少坑也總結(jié)出了一些行之有效的技巧。這篇文章就結(jié)合官方的最佳實踐把三個我認為最關(guān)鍵的改進思路拆開來講每個都會配上具體的實操示例和踩坑記錄。先說一個總體的判斷很多人寫Skill容易犯兩個極端——要么寫得太粗一句話完事AI根本不知道邊界在哪要么寫得太細事無巨細全塞進去結(jié)果AI反而被冗長的指令拖慢甚至出現(xiàn)“選擇性失明”——關(guān)鍵規(guī)則淹沒在無關(guān)緊要的細節(jié)里。官方這次給出的三個技巧恰好就是針對這兩個極端問題的。2. 技巧一把“隱式知識”變成“顯式規(guī)則”2.1 為什么Skill經(jīng)?！翱雌饋矶藢嶋H沒懂”我第一個要講的核心技巧是官方文檔里反復強調(diào)的一點不要假設(shè)模型能自動理解你腦子里的隱含邏輯要把所有決策依據(jù)都寫出來。舉個例子。之前我寫過一個用于“會議紀要整理”的Skill。最初版本是這么寫的將會議錄音轉(zhuǎn)寫文本整理為會議紀要提取行動項和負責人?？雌饋頉]問題對吧但實際跑起來AI給我的結(jié)果總是差一口氣。比如它把“討論過程”也當成行動項提取進去了。它分不清“張總說下周給方案”和“張總建議李工下周給方案”的區(qū)別把建議者也當成了負責人。它把“盡快”“近期”這類模糊時間詞直接保留而沒有轉(zhuǎn)成具體日期。問題就出在我“以為AI懂”但實際上AI并不懂什么叫“行動項”、什么叫“負責人”、什么叫“可執(zhí)行的下一步”。這些在我腦子里是常識的知識對模型來說只是一堆模糊的自然語言。2.2 顯式化的具體做法用“決策樹”而不是“描述句”官方最佳實踐里提了一個非常關(guān)鍵的點與其告訴Skill“要做什么”不如告訴它“在什么情況下怎么做選擇”。受這個思路啟發(fā)我把上面的Skill改成了帶決策邏輯的版本。核心部分是這樣設(shè)計的對于轉(zhuǎn)寫文本中的每一段發(fā)言按以下順序判斷它是否需要提取為行動項 1. 該發(fā)言是否包含一個明確的待辦事項動詞目標時間 - 是繼續(xù)下一步判斷 - 否跳過不作為行動項 2. 該待辦事項的負責人是誰 - 若說話者直接承諾自己完成負責人為說話者本人 - 若說話者將任務(wù)指派給其他人負責人為被指派者 - 若說話者僅提出建議但未明確指派則標記為“待確認”不要臆測負責人 3. 該待辦事項的截止時間如何確定 - 文本中有明確日期直接采用 - 文本中有“明天”“下周”等相對時間詞以本次會議日期為基準換算成具體日期 - 無任何時間信息標記為“未設(shè)定”不要隨意猜測改完之后同樣的輸入AI輸出的行動項準確率高了很多。最明顯的變化是它不再把“討論性發(fā)言”誤判成“行動項”了也學會了遇到不確定信息時標注“待確認”而不是硬編一個答案。2.3 實操心得從“你的輸出不對”反向推導規(guī)則這里分享一個我自己反復使用的推導方法。當你發(fā)現(xiàn)Skill輸出不符合預期時不要只改Prompt讓它“注意一點”而要去問AI“你是怎么判斷的”——注意不是讓AI改輸出而是讓它描述自己的推理過程。這一步特別有價值因為它會暴露你規(guī)則中的漏洞。比如我那個會議紀要Skill當時AI解釋自己提取負責人時“根據(jù)發(fā)言上下文推斷張總可能是負責人”。這就是問題根源AI在用“可能”“推測”的方式做決策而真正可靠的Skill應該讓AI只依據(jù)文本中明確的指認關(guān)系來決策沒有明確指認就標記待確認。當我把這條明確寫進規(guī)則后輸出穩(wěn)定性一下就上來了。注意這里的關(guān)鍵不是告訴AI“不要猜測”而是給它一套“什么情況下可以判斷、什么情況下不能判斷”的明確標準。光喊口號式的“不要瞎猜”對模型約束力很弱因為模型并不知道“瞎猜”在你這里的具體定義是什么。3. 技巧二為Skill設(shè)計清晰的“觸發(fā)-執(zhí)行-終止”邊界3.1 不清邊界帶來的典型問題第二個技巧是我在實際使用中感受最深的一個。官方文檔里專門提到了Skill應該明確“何時該用”和“何時不該用”但很多人寫Skill時容易忽略這個問題或者說根本沒想到要規(guī)定“何時不該用”。一個真實案例。我寫過一個小工具類Skill用來將碎片化筆記整理成結(jié)構(gòu)化文檔。最初版本是這樣將用戶提供的筆記整理為結(jié)構(gòu)化文檔包含標題、摘要、正文、要點。聽起來很通用對吧結(jié)果在真實使用中就翻車了。用戶有時候提供的是閑聊內(nèi)容有時候是已經(jīng)整理好的文章有時候是一堆詩或者心情記錄這個Skill照樣一股腦全給塞進“摘要正文要點”的框架里。把一首詩整理成“要點1、要點2、要點3”這體驗能好嗎問題就出在這個Skill的觸發(fā)條件寫得太寬了——只要用戶說“幫我整理筆記”它就觸發(fā)但它又缺乏終止條件——沒規(guī)定“什么情況下這個Skill不應該使用”。3.2 三條邊界規(guī)則的具體寫法基于這個教訓我后來把Skill的邊界設(shè)計分為三層第一層強觸發(fā)條件。明確列出哪些情況下Skill必須啟用包括可以量化的特征比如輸入格式、關(guān)鍵詞、用戶的意圖標志。觸發(fā)條件滿足任一即可 - 用戶明確要求“整理”“結(jié)構(gòu)化”“做筆記”“重排格式” - 用戶輸入內(nèi)容超過300字且包含多個獨立主題 - 用戶輸入包含明顯的信息層級如列表、編號、章節(jié)標題第二層模糊區(qū)判斷。列出那些容易被誤判為觸發(fā)、但實際上不該觸發(fā)的情況告訴AI遇到這種情況應該怎么做。模糊區(qū)以下情況請與用戶確認后再執(zhí)行 - 用戶輸入以閑聊開頭且未明確表達整理意圖 - 用戶已經(jīng)提供了一份成品文檔僅希望發(fā)表評論或修改意見 - 用戶輸入是詩歌、小說、對話稿等非說明性文體 處理方式先回復一句簡短的確認語例如“我注意到這看起來像是X類型內(nèi)容你希望我按結(jié)構(gòu)化筆記處理還是保持原樣”第三層終止條件。這個很多人完全沒想過。一個Skill不能是萬能的必須有明確的終止條件——當AI發(fā)現(xiàn)輸入超出自己的能力范圍或授權(quán)范圍時應該主動停止。終止條件滿足任一即可停止處理 - 用戶輸入涉及醫(yī)療診斷、法律裁決、金融投資等專業(yè)決策且用戶要求輸出權(quán)威結(jié)論 - 用戶要求刪除或篡改已有文檔中的關(guān)鍵信息且無合理授權(quán) - 用戶要求將整理結(jié)果用于明顯不當?shù)挠猛救鐐卧煊涗涍@三個邊界劃分到位后這個Skill的“存在感”反而變低了——因為它在不該出現(xiàn)的時候會主動退出而不是硬著頭皮處理。用戶也說不清哪里變了但整體體驗就是“舒服了”。這就是好Skill的特質(zhì)平時低調(diào)需要時可靠。3.3 和Agent工作流的配合方式順帶說一個與邊界相關(guān)的進階用法。如果你把Skill嵌在Agent工作流里使用比如通過Claude Agent SDK那邊界規(guī)則還有一個額外價值——它可以幫Agent節(jié)省大量的無效調(diào)用。我在一個調(diào)研類Agent里掛了多個Skill分別處理資料收集、文檔生成、數(shù)據(jù)提取。過去因為Skill邊界不清Agent經(jīng)常在錯誤的時間調(diào)用錯誤的Skill比如用戶明明在閑聊Agent卻莫名其妙觸發(fā)了一次“資料收集”。加上邊界規(guī)則后Agent會先根據(jù)對話內(nèi)容判斷該不該調(diào)Skill、調(diào)哪個而不是一上來就盲目調(diào)用。這個優(yōu)化看起來不起眼但對Token消耗和響應速度的影響非常明顯尤其是在跑比較長的工作流時。4. 技巧三用“示例驅(qū)動”替代“規(guī)則堆砌”4.1 模型更擅長模仿而不是遵循抽象指令第三個技巧來自官方文檔里關(guān)于“Few-shot示例”的強調(diào)。Anthropic官方在多個場合都提過給模型看具體的輸入輸出示例比給它寫十條抽象規(guī)則更有效。這其實很符合語言模型的工作機制——它是靠預測下一個token來生成內(nèi)容的給它看一個“標準答案”的分布它會自然地模仿而給它看一堆規(guī)則它需要先將規(guī)則“翻譯”成輸出分布這個翻譯過程就容易丟信息。我自己早期寫Skill的時候習慣用大段大段的“要求”“必須”“禁止”。后來發(fā)現(xiàn)規(guī)則寫得越多模型反而越容易“跑偏”。一個很典型的現(xiàn)象你列了十條規(guī)則模型可能會完美遵守前三條然后從第四條開始逐漸“遺忘”但如果給三條示例模型幾乎能完整復現(xiàn)示例中的輸出風格和細節(jié)處理方式。4.2 如何設(shè)計高質(zhì)量示例示例的質(zhì)量直接決定Skill的表現(xiàn)。這里分享幾個我總結(jié)的設(shè)計要點示例要覆蓋“典型情況”而不是“極端情況”。很多人喜歡給Skill配一個特別復雜的示例來展示能力上限但實際使用中模型遇到最多的反而是常規(guī)情況。所以示例應該盡量貼近日常輸入讓模型掌握“常規(guī)輸出長什么樣”然后再額外給一個“略復雜”的示例展示如何處理邊界。示例要展示完整過程而不只是輸入輸出。最好的示例是帶“推理過程”的。在示例中用注釋的方式展示AI是如何一步步得出最終結(jié)果的。這比只給配對的輸入輸出更有效因為模型能看到你希望的決策路徑。下面是我在一個“信息提取Skill”里使用的示例片段結(jié)構(gòu)可以直觀感受到這種帶過程注釋的示例示例輸入 “小張上周五把項目報告發(fā)給了劉總劉總看完后覺得數(shù)據(jù)部分需要補充讓小王這周二之前重新統(tǒng)計并更新。” 示例處理過程 - 識別關(guān)鍵事件項目報告提交上周五、審閱反饋數(shù)據(jù)部分需補充、重新統(tǒng)計任務(wù)這周二前 - 任務(wù)負責人小王劉總指派非原說話者 - 截止時間這周二以文檔生成日期為基準換算若文檔中未記錄今天日期則標記為待確認 - 輸出行動項 1. 負責人小王”任務(wù)重新統(tǒng)計項目報告數(shù)據(jù)截止時間這周二請確認具體日期狀態(tài)進行中這個示例的價值在于它不僅告訴模型“要提取什么”還告訴模型“遇到模棱兩可的信息時應該怎么處理”。4.3 示例的“最小必要數(shù)量”經(jīng)驗關(guān)于示例數(shù)量一個常見的疑問是“到底放幾個示例合適”。我的經(jīng)驗是3-5個高質(zhì)量示例通常是最優(yōu)區(qū)間。少于3個模型對輸出風格的把握不夠穩(wěn)多于5個Skill體積變大同時Token消耗也隨之上升而帶來回報的邊際效益卻不明顯。如果Skill涉及多種類型輸入比如同時處理會議紀要、文章筆記、日程記錄建議按類型各給1-2個示例而不是只給一種類型的多個示例。這樣能幫助模型把不同輸入映射到不同的輸出模式比單一類型堆示例效果更好。下面是一個對比效果表來自我自己做過的一組小實驗示例數(shù)量輸出風格穩(wěn)定性輸出格式準確率處理“模糊輸入”的能力平均Token消耗0個示例差風格漂移低格式隨意差不知道怎么辦最低但返工多1個示例一般會模仿中較差中等3個示例穩(wěn)定高中上適中5個示例很穩(wěn)定高好略高10個示例穩(wěn)定但過度死板極高反而下降過于依賴模板消耗明顯增加每次打磨Skill遇到棘手情況我首先動手調(diào)整的就是示例部分而不是去加規(guī)則——這是一個屢試不爽的方向。5. 實操案例將三個技巧應用到“簡歷篩選Skill”到這里如果只是泛泛講技巧多少有點“紙上談兵”。下面用一個完整的實操案例把上面三個技巧串起來展示它們是如何在一個真實的Skill里協(xié)同生效的。這個案例我會結(jié)合一個使用頻率很高的場景簡歷篩選 Skill——畢竟招聘HR和團隊Leader經(jīng)常會用到它來大批量篩選投遞簡歷。5.1 場景需求與Skill目標假設(shè)我們收到了一大批簡歷希望用Skill快速完成初篩分類、標記優(yōu)勢點、給出建議。目標不是“替代HR判斷”而是將簡歷中的關(guān)鍵信息提煉出來降低HR逐份閱讀的時間成本。在動筆之前先明確幾個設(shè)計決策輸出要結(jié)構(gòu)化。一份簡歷篩選結(jié)果應該包含候選人基本信息、匹配度評分、核心優(yōu)勢、風險點、建議。這樣團隊可以批量對比而不需要每份都翻原始簡歷。評分標準要明確。匹配度評分不應該是一個模糊的“8分”而要能解釋為什么給8分。功能上需要給出評分依據(jù)清單。邊界要設(shè)定好。該Skill無法驗證簡歷真?zhèn)我矡o法代替面試判斷這些要在輸出中明確標識防止AI“越權(quán)”。5.2 構(gòu)建Skill的核心結(jié)構(gòu)基于上面的目標我設(shè)計了如下Skill結(jié)構(gòu)簡化版示意技能名稱簡歷篩選助手 觸發(fā)條件 - 用戶提供一份或多份簡歷文本 - 用戶要求進行簡歷評估、篩選、排序 處理流程 1. 提取基本信息姓名、年齡、學歷、工作經(jīng)驗年限、當前崗位、期望崗位 2. 提取技能棧技術(shù)棧、工具、行業(yè)領(lǐng)域經(jīng)驗、證書資質(zhì) 3. 匹配度評估根據(jù)用戶提供的崗位JD職位描述逐項對照候選人的經(jīng)歷、技能 4. 評分與建議輸出匹配度評分百分制、理由、建議關(guān)注點 輸出格式要求 - 每位候選人輸出一段JSON結(jié)構(gòu)化摘要包含字段basic_info, skills, score, strengths, risks, suggestions - 其中score必須附帶評估理由不能只說分數(shù) 終止條件 - 若簡歷中信息嚴重缺失無法評估則輸出“信息不足建議補充” - 若簡歷數(shù)量超過50份建議分批處理以避免輸出過長這個結(jié)構(gòu)本身不算復雜但它為AI劃定了清晰的流程邊界——先做什么、再做什么、最后輸出什么、什么情況下不繼續(xù)。5.3 在Skill中加入決策規(guī)則接下來是關(guān)鍵部分給匹配度評分寫一套明確的決策規(guī)則。這是用第一個技巧——“把隱式知識變成顯式規(guī)則”——的地方。很多人寫簡歷篩選Skill時只會說“請評估候選人與崗位的匹配度”但什么是匹配度匹配度是由哪些具體因素組成的這些因素各自占多重的權(quán)重不寫清楚AI給出的評分就會有比較大的隨機性。我設(shè)計的評分模型如下你可以根據(jù)自己團隊的需求調(diào)整權(quán)重匹配度評分 硬技能匹配40% 行業(yè)/項目經(jīng)驗匹配30% 軟技能信號15% 穩(wěn)定性信號10% 學習潛力信號5% 硬技能匹配40分 - 核心技能與JD中的技能完全重合的每項計10分最多計30分 - 有JD中沒列但明顯相關(guān)的技能每項計2分最多計5分 - 無重合技能但具備同類工具/框架經(jīng)驗計5分 行業(yè)/項目經(jīng)驗匹配30分 - 有同行業(yè)項目經(jīng)驗計15分 - 項目規(guī)模與JD中描述的團隊規(guī)模相近計5分 - 有端到端負責項目的經(jīng)驗而非只負責其中片段計10分 軟技能信號15分基于文本線索判斷 - 描述中體現(xiàn)主動推動、跨部門協(xié)調(diào)、結(jié)果導向等詞匯或案例每項計5分最多計入10分 - 體現(xiàn)抗壓能力或在復雜環(huán)境中完成目標的例子計5分 穩(wěn)定性信號10分 - 每段工作經(jīng)驗少于1年扣除3分/段最多扣6分 - 工作年限與崗位級別是否匹配如候選人3年經(jīng)驗應聘初級崗位不額外扣分但要備注 學習潛力信號5分 - 有自學項目、開源貢獻、新技能學習記錄計3分 - 有培訓證書或相關(guān)課程計2分這套模型并不完美但它給了AI一個明確的框架避免“憑感覺打分”。5.4 配置示例讓AI學會處理模糊信息最后用幾個示例來鞏固這個Skill的行為。我特意讓示例覆蓋三種不同情況理想匹配、部分匹配、信息不足。下面摘錄關(guān)鍵示例說明示例輸入 崗位JD產(chǎn)品經(jīng)理 3年以上經(jīng)驗負責B端產(chǎn)品規(guī)劃熟悉需求分析、項目管理、數(shù)據(jù)分析。 候選人A簡歷摘要 3年產(chǎn)品經(jīng)理經(jīng)驗在某SaaS公司負責B端產(chǎn)品從0到1設(shè)計獨立完成需求調(diào)研、PRD撰寫、數(shù)據(jù)分析推動開發(fā)團隊完成迭代。此前做過UI設(shè)計。 示例輸出 basic_info: 姓名候選人A工作年限3年當前崗位產(chǎn)品經(jīng)理 skills: 需求分析、PRD撰寫、數(shù)據(jù)分析、項目管理、UI設(shè)計輔助技能、SaaS業(yè)務(wù) score: 82分 得分理由 - 硬技能匹配滿足需求分析、項目管理、數(shù)據(jù)分析、B端產(chǎn)品規(guī)劃加權(quán)后共30分 - 行業(yè)經(jīng)驗匹配有SaaS B端產(chǎn)品經(jīng)驗符合行業(yè)方向計20分 - 軟技能信號有“從0到1設(shè)計”“推動開發(fā)團隊完成迭代”等主動結(jié)果導向案例計10分 - 穩(wěn)定性信號每段工作超過1年無扣分計10分 - 學習潛力信號未體現(xiàn)明確自學證據(jù)計2分 - 總分72分不對重新計算30201010272分82分不合理。 重新計算 - 硬技能30分 - 行業(yè)經(jīng)驗20分 - 軟技能10分 - 穩(wěn)定性10分 - 學習潛力2分 總分72分 建議可進入面試重點考察B端復雜業(yè)務(wù)的理解深度。這個示例之所以要寫得這么詳細甚至包含一次“重新計算”是為了告訴AI評分必須基于規(guī)則逐項加總中途即使覺得哪里不對也要重新核算而不是直接編一個最終印象分。這能顯著降低評分漂移問題。5.5 實操中遇到的坑與解決這個Skill在實際使用中我遇到了幾個值得分享的坑坑一JD缺失時AI自動 “腦補”。有時候用戶只丟過來一份簡歷說“幫我篩一下”但沒提供JD。最初版本AI會自行假設(shè)一個“常見產(chǎn)品經(jīng)理崗位”然后評分這其實是錯誤的。后來我在觸發(fā)條件里加了一條未提供JD時先詢問用戶或默認不輸出評分只輸出信息摘要。這個小小的修改避免了大量無意義的“假評分”?？佣敵龈袷接袝r候會變成Markdown而非JSON。盡管Skill里明確要求了JSON結(jié)構(gòu)化輸出但模型偶爾會“自作主張”換成更易讀的Markdown格式。這看起來沒毛病但對后續(xù)批量處理非常不友好。解決辦法是在示例中增加一個“錯誤格式與正確格式”的對照告訴AI“如果你用了Markdown輸出請立即改回JSON”。示例驅(qū)動在這個場景下比規(guī)則描述更有效?？尤粋€候選人對應多份不同版本簡歷。實際招聘中經(jīng)常遇到一種情況一位候選人在不同招聘網(wǎng)站上有多個版本的簡歷信息還互相矛盾。Skill如果只看其中一份就會被不完整信息帶偏。我在處理流程里加了一步若檢測到同姓名候選人提供多份簡歷先做字段去重和沖突標記再進入評分流程。這一步看似簡單但實際幫我們避免了很多低級錯誤。6. 更多實戰(zhàn)技巧與常見問題速查6.1 Skill調(diào)試中的常用技巧調(diào)試Skill是門手藝活。我用了很長時間才從“瞎調(diào)”進化到“有套路地調(diào)”。這里分享幾個我覺得最實用的調(diào)試方法逐模塊測試法。別每次都把完整Skill丟進去測試把流程拆開分別測試“提取信息”“評分”“輸出格式”這幾個環(huán)節(jié)看看哪個環(huán)節(jié)最容易出問題。我自己的經(jīng)驗是大多數(shù)Skill的瓶頸出在“規(guī)則與示例不一致”——比如規(guī)則說“輸出JSON”示例卻展示的是Markdown這時模型往往會優(yōu)先跟示例走。檢查一遍Skill內(nèi)部的一致性能解決很多莫名其妙的問題。用“極端輸入”做壓力測試。我發(fā)現(xiàn)很多Skill的bug只有在輸入邊界情況時才會暴露。比如簡歷篩選Skill可以故意輸入一份格式很差、內(nèi)容很少、甚至有亂碼的簡歷看看它能輸出什么。好的Skill應該在這種情況下給出“信息不足”的提示而不是強行編造一個分數(shù)。經(jīng)常做這種測試能讓你提前發(fā)現(xiàn)規(guī)則漏洞。記錄“錯誤樣本”并反推規(guī)則。和之前提到過的“讓AI描述推理過程”類似當你發(fā)現(xiàn)某個輸出離譜時不要只改一次就完事。最好把錯誤輸出保存下來分析它出錯的“觸發(fā)點”是什么然后針對那個點寫規(guī)則。我自己的經(jīng)驗是一個Skill前前后后要改五六版才能穩(wěn)定下來這非常正常。6.2 常見問題速查表下面整理一份通用的Skill調(diào)試問題速查表適配各類Skill場景。這本身也是我在日常工作中持續(xù)維護的一份私有文檔臨床癥狀可能的原因推薦的解決手段Skill輸出風格每次都不穩(wěn)定示例過少或示例覆蓋不全增加到3-5個示例覆蓋輸入類型變化Skill對邊界情況完全沒反應觸發(fā)條件和終止條件缺失明確“何時該用”“何時不該用”評分/判斷類輸出隨機性大決策規(guī)則不夠顯式設(shè)計帶權(quán)重的評分模型或決策樹格式經(jīng)常變來變?nèi)ヒ?guī)則與示例不一致或示例中沒有“正確/錯誤格式對照”強制示例中使用目標格式必要時給出反例模型“自作主張”猜測信息未規(guī)定“信息缺失時如何處理”增加“未知→標記為待確認”的規(guī)則Skill在長對話中逐漸“失靈”上下文過長導致早期指令稀釋在Skill開頭重復關(guān)鍵約束或拆分多個小型Skill組合調(diào)用輸出過于冗長廢話多示例中輸出本身就冗長缺少“簡潔范式”在示例中展示一個“理想簡潔輸出”并明確要求字數(shù)范圍6.3 一些進階但有用的冷門技巧除了上述三個核心技巧這里再補充幾個我在實踐中覺得非常有用的冷門細節(jié)給Skill寫一個“自我介紹”小節(jié)。也就是說Skill開頭應該有一小段話用自然語言概括這個Skill的核心價值和邊界。很多人覺得這是廢話但實際上它有兩個作用一是讓模型在長對話中對Skill的記憶更牢靠因為它會反復引用這個自我描述二是讓后續(xù)閱讀Skill的人快速理解設(shè)計意圖。示例中故意加入一個“反例”。官方文檔里很少提到這一點但它真的很管用。比如你要模型輸出JSON格式在示例里放一個“錯誤的Markdown輸出”告訴它“這不是期望格式不要這樣輸出”。反例能幫助模型更精準地鎖定邊界比只給正例效果好得多。在Skill中預留“反饋循環(huán)”。你可以在Skill末尾加一個小小的“自檢提示”讓模型在輸出之前先對照檢查一遍“檢查輸出是否符合以上所有格式與內(nèi)容要求若不符合請你重新生成?！?這個提示能明顯減少模型“跑飛”的次數(shù)代價只是多消耗一點點Token物超所值。7. 從Skill到工作流一套完整的落地思路最后一個部分我想把視角從單個Skill拉遠一點聊聊Skill和工作流的關(guān)系。因為在實際項目中很少有人會只用一個Skill通常是一個工作流里掛好幾個Skill每個Skill負責一個環(huán)節(jié)配合起來完成任務(wù)。7.1 什么時候適合用Skill什么時候適合用工作流這是一個特別容易被混淆的問題。我自己的判斷標準很簡單當一個任務(wù)可以相對獨立地復用并且每次觸發(fā)時輸入輸出形式都類似那適合做成Skill。當一個任務(wù)涉及多個階段的順序處理、需要中間狀態(tài)流轉(zhuǎn)、需要條件分支那更適合做成工作流Workflow。比如“收集資料 → 分析 → 生成報告 → 格式化輸出”這種多步處理明顯是工作流的范疇。換句話說Skill適合封裝“子能力”工作流適合編排“完整流程”。兩者并不互斥配合使用才能發(fā)揮最大價值。7.2 Skill組合與沖突處理在實際項目中幾個Skill同時存在時容易產(chǎn)生“沖突”。最常見的沖突是兩個Skill有不同的輸出格式要求而模型在同一個上下文中不知道該聽誰的。解決思路是在更高一層比如工作流或系統(tǒng)Prompt顯式聲明Skill的調(diào)用順序和優(yōu)先級。例如“先調(diào)用簡歷信息提取Skill得到結(jié)構(gòu)化數(shù)據(jù)后再調(diào)用簡歷評分Skill。兩者輸出格式不同以評分Skill的輸出為準?！边@個問題聽起來簡單但處理不好會帶來非常大的調(diào)試成本。我過去就把兩個互相對立的Skill放在同一個Agent里結(jié)果模型被搞得一會用這種格式、一會用那種格式浪費了很長時間才排查出問題。7.3 輕量化設(shè)計給團隊的實踐建議如果你是在團隊里引入Skill機制我的建議是先從輕量級開始建立一套“可讀性優(yōu)先”的Skill規(guī)范再逐步追求復雜度。很多團隊一開始就試圖搭建巨型Skill庫把所有業(yè)務(wù)邏輯都塞進去結(jié)果維護成本極高效果也差——因為模型在長指令下的表現(xiàn)會隨著指令長度增加而衰減。具體來說可以這樣做每個Skill盡量控制在一屏內(nèi)200~300行以內(nèi)只做一件明確的事。Skill之間通過命名規(guī)范避免歧義例如前綴統(tǒng)一用“skill_簡歷_評分”這種格式。版本控制必須跟代碼一樣納入Git每次修改記錄原因方便回滾。Skill的測試集要逐步沉淀下來形成一份回歸測試專用的輸入輸出樣例。把這些基礎(chǔ)工作做扎實了Skill庫的擴展才不會被歷史包袱拖垮。8. 最后的一點個人體會寫了這么多回頭看Anthropic官方這份最佳實踐其實它傳遞的核心思想非常樸素想讓模型穩(wěn)定可靠地完成任務(wù)你需要把不確定變成確定把隱式變成顯式把抽象規(guī)則變成具體示例。這三個技巧聽起來像廢話但真正做到的人在少數(shù)。我自己在多次迭代Skill的過程中最深的體會是打磨Skill是一個持續(xù)對抗“信息衰減”的過程——模型不短路規(guī)則不冗余則輸出自然就穩(wěn)定。每一次從“AI輸出離譜”到“AI輸出穩(wěn)定”的跨越背后都是靠更清晰的邊界、更嚴謹?shù)拇朕o、更貼近真實使用的示例堆出來的。如果你正在被某個Skill的穩(wěn)定性問題折磨我的建議是先別急著加更多規(guī)則回頭看看三個地方——觸發(fā)/終止邊界是否清晰、決策規(guī)則是否顯式、示例是否覆蓋了不同情況。把這三個基礎(chǔ)點打磨到位大部分問題都會迎刃而解。以上是我基于實戰(zhàn)踩坑得出的一些方法。如果你在自己的Skill調(diào)試中有更好的技巧或心得也很歡迎一起交流討論。技能工程這件事最好的學習方式就是在真實項目中一遍遍打磨、試錯、總結(jié)然后把好的經(jīng)驗沉淀成可復用的資產(chǎn)。