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