最近很多做 AI 應(yīng)用和 Agent 開發(fā)的朋友跑來問我同一個問題Skill 到底是個什么東西怎么越看越像 Prompt為什么官方文檔里把它吹得天花亂墜我用起來卻總是不痛不癢有這個困惑的不在少數(shù)。過去大半年Codex、Claude Code、Trae 這些終端型 Agent 陸續(xù)把 Skill 推到了臺前GitHub 上各種 skill 倉庫如雨后春筍連“skill 推薦”“skill creator”這類熱詞都跟著起來了。但風(fēng)口越熱大家就越容易走偏。我見過有人把幾十個 Skill 一股腦塞進(jìn) Agent結(jié)果模型在選 Skill 的時候比干活還慢也有人把一條簡單的 Prompt 套上 Skill 的殼就發(fā)出來宣稱“工程化落地”更常見的是Skill 寫了一大堆測試一跑就翻車翻完車也不知道是該改提示詞、改腳本還是改目錄結(jié)構(gòu)。這篇文章我不打算做名詞科普而是想從工程實(shí)踐的角度把一個 Skill 從設(shè)計(jì)、編寫、測試到迭代的完整鏈路拆開講透順便潑幾盆冷水哪些場景根本不需要 Skill哪些做法是在給 Agent 系統(tǒng)埋雷?？赐曛竽阒辽倌芑卮鹑齻€問題——Skill 的本質(zhì)是什么一個及格的 Skill 是怎么落地實(shí)現(xiàn)的以及怎么判斷自己是不是正在濫用它。1. Skill 概念的來龍去脈以及它到底在解決什么問題1.1 從“會聊天”到“會干活”Agent 缺的是可復(fù)用的能力單元要理解 Skill得先看大模型產(chǎn)品形態(tài)的演進(jìn)。最早我們接觸的是對話機(jī)器人模型的任務(wù)是“回答”而不是“完成”。后來有人把多輪對話、工具調(diào)用、記憶管理拼在一起做出了 Agent 的雛形——模型開始能調(diào) API、讀文件、寫代碼。到了這個階段問題就變了模型雖然什么都會一點(diǎn)但它在面對某個特定領(lǐng)域任務(wù)時沒有任何“職業(yè)習(xí)慣”。什么概念你讓一個剛畢業(yè)的高材生去寫周報(bào)他能寫出來但寫出來的東西要么格式不對要么啰嗦得像個流水賬。你讓他去分析日志他會用 grep 把報(bào)錯抓出來但他不會先按時間窗口切分?jǐn)?shù)據(jù)再逐層聚合錯誤碼最后給你一份帶著趨勢判斷的報(bào)告——因?yàn)檫@些是你在公司里帶了他三個月之后他才學(xué)會的“崗位技能”。Skill 就是給大模型做“崗前培訓(xùn)”的那個載體。它不是模型參數(shù)里的能力也不是一次性的對話指令而是一套結(jié)構(gòu)化的、可復(fù)用、可版本化、可被多個場景裝載的“能力單元”?？梢哉fAgent 負(fù)責(zé)“臨場發(fā)揮”Skill 負(fù)責(zé)“有章法”。我在實(shí)際項(xiàng)目里的體感是沒有 Skill 的 Agent 像一個什么都懂但沒有任何工作經(jīng)驗(yàn)的實(shí)習(xí)生有了 Skill 的 Agent 才像一個帶過一段時間的正式員工。這句話聽起來很簡單但它決定了 Skill 在設(shè)計(jì)上必須同時包含“說明”和“執(zhí)行”兩個維度——光告訴模型要怎么做不夠還得給它提供可執(zhí)行的具體工具腳本和參考樣例。1.2 Skill、Prompt、Plugin、Agent 的邊界在哪里這四者的關(guān)系幾乎是每次分享必被問的問題。我先說結(jié)論Skill 是一種介于 Prompt 和完整 Agent 之間的工程形態(tài)它不是單純用來“提示”模型的文本也不是一個獨(dú)立自主的智能體它是可以被 Agent 隨時調(diào)用的一組流程化能力。如果畫一條軸最左邊是 Prompt——一段文本只在你輸入的那一次會話里生效沒有固定的存儲結(jié)構(gòu)沒有可復(fù)用的執(zhí)行邏輯。最右邊是 Agent——一個具備目標(biāo)拆解、多步規(guī)劃、工具調(diào)度、自我糾偏能力的完整系統(tǒng)。Skill 落在中間偏右的位置它有固定的格式有一定的執(zhí)行腳本但自身不做復(fù)雜規(guī)劃它的“決策權(quán)”受限本質(zhì)上是供一個更大的智能體使用的模塊。那 Plugin 呢Plugin 在多數(shù)框架里指的是系統(tǒng)層的擴(kuò)展點(diǎn)比如給某個應(yīng)用插一個鑒權(quán)中間件或者給 IDE 插一個語言服務(wù)器。它關(guān)注的是“軟件系統(tǒng)的集成”Skill 關(guān)注的是“模型能力的復(fù)用”。一個 Skill 內(nèi)部可能會調(diào)用一個或多個工具腳本這些腳本可以長得像 Plugin但 Skill 的邊界更偏向“提示詞 腳本 元數(shù)據(jù)”的組合。我用一句話給團(tuán)隊(duì)講清這件事Prompt 是你說的一句話Skill 是你沉淀下來的一份 S.O.P.Plugin 是你工具箱里的一把螺絲刀Agent 是那個拿著螺絲刀按 S.O.P. 干活的人。1.3 為什么 Skill 在最近半年突然成了香餑餑熱詞不會憑空出現(xiàn)。Skill 之所以爆發(fā)是因?yàn)閹讉€條件恰好湊齊了。第一模型底座的能力到了臨界點(diǎn)。代碼型 Agent 已經(jīng)能穩(wěn)定完成多步文件操作和命令行調(diào)用模型需要在“調(diào)用之前”知道該遵循什么流程——Skill 完美補(bǔ)上了這個接口位。第二終端型 Agent 產(chǎn)品Codex、Claude Code、Trae 這類開始流行它們天然允許用戶在自己的工作目錄里塞一個.claude/skills或類似的結(jié)構(gòu)化目錄這讓 Skill 的“可分發(fā)”屬性大大增強(qiáng)。第三社區(qū)生態(tài)起來了越來越多的開發(fā)者開始公開自己的 SKILL.md大家發(fā)現(xiàn)同一個 Skill 可以跨項(xiàng)目復(fù)用于是“skill 推薦”“skill creator”這類新熱詞就跟著長了出來。但繁榮背后有個隱患門檻太低了。寫一個 Skill 的真實(shí)門檻并不高誰都能把一段話包裝成 Skill但一段話包裝出來的東西根本撐不起“工程化”三個字。所以接下來我重點(diǎn)拆解真正合格的 Skill 到底該由哪些部分構(gòu)成。2. Skill 的本質(zhì)拆解一份“可執(zhí)行的說明書”背后有什么2.1 Skill 的真實(shí)形態(tài)是“結(jié)構(gòu)化知識 可執(zhí)行邏輯”的復(fù)合體很多人把 SKILL.md 看成“更長的 System Prompt”這是目前最大的誤解。Prompt 的目標(biāo)是影響模型的輸出風(fēng)格和內(nèi)容而 Skill 的目標(biāo)是讓模型在特定任務(wù)上“按流程辦事、按標(biāo)準(zhǔn)產(chǎn)出”。我拆過很多個公開的 Skill發(fā)現(xiàn)凡是好用的內(nèi)部都藏著一個共性結(jié)構(gòu)先告訴模型“這個技能什么時候該用、邊界在哪里”再給它“完整可執(zhí)行的操作步驟”最后給它“參考工具腳本和驗(yàn)收標(biāo)準(zhǔn)”。這有點(diǎn)像傳統(tǒng)軟件開發(fā)里的“接口文檔 單元測試”——前者定義行為契約后者驗(yàn)證行為正確。舉個例子一個“日志分析 Skill”如果只寫“你需要分析日志并找出錯誤”那它連 Prompt 都不如。合格的版本應(yīng)該寫清楚日志文件可能多大、什么格式、常見的錯誤碼含義、按什么維度聚合、最終輸出什么結(jié)構(gòu)同時附一個統(tǒng)計(jì)腳本自動把高頻錯誤和異常趨勢算出來。這樣才能保證無論誰來調(diào)用產(chǎn)出的質(zhì)量和格式是穩(wěn)定一致的。2.2 Skill 的核心組成聲明、說明、參考實(shí)現(xiàn)、測試我把一個工程化的 Skill 拆成四個模塊來看。第一是元信息聲明。包括 Skill 的名字、描述、觸發(fā)條件、依賴環(huán)境。這部分不是給人看的是給 Agent 的“路由系統(tǒng)”看的。描述寫得好不好直接決定了模型在遇到任務(wù)時會不會選到這個 Skill。很多 Skill 不好用的首要原因就是描述太差模型根本判斷不出什么時候該調(diào)用它。第二是行為說明。這是 SKILL.md 的主體告訴模型“按什么順序、用什么方式、輸出成什么樣子”。行為說明要足夠細(xì)——步驟要編號邊界要寫死異常分支要講清楚。第三是參考實(shí)現(xiàn)。也就是配套的腳本或模板代碼。它們的作用是把“確定的部分”從模型的推理壓力里解放出來。比如解析 JSON、計(jì)算聚合指標(biāo)這類操作交給腳本做又快又穩(wěn)不需要模型自己發(fā)揮。第四是測試用例。一套能驗(yàn)證 Skill 是否正常工作的輸入輸出樣例。沒有測試Skill 就是個盲盒沒人知道它在下一次調(diào)用中會不會打出離譜的結(jié)果。2.3 一個好 Skill 應(yīng)該滿足的三個標(biāo)準(zhǔn)我衡量一個 Skill 是否合格只看三個標(biāo)準(zhǔn)。第一可觸發(fā)。模型讀到對應(yīng)任務(wù)時能夠穩(wěn)定地把這個 Skill 選出來。換句話說它的描述和業(yè)務(wù)場景之間要有足夠明確的映射不能是那種模棱兩可的泛泛而談。第二可執(zhí)行。按照 SKILL.md 里的流程配合參考腳本確實(shí)能跑通產(chǎn)出符合預(yù)期。第三可驗(yàn)收。你有一套明確的檢查辦法能判斷 Skill 的輸出到底對不對而不是“看起來差不多”。不可驗(yàn)收的 Skill 寫得再漂亮也無法迭代。這三個標(biāo)準(zhǔn)聽著簡單但當(dāng)我拿它去檢視自己手頭的 Skill 時會發(fā)現(xiàn)一大批項(xiàng)目連第一條都過不了——因?yàn)槊枋鰧懙貌磺宀怀嗀gent 在關(guān)鍵時刻根本不調(diào)用它。3. 工程實(shí)現(xiàn)手把手教你寫一個能用的 Skill3.1 目錄結(jié)構(gòu)與命名規(guī)范先搭好一個不會亂的架子我建議每個 Skill 在項(xiàng)目里單獨(dú)占一個目錄目錄名就是 Skill 的名字內(nèi)部再按“說明、腳本、資源、測試”拆分子目錄。以一個通用的格式為例skill-name/ ├── SKILL.md ├── scripts/ │ ├── run.py │ └── utils.py ├── assets/ │ ├── templates/ │ └── examples/ └── tests/ ├── case1.md └── case2.md目錄命名必須短、具體、一眼能看懂用途。比如log-analyzer就比analysis-tool好得多——前者明確了對象和動作后者是個誰都能往里塞東西的筐。scripts目錄放 Skill 運(yùn)行時需要調(diào)用的腳本。assets放模板文件、參考輸出樣例。tests放測試輸入和預(yù)期的輸出結(jié)果。這個結(jié)構(gòu)不是硬性標(biāo)準(zhǔn)不同框架的約定略有差異但“說明、腳本、測試三者分離”的思路是通用的。3.2 SKILL.md 該怎么寫才不會被模型當(dāng)作空氣這是全場最關(guān)鍵的一步。SKILL.md 寫不好后續(xù)的工作白搭。我根據(jù)自己的踩坑經(jīng)驗(yàn)把它拆成幾個區(qū)塊來寫。第一塊是身份與能力邊界。開頭就要直接告訴模型這個 Skill 叫什么、在什么范圍內(nèi)有效。比如“本 Skill 用于服務(wù)端日志文件的錯誤模式分析不處理前端埋點(diǎn)數(shù)據(jù)”。能力邊界寫得越清楚模型越不會亂用。第二塊是觸發(fā)條件。要明確列出什么情況應(yīng)該使用、什么情況堅(jiān)決不要用。觸發(fā)條件不能太窄太窄了模型想用的時候找不到它也不能太寬太寬了模型會在無關(guān)場景下硬套。我的經(jīng)驗(yàn)是至少列出三個肯定觸發(fā)的場景作為正例再列兩個禁止觸發(fā)的場景作為負(fù)例。第三塊是執(zhí)行步驟。用有序列表逐步描述工作流。每一步都要具體到“做什么、怎么做、產(chǎn)出什么”。不要只寫“分析日志”要寫“先用腳本提取時間窗口內(nèi)的錯誤碼分布再按錯誤碼聚合相關(guān)上下文最后輸出 JSON 格式的匯總報(bào)告”。第四塊是輸出規(guī)范。直接用模板定義一個輸出格式可以是 JSON、Markdown 表格或自定義文本格式。最好是給一個完整的輸出樣例讓模型照著填。這一步能顯著提升結(jié)果的可控性。第五塊是失敗兜底。告訴模型在遇到什么情況時應(yīng)該放棄、向上報(bào)告或者嘗試降級處理。沒有兜底的 Skill 一旦出錯Agent 就可能陷入死循環(huán)。用我自己的一個精簡版為例# Log Analyzer 本 Skill 用于分析服務(wù)端日志文件定位錯誤模式并輸出量化摘要。 不對前端埋點(diǎn)、業(yè)務(wù)訂單數(shù)據(jù)做分析。 ## 適用場景 - 用戶反饋接口報(bào)錯率上升需要快速定位錯誤碼分布。 - 上線后需要檢驗(yàn)日志中是否出現(xiàn)新的異常類型。 - 定時巡檢多個服務(wù)的錯誤日志。 ## 不適用場景 - 實(shí)時流式日志的監(jiān)控請交給告警系統(tǒng)。 - 需要逐條閱讀的深度業(yè)務(wù)日志。 ## 執(zhí)行步驟 1. 確認(rèn)日志路徑與格式必要時先預(yù)覽前 50 行。 2. 調(diào)用 scripts/run.py 統(tǒng)計(jì)錯誤碼分布和時間趨勢。 3. 對 TOP5 錯誤碼提取各自的典型上下文。 4. 按輸出規(guī)范生成摘要。 ## 輸出規(guī)范 { time_window: ..., total_errors: 0, top_errors: [], trend: increasing/decreasing/stable } ## 失敗兜底 - 日志文件不存在或?yàn)榭罩苯臃祷靥崾拘畔ⅰ?- 腳本運(yùn)行出錯附上原始報(bào)錯并停止流程。這里最容易被忽略的是“失敗兜底”這一段。沒有它模型在腳本報(bào)錯時往往會憑想象力編一個結(jié)果——這錯得很隱蔽很致命。3.3 參考腳本的設(shè)計(jì)原則不要什么都指望模型推理Skill 里要不要帶代碼是很多人的糾結(jié)點(diǎn)。我的原則很簡單凡是確定性邏輯全部下沉到腳本凡是開放判斷才留給模型。打個比方統(tǒng)計(jì)錯誤碼出現(xiàn)次數(shù)這種邏輯是確定的人類看一眼代碼就能驗(yàn)證讓模型去數(shù)反而可能數(shù)錯就應(yīng)該寫成腳本。而“整體報(bào)錯趨勢是上升還是下降”這種需要結(jié)合業(yè)務(wù)上下文判斷的結(jié)論則適合讓模型綜合輸出。腳本的價值是把模型從“計(jì)算器”這個不稱職的角色里解放出來讓它專注做“分析師”。設(shè)計(jì)腳本時還要注意容錯。日志格式千奇百怪腳本至少要做到文件不存在時給出明確報(bào)錯、解析失敗的行跳過而不是中斷、輸入超大文件時有合理的采樣策略。這些細(xì)節(jié)看著瑣碎但真到了 Agent 自動運(yùn)行的時候每個沒有兜底的分支都可能變成一個白癡行為。另外腳本的運(yùn)行方式要寫清楚最好在 SKILL.md 里給出標(biāo)準(zhǔn)命令。不要讓模型猜是python3 run.py還是bash run.sh。能顯式規(guī)定的就不要留給模型自由發(fā)揮。3.4 測試與調(diào)優(yōu)怎么確認(rèn) Skill 真的在生效很多 Skill 發(fā)布了就沒人管這是工程化的大忌。我建議每個 Skill 至少要配三組測試一組典型正常場景一組邊界場景一組不該觸發(fā)場景。典型正常場景就是技能最核心的任務(wù)驗(yàn)證“走正常流程能不能跑通”。邊界場景測試的是“輸入有變化時Skill 是否能優(yōu)雅處理”。不該觸發(fā)場景測試的是“模型在無關(guān)任務(wù)上會不會誤用這個 Skill”。三組測試都過了Skill 才敢說基本可用。做完測試還要做“可觀測性驗(yàn)證”。一個常見困惑是怎么知道模型到底有沒有按我的 SKILL.md 走我的做法是讓 Skill 在流程中留下“執(zhí)行痕跡”——比如規(guī)定模型在輸出摘要的末尾附加一個元信息塊或者固定調(diào)用一個能寫日志的腳本。這樣當(dāng)你審查結(jié)果時能一眼看出它到底走了沒有。調(diào)優(yōu)時優(yōu)先檢查觸發(fā)條件和執(zhí)行步驟不建議一上來就改提示詞的口吻。大部分 Skill 失靈問題都出在“模型壓根沒選到它”或者“選到之后不知道下一步具體該做什么”上。4. 你大概率正在濫用 Skill 的 5 個信號4.1 信號一把 Skill 當(dāng)成了 Prompt 收藏夾這是我見到的最高頻錯誤。很多人寫的 Skill 其實(shí)是“換個格式的精美 Prompt”“你是一位資深的產(chǎn)品經(jīng)理請用結(jié)構(gòu)化思維分析這個問題……”——Stop。Skill 必須有可執(zhí)行性至少要包含操作步驟、工具調(diào)用或輸出規(guī)范這些“帶骨架”的內(nèi)容。如果一段話去掉“Skill”的外殼之后本質(zhì)上還是“請幫我做好 X”那它就是 Prompt 披了個馬甲。把這種內(nèi)容掛到 Agent 上不會讓模型變強(qiáng)只會讓你的配置文件變長、路由開銷變高。我自己的判斷標(biāo)準(zhǔn)是如果寫完的 Skill 沒有任何腳本、沒有任何能機(jī)器校驗(yàn)的輸出規(guī)范也不包含特定領(lǐng)域的分步方法論那我就不該叫它 Skill。4.2 信號二一個 Agent 掛了十幾個互不相關(guān)的 Skill有人為了追求功能齊全把市場調(diào)研、周報(bào)生成、代碼審查、PPT 排版全掛到同一個 Agent 上結(jié)果每次任務(wù)觸發(fā)時模型都要在十幾個 Skill 描述里做一次“路由決策”。決策空間越大選錯的概率越高選錯了后續(xù)輸出就跑偏而且跑偏得很隱蔽——因?yàn)槟Ｐ统３憩F(xiàn)得“看起來很像那么回事”。我在項(xiàng)目里的經(jīng)驗(yàn)是單個 Agent 上同時掛載的 Skill 最好不超過四五個且這些 Skill 應(yīng)該在領(lǐng)域上有某種相關(guān)性。如果業(yè)務(wù)場景差異太大拆成多個不同的 Agent分別掛各自的 Skill 組合效果會比“一個大而全的 Agent”好得多。4.3 信號三重復(fù)發(fā)明輪子把模型原生能力包成了 Skill模型的上下文理解、通用推理、基礎(chǔ)文本改寫這些能力本身就是內(nèi)置的你不需要為它們寫 Skill。比如“將一段英文翻譯成中文并潤色”這種任務(wù)直接對話就能完成包一層 Skill 除了增加截?cái)囡L(fēng)險(xiǎn)毫無幫助。優(yōu)雅的邊界是什么樣的判斷標(biāo)準(zhǔn)是“是否需要領(lǐng)域知識或固定流程”。如果任務(wù)每一步都依賴模型臨場發(fā)揮沒有外部依賴、沒有固定步驟、沒有獨(dú)特產(chǎn)出規(guī)范那它就是原生能力不該包裝成 Skill。Skill 應(yīng)該用在“一個外行無法通過簡單對話直接完成”的領(lǐng)域任務(wù)上比如法律文書一致性審查、行業(yè)數(shù)據(jù)源匯總、復(fù)雜報(bào)表生成。這些任務(wù)里有固定的業(yè)務(wù)規(guī)則和產(chǎn)出標(biāo)準(zhǔn)才需要沉淀成 Skill。4.4 信號四只寫不給測Skill 成了盲盒Skill 本質(zhì)上是代碼資產(chǎn)不測試就是負(fù)資產(chǎn)。我見過很多團(tuán)隊(duì)興致勃勃地寫完一個日志分析 Skill結(jié)果真實(shí)日志里只要出現(xiàn)一種 SKILL.md 沒覆蓋的格式腳本就崩了模型就在崩潰邊緣瘋狂補(bǔ)丁越補(bǔ)越離譜。正確的做法是把測試當(dāng)成 Skill 開發(fā)的一部分每次改動 SKILL.md 或者腳本都至少要跑一遍回歸。我不是說一定要上 CI/CD但至少你心里要對“這個 Skill 現(xiàn)在能不能用”有一個明確答案。連這個答案都給不出就不要把它放進(jìn)任何會自動運(yùn)行的系統(tǒng)里。我一直強(qiáng)調(diào)不可驗(yàn)收的 Skill 是無法迭代的。因?yàn)槟阍诔鰡栴}的時候根本不知道是腳本的問題、SKILL.md 指導(dǎo)的問題還是模型執(zhí)行的問題最后只能靠猜。4.5 信號五版本混亂、沒有維護(hù)責(zé)任人Skill 這種形態(tài)很容易讓人低估它的維護(hù)成本。Skill 會依賴模型版本、依賴腳本環(huán)境、依賴所在項(xiàng)目的具體情況任何一個變量變了它都可能開始“發(fā)神經(jīng)”。我在實(shí)際的工作中有個體會Skill 庫和代碼庫一樣需要版本管理、變更記錄、一個明確的責(zé)任人。否則三個月后模型版本升了某個 Skill 突然開始產(chǎn)生奇怪結(jié)果你翻遍記錄都找不出它是什么時候變的、為什么變只能從頭排查。5. 常見問題與排查技巧實(shí)錄5.1 Skill 加載了但不生效先分清是“沒看到”還是“做不到”Skill 不生效需要先確認(rèn)故障在哪一層。把排查分成三層加載層、選擇層、執(zhí)行層。加載層是 Skill 文件有沒有被正確放到 Agent 約定讀取的目錄命名、格式是否符合規(guī)范。很多框架對目錄名和 SKILL.md 文件名有嚴(yán)格約定一個字符錯了就靜默失敗。選擇層是模型面對當(dāng)前任務(wù)時到底有沒有把這個 Skill 納入候選。這一步最容易出問題。如果你想測試我建議直接在一個新會話里問模型“當(dāng)前環(huán)境下有哪些 Skill 可用”先看它能不能報(bào)出你的 Skill 名字再給一個明確觸發(fā)場景看它會不會主動選擇。選不到的話問題一般出在 SKILL.md 的描述語句上——太泛、太偏、和目標(biāo)任務(wù)同名性太弱都會讓路由失敗。執(zhí)行層是模型選擇并讀取 SKILL.md 之后有沒有按步驟執(zhí)行、腳本有沒有跑起來。這一層需要看工具調(diào)用日志。如果腳本根本沒被調(diào)用說明 SKILL.md 里的步驟寫得不夠顯式模型選擇性地跳過了如果腳本調(diào)用了但結(jié)果不對再回到腳本本身的容錯上排查。5.2 模型總是不按 SKILL.md 的步驟走怎么辦這一步的根因通常是步驟粒度太粗。多數(shù)模型執(zhí)行長流程時傾向于按自己的“常識”來理解一步操作而不會腦補(bǔ)你沒有寫的細(xì)節(jié)。比如你寫“提取錯誤碼”模型不知道是要用 Python 腳本還是用 grep這時它的選擇就不可控了。解決方法是把每一步寫成像機(jī)器指令一樣明確。建議給每個步驟配上“用什么工具、執(zhí)行什么命令、讀取哪個文件、產(chǎn)出什么中間結(jié)果”。寧可多寫幾行也不要留給模型發(fā)揮空間。我測試過同一個 Skill把步驟從“2. 統(tǒng)計(jì)錯誤碼”改成“2. 運(yùn)行 scripts/run.py --input 日志路徑 --output /tmp/error_summary.json”執(zhí)行準(zhǔn)確率提升非常明顯。另外一個容易踩的點(diǎn)是SKILL.md 太長。如果一份 SKILL.md 超過了上下文窗口的舒適區(qū)模型在后續(xù)生成過程中可能會“遺忘”后半段的規(guī)范。好東西要學(xué)會精煉步驟能合并就合并說明能去冗余就去冗余。5.3 多個 Skill 沖突了怎么辦沖突場景最典型的是同一個任務(wù)既能由 Skill A 處理也能由 Skill B 處理結(jié)果模型二選一的時候選錯了。我的處理辦法是給 Skill 設(shè)置顯式的邊界聲明在描述里直接寫明“本 Skill 優(yōu)先處理 X 場景Y 場景請交給 Z 處理”。如果沖突仍然存在就要回到觸發(fā)條件設(shè)計(jì)的正反例上。把常見的易混淆場景分別放進(jìn)兩個 Skill 的“不適用場景”段里。這樣等于在路由層面做了人工消歧能顯著降低選錯概率。5.4 Skill 寫太多之后 Agent 變笨了怎么處理這是系統(tǒng)性問題的癥狀不是單個 Skill 的問題。Skill 多了以后每個 Skill 的描述都要占用模型的注意力路由決策變慢錯誤率變高。我會定期做歸檔操作把低頻使用的 Skill 移出默認(rèn)加載列表改成按需加載把高頻使用的 Skill 合并同類項(xiàng)把已經(jīng)證明無效的 Skill 直接刪除。不要有不舍得刪的心理——Skill 是資產(chǎn)但它首先應(yīng)該是“可用資產(chǎn)”不可用的東西躺在那里只會繼續(xù)消耗上下文和注意力。判斷一個 Skill 留不留我只有一個問題如果這個 Skill 被刪了這些任務(wù)你會不會真的覺得不方便如果答案是不會或者不確定那它就該被歸檔或重寫。寫在最后的幾句實(shí)在話Skill 是好東西但它是一種工程產(chǎn)物不是玄學(xué)道具。我個人的經(jīng)驗(yàn)是在決定要不要造一個 Skill 之前先回答三個問題這個任務(wù)是否會反復(fù)出現(xiàn)三周以上它是不是有固定的多步操作流程它是否需要結(jié)合外部腳本或模板才能穩(wěn)定完成如果三個答案里至少有兩個是肯定的再考慮把 Skill 提上日程否則寫 Prompt 就夠了。代碼寫多了之后人會對“封裝”產(chǎn)生本能好感但在 Agent 領(lǐng)域每一次封裝都在給系統(tǒng)的路由和決策增加成本。克制本身就是一種工程能力。希望這篇拆解能幫你在下一次動手前多想一步你到底是在打造一件趁手的兵器還是僅僅在往工具箱里囤積一件精美的擺設(shè)。