詳解 Agent Skills, Rules, Subagents
整理版優先睇
AI編程助手配置項嘅演進邏輯：從Rules到Skills，最終收斂成靜態上下文同動態能力兩個核心概念。
呢篇文章出自「知識藥丸」付費合集《賈傑的AI編程秘籍》，作者係AI編程專家賈傑。佢見到好多開發者面對Cursor等AI助手嘅Rules、Commands、MCP Servers、Subagents、Modes、Hooks、Tools等配置項一頭霧水，覺得「我只係想AI幫我寫啲碼，點解好似喺度搓火箭？」為咗幫大家釐清呢啲概念，作者從技術演進角度拆解每個配置項嘅出場原因同定位，最終指出呢啲野會收斂成一個優雅嘅解決方案：Agent Skills。
文章首先指出早期AI模型有幻覺問題，開發者用Rules文件畀AI一個「備忘錄」，每次對話都塞畀佢。但隨住項目變大，Rules膨脹，於是拆分多個文件，但本質都係靜態上下文。之後出現Commands，將重複工作流打包成斜槓命令，按需加載。再嚟就係MCP Servers，俾AI連接外部系統（數據庫、Slack等），但會引致上下文膨脹。第四階段係Modes同Subagents，改變AI行為模式，提高可靠性。第五階段係Hooks，提供確定性執行點。最終，呢啲概念統一成Skills——一個開放標準，打包可複用知識同腳本。
整體結論係：用戶唔需要理會所有配置項，只需關注Rules（靜態上下文）同Skills（動態能力），其他由工具自動優化。作者建議從建立精簡Rules開始，每次AI犯錯就記錄一條規則，慢慢積累。
- AI編程助手嘅配置項演進有清晰邏輯：從Rules到Skills，最終收斂成靜態上下文（Rules）同動態能力（Skills）兩個核心概念。
- Rules係每次對話都塞畀AI嘅備忘錄，解決幻覺問題；Commands係打包成斜槓命令嘅可複用工作流，按需加載。
- MCP Servers俾AI連接外部系統（數據庫、Slack等），但會引致上下文膨脹；Subagents同Modes改變AI行為模式，提升可靠性。
- Hooks係確定性執行點（例如Before/After Hook），用於安全審計；Skills融合所有概念，輕量易分發，同MCP互補。
- 用戶最佳實踐：只關注Rules（保持精簡，隨項目演進更新）同Skills（未來生態會似npm一樣），其他由工具自行優化。
結構示例
# .cursorrules 示例- 我們的代碼庫使用 TypeScript- 所有組件必須使用函數式組件，不要用 class- API 調用統一使用 axios，基礎 URL 是 /api/v2- 記住:我們沒有用戶認證系統!別給我生成登錄頁面!點解AI編程助手咁多配置項？
早期AI模型有致命問題：幻覺，即係一本正經地胡說八道。為咗解決呢個問題，開發者諗出一個簡單粗暴嘅方法：將「AI每次都會搞錯嘅嘢」寫成一份文檔，每次對話都塞畀AI睇。呢個就係Rules文件嘅由來。
之後開發者開始拆分Rules，變成多個文件，例如coding-style.md、api-conventions.md等。但本質上呢啲Rules最終都係合併成一份靜態上下文，每次對話開始時一股腦塞畀AI。咁樣做嘅問題係：唔係所有Rules都需要每次出現，例如寫前端時數據庫Schema規則其實冇必要出現。
從Commands到MCP：能力升級但代價係上下文膨脹
當你用AI編程助手用得熟練，就會發現有啲操作係重複嘅，例如每次提交前都要生成commit message、執行git commit、創建PR。於是就有咗Slash Commands（斜槓命令），例如/commit-and-pr，一條命令搞掂成個流程。呢個本質上係可複用嘅工作流，按需加載。
但開發者唔滿足於只係寫Prompt，佢哋想AI執行真正嘅代碼。於是出現咗MCP（Model Context Protocol），可以理解成AI嘅「USB-C接口」，用嚟連接外部系統，例如讀取Google Drive、查詢PostgreSQL、操作GitHub等。MCP Server讓AI擁有用具，好似裝咗義肢咁。
舉個例：你叫AI「喺數據庫揾最新銷售報告，然後發電郵畀經理」，AI會透過MCP客戶端發現database_query同email_sender工具，依次調用完成任務。
Modes、Subagents同Hooks：提升可靠性
有時你想改變AI嘅行為模式，例如「規劃模式」下只做架構設計唔寫代碼，「調試模式」聚焦錯誤排查。呢個就係Subagent嘅概念：為AI設定一個臨時人格，限制工具範圍同調整Prompt，令佢更專注可靠。而Mode更進一步，可以修改系統提示詞、提供特定UI元素、加入記憶提醒。
但呢啲都係「軟約束」，AI仍然可能出錯。於是就有咗Hooks——確定性嘅、100%可靠嘅執行點。例如Before Hook自動注入項目配置，After Hook記錄對話日誌。Hooks讓你可以喺AI工作流中插入可控邏輯，對安全審計好有用。
終極形態：Skills化繁為簡
到目前為止，我哋有Rules、Commands、MCP Servers、Subagents、Modes、Hooks……咁多概念，對用戶嚟講太混亂。好消息係呢啲嘢正在收斂到一個優雅嘅解決方案：Agent Skills。Skills係一個開放標準，用於打包可複用嘅知識同腳本，擴展AI Agent嘅專業能力。
Skills有兩種形態：基礎形態似Commands，封裝一個工作流，例如git-pr-flow.skill.md；高級形態可以包含腳本、可執行文件、資源文件，例如一個my-skill/目錄。Skills嘅好處係唔會膨脹上下文（需要時先加載），易於分發（一條命令安裝畀成個團隊），而且係開放標準。
作者建議：作為普通用戶，你只需要關注兩樣嘢：Rules（靜態上下文）同Skills（動態能力），其他由工具自行優化。Rules要保持精簡高質，只寫「AI經常搞錯」嘅核心規則，而且係「活嘅文檔」，隨項目演進更新。
總結：從一團亂麻到優雅清晰
回顧呢段演進史：Rules（靜態上下文）→ Commands（可複用Prompt）→ MCP Servers（連接外部系統）→ Modes & Subagents（調整行為模式）→ Hooks（確定性執行點）→ Skills（統一解決方案）。最終收斂到兩個核心概念：靜態上下文（Rules）同動態能力（Skills）。
而家當你再見到Rules、MCP、Skills呢啲概念時，應該清楚曬啦！建議你而家就開始建立自己嘅Rules文件，每次AI犯錯就記錄一條規則，慢慢積累，AI嘅表現會越來越符合你嘅預期。
👀 最新、最有用嘅AI編程姿勢，都係嚟自「知識藥丸」
Rules、Commands、MCP Servers、Subagents、Modes、Hooks、Tools……用AI寫code咁多配置項，邊個睇邊個一頭霧水
呢啲都係啲咩嚟㗎？點解要搞到咁複雜？我只係想叫AI幫我寫啲code，點解感覺好似喺度整火箭咁？
好啦，睇完呢篇文章之後，我突然醍醐灌頂——原來呢啲嘢背後有一條清晰嘅演進邏輯，而且最終佢哋會收斂到一個優雅嘅解決方案。我哋一齊從技術演進嘅角度理清楚呢啲嘢。
《賈傑嘅AI編程秘籍》付費合集，共10篇，而家已經完結。30蚊交個朋友，學唔到真嘢可以揾我退錢；）
仲有我嘅墨問合集《100個思維碎片》，1蚊100篇，同你一齊探討一啲有意思嘅話題（文末有訂閲方式）
起點：Rules — 俾健忘嘅AI一份備忘錄
問題從邊度嚟？
早期嘅AI模型有個致命問題：幻覺（Hallucination）。
咩係幻覺？就係AI會一本正經咁胡說八道。你叫佢寫code，佢可能會作一個根本唔存在嘅API；你叫佢遵守某個編碼規範，佢轉頭就唔記得咗。
咁要點樣解決呢？
Rules登場
開發者們諗到一個簡單粗暴嘅方法：將嗰啲「AI每次都搞錯嘅嘢」寫成一份文檔，然後喺每次對話中都塞俾AI睇。
這就是 Rules文件嘅由來。
# .cursorrules 示例
- 我們的代碼庫使用 TypeScript
- 所有組件必須使用函數式組件，不要用 class
- API 調用統一使用 axios，基礎 URL 是 /api/v2
- 記住:我們沒有用戶認證系統!別給我生成登錄頁面!Rules就好似係俾AI準備嘅「備忘錄」，同佢講：「喂，千祈唔好唔記得呢啲重要嘅嘢！」
冇錯，呢個方案確實有用。但隨住項目變大，Rules文件都開始膨脹……
進化：多個Rules文件
當一個Rules文件寫到幾千行嗰陣，維護起嚟就好痛苦。於是大家開始拆分Rules:
.cursor/
├── rules/
│ ├── coding-style.md
│ ├── api-conventions.md
│ └── database-schema.md不過本質上，呢啲Rules最終都係會合併成一份靜態上下文（Static Context），喺每次對話開始時一次過塞俾AI。
呢度有個問題：唔係所有Rules都需要喺每次對話中出現。
例如我喺寫前端code嗰陣，數據庫嘅Schema規則其實冇必要出現喺上下文入面，係咪？但喺嗰個時候，AI模型嘅工具調用能力仲未夠成熟，做唔到「按需加載」，只能暫時咁樣湊合用住先。
我哋記住呢個痛點，後面會講到佢嘅解決方案。
第二階段：Commands — 將工作流打包帶走
新嘅需求出現咗
當你用AI編程助手用得越嚟越熟練，你會發現：有啲操作係重複嘅。
例如我每次提交code之前都要做呢幾步：
1. 叫AI生成一個規範嘅commit message 2. 執行 git commit3. 自動創建PR並填寫描述
如果每次都要手動輸入呢一串提示詞，咁都太麻煩掛？
Slash Commands 閃亮登場
於是就有咗 Slash Commands（斜槓命令）嘅概念。
/commit-and-pr一個命令，搞掂成個流程！
你可以將常用嘅Prompt打包成一個命令，甚至可以分享俾團隊成員，或者放入Git倉庫做版本管理。呢個本質上就係可複用嘅工作流。
P.S. 我個人最鍾意嘅命令係 /commit-and-pr，真係超級省事！
本質係咩？
Commands其實都係文本（Prompt嘅封裝），只不過佢係「按需加載」嘅——只有當你主動調用嗰陣，佢先會被添加到上下文入面。
但好快，開發者們就唔滿足於「淨係寫Prompt」喇。佢哋想要：叫AI執行真正嘅code。
第三階段：MCP Servers — 俾AI裝上「義肢」
AI嘅侷限性
AI模型雖然好聰明，但佢有個硬傷：佢只能生成文本。
佢唔可以：
• 訪問你嘅數據庫 • 讀取Slack消息 • 喺Linear入面創建Issue • 連接外部API
呢個就好似一個聰明嘅大腦，但缺少手腳。
MCP係咩？
MCP（Model Context Protocol，模型上下文協議）係一個開源標準，用嚟連接AI應用同外部系統。你可以將佢理解成 AI嘅「USB-C接口」——就好似USB-C為電子設備提供咗標準化嘅連接方式，MCP為AI提供咗標準化嘅「插件系統」。
通過MCP Server，AI可以：
• 讀取Google Drive入面嘅文檔 • 喺Slack入面發送消息 • 查詢PostgreSQL數據庫 • 操作GitHub倉庫 • ……甚至控制瀏覽器（Puppeteer）
呢個簡直係俾AI裝上咗義肢!
一個具體例子
假設你叫AI幫你：「喺數據庫入面揾最新嘅銷售報告，然後發電郵俾我嘅經理。」
AI會通過MCP客戶端發現可用嘅工具，例如 database_query 和 email_sender，然後依次調用呢啲工具完成任務。
成個過程係咁樣嘅：
1. 工具發現：AI發現有數據庫查詢工具同郵件發送工具 2. 第一次調用：查詢數據庫，獲取報告數據 3. 第二次調用：發送郵件，附上報告內容 4. 返回結果：「我已經找到最新報告並發俾你嘅經理喇」
係咪好型？
但都有代價
MCP Servers帶嚟咗強大嘅能力，但都有個問題：上下文膨脹。
如果你安裝咗10個MCP Server，每個暴露10個工具，咁就係100個工具嘅說明文檔要塞入上下文入面。呢個會嚴重影響性能同準確性。
唔使急，後面會講到解決方案。
第四階段：Modes & Subagents — 俾AI換上唔同嘅「人格面具」
更複雜嘅需求
有時候，你唔止想俾AI加能力，仲想改變佢嘅行為模式。
比如:
• 我希望AI喺「規劃模式」下只做架構設計，唔寫具體code • 我希望AI喺「調試模式」下聚焦於錯誤排查 • 我希望AI喺處理某個子任務嗰陣，只能訪問特定嘅工具
呢個就催生咗 Modes（模式）同 Subagents（子代理）嘅概念。
Subagent係咩？
Subagent就好似係俾AI設定一個臨時人格:
# Subagent: 前端開發專家
你是一個前端開發專家，專注於 React 和 TypeScript。
你只能使用以下工具:
- 文件編輯
- npm 命令
- ESLint 檢查通過限制工具範圍同調整Prompt，Subagent可以令AI更專注、更可靠。
Mode更進一步
Mode唔止改變指令，仲可以：
• 修改系統提示詞 • 提供特定嘅UI元素（例如「計劃視圖」） • 喺提示中添加「記憶提醒」（令AI記住當前模式）
其實Mode同Subagent嘅核心目標都係：提高可靠性同可發現性。
但呢啲都仲係「軟約束」——AI仍然可能會出錯。咁有冇硬約束呢?
第五階段：Hooks — 俾AI加上「強制檢查點」
咩係Hook？
Hook係確定性嘅、100%可靠嘅執行點。
同前面嗰啲「AI可能會聽你講，亦可能唔聽」嘅機制唔同，Hook係必定會執行嘅腳本。
典型用法：
Before Hook（每次對話開始前）：
// 自動注入當前項目配置
injectProjectConfig();After Hook（對話結束後）：
// 記錄日誌
logConversation();
// 自動保存到數據庫
saveToDatabase();Hook令你可以喺AI嘅工作流入面插入可控嘅邏輯，呢個對於安全、審計、集成外部系統都非常有用。
終極形態：Skills — 化繁為簡
混亂嘅現狀
到呢度，我哋已經有咗：
• Rules（靜態上下文） • Commands（可複用提示詞） • MCP Servers（外部工具集成） • Subagents（子任務代理） • Modes（行為模式） • Hooks（確定性腳本）
呢個都太亂掛！
作為用戶，我只係想叫AI幫我寫code，點解要理解咁多概念？
Skills：統一嘅答案
好消息係，呢啲概念正在收斂到一個優雅嘅解決方案：Agent Skills。
Skills係一個開放標準，用嚟打包可複用嘅知識同腳本，擴展AI Agent嘅專業能力。
Skills嘅兩種形態
基礎形態：就好似Commands，封裝一個工作流
# git-pr-flow.skill.md
自動生成 commit message、提交代碼並創建 PR高級形態：可以包含腳本、可執行文件、資源文件——任何你想打包嘅嘢
my-skill/
├── SKILL.md # 技能說明
├── scripts/ # 可執行腳本
└── assets/ # 資源文件點解Skills更好？
1. 唔會膨脹上下文：Skills只喺需要嗰陣先加載 2. 易於分發：一條命令就可以安裝俾成個團隊 3. 開放標準：任何AI Agent都可以支援
# 一鍵安裝技能
npx ai-agent-skills install frontend-design --agent cursor與MCP嘅關係
你可能會問：咁MCP呢？仲用唔用？
梗係用啦！
Cursor對MCP進行咗優化，如果你安裝咗10個MCP Server，每個有10個工具，系統會按需加載工具，而唔係一次過塞入上下文。
Skills同MCP唔係競爭關係，而係互補嘅：
• Skills：更輕量，適合打包工作流同知識 • MCP：更強大，支援OAuth等高級功能
最佳實踐：我應該關注啲咩？
好啦，講咗咁多歷史，作為普通用戶，我到底應該點用？
核心原則：只關注兩個嘢
作為Coding Agent嘅用戶，你只需要關注：
1. Rules（靜態上下文） 2. Skills（動態能力）
其他嘅交俾工具自己優化就得。
Rules嘅最佳實踐
保持精簡、高質量。
Rules會包含喺每次對話入面，所以唔好寫成一本書。只寫嗰啲「AI經常搞錯」嘅核心規則。
我嘅習慣係：
• 當AI犯錯嗰陣，喺PR上面@cursor，叫佢更新Rules • Rules係「活嘅文檔」，隨住項目演進而更新
# 好的 Rules
- 使用 TypeScript strict 模式
- 組件文件命名:PascalCase.tsx
- API 基礎路徑:/api/v2
# 不好的 Rules(太囉嗦)
- TypeScript 是一種強類型的 JavaScript 超集……(省略 500 字)Skills嘅未來
Skills仲好新，而家仲未有太多「最佳實踐」。
但我相信，喺未來6個月入面，隨住生態嘅建立，Skills會變得越嚟越重要。
就好似前端嘅npm包一樣，會有一個龐大嘅「Skills生態系統」俾你選擇同安裝。
總結
等我哋回顧一下呢段進化史：
1. Rules：靜態上下文，每次都加載 2. Commands：可複用嘅Prompt 3. MCP Servers：連接外部系統，俾AI賦予真實能力 4. Modes & Subagents：調整AI行為模式 5. Hooks：確定性嘅執行點 6. Skills：統一嘅解決方案，化繁為簡
最終，呢一切都收斂到兩個核心概念：
• 靜態上下文（Rules） • 動態能力（Skills）
呢個演進過程唔係「瞎折騰」，而係AI編程助手喺不斷成熟嘅過程中，逐步揾到最優解嘅探索之路。
從一團亂麻，到優雅清晰——呢個就係技術進步嘅魅力。
而家，當你再見到 Rules、MCP、Skills 呢啲概念嗰陣，係咪清楚曬？
P.S. 如果你都有用Cursor或者其他AI編程助手，建議而家就開始建立你嘅Rules文件。由細微嘢做起，每次AI犯錯就記錄一條規則，慢慢累積，你會發現AI嘅表現越嚟越符合你嘅期待。
參考資料
• Model Context Protocol官方文檔 • Anthropic: Introducing the Model Context Protocol • Cursor Agent Skills文檔 • Agent Skills開放標準
堅持創作唔容易，求個一鍵三連，多謝你～❤️
以及「AI Coding技術交流羣」，聯絡ayqywx我拉你入羣，共同交流學習～
👀 最新、最有用的AI編程姿勢，總來自「知識藥丸」
Rules、Commands、MCP Servers、Subagents、Modes、Hooks、Tools……用AI寫個代碼這麼多配置項，誰看誰懵逼
這都是些啥玩意兒?為什麼要搞得這麼複雜?我就是想讓 AI 幫我寫點代碼，怎麼感覺像在搓火箭?
好吧，看完這篇文章後，我突然醍醐灌頂——原來這些東西背後有一條清晰的演進邏輯，而且最終它們會收斂到一個優雅的解決方案。我們來一起從技術演進的角度理清楚這些東西。
《賈傑的AI編程秘籍》付費合集，共10篇，現已完結。30元交個朋友，學不到真東西找我退錢；）
以及我的墨問合集《100個思維碎片》，1塊錢100篇，與你探討一些有意思的話題（文末有訂閲方式
起點:Rules — 給健忘的 AI 一份備忘錄
問題從哪來?
早期的 AI 模型有個致命問題:幻覺(Hallucination)。
什麼是幻覺?就是 AI 會一本正經地胡說八道。你讓它寫代碼，它可能會編造一個根本不存在的 API;你讓它遵守某個編碼規範，它轉頭就忘了。
那要怎麼解決呢?
Rules 登場
開發者們想出了一個簡單粗暴的辦法:把那些"AI 每次都會搞錯的東西"寫成一份文檔，然後在每次對話中都塞給 AI 看。
這就是 Rules 文件的由來。
# .cursorrules 示例
- 我們的代碼庫使用 TypeScript
- 所有組件必須使用函數式組件，不要用 class
- API 調用統一使用 axios，基礎 URL 是 /api/v2
- 記住:我們沒有用戶認證系統!別給我生成登錄頁面!Rules 就像是給 AI 準備的"備忘錄"，告訴它:"嘿，別忘了這些重要的事!"
沒錯，這個方案確實管用。但隨着項目變大，Rules 文件也開始膨脹……
進化:多個 Rules 文件
當一個 Rules 文件寫到幾千行時，維護起來就很痛苦了。於是大家開始拆分 Rules:
.cursor/
├── rules/
│ ├── coding-style.md
│ ├── api-conventions.md
│ └── database-schema.md不過本質上，這些 Rules 最終還是會合併成一份靜態上下文(Static Context)，在每次對話開始時一股腦塞給 AI。
這裏有個問題:不是所有 Rules 都需要在每次對話中出現。
比如我在寫前端代碼時，數據庫的 Schema 規則其實沒必要出現在上下文裏，對吧?但在當時，AI 模型的工具調用能力還不夠成熟，沒法做到"按需加載"，只能先這麼湊合着用。
我們記住這個痛點，後面會講到它的解決方案。
第二階段:Commands — 把工作流打包帶走
新的需求出現了
當你用 AI 編程助手用得越來越熟練，你會發現:有些操作是重複的。
比如我每次提交代碼前都要做這幾步:
1. 讓 AI 生成一個規範的 commit message 2. 執行 git commit3. 自動創建 PR 並填寫描述
如果每次都要手動輸入這一串提示詞，那也太麻煩了吧?
Slash Commands 閃亮登場
於是就有了 Slash Commands(斜槓命令)的概念。
/commit-and-pr一個命令，搞定整套流程!
你可以把常用的 Prompt 打包成一個命令，甚至可以分享給團隊成員，或者放進 Git 倉庫裏版本管理。這本質上就是可複用的工作流。
P.S. 我個人最喜歡的命令是 /commit-and-pr，真的超級省事!
本質是什麼?
Commands 其實還是文本(Prompt 的封裝)，只不過它是"按需加載"的——只有當你主動調用時，它才會被添加到上下文中。
但很快，開發者們就不滿足於"只能寫 Prompt"了。他們想要:讓 AI 執行真正的代碼。
第三階段:MCP Servers — 給 AI 裝上"義肢"
AI 的侷限性
AI 模型雖然很聰明，但它有個硬傷:它只能生成文本。
它不能:
• 訪問你的數據庫 • 讀取 Slack 消息 • 在 Linear 裏創建 Issue • 連接外部 API
這就好比一個聰明的大腦，但缺少手腳。
MCP 是什麼?
MCP(Model Context Protocol，模型上下文協議)是一個開源標準，用於連接 AI 應用與外部系統。你可以把它理解成 AI 的"USB-C 接口"——就像 USB-C 為電子設備提供了標準化的連接方式，MCP 為 AI 提供了標準化的"插件系統"。
通過 MCP Server，AI 可以:
• 讀取 Google Drive 裏的文檔 • 在 Slack 裏發送消息 • 查詢 PostgreSQL 數據庫 • 操作 GitHub 倉庫 • ……甚至控制瀏覽器(Puppeteer)
這簡直是給 AI 裝上了義肢!
一個具體例子
假設你讓 AI 幫你:"在數據庫裏找到最新的銷售報告，然後發郵件給我的經理。"
AI 會通過 MCP 客戶端發現可用的工具，比如 database_query 和 email_sender，然後依次調用這些工具完成任務。
整個過程是這樣的:
1. 工具發現:AI 發現有數據庫查詢工具和郵件發送工具 2. 第一次調用:查詢數據庫，獲取報告數據 3. 第二次調用:發送郵件，附上報告內容 4. 返回結果:"我已經找到最新報告併發給你的經理了"
是不是很酷?
但也有代價
MCP Servers 帶來了強大的能力，但也有個問題:上下文膨脹。
如果你安裝了 10 個 MCP Server，每個暴露 10 個工具，那就是 100 個工具的說明文檔要塞進上下文裏。這會嚴重影響性能和準確性。
別急，後面會講到解決方案。
第四階段:Modes & Subagents — 給 AI 換上不同的"人格面具"
更復雜的需求
有時候，你不只是想給 AI 加能力，你還想改變它的行為模式。
比如:
• 我希望 AI 在"規劃模式"下只做架構設計，不寫具體代碼 • 我希望 AI 在"調試模式"下聚焦於錯誤排查 • 我希望 AI 在處理某個子任務時，只能訪問特定的工具
這就催生了 Modes(模式)和 Subagents(子代理)的概念。
Subagent 是什麼?
Subagent 就像是給 AI 設定一個臨時人格:
# Subagent: 前端開發專家
你是一個前端開發專家，專注於 React 和 TypeScript。
你只能使用以下工具:
- 文件編輯
- npm 命令
- ESLint 檢查通過限制工具範圍和調整 Prompt，Subagent 可以讓 AI 更專注、更可靠。
Mode 更進一步
Mode 不僅改變指令，還能:
• 修改系統提示詞 • 提供特定的 UI 元素(比如"計劃視圖") • 在提示中添加"記憶提醒"(讓 AI 記住當前模式)
其實 Mode 和 Subagent 的核心目標都是:提高可靠性和可發現性。
但這些還是"軟約束"——AI 仍然可能出錯。那有沒有硬約束呢?
第五階段:Hooks — 給 AI 加上"強制檢查點"
什麼是 Hook?
Hook 是確定性的、100% 可靠的執行點。
和前面那些"AI 可能聽你的，也可能不聽"的機制不同，Hook 是必定會執行的腳本。
典型用法:
Before Hook(每次對話開始前):
// 自動注入當前項目配置
injectProjectConfig();After Hook(對話結束後):
// 記錄日誌
logConversation();
// 自動保存到數據庫
saveToDatabase();Hook 讓你可以在 AI 的工作流中插入可控的邏輯，這對於安全、審計、集成外部系統都非常有用。
終極形態:Skills — 化繁為簡
混亂的現狀
到這裏，我們已經有了:
• Rules(靜態上下文) • Commands(可複用提示詞) • MCP Servers(外部工具集成) • Subagents(子任務代理) • Modes(行為模式) • Hooks(確定性腳本)
這也太亂了吧!
作為用戶，我就是想讓 AI 幫我寫代碼，為什麼要理解這麼多概念?
Skills:統一的答案
好消息是，這些概念正在收斂到一個優雅的解決方案:Agent Skills。
Skills 是一個開放標準，用於打包可複用的知識和腳本，擴展 AI Agent 的專業能力。
Skills 的兩種形態
基礎形態:就像 Commands，封裝一個工作流
# git-pr-flow.skill.md
自動生成 commit message、提交代碼並創建 PR高級形態:可以包含腳本、可執行文件、資源文件——任何你想打包的東西
my-skill/
├── SKILL.md # 技能說明
├── scripts/ # 可執行腳本
└── assets/ # 資源文件為什麼 Skills 更好?
1. 不會膨脹上下文:Skills 只在需要時才加載 2. 易於分發:一條命令就能安裝給整個團隊 3. 開放標準:任何 AI Agent 都可以支持
# 一鍵安裝技能
npx ai-agent-skills install frontend-design --agent cursor與 MCP 的關係
你可能會問:那 MCP 呢?還用嗎?
當然用!
Cursor 對 MCP 進行了優化，如果你安裝了 10 個 MCP Server，每個有 10 個工具，系統會按需加載工具，而不是一次性塞進上下文。
Skills 和 MCP 不是競爭關係，而是互補的:
• Skills:更輕量，適合打包工作流和知識 • MCP:更強大，支持 OAuth 等高級功能
最佳實踐:我應該關注什麼?
好吧，講了這麼多歷史，作為普通用戶，我到底該怎麼用?
核心原則:只關注兩個東西
作為 Coding Agent 的用戶，你只需要關注:
1. Rules(靜態上下文) 2. Skills(動態能力)
其他的交給工具自己優化就行。
Rules 的最佳實踐
保持精簡、高質量。
Rules 會包含在每次對話中，所以不要寫成一本書。只寫那些"AI 經常搞錯"的核心規則。
我的習慣是:
• 當 AI 犯錯時，在 PR 上 @cursor，讓它更新 Rules • Rules 是"活的文檔"，隨着項目演進而更新
# 好的 Rules
- 使用 TypeScript strict 模式
- 組件文件命名:PascalCase.tsx
- API 基礎路徑:/api/v2
# 不好的 Rules(太囉嗦)
- TypeScript 是一種強類型的 JavaScript 超集……(省略 500 字)Skills 的未來
Skills 還很新，現在還沒有太多"最佳實踐"。
但我相信，在未來 6 個月裏，隨着生態的建立，Skills 會變得越來越重要。
就像前端的 npm 包一樣，會有一個龐大的"Skills 生態系統"供你選擇和安裝。
總結
讓我們回顧一下這段進化史:
1. Rules:靜態上下文，每次都加載 2. Commands:可複用的 Prompt 3. MCP Servers:連接外部系統，給 AI 賦予真實能力 4. Modes & Subagents:調整 AI 行為模式 5. Hooks:確定性的執行點 6. Skills:統一的解決方案，化繁為簡
最終，這一切都收斂到兩個核心概念:
• 靜態上下文(Rules) • 動態能力(Skills)
這個演進過程並不是"瞎折騰"，而是 AI 編程助手在不斷成熟的過程中，逐步找到最優解的探索之路。
從一團亂麻，到優雅清晰——這就是技術進步的魅力。
現在，當你再看到 Rules、MCP、Skills 這些概念時，是不是清楚多了?
P.S. 如果你也在用 Cursor 或其他 AI 編程助手，建議現在就開始建立你的 Rules 文件。從小事做起，每次 AI 犯錯就記錄一條規則，慢慢積累，你會發現 AI 的表現越來越符合你的期待。
參考資料
• Model Context Protocol 官方文檔 • Anthropic: Introducing the Model Context Protocol • Cursor Agent Skills 文檔 • Agent Skills 開放標準
堅持創作不易，求個一鍵三連，謝謝你～❤️
以及「AI Coding技術交流羣」，聯繫 ayqywx 我拉你進羣，共同交流學習～