Skill、MCP、Workflow、Rules、Memory 有何分別？掘金長文以實際開發任務劃出功能邊界

一篇發布於掘金、署名 jerrywus 的技術長文（2026 年 10 月 31 日），嘗試回答 AI 編程工具使用中常見的名詞混淆問題：Skill、MCP、Workflow、Rules 與 Memory 各自處理什麼，何時該用哪一個。作者以自身在小程式開發、設計稿處理等場景的經驗作為例證，閱讀量約 24 分鐘。本臺整理該文可核實的要點如下。

一個任務、五種分工

作者以「根據 Figma 設計稿實現頁面」為例，說明五個概念可在同一任務中各司其職：MCP 負責以統一協定接入設計稿等外部工具與資料；Skill 規定這類任務的方法，例如圖片如何處理；Workflow 安排確認與執行的先後順序；Rules 限制哪些檔案不能更動；Memory 則儲存日後仍需取用的約定與偏好。

文中給出的對照大致為：Rules 處理「適用範圍內須一直遵守的約定」，例如未經授權不得提交程式碼；Skill 處理「這一類任務按什麼方法做」；MCP 處理外部工具接入；Workflow 處理先後順序與暫停條件；Memory 處理值得留存的舊資訊，例如已確認的決策與環境限制。

作者同時提醒，各家產品命名互有重疊：一個 Skill 可以包含 Workflow，某些客戶端也可能把規則檔案放在 Memory 選單底下。判斷一個功能實際做什麼，應看其載入時機、維護方式與執行行為，而非只認選單名稱。

實例：Figma 切圖與 COS 上傳

作者描述自身的小程式開發流程：從 Figma 匯出素材、壓縮 PNG、上傳至騰訊雲 COS、複製位址再放回程式碼。這套重複操作後來被封裝為一個名為 image-auto-upload 的 Skill，內含壓縮與上傳兩個腳本。

在這個案例中，作者用 Figma MCP 讀取設計稿；圖片如何壓縮、傳到哪裡、如何回傳連結，寫在 Skill 說明中；「先確認素材清單再上傳」構成該任務的 Workflow；「密鑰不能出現在程式碼與日誌中」則屬於長期規則。實際呼叫壓縮服務與 COS SDK 的是腳本本身，AI 判斷當前任務需要哪些步驟，再透過宿主工具執行。

作者據此提出一個取捨原則：若既有腳本能完成任務、Agent 又能執行命令，可以先這樣用，沒有必要為了湊齊配置而給每個腳本再套一層 MCP 服務。文中另提及，舊做法是上傳成功後即清理來源圖片，如今設計類似流程時會改為先保留來源檔，核驗遠端結果後再按約定清理。

Rules：把反覆糾正的要求寫進檔案

針對 Rules，作者建議把那些「已經說過很多次」的要求寫進長期指令檔案，例如「不要順手把其他問題也改了」「工作區原有的修改不算這一輪做的」「測試沒跑就寫沒跑」。Claude Code 常見的檔案是 CLAUDE.md，Codex 與 Pi 常見的是 AGENTS.md，由客戶端決定檔案如何被發現與載入。

文中示範的專案協作約定包括：修改前先檢查工作區、沿用既有元件與依賴、介面失敗必須保留錯誤訊息、修改後執行相關檢查並記錄結果、未經明確授權不暫存不提交不推送。

分層方面，作者建議：所有專案都適用的個人偏好放在使用者層級；團隊共享的建構命令與目錄約定放在專案層級；只約束介面目錄的規範，就盡量限定到該範圍。文中並以 Claude Code 的語法為例，示範在 .claude/rules/api.md 中以 paths 欄位限定規則只作用於 src/api 下的 TypeScript 檔案，同時註明這是特定工具的寫法，換到其他工具需另查支援方式。

脈絡與邊界

這篇文章發布於 AI 編程工具競相引入 Skill、MCP 等機制的階段。讀者若追蹤本站先前的整理，可以對照兩則背景：其一，開發者在 V2EX 分享以氛圍編程打造的AI Vault 技能與 MCP 統一管理工具，同樣面對多 Agent 環境下技能與提示詞的組織問題；其二，W3C 孵化中的WebMCP 瀏覽器標準則涉及 MCP 概念向網頁端延伸的方向。

須說明的是，本文整理僅依據掘金該篇長文的內容，其中開發流程細節均為作者自述經驗，未經獨立驗證；各工具的具體語法與支援範圍可能隨版本變動，實際使用仍應以官方文件為準。