前陣子我把一個叫小龍蝦的內(nèi)部AI助手調(diào)教了一通結(jié)果它從什么都聊得來但什么都落不了地的通用聊天對象變成了一個能拆指標(biāo)、查數(shù)據(jù)、出結(jié)論的分析師。整個過程沒有改模型、沒有換底座只是給它加了幾個 Skill——也就是技能包。這件事讓我對AI能不能干活這件事有了新的判斷很多時候瓶頸不在模型聰明不聰明而在你有沒有把專業(yè)方法教給它。這篇文章想把我加 Skill 的整套思路、文件寫法、踩坑記錄都攤開來講。適合正在做 AI 助手、智能體或者想讓自己手頭 AI 工具更專業(yè)的朋友參考尤其是那些覺得AI 回答得很對但沒用的人。1. 先把事情說清楚Skill 到底是什么先厘清概念。Skill 在這里不是指某個算法也不是某個固定模型而是一份預(yù)設(shè)的專業(yè)操作流程 工具調(diào)用方式相當(dāng)于你給 AI 配了一本崗位手冊。沒加 Skill 之前AI 面對幫我看下這個月銷售為什么跌了這種問題它只能憑訓(xùn)練時的常識回答講一些可能是市場原因、競品原因、價格原因這類永遠(yuǎn)正確的廢話。加了 Skill 之后它會先走一套分析師的操作路徑先確認(rèn)口徑、拉數(shù)、看趨勢、找異常、再下結(jié)論。我理解 Skill 的一層本質(zhì)是把人會但 AI 不會的工作經(jīng)驗(yàn)外置出來。比如一個分析師看到數(shù)據(jù)表第一反應(yīng)一定是檢查有沒有空值、字段是不是文本格式、要不要去重。這些東西不會寫在任何教科書里但會寫在這個人的腦子里。Skill 就是把這類腦子里的流程固化成文字再讓 AI 按規(guī)定流程執(zhí)行。這跟你帶新人一模一樣你不可能天天陪著新人重復(fù)講一遍流程但你可以給它一份流程手冊讓它按手冊辦事。還有一個容易被忽略的點(diǎn)Skill 不是提示詞。提示詞是你每次提問都要重復(fù)的一段話費(fèi) token 且不穩(wěn)定。Skill 是掛在 AI 身上的一個模塊它會在需要的時候被自動喚起相當(dāng)于一個常駐的專業(yè)技能。比如你給 AI 配了SQL 查詢這個 Skill它遇到查一下上季度復(fù)購率這類問題就會自動帶上寫 SQL、查數(shù)據(jù)庫的動作鏈而不是從記憶里猜一個復(fù)購率給你。這種機(jī)制的好處在于你的分析經(jīng)驗(yàn)、行業(yè)知識、判斷準(zhǔn)則全部沉淀在了一個個 Skill 包里。換一個新模型也能直接把 Skill 導(dǎo)過去繼續(xù)用并不依賴某一個特定模型。我實(shí)際測下來同一個 Skill 在不同版本模型上都能跑區(qū)別只是執(zhí)行質(zhì)量有高有低起碼流程不會丟。2. 我給小龍蝦配了五個 Skill它們各管一攤我一開始也沒想好要配幾個先列了日常分析工作里最高頻的五個環(huán)節(jié)拿臟數(shù)據(jù)、拆業(yè)務(wù)問題、查數(shù)、看圖、寫報(bào)告。后來又砍掉兩個合并了一個最后留下五個各管一攤互不重疊。這五個 Skill 才真正讓小龍蝦有了分析師骨架。2.1 數(shù)據(jù)清洗 Skill先保證數(shù)據(jù)能看數(shù)據(jù)清洗 Skill 是我第一個做的因?yàn)樗蟹治龅钠瘘c(diǎn)都是數(shù)據(jù)。小龍蝦之前會對用戶給的表格數(shù)據(jù)照單全收哪怕里面一堆空值、重復(fù)行、亂碼它照樣做分析最后結(jié)論自然是錯的。加了這個 Skill 之后它的第一步動作變成了先體檢再手術(shù)。具體來說這個 Skill 的指令里明確寫了五步識別字段類型、檢查缺失值比例、處理重復(fù)記錄、排查明顯異常值、輸出數(shù)據(jù)質(zhì)量說明。每一步都有閾值和動作比如關(guān)鍵字段缺失超過 30% 時不要直接刪除或填充先向用戶說明并建議補(bǔ)充數(shù)據(jù)。這就規(guī)避了 AI 在要不要填空值上自作主張的問題。我還在這個 Skill 里加了一條重要規(guī)定清洗前后必須有對比。一旦對數(shù)據(jù)做過任何修改比如刪行、類型轉(zhuǎn)換、歸一化必須在回答里說明原始數(shù)據(jù)多少行、清洗后多少行、改了什么、為什么改。否則分析做完別人根本不知道你的結(jié)論是基于什么數(shù)據(jù)得出來的。2.2 指標(biāo)拆解 Skill看到問題先離手先拆結(jié)構(gòu)第二個 Skill 解決的是答非所問的問題。以前小龍蝦拿到轉(zhuǎn)化率低了這種問題會直接開始提建議比如優(yōu)化著陸頁、加強(qiáng)AB測試。建議本身沒錯但完全跳過了為什么低的歸因環(huán)節(jié)等于沒分析就開藥方。指標(biāo)拆解 Skill 的邏輯是給小龍蝦裝了一套路演式拆解框架。指令里規(guī)定遇到業(yè)務(wù)指標(biāo)波動類問題第一不準(zhǔn)下結(jié)論第二不準(zhǔn)提方案先拆出指標(biāo)體系包含一級指標(biāo)、二級指標(biāo)、三級指標(biāo)。一級指標(biāo)是這個問題的核心二級是它的構(gòu)成因子三級是最細(xì)的可落地粒度。拆完之后才允許逐步排查。拿銷售額下跌來舉例拆解路徑大概是銷售額等于流量乘以轉(zhuǎn)化率再乘以客單價。流量里又分新客老客、渠道來源轉(zhuǎn)化率分首購轉(zhuǎn)化和復(fù)購轉(zhuǎn)化客單價分品類結(jié)構(gòu)、優(yōu)惠力度。拆到這一步AI就不再說廢話了它會按這個路徑去查每一個環(huán)節(jié)的數(shù)據(jù)最后定位是哪一層出了事。這一招我強(qiáng)烈建議所有做業(yè)務(wù)分析的人都給 AI 配上效果立竿見影。2.3 SQL 查詢 Skill把可能變成確定第三個 Skill 是 SQL 查詢。這是讓小龍蝦從一個嘴上分析師變成手里有數(shù)分析師的關(guān)鍵一步。以前它最大的問題不是不會寫 SQL而是從來不主動查數(shù)全靠模型記憶里的常識回答用戶?？墒菢I(yè)務(wù)數(shù)據(jù)每分每秒都在變記憶里的數(shù)據(jù)怎么可能反映真實(shí)情況我給這個 Skill 設(shè)定的職責(zé)有兩條第一凡是涉及具體數(shù)字、比例、趨勢的問題必須先查詢數(shù)據(jù)源禁止用預(yù)估數(shù)據(jù)回答第二查詢過程中必須輸出完整的 SQL讓用戶能看到查詢邏輯而不是丟一個結(jié)果就完事。這兩條直接堵死了 AI一本正經(jīng)胡說八道的路。這個 Skill 的 instructions 里還內(nèi)置了一些常見查詢模板按日周月聚合、同環(huán)比計(jì)算、漏斗各環(huán)節(jié)人數(shù)、留存率的計(jì)算邏輯。這些模板都是我從日常分析里整理出來的高頻片段有這些模板兜底小龍蝦寫出來的 SQL 很少跑錯查詢路徑也清晰可追蹤。它不需要成為數(shù)據(jù)庫專家但至少得是個合格的取數(shù)工具人。2.4 圖表解讀 Skill從看圖說話到看懂圖背后的含義第四個 Skill 是圖表解讀。起因是有人拿著后臺截圖讓小龍蝦分析結(jié)果它僅僅把圖上的數(shù)字復(fù)述了一遍——一月 100 萬二月 80 萬三月 90 萬——這叫念圖不叫分析。我加這個 Skill是讓它學(xué)會識別圖表類型、結(jié)構(gòu)、坐標(biāo)軸含義然后按格式去讀。這個 Skill 教會了小龍蝦幾個關(guān)鍵姿勢先看橫縱軸和單位確認(rèn)口徑再看整體趨勢判斷是持續(xù)上升、波動還是周期性然后看異常點(diǎn)比如突然的尖峰、斷崖最后才是歸因分析結(jié)合業(yè)務(wù)背景給出可能解釋。它還要注意一個常見陷阱圖表相關(guān)性不等于因果性看到兩條線一起漲不能直接說因?yàn)?A 所以 B。我還在指令里加了一條強(qiáng)制要求在解讀任何圖表前必須明確聲明數(shù)據(jù)范圍和截止日期。這一條看起來很簡單但能擋住大量拿舊圖說新事的錯誤。分析里面最怕的就是時間口徑混亂圖表 Skill 把這一點(diǎn)寫死之后小龍蝦每次都會先問這個數(shù)據(jù)是截至什么時候的。2.5 分析報(bào)告 Skill把零散結(jié)論拼成能交付的東西最后一個加的是分析報(bào)告 Skill。前面四個 Skill 讓小龍蝦有了單點(diǎn)能力但用戶要的從來不是一個結(jié)論而是一份完整交付物。分析報(bào)告 Skill 負(fù)責(zé)把這些能力串在一起按統(tǒng)一格式輸出。我參考自己寫報(bào)告的習(xí)慣把報(bào)告結(jié)構(gòu)固化成了六段背景與目的、數(shù)據(jù)說明、核心結(jié)論、分析過程、風(fēng)險提示、行動建議。前兩段交代背景和口徑中間三段講清楚發(fā)現(xiàn)了什么、為什么、意味著什么最后一段給出能落地的動作并明確每一條建議需要誰去跟進(jìn)、大概做什么拒絕模糊的加強(qiáng)運(yùn)營這種話。關(guān)鍵的一點(diǎn)是這份 Skill 里我寫死了兩個原則全文結(jié)論必須有數(shù)據(jù)支撐不能出現(xiàn)大概可能也許所有建議必須與前面的分析有因果關(guān)系。這兩條原則讓小龍蝦產(chǎn)出的報(bào)告風(fēng)格從AI 味十足變得像一個分析師的手筆。3. 手把手講清楚一個 Skill 文件到底怎么寫很多人以為 Skill 很難其實(shí)文件結(jié)構(gòu)非常簡單它就是一個 Markdown 文件加可選工具腳本。真正難的是文件里指令的寫法。以我實(shí)際經(jīng)驗(yàn)來看一個 Skill 文件最核心的部分就兩塊一塊是開頭的 description決定 AI 什么時候主動調(diào)用它另一塊是正文的 instructions決定 AI 調(diào)起來之后干得專不專業(yè)。這兩塊寫明白了Skill 就成了一大半。3.1 description決定觸發(fā)時機(jī)千萬別寫成小作文很多人會把 description 寫得特別詳細(xì)試圖在觸發(fā)階段就把所有情況都描述一遍。實(shí)測下來這是誤區(qū)。description 一旦變長AI 對它的語義識別反而會飄該觸發(fā)的時候不觸發(fā)不該觸發(fā)的時候亂觸發(fā)。我總結(jié)出一條經(jīng)驗(yàn)description 只用三句話說明什么場景、什么任務(wù)、什么輸入。舉例我寫的數(shù)據(jù)清洗Skill 的 description 是這樣的當(dāng)用戶提供原始數(shù)據(jù)文件、表格數(shù)據(jù)、導(dǎo)出的業(yè)務(wù)報(bào)表或包含大量字段的數(shù)據(jù)樣本需要校驗(yàn)數(shù)據(jù)質(zhì)量、處理缺失值或重復(fù)數(shù)據(jù)時使用本技能完成數(shù)據(jù)清洗與質(zhì)量說明。這一句話里明確寫了四件事觸發(fā)條件是用戶提供了原始數(shù)據(jù)任務(wù)是校驗(yàn)數(shù)據(jù)質(zhì)量動作是處理缺失值和重復(fù)數(shù)據(jù)產(chǎn)出是輸出質(zhì)量說明。不解釋原理不寫流程不寫邊界一句話六個要素AI 就能在遇到類似場景時把它拉起來。這里有個細(xì)節(jié)值得強(qiáng)調(diào)description 里一定要包含用戶可能使用的口語化詞而不僅僅是專業(yè)術(shù)語。用戶不會說請做數(shù)據(jù)質(zhì)量校驗(yàn)他們會說這個表有點(diǎn)臟幫我弄一下數(shù)據(jù)有問題你看看。我在很多 Skill 的 description 里都會補(bǔ)上這類口語觸發(fā)詞實(shí)測可以顯著提高調(diào)用率。3.2 instructions把操作步驟寫細(xì)把判斷規(guī)則寫死如果說 description 負(fù)責(zé)讓 AI 進(jìn)門instructions 就是進(jìn)門之后按什么規(guī)矩干活。這一部分不需要你寫太多高深的東西但一定要具體、可執(zhí)行、有順序。我在 instructions 上踩過一次很深的坑一開始寫得太像人話比如請仔細(xì)檢查數(shù)據(jù)質(zhì)量發(fā)現(xiàn)問題及時處理。這種話 AI 讀了跟沒讀一樣該含糊還是含糊。后來我改成先按字段識別數(shù)據(jù)類型再逐字段統(tǒng)計(jì)缺失率缺失率超過 30% 的字段標(biāo)記為高風(fēng)險并提示用戶它才開始真正按這個順序執(zhí)行。寫 instructions 的另一個要點(diǎn)是把判斷規(guī)則寫死留決策空間給是否繼續(xù)而不是怎么操作。舉一個例子在指標(biāo)拆解Skill 里我不能讓它自由決定怎么拆而是直接寫出拆解模板先拆構(gòu)成公式再拆漏斗路徑再拆影響因素。但遇到數(shù)據(jù)不足時是否繼續(xù)強(qiáng)拆這種問題Skill 里明確寫了一句話數(shù)據(jù)不足以支撐某級指標(biāo)時禁止憑經(jīng)驗(yàn)補(bǔ)數(shù)應(yīng)列出缺失清單并詢問用戶。這樣既保住了確定性又留下了人類介入的口子。3.3 一個可以直接套用的 Skill 文件模板寫一個通用模板你可以直接復(fù)制改內(nèi)容。它基于我實(shí)際在用的最簡結(jié)構(gòu)適合純指令型 Skill。--- name: 技能包名稱 description: 當(dāng)用戶出現(xiàn)什么行為、遇到什么任務(wù)、提供什么輸入時使用該技能。觸發(fā)詞包括xxx、xxx。 --- # 職責(zé)邊界 本技能負(fù)責(zé)什么不負(fù)責(zé)什么。邊界寫清楚是為了避免和其他技能沖突。 # 執(zhí)行步驟 1. 第一步接收輸入并確認(rèn)完整性缺什么先列出清單再動手。 2. 第二步執(zhí)行核心處理包括動作 A、動作 B、動作 C。 3. 第三步對結(jié)果進(jìn)行自檢檢查項(xiàng)目包括 X、Y、Z。 4. 第四步按指定格式輸出包含字段一、字段二、字段三。 # 判斷規(guī)則 - 遇到情況 A 時執(zhí)行操作 B。 - 遇到情況 C 時停止操作并向用戶說明原因。 - 遇到底層數(shù)據(jù)與預(yù)期不一致時以實(shí)際數(shù)據(jù)為準(zhǔn)并說明差異。 # 輸出格式 固定結(jié)構(gòu)結(jié)果摘要、關(guān)鍵過程說明、完整數(shù)據(jù)列表、下一步建議。這個模板你可能覺得簡單但它已經(jīng)能覆蓋八成分析類 Skill 的場景。我在實(shí)際使用中每個 Skill 文件也就是二三十行寫多了既難維護(hù)又容易讓模型在執(zhí)行時顧此失彼。4. 加了 Skill 之后小龍蝦到底變了什么東西做出來得看療效。我特意留了一份加 Skill 前的對話記錄跟加完之后的表現(xiàn)做了對比差距非常明顯。先說最直觀的感受加 Skill 前它像一個熱心的外行加 Skill 后像一個冷靜的同行。外行和同行的區(qū)別不在答案對不對而在流程穩(wěn)不穩(wěn)。以前它可能十次里有三次答得不錯但剩下七次在胡說。加了 Skill 之后它可能不會給你驚艷的答案但每次流程都對輸出穩(wěn)定在六十分以上這在實(shí)際使用里遠(yuǎn)比偶發(fā)的九十分重要。4.1 從直接給答案到先拆問題加 Skill 前小龍蝦拿到為什么最近的用戶留存下降了的問題會直接羅列一堆可能原因。加 Skill 之后它的回答變成了先確認(rèn)口徑、再拆結(jié)構(gòu)、再逐步排查最后才給結(jié)論。我舉個例子同樣是問留存下降加 Skill 前它是這樣答的留存下降可能是產(chǎn)品更新影響用戶體驗(yàn)也可能是競品分流建議加強(qiáng)用戶關(guān)懷。這句式是不是很熟悉每個詞單獨(dú)拎出來都沒錯連起來就是一句正確的廢話。加 Skill 之后它第一句話是需要先確認(rèn)兩個問題你說的留存是次日留存、7 日留存還是 30 日留存統(tǒng)計(jì)口徑是按設(shè)備去重還是按賬號去重然后才開始下一步。這就是分析師和聊天機(jī)器人的分水嶺分析師先鎖口徑再談結(jié)論。4.2 從空泛建議到結(jié)構(gòu)化交付第二個顯著變化是輸出形式。以前小龍蝦的回答是作文式的一大段讀起來順暢但整理信息很累?，F(xiàn)在它會按結(jié)論—證據(jù)—建議三個層次組織輸出開頭先亮結(jié)論然后列支撐數(shù)據(jù)最后才給建議。這里我強(qiáng)烈安利一個寫法在分析報(bào)告 Skill 里規(guī)定結(jié)論必須寫在開頭證據(jù)必須緊跟在結(jié)論后面。這樣做有兩個好處一是讀者前五秒就能拿到核心信息二是AI為了不寫出孤立結(jié)論會被倒逼著去找數(shù)據(jù)支撐。很多 AI 輸出空洞根源是它沒有這個結(jié)構(gòu)約束。Skill 能把結(jié)構(gòu)約束固定下來。4.3 從憑記憶回答到先查數(shù)再說話這個變化最重要。給小龍蝦配了 SQL 查詢 Skill 之后它不再憑記憶里的數(shù)據(jù)回答了。每拿到一個與數(shù)字相關(guān)的問題它會先寫 SQL 查數(shù)據(jù)查詢結(jié)果出來之后再基于真實(shí)數(shù)據(jù)進(jìn)行判斷。有件事我記得很清楚有一次問它上個月某渠道的轉(zhuǎn)化率是多少它的操作路徑是先檢查數(shù)據(jù)庫里有沒有該渠道的字段定義再寫 SQL 按渠道分組算轉(zhuǎn)化率最后把 SQL 和執(zhí)行結(jié)果一起貼出來。你能清楚看到它是怎么得出結(jié)論的而不是扔給你一個數(shù)字。這種可追溯性會讓你愿意信它的分析這也是我理解的專業(yè)感的真正來源。4.4 一個完整的加 Skill 前后對比表我把幾個維度的變化整理成了一張表可以作為你評估要不要加 Skill的一個參考標(biāo)準(zhǔn)對比維度加 Skill 前加 Skill 后面對開放問題直接羅列可能原因先確認(rèn)口徑和定義面對數(shù)據(jù)表直接描述、不看質(zhì)量先清洗、先看缺失與異常面對具體數(shù)字憑記憶或猜測寫 SQL 查詢給出執(zhí)行過程輸出形式一大段文字結(jié)論置頂、證據(jù)分列、建議在后面對圖表復(fù)述數(shù)字讀趨勢、找異常、給歸因錯誤率不穩(wěn)定隨時跑偏流程穩(wěn)定很少犯低級錯誤交付感聊天記錄像一份簡版報(bào)告這張表不是夸張而是我調(diào)整前后來回切換的真實(shí)體感。甚至現(xiàn)在我給別的內(nèi)部 AI 配技能時也會拿這張表當(dāng)驗(yàn)收標(biāo)準(zhǔn)加了 Skill 之后必須能看到這些維度里的至少三個發(fā)生變化否則說明 Skill 沒寫到位。5. 實(shí)操中踩過的坑希望你不用再踩一遍任何事情只有自己上手做才會碰到文檔里不寫的坑。Skill 配置看起來是寫一個 Markdown 文件那么簡單實(shí)際用起來問題不少。我把真正影響效果的幾個坑列出來應(yīng)該能幫你省掉不少試錯時間。5.1 description 寫太長觸發(fā)反而變差第一次配 Skill 時我給數(shù)據(jù)清洗寫了一段三百字的 description里面詳細(xì)解釋了什么情況該調(diào)用、哪些情況不該調(diào)用、具體執(zhí)行時要注意什么細(xì)節(jié)。結(jié)果很打臉用戶問幫我看下這個表的時候它沒有觸發(fā)用戶說今天的天氣適合爬山嗎它反而觸發(fā)了。原因就是 description 里的邊界描述太多AI 在識別語義時被干擾了。后來我把 description 砍到六十字以內(nèi)只留觸發(fā)條件和核心任務(wù)。效果立竿見影觸發(fā)率一下子正常了。所以我的建議是description 里只寫遇到什么說什么執(zhí)行細(xì)節(jié)全部放 instructions 里。觸發(fā)和執(zhí)法的職責(zé)要分開混在一起兩邊都做不好。5.2 多個 Skill 之間的指令互相打架我第二個踩的坑是不同 Skill 里的規(guī)則互相沖突。比如指標(biāo)拆解Skill 要求遇到問題先拆結(jié)構(gòu)、不要著急給方案但分析報(bào)告Skill 又要求在報(bào)告開頭直接寫核心結(jié)論。這兩個要求同時觸發(fā)時就發(fā)生了沖突小龍蝦一會兒先給結(jié)論一會兒說先要拆解再下結(jié)論輸出混亂。解決的辦法是在每個 Skill 里加一個職責(zé)邊界小節(jié)明確寫清楚什么情況下本技能讓位給其他技能。比如我在分析報(bào)告Skill 里加了一行如果當(dāng)前任務(wù)處于初步分析階段尚未完成數(shù)據(jù)確認(rèn)與指標(biāo)拆解本技能的核心結(jié)論輸出操作暫緩優(yōu)先執(zhí)行指標(biāo)拆解流程。有了這條優(yōu)先級規(guī)則沖突就消失了。這個細(xì)節(jié)推薦每個人都學(xué)一下比單純刪掉某些規(guī)則要更有用。5.3 不是所有問題都需要掛 Skill這是一個使用策略問題。我一開始把指標(biāo)拆解數(shù)據(jù)清洗SQL 查詢?nèi)吭O(shè)為常駐結(jié)果對用戶一個簡單的閑聊式提問AI 也先來一套拆解流程用戶覺得它變啰嗦了。后來我調(diào)整了策略把 Skill 改為按需觸發(fā)而非全部常駐通過 description 的設(shè)置讓它只在真正相關(guān)的場景里啟動。這里有個經(jīng)驗(yàn)判斷對話型場景保持輕量任務(wù)型場景才掛重流程。要是用戶只是隨口問一句幫我解釋一下什么是留存率你讓 SQL Skill 和指標(biāo)拆解 Skill 全跑一遍反而是負(fù)擔(dān)。Skill 不是越多越好而是在對的問題里出現(xiàn)在不對的問題里隱身。這個權(quán)重需要你根據(jù)自己的實(shí)際使用場景去調(diào)。5.4 參數(shù)和細(xì)節(jié)寫太死場景一變就失效Skill 的內(nèi)容是固定文字但業(yè)務(wù)問題千變?nèi)f化。我在早期版本里把指標(biāo)拆解模板寫死為流量等于新客加老客結(jié)果遇到一個純 B 端銷售場景這個拆解就完全不適用了。后來改為先給出通用的拆解原則構(gòu)成公式、漏斗路徑、同環(huán)比分類再強(qiáng)調(diào)用戶當(dāng)前問題的業(yè)務(wù)類型根據(jù)業(yè)務(wù)類型選擇匹配模板。這個經(jīng)驗(yàn)教訓(xùn)是Skill 里要寫方法而不是結(jié)論。方法能遷移結(jié)論不能。比如先確認(rèn)口徑再分析在所有行業(yè)通用但零售行業(yè)要先看 SKU 結(jié)構(gòu)就只對特定行業(yè)有效。在 Skill 里適當(dāng)保留通用性配合少量行業(yè)示例是最穩(wěn)的寫法。5.5 一個常見的排查思路當(dāng)發(fā)現(xiàn)加了 Skill 后 AI 表現(xiàn)變化不大別急著換模型先按這個順序排查description 觸發(fā)條件是否明確instructions 是否足夠具體是否存在與其他 Skill 沖突的規(guī)則你在測試時是否正在使用一個與 Skill 完全不相關(guān)的場景。大多數(shù)問題都出在這四個環(huán)節(jié)而不是出在模型能力上。我把容易遇到的問題整理成了一個速查表方便你在實(shí)際操作時對照排查現(xiàn)象可能原因處理辦法Skill 從不觸發(fā)description 太長或關(guān)鍵詞不匹配縮短 description加入用戶口語化觸發(fā)詞Skill 亂觸發(fā)description 邊界不清明確寫不適合什么場景縮小觸發(fā)面執(zhí)行流程混亂instructions 不夠具體AI 自由發(fā)揮逐步列出動作每步只給一個任務(wù)兩個 Skill 同時響應(yīng)職責(zé)邊界重疊在各自文件里寫清優(yōu)先級和讓位規(guī)則輸出仍然是正確的廢話缺少輸出格式約束強(qiáng)制規(guī)定輸出結(jié)構(gòu)結(jié)論必須前置換了場景就失效Skill 寫得太針對具體業(yè)務(wù)多用通用方法少寫特定結(jié)論這篇東西寫到這里我已經(jīng)把自己從零配到能用的整條路線攤開了。如果讓我重新做一次我會把第一步放在梳理分析師的工作流上而不是急著寫文件。流程想清楚了Skill 只是把流程翻譯成 AI 能讀的文字而已。最后一句送給正在折騰 AI 助手的朋友別總想著換更聰明的模型先把你想讓它做的事認(rèn)認(rèn)真真寫成一個它能看懂的標(biāo)準(zhǔn)動作效果通常比換模型來得更快。