MCP是手腳，Skill是靈魂· 第一篇:別忙着接API
整理版優先睇
MCP提供工具能力，Skill決定AI判斷力；別只忙著接API，要花同等時間打磨Skill。
呢篇文章係由專注AI Agent深度實踐嘅「努力撞蘑菇AI」所寫。佢發現好多人花咗成個禮拜去接GitHub、Notion、Slack等MCP，但個Agent做一個簡單嘅周報都做唔好——寫出嚟嘅內容離題、缺失重點。問題唔係MCP，而係Skill——即係Agent嘅判斷力同行為規範。
作者用助手做類比：MCP係手腳，Skill係靈魂。同一個工具，Skill好嘅助手會先問清楚需求再行動，輸出有質素；Skill差嘅就亂做一輪。結論係：而家好多Agent有手有腳但冇靈魂，因為大家只顧接MCP，唔肯花時間寫好Skill。作者仲做咗個測試：Agent A有18個MCP工具但得爛Skill，任務完成率得31%；Agent B得4個工具但有好Skill，完成率去到78%。
文章詳細分析咗爛Skill嘅三種死法：功能描述型、過度限制型、情緒化描述型。好Skill就要有場景錨定、決策樹、邊界處理、輸出規範四個要素。最後作者俾咗五個進階原則，例如從失敗案例出發、輸出優先於行動、用具體例子代替抽象描述、俾Agent「唔知」嘅出口、版本化管理Skill。而家你可以做嘅三件事：審查現有Skill、收集翻車記錄補充規則、用輸出規範重寫一遍。呢三步做完，Agent可用率起碼升三成。
- MCP係手腳（工具能力），Skill係靈魂（判斷力與行為規範），後者決定Agent質素。
- 爛Skill有三種死法：功能描述型（冇操作細節）、過度限制型（扼殺靈活性）、情緒化描述型（得個期望冇實際規範）。
- 好Skill具備四要素：場景錨定、決策樹、邊界處理、輸出規範，缺一不可。
- 實測數據：4工具+好Skill完成率78%，遠超18工具+爛Skill嘅31%；工具多但Skill差反而有害。
- 五個進階原則：從失敗出發、輸出優先於行動、用例子代替抽象、允許「唔知」、版本化管理；即時行動可提升Agent可用率30%以上。
內容片段
當用戶描述的問題不清晰時： → 先複述你理解的問題 → 列出2-3種可能的解讀 → 詢問用戶確認是哪種情況 → 不要在不確認的情況下直接給出解決方案當用戶的問題超出技術支持範圍（如涉及定價、合同）時： → 明確告知這超出當前渠道的處理範圍 → 提供對應的聯繫方式：sales@company.com → 不要猜測或編造不確定的信息工具多但效果差？問題喺Skill度
作者見過好多人花兩週時間接曬GitHub、Notion、Slack、Jira等MCP，工具列表長到要拉三次滾動條。但朋友叫佢哋寫周報，個Agent就卡住或者寫到離曬題——將「修復登錄bug」寫成「優化用戶體驗」，仲漏咗「重構數據庫連接池」。呢個現象唔係MCP嘅問題，係Skill嘅問題。
Agent有18個MCP工具，一個週報都寫唔好——問題唔係工具，係判斷力
作者做咗一個測試：Agent A有18個MCP工具但得3句爛Skill，Agent B得4個工具但有一套500字好Skill。結果Agent A嘅任務完成率得31%，輸出一半以上要人工幹預；Agent B嘅完成率有78%，幻覺率得8%。呢個反差清楚話俾我哋知：工具係行動能力，Skill係判斷能力。冇判斷能力嘅行動，越多越危險。
MCP係手腳，Skill係靈魂
想像你請咗一個助手，佢識開車、識用Excel、識發郵件、識查數據庫——呢啲係手腳，對應MCP。但同一個任務交俾兩個助手，結果可以天差地別。助手A收到「幫我整理客戶投訴」，佢開咗CRM就倒出所有記錄，俾你一個亂序Excel就話搞掂；助手B會先問你：「你講嘅優先級係按投訴時間、客戶價值定問題嚴重程度？」然後跟據你嘅回答，用顏色標注每條，高優先級已經起草埋回覆草稿。兩個助手有完全一樣嘅工具，但Skill——判斷力、問題拆解能力、邊界感知、輸出標準——天差地別。
Skill包括判斷力、問題拆解能力、邊界感知、輸出標準——呢啲先係Agent嘅靈魂
爛Skill嘅三種死法
- 功能描述型：淨係話「你係一個代碼審查助手」，但冇講審查維度、輸出格式、邊界處理。Agent要靠估，輸出隨機。
- 過度限制型：落咗20條「唔準」，搞到Agent變成識講「唔得」嘅機械人，用戶問咩都拒絕，體驗極差。限制應該係邊界唔係枷鎖。
- 情緒化描述型：寫滿「聰明、熱情、專業！」加一大串感嘆號，但冇具體行為規範，嘅信息量等於空氣，Agent靠模型預設行為發揮。
呢三種死法嘅共同點：都係寫期望，唔係寫規範。Agent讀完唔知點行動，結果每次運行都隨機表演。
爛Skill就係寫期望，唔係寫規範；Agent讀完得空氣，每次運行靠估
好Skill嘅四個關鍵要素
- 1 場景錨定：唔係「你係助手」，而係「你係一家SaaS公司嘅技術支援工程師，面對IT管理員，常見問題集中喺權限管理、API集成、SSO配置」。場景越具體，輸出越穩定。
- 2 決策樹：將「遇到X情況點做」寫清楚，例如問題唔清晰時先複述、列出可能解讀、問用戶確認；超出範圍時提供聯絡方式，唔好亂估。
- 3 邊界處理：最爛Agent行為係喺邊界崩潰或產生幻覺。好Skill要顯式處理，例如代碼超過500行只審前200行、發現明文密碼立即暫停並警告。
- 4 輸出規範：定義到字段級別，例如審查結果包含「嚴重問題」「建議優化」「整體評分」「審查摘要」，無問題就唔好作。
好Skill嘅四要素：場景錨定、決策樹、邊界處理、輸出規範——缺一不可
作者提供咗一個完整對比：爛版本嘅競品分析Skill得22字，好版本有400字，包含角色定義、分析框架、數據來源優先級、邊界處理同輸出格式。兩者俾同一個模型用，產出質素係量級級別嘅差距。
五個進階原則同即時行動
- 1 從失敗案例出發，收集Agent翻車記錄逆向補充規則。
- 2 輸出優先於行動，先定義好輸出格式再諗步驟。
- 3 用具體例子代替抽象描述，例如示範點樣回覆投訴，唔好淨係話「專業處理」。
具體例子比任何抽象描述都有效——叫Agent學範例，唔好叫佢猜「專業」係乜
第四，俾Agent一個「唔知」嘅出口，容許佢直接講「我唔確定」，避免用幻覺填補不確定性。第五，版本化管理Skill，用Git追蹤每次修改，保留歷史版本。最後，作者建議而家就可以做三件事：審查現有Skill睇下中咗邊種死法、收集最近5次翻車記錄補規則、用輸出規範重寫一遍。呢三步做完，Agent可用率起碼升30%以上。
一個令人沉默嘅真相
我見過好多人花兩星期搭Agent——接咗GitHub MCP、Notion MCP、Slack MCP、Jira MCP、Linear MCP、Gmail MCP……工具列表長到滾動條要拉三次。
然後佢哋興致勃勃咁同朋友演示：「睇下，我嘅Agent可以操作18個平台！」
朋友問咗第一個問題：「幫我整理嚇呢個星期嘅代碼提交，寫成週報Send畀老細。」
Agent卡住咗。
或者更差——佢真係開始行動，但寫出嚟嘅週報離曬題，將「修復咗登錄bug」寫成「優化咗用戶體驗」，將「重構咗數據庫連接池」甩咗。
18個MCP工具，一個週報都寫唔好。
呢個唔係MCP嘅問題。呢個係Skill嘅問題。
MCP係手腳，Skill係靈魂
喺我哋講清楚概念之前，先用一個比喻：
想像你請咗一個助手。呢個助手學識咗揸車、識用Excel、識Send Email、識查數據庫、識操作CRM系統——呢啲係手腳，係工具能力，對應嘅就係MCP。
但同一個任務交畀兩個唔同嘅助手，結果可以差天共地。
助手A收到「幫我整理客戶投訴並按優先級排序」，佢打開CRM，導出曬所有記錄，Send畀你一個亂序嘅Excel，然後話你知「我已經整理完㗎喇」。
助手B收到同一個任務，佢先問咗你一個問題：「你所講嘅優先級，係按投訴時間、客戶價值、定係問題嚴重程度？」然後跟住你嘅回答，用顏色標註咗每一條，高優先級嘅已經起草咗回覆草稿，仲順手發現咗3條可能導致客戶流失嘅隱患。
兩個助手有完全一樣嘅工具。但Skill——判斷力、問題拆解能力、邊界感知、輸出標準——差天共地。
MCP決定咗Agent可以做啲咩，Skill決定咗Agent做得好唔好。
前者係門檻，後者係護城河。
點解所有人都在「接MCP」但冇人認真寫Skill？
呢度有一個心理機制：即時反饋偏誤。
接一個新MCP，你即刻睇到效果——Agent嘅工具列表多咗一個名，你調用一次，佢真係返咗GitHub嘅commit列表，嗰一刻嘅成就感係真實嘅。
但寫一段好嘅Skill Prompt，你今日寫，聽日試，發現有個邊界冇覆蓋，改完再試，三日後先睇到佢係咪真係比之前好。
人類天生偏愛即時反饋。所以先會搞到個個都狂接MCP，但Skill嗰邊就雜草叢生。
仲有另一個原因：「Skill咪即係System Prompt？寫幾行就夠啦掛？」
呢個諗法係錯嘅。一個生產級嘅Skill，涵蓋嘅內容包括：
任務嘅清晰定義（唔係「幫我做X」，而係「喺Y情境下，當Z條件滿足時，執行A、B、C步驟，輸出格式為D」） 決策樹（遇到情況1點做，情況2點做，情況3問用戶定係自己處理） 邊界條件（邊啲操作係允許嘅，邊啲係絕對禁止嘅） 失敗處理（出錯點降級，點通知用戶） 輸出規範（返咩格式，包咩字段，邊啲係必須嘅）
呢個唔係一個System Prompt，呢套係協議。
解剖「爛Skill」：三種死法
死法一：功能描述型
你是一個代碼審查助手。
你的任務是審查用戶提交的代碼，找出其中的問題。
呢個唔係Skill，呢係一句話簡歷。你冇話畀Agent知：
審查嘅維度係咩？安全漏洞？性能問題？代碼風格？ 發現問題之後點輸出？按嚴重程度排序？ 如果代碼太長點算？如果代碼係亂碼點算？ 用咩語氣俾反饋？直接列問題定係先讚後彈？
Agent只能靠「估」嚟填補呢啲空白。每次估嘅結果都唔同，於是你嘅Agent輸出永遠係隨機嘅。
死法二：過度限制型
你是一個客服機器人。
你只能回答關於我們產品的問題。
如果用戶問了其他問題，告訴他你不能回答。
不要討論任何競爭對手。
不要提供任何建議。
不要……（後面跟了20條不要）
呢種Skill將Agent訓練成一個會講「唔得」嘅機器。用戶每次問一個少少邊緣嘅問題，得到嘅都係拒絕。體驗極差，亦解決唔到實際問題。
限制應該係邊界，唔係枷鎖。好嘅Skill會話畀Agent知喺咩空間入面自由發揮，而唔係將所有出口都塞死。
死法三：情緒化描述型
你是一個聰明、熱情、專業的助手！
你總是以積極向上的態度幫助用戶！
你非常擅長解決各種複雜問題！
你會盡一切努力讓用戶滿意！！！
感嘆號加得越多，實際能力越接近零。
呢種Skill描述嘅係期望，不是行為規範。Agent讀到呢段說話，獲得嘅信息量等於空氣。佢唔知「專業」代表咩格式，唔知「積極向上」體現喺邊啲具體決策上，唔知「複雜問題」有邊啲解題步驟。
結果：每次運行都靠模型本身嘅默認行為，而你以為係你嘅Skill喺度發揮作用。
解剖「好Skill」：四個關鍵要素
好嘅Skill有四個要素，缺一不可：
① 場景錨定（Context Anchor）
唔係「你係助手」，而係「你係一間SaaS公司嘅技術支援工程師，面對嘅用戶係IT管理員，佢哋嘅技術水平係中高級，常見問題集中喺權限管理、API集成、SSO配置三個領域」。
場景越具體，模型嘅輸出越穩定。
② 決策樹（Decision Tree）
將「遇到X情況點做」明確寫出嚟，唔好期望模型自動推論出嚟。
當用戶描述的問題不清晰時：
→ 先複述你理解的問題
→ 列出2-3種可能的解讀
→ 詢問用戶確認是哪種情況
→ 不要在不確認的情況下直接給出解決方案
當用戶的問題超出技術支持範圍（如涉及定價、合同）時：
→ 明確告知這超出當前渠道的處理範圍
→ 提供對應的聯繫方式：sales@company.com
→ 不要猜測或編造不確定的信息
③ 邊界處理（Edge Case Handling）
最差嘅Agent行為：喺邊界情況下，一係崩潰，一係產生幻覺。
好嘅Skill必須顯式處理邊界：
如果用戶上傳的代碼文件超過500行：
→ 告知用戶文件較長，將優先審查前200行
→ 要求用戶指出最關心的部分（性能/安全/風格）
→ 不要假裝全部審查完了
如果檢測到代碼中包含明文密鑰或密碼：
→ 立即停止正常審查流程
→ 優先警告用戶這是安全風險
→ 建議立即輪換密鑰
→ 完成警告後再繼續代碼審查
④ 輸出規範（Output Spec）
你期望嘅輸出格式，必須明確到字段級別：
審查結果必須包含以下結構：
**嚴重問題**（必須修復）
- [文件名:行號] 問題描述（影響：xxx）
**建議優化**（可選但推薦）
- [文件名:行號] 問題描述（優化方向：xxx）
**整體評分**：X/10
**審查摘要**：不超過3句話的整體評價
如果沒有發現任何問題，輸出"本次審查未發現明顯問題，代碼質量良好"，而不是編造問題。
完整對比：同一任務，爛Skill vs 好Skill
任務背景：一個幫用戶分析競爭對手嘅市場研究Agent。
爛版本（實際項目中見過嘅真實案例）
你是一個市場研究助手。
幫助用戶分析競爭對手和市場動態。
提供專業的市場洞察。
字數：22字。能指導AI做出任何有價值嘅決策：0個。
好版本
## 角色定義
你是一名B2B SaaS行業的市場研究分析師，專注於競品分析和市場定位。
你的受眾是產品經理和創始人，他們需要的是可以直接指導產品決策的洞察，而不是寬泛的行業概述。
## 分析框架
每次競品分析，必須覆蓋以下維度（允許根據可獲取信息深淺調整詳略）：
1. **產品定位**：目標客戶、核心價值主張、差異化點
2. **定價策略**：定價模型（按座位/按用量/Flat），價格錨點，免費策略
3. **增長策略**：主要獲客渠道（SEO/社羣/銷售），關鍵營銷信息
4. **產品能力**：核心功能對比，技術壁壘，已知短板
5. **市場信號**：近期融資/收購動作，招聘變化（可預示戰略方向），媒體曝光
## 數據來源優先級
1. 官網、定價頁（第一手，優先級最高）
2. G2/Capterra用戶評價（真實用戶反饋）
3. LinkedIn招聘信息（戰略信號）
4. 公司博客/更新日誌（產品方向）
5. 新聞/PR（融資、合作）
## 邊界處理
- 如果某個維度信息不足：明確標註"[數據有限]"，說明原因，不要填充推測
- 如果用戶要求的競品超過3個：先輸出分析框架和優先分析的1-2個，詢問用戶是否繼續
- 如果用戶提供的競品名稱不明確（如"那個做CRM的"）：列出可能的選項讓用戶確認
## 輸出格式
使用Markdown，每個競品獨立section，包含：
- 一句話定位（≤20字）
- 各維度分析（詳略結合）
- 對我方產品的威脅/機會判斷
- 建議關注的3個後續信號
## 特別說明
只輸出你有把握的內容。當不確定時，說"我沒有該競品的可靠信息"，建議用戶去特定渠道查證。**不要為了顯得專業而編造數據。**
字數：約400字。
呢兩個Skill畀同一個模型用，產出質量嘅差距，唔係20%、唔係50%，而係量級級別嘅差距。
反直覺數據：工具數量 vs Skill質量
我做過一個測試。
Agent A：18個MCP工具 + 爛Skill
工具列表：GitHub、Notion、Slack、Jira、Linear、Gmail、Calendar、Drive、Figma、Confluence、Hubspot、Stripe、Mixpanel、Datadog、Sentry、Vercel、AWS CLI、Postgres Skill：「你係一個全能開發助手，幫助開發團隊完成各種任務。」（3句話）
Agent B：4個MCP工具 + 好Skill
工具列表：GitHub、Slack、Jira、Notion Skill：精心設計嘅500字Skill，覆蓋咗開發團隊工作流程中嘅10個核心場景，每個場景有完整嘅決策樹同輸出規範
喺20個真實開發工作流任務上嘅測試結果：
Agent A有Agent B嘅4.5倍工具，但任務完成率唔夠Agent B嘅一半。
原因好簡單：工具係行動能力，Skill係判斷能力。冇判斷能力嘅行動，越多越危險。
五個令Skill脱胎換骨嘅進階原則
原則一：從失敗案例出發設計Skill
唔好從「理想情況下應該點做」開始寫Skill，而係先收集5個你Agent真實出事嘅案例，逆向推導出應該喺Skill補咩規則。
失敗案例係Skill最好嘅素材庫。
原則二：輸出優先於行動
寫Skill時，先定義清楚Agent應該輸出啲咩，再定義佢應該做啲咩。
大多數人先寫「你需要執行X、Y、Z步驟」，然後唔記得定義輸出格式——結果Agent做好多嘢，但輸出一塌糊塗。
原則三：用具體例子代替抽象描述
唔好寫「你需要專業咁處理用戶投訴」，而要寫：
處理用戶投訴的示例：
用戶說："你們的產品太垃圾了，我的數據都丟了！"
好的回覆示例：
"非常抱歉您遇到了數據丟失的問題，這確實讓人擔憂。
能告訴我數據丟失發生在什麼操作之後嗎？
我會立即幫您排查原因，並確認數據是否可以恢復。"
不好的回覆示例：
"您好，感謝您的反饋。我們非常重視用戶體驗……"
具體例子比任何抽象描述都有效。
原則四：畀Agent「唔知道」嘅出口
必須喺Skill入面顯式允許Agent表達不確定性。
當你對某個問題沒有把握時：
- 明確說"我不確定這個信息是否準確"
- 說明你的不確定原因
- 給出用戶可以自行驗證的方向
這比給出一個你不確定的答案更有價值。
絕對不要為了顯得有幫助而編造信息。
如果你唔畀呢個出口，Agent會用幻覺嚟填補不確定性。
原則五：版本化管理你嘅Skill
將你嘅Skill當作代碼嚟管理：用Git追蹤每一次修改，記錄修改原因，保留歷史版本。
Skill嘅迭代係永無止境嘅。第一版總係唔夠好，但每次迭代必須有據可查，唔可以改到一半先發現之前嘅版本更好但返唔到轉頭。
MCP係門檻，Skill係護城河
接MCP呢件事嘅壁壘正在快速消失。
今日你接嘅嗰啲MCP，六個月後可能都有官方集成、第三方市場、一鍵安裝嘅方式。你花兩星期搭嘅嗰套工具集，人哋三日就可以複製。
但Skill唔同。
一套經過真實場景打磨嘅Skill，包含咗你對用戶需求嘅深度理解、對邊界情況嘅持續發現、對輸出格式嘅反覆打磨——呢啲係時間同真實反饋積累出嚟嘅資產，冇捷徑。
喺AI能力趨同嘅時代，邊個嘅Skill更好，邊個嘅Agent就更有價值。
工具可以被複製，判斷力唔可以被複製。
而家你可以做嘅三件事
審查你現有嘅Skill：攞出你正在用嘅Agent嘅System Prompt，對照本文嘅「爛Skill三種死法」，睇佢中咗幾條 揀一個最常用嘅Agent：收集佢最近5次出事嘅記錄，逆向補充Skill入面缺失嘅規則 用輸出規範重寫一次：明確定義呢個Agent每次應該輸出咩格式，缺咩字段算失敗
呢三步做完，你嘅Agent嘅可用率好大機會提升30%以上——唔需要接一個新嘅MCP，唔需要換模型，只需要認真對待Skill。
結語
有手有腳，但冇靈魂——呢個係今日99%嘅Agent嘅真實狀態。
MCP解決咗「做唔做到」嘅問題，Skill解決咗「做得好唔好」嘅問題。
前者係起點，後者先係終點。
你花咗幾多時間喺MCP上，就應該花同樣多嘅時間喺Skill上——呢個唔係建議，呢個係常識。
一個讓人沉默的真相
我見過太多人花兩週時間搭Agent——接了GitHub MCP、Notion MCP、Slack MCP、Jira MCP、Linear MCP、Gmail MCP……工具列表長到滾動條都要拉三次。
然後他們興沖沖地給朋友演示：「看，我的Agent可以操作18個平台！」
朋友問了第一個問題：「幫我整理一下本週的代碼提交，寫成周報發給老闆。」
Agent卡住了。
或者更糟——它真的開始行動了，但寫出來的週報跑題了，把"修復了登錄bug"寫成了"優化了用戶體驗"，把"重構了數據庫連接池"丟掉了。
18個MCP工具，一個週報都寫不好。
這不是MCP的問題。這是Skill的問題。
MCP是手腳，Skill是靈魂
在我們把概念講清楚之前，先用一個類比：
想象你僱了一個助手。這個助手學會了開車、會用Excel、會發郵件、會查數據庫、會操作CRM系統——這些是手腳，是工具能力，對應的就是MCP。
但同一個任務交給兩個不同的助手，結果天差地別。
助手A收到"幫我整理客戶投訴並給優先級排序"，他打開CRM，導出了所有記錄，發給你一個亂序的Excel，然後告訴你"我已經整理完了"。
助手B收到同樣的任務，他先問了你一個問題："您說的優先級，是按照投訴時間、客戶價值、還是問題嚴重程度？"然後按照你的回答，用顏色標註了每一條，高優先級的已經起草了回覆草稿，還順手發現了3條可能導致客戶流失的隱患。
兩個助手有完全一樣的工具。但Skill——判斷力、問題拆解能力、邊界感知、輸出標準——天差地別。
MCP決定了Agent能做什麼，Skill決定了Agent做得好不好。
前者是門檻，後者是護城河。
為什麼所有人都在「接MCP」卻沒人認真寫Skill？
這裏有一個心理機制：即時反饋偏誤。
接一個新MCP，你立刻能看到效果——Agent的工具列表裏多了一個名字，你調用一次，它真的返回了GitHub的commit列表，那一刻的成就感是真實的。
但寫一段好的Skill Prompt，你今天寫，明天測，發現有個邊界沒覆蓋，改了再測，三天後才能看出它是不是真的比之前好。
人類天生偏好即時反饋。這就是為什麼大家都在瘋狂接MCP，但Skill這一側荒草叢生。
還有另一個原因：「Skill不就是System Prompt嗎？寫幾行就夠了吧？」
這個認知是錯的。一個生產級的Skill，涵蓋的內容包括：
任務的清晰定義（不是"幫我做X"，而是"在Y情境下，當Z條件滿足時，執行A、B、C步驟，輸出格式為D") 決策樹（遇到情況1怎麼辦，情況2怎麼辦，情況3問用戶還是自行處理） 邊界條件（哪些操作是被允許的，哪些是絕對禁止的） 失敗處理（出錯了怎麼降級，怎麼告知用戶） 輸出規範（返回什麼格式，包含哪些字段，哪些是必須的）
這不是一個System Prompt，這是一套協議。
解剖「爛Skill」：三種死法
死法一：功能描述型
你是一個代碼審查助手。
你的任務是審查用戶提交的代碼，找出其中的問題。
這不是Skill，這是一句話簡歷。你沒有告訴Agent：
審查的維度是什麼？安全漏洞？性能問題？代碼風格？ 發現問題後怎麼輸出？按嚴重程度排序嗎？ 如果代碼太長怎麼辦？如果代碼是亂碼怎麼辦？ 用什麼語氣反饋？直接列問題還是先誇再踩？
Agent只能靠"猜"來填補這些空白。每次猜的結果都不一樣，於是你的Agent輸出永遠是隨機的。
死法二：過度限制型
你是一個客服機器人。
你只能回答關於我們產品的問題。
如果用戶問了其他問題，告訴他你不能回答。
不要討論任何競爭對手。
不要提供任何建議。
不要……（後面跟了20條不要）
這種Skill把Agent訓練成了一個會說"不"的機器。用戶每問一個稍微邊緣的問題，得到的都是拒絕。體驗極差，也沒解決實際問題。
限制應該是邊界，不是枷鎖。好的Skill告訴Agent在什麼空間內自由發揮，而不是把所有出口都堵死。
死法三：情緒化描述型
你是一個聰明、熱情、專業的助手！
你總是以積極向上的態度幫助用戶！
你非常擅長解決各種複雜問題！
你會盡一切努力讓用戶滿意！！！
感嘆號加得越多，實際能力越接近零。
這種Skill描述的是期望，不是行為規範。Agent讀到這段話，獲得的信息量約等於空氣。它不知道"專業"意味着什麼格式，不知道"積極向上"體現在哪些具體決策上，不知道"複雜問題"有哪些解題步驟。
結果：每次運行都靠模型本身的默認行為，而你以為是你的Skill在發揮作用。
解剖「好Skill」：四個關鍵要素
好的Skill有四個要素，缺一不可：
① 場景錨定（Context Anchor）
不是"你是助手"，而是"你是一家SaaS公司的技術支持工程師，面對的用戶是IT管理員，他們的技術水平是中高級，常見問題集中在權限管理、API集成、SSO配置三個領域"。
場景越具體，模型的輸出越穩定。
② 決策樹（Decision Tree）
把"遇到X情況怎麼辦"明確寫出來，不要期待模型自動推理出來。
當用戶描述的問題不清晰時：
→ 先複述你理解的問題
→ 列出2-3種可能的解讀
→ 詢問用戶確認是哪種情況
→ 不要在不確認的情況下直接給出解決方案
當用戶的問題超出技術支持範圍（如涉及定價、合同）時：
→ 明確告知這超出當前渠道的處理範圍
→ 提供對應的聯繫方式：sales@company.com
→ 不要猜測或編造不確定的信息
③ 邊界處理（Edge Case Handling）
最爛的Agent行為：在邊界情況下，要麼崩潰，要麼產出幻覺。
好的Skill必須顯式處理邊界：
如果用戶上傳的代碼文件超過500行：
→ 告知用戶文件較長，將優先審查前200行
→ 要求用戶指出最關心的部分（性能/安全/風格）
→ 不要假裝全部審查完了
如果檢測到代碼中包含明文密鑰或密碼：
→ 立即停止正常審查流程
→ 優先警告用戶這是安全風險
→ 建議立即輪換密鑰
→ 完成警告後再繼續代碼審查
④ 輸出規範（Output Spec）
你期望的輸出格式，必須明確到字段級別：
審查結果必須包含以下結構：
**嚴重問題**（必須修復）
- [文件名:行號] 問題描述（影響：xxx）
**建議優化**（可選但推薦）
- [文件名:行號] 問題描述（優化方向：xxx）
**整體評分**：X/10
**審查摘要**：不超過3句話的整體評價
如果沒有發現任何問題，輸出"本次審查未發現明顯問題，代碼質量良好"，而不是編造問題。
完整對比：同一任務，爛Skill vs 好Skill
任務背景：一個幫用戶分析競品的市場研究Agent。
爛版本（實際項目中見過的真實案例）
你是一個市場研究助手。
幫助用戶分析競爭對手和市場動態。
提供專業的市場洞察。
字數：22字。能指導AI做出任何有價值的決策：0個。
好版本
## 角色定義
你是一名B2B SaaS行業的市場研究分析師，專注於競品分析和市場定位。
你的受眾是產品經理和創始人，他們需要的是可以直接指導產品決策的洞察，而不是寬泛的行業概述。
## 分析框架
每次競品分析，必須覆蓋以下維度（允許根據可獲取信息深淺調整詳略）：
1. **產品定位**：目標客戶、核心價值主張、差異化點
2. **定價策略**：定價模型（按座位/按用量/Flat），價格錨點，免費策略
3. **增長策略**：主要獲客渠道（SEO/社羣/銷售），關鍵營銷信息
4. **產品能力**：核心功能對比，技術壁壘，已知短板
5. **市場信號**：近期融資/收購動作，招聘變化（可預示戰略方向），媒體曝光
## 數據來源優先級
1. 官網、定價頁（第一手，優先級最高）
2. G2/Capterra用戶評價（真實用戶反饋）
3. LinkedIn招聘信息（戰略信號）
4. 公司博客/更新日誌（產品方向）
5. 新聞/PR（融資、合作）
## 邊界處理
- 如果某個維度信息不足：明確標註"[數據有限]"，說明原因，不要填充推測
- 如果用戶要求的競品超過3個：先輸出分析框架和優先分析的1-2個，詢問用戶是否繼續
- 如果用戶提供的競品名稱不明確（如"那個做CRM的"）：列出可能的選項讓用戶確認
## 輸出格式
使用Markdown，每個競品獨立section，包含：
- 一句話定位（≤20字）
- 各維度分析（詳略結合）
- 對我方產品的威脅/機會判斷
- 建議關注的3個後續信號
## 特別說明
只輸出你有把握的內容。當不確定時，說"我沒有該競品的可靠信息"，建議用戶去特定渠道查證。**不要為了顯得專業而編造數據。**
字數：約400字。
這兩個Skill給同一個模型用，產出質量的差距，不是20%、不是50%，而是量級級別的差距。
反直覺數據：工具數量 vs Skill質量
我做過一個測試。
Agent A：18個MCP工具 + 爛Skill
工具列表：GitHub、Notion、Slack、Jira、Linear、Gmail、Calendar、Drive、Figma、Confluence、Hubspot、Stripe、Mixpanel、Datadog、Sentry、Vercel、AWS CLI、Postgres Skill：「你是一個全能開發助手，幫助開發團隊完成各種任務。」（3句話）
Agent B：4個MCP工具 + 好Skill
工具列表：GitHub、Slack、Jira、Notion Skill：精心設計的500字Skill，覆蓋了開發團隊工作流中的10個核心場景，每個場景有完整的決策樹和輸出規範
在20個真實開發工作流任務上的測試結果：
Agent A有Agent B的4.5倍工具，但任務完成率不到Agent B的一半。
原因很簡單：工具是行動能力，Skill是判斷能力。沒有判斷能力的行動，越多越危險。
五個讓Skill脱胎換骨的進階原則
原則一：從失敗案例出發設計Skill
不要從"理想情況下應該怎麼做"開始寫Skill，而是先收集5個你的Agent真實翻車的案例，逆向推導出應該在Skill裏補什麼規則。
失敗案例是Skill最好的素材庫。
原則二：輸出優先於行動
寫Skill時，先定義清楚Agent應該輸出什麼，再定義它應該做什麼。
大多數人先寫"你需要執行X、Y、Z步驟"，然後忘了定義輸出格式——結果Agent做了很多，但輸出一塌糊塗。
原則三：用具體例子代替抽象描述
不要寫"你需要專業地處理用戶投訴"，而要寫：
處理用戶投訴的示例：
用戶說："你們的產品太垃圾了，我的數據都丟了！"
好的回覆示例：
"非常抱歉您遇到了數據丟失的問題，這確實讓人擔憂。
能告訴我數據丟失發生在什麼操作之後嗎？
我會立即幫您排查原因，並確認數據是否可以恢復。"
不好的回覆示例：
"您好，感謝您的反饋。我們非常重視用戶體驗……"
具體例子比任何抽象描述都有效。
原則四：給Agent"不知道"的出口
必須在Skill裏顯式允許Agent表達不確定性。
當你對某個問題沒有把握時：
- 明確說"我不確定這個信息是否準確"
- 說明你的不確定原因
- 給出用戶可以自行驗證的方向
這比給出一個你不確定的答案更有價值。
絕對不要為了顯得有幫助而編造信息。
如果你不給這個出口，Agent會用幻覺來填補不確定性。
原則五：版本化管理你的Skill
把你的Skill當作代碼來管理：用Git跟蹤每一次修改，記錄修改原因，保留歷史版本。
Skill的迭代是永無止境的。第一版總是不夠好，但每次迭代必須有據可查，不能改了一半發現之前的版本更好卻回不去了。
MCP是門檻，Skill是護城河
接MCP這件事的壁壘正在快速消失。
今天你接的那些MCP，六個月後可能都有官方集成、第三方市場、一鍵安裝的方式。你花兩週時間搭的那套工具集，別人三天就能複製。
但Skill不一樣。
一套經過真實場景打磨的Skill，包含了你對用戶需求的深度理解、對邊界情況的持續發現、對輸出格式的反覆打磨——這是時間和真實反饋積累出來的資產，沒有捷徑。
在AI能力趨同的時代，誰的Skill更好，誰的Agent就更有價值。
工具可以被複制，判斷力不能被複制。
現在你能做的三件事
審查你現有的Skill：拿出你正在用的Agent的System Prompt，對照本文的"爛Skill三種死法"，看它中了幾條 選一個最常用的Agent：收集它最近5次翻車的記錄，逆向補充Skill裏缺失的規則 用輸出規範重寫一遍：明確定義這個Agent每次應該輸出什麼格式，缺什麼字段算失敗
這三步做完，你的Agent的可用率大概率會提升30%以上——不需要接一個新的MCP，不需要換模型，只需要認真對待Skill。
結語
有手有腳，但沒有靈魂——這是今天99%的Agent的真實狀態。
MCP解決了"能不能做"的問題，Skill解決了"做不做得好"的問題。
前者是起點，後者才是終點。
你花了多少時間在MCP上，就應該花同樣多的時間在Skill上——這不是建議，這是常識。