我用 Skills 讓 8 個 AI Agent 每天自動幫我工作，是什麼感覺？
大約兩個月前我寫了第一個 SOUL.md，當時只是想讓 Claude 記住我的寫作風格，不要每次都重新交代一次。現在回頭看，那個小小的決定，啟動了一場完全不同的工作方式。
今天我的 OpenClaw 生態裡有 20+ 個 Skills，每天幫我自動工作。8 個 Agent 各司其職——Lala 是總指揮，Ori 負責研究，Craft 負責內容決策，Lumi 負責工程管理，Sage 負責投資分析，Pixel 做視覺，Kai-1 和 Kai-2 是兩個 Coding 執行者。每個 Agent 都有自己的 SOUL.md、AGENTS.md、TOOLS.md，每天自動執行內容生產、投資監控、程式開發，幾乎不需要我介入。
但這篇不是要炫耀我做了什麼。
你可能裝好了 OpenClaw，打開 Claude Code，甚至試著寫了幾個 Prompt——但不知道怎麼設計一個「真正好用的 Skill」。一個你寫一次，Claude 就能反覆幫你執行的自動化工作流。
這篇是給你的。從方法論到真實案例，從架構設計到常見錯誤，全部攤開來講。
一、什麼是 OpenClaw Skills？
先釐清一件事：Skill 不是 Prompt。
這兩個東西看起來像，用起來完全不同。
普通 Prompt 是一次性的。你每次跟 Claude 對話，都要重新說明背景、重新交代格式、重新描述你要什麼。Claude 不記得你上次說了什麼，它每次都是一張白紙。
OpenClaw Skill 不一樣。它是持久化的——你寫一次，Claude 每次啟動都知道。它是可組合的——Skills 之間可以互相調用，串成完整的工作流。它有記憶——透過 MEMORY.md 和共享狀態檔，Claude 記得上次做到哪裡。
為什麼「設計 Skill」比「寫 Prompt」更重要？
因為 Prompt 是你在場才能用的東西。Skill 是你不在場，Claude 也能幫你工作的東西。
舉個最直接的例子。我的 Craft（內容 Agent）的 SOUL.md 裡面寫了一段：
你不直接寫任何內容——寫作是 content-research-writer 的事。 但你決定寫不寫、怎麼寫、為誰寫。
這不是一個 Prompt。這是一個角色定義。它告訴 Craft：你是 Content Leader，你的工作是決策和把關，不是下場寫字。這個區別很重要——它讓 Craft 知道自己的邊界在哪裡，什麼事該做，什麼事該交給別人。
一個好的 Skill，就是給 Claude 一份「工作說明書」。
二、MAPS 方法論中文詳解
MAPS 是 Axton 的框架，我用自己的 8 Agent 生態實踐了一年，以下是我的中文版詮釋。
【M — Mindset：把 AI 當員工設計，不是當工具使用】
大部分人用 AI 的方式是「工具模式」——你叫它做什麼就做什麼。你輸入，它輸出，做完收工。
但如果你想讓 AI 幫你做真正有價值的事，你要切換到「員工模式」——給它一個角色、一組職責、一套判斷原則。它會主動決策、主動回報、遇到問題主動問你。
具體怎麼做？寫 SOUL.md 的時候問自己兩個問題：
- 這個 Agent 的核心信念是什麼？
- 什麼情況下它應該說不？
第二個問題特別關鍵。大部分人只設計了 Agent 「該做什麼」，但從來沒設計「不該做什麼」。
我的 Sage（投資研究 Agent）的 SOUL.md 裡面有一條：
敢說不知道——如果數據不夠，就說數據不足，不硬湊一個看起來像回答的回答。這條規則改變了 Sage 的行為模式。一般的 AI 你問它問題，它一定會硬擠出一個答案。但 Sage 不會。它會說：「這部分數據不足，我無法做出有信心的判斷。」
這讓 Sage 變得可信任。因為當它說「看多」的時候，我知道它是基於充分數據的判斷，不是在敷衍我。
【A — Architecture：Skills 的四層結構】
每一個好用的 Skill，都有四層：
Input（接收什麼）↓
Process（怎麼處理）
↓
Output（產出什麼格式）
↓
Handoff（交給誰、觸發什麼）
拿 Ori（研究 Agent）當例子：
- Input：Reddit/Twitter 上的痛點素材
- Process：5 維度評估——讀者利益、受眾契合、時效性、差異化、品牌一致性
- Output：結構化研究報告 + Self-QA 表
- Handoff：sessions_send 給 Craft，觸發內容生產流程
注意最後一層 Handoff。這是很多人漏掉的——你的 Skill 做完了，然後呢？如果沒有 Handoff，產出就死在那裡，沒有人接手。
【P — Prompt：讓 Skill 有角色、有判斷力、有邊界】
Prompt 設計不是在寫指令，是在「定義一個人」。三個關鍵要素：
第一，角色宣告（Who）。不是「你是一個 AI 助手」，是：
你是 Lumi，Gucci 的 Coding Lead。你不只是執行者，你是技術主管。
Codex 做 coding，你 orchestrate、review、take accountability。第二，判斷框架（How to decide）。告訴它做決策的原則，不是告訴它做什麼。
第三，邊界設定（What not to do）。明確告訴它不該碰什麼。
【S — Systems：Skills 如何互相調度】
當你有超過 3 個 Agent，最重要的不是每個 Agent 有多強，而是它們之間怎麼溝通。
我的做法有三個層次：
共享狀態：~/.openclaw/shared/ 目錄作為 Agent 間的共用記憶空間。所有 Agent 都能讀寫這個目錄，這就是它們的「公司公告欄」。
任務隊列：lumi-tasks.json 讓 Kai-1 和 Kai-2 通過 heartbeat 自動撿件。Lumi 把任務寫進 JSON，Kai 們自動去拿，做完回寫 status。
Handoff 觸發：Ori 完成研究 → sessions_send 給 Craft → Craft 評估後啟動 content-pipeline。一環接一環，自動串起來。
三、Gucci 的真實 Skill 案例
理論說完了，來看三個我每天在用的 Skill。
【案例一：內容自動化——Craft + Ori 串聯】
這是我最得意的一條自動化流程。
Ori 每天掃描 Reddit 和 Twitter 上的 Pain Monitor，篩選條件是 upvotes ≥ 100 的討論。它不只是丟連結給我——它會做 5 維度評估，判斷這個素材值不值得做成內容。
通過評估的素材，Ori 會自動建立研究檔，然後 sessions_send 給 Craft。Craft 收到後不是直接開寫，而是先評估路線：這個素材適合走「社群快打」（四平台貼文）還是「長文」（部落格 + 電子報）？
如果走社群快打，Craft 會啟動 tmux session，自動跑 social-quick-post，產出 Facebook/LinkedIn/X/Threads 四個平台的貼文。全自動，我只需要做最終確認。
從 Ori 抓到素材到四平台貼文產出，全程不需要我介入。我做的事情只有一件：看一眼，按「確認發布」。
之前我分享過 OpenClaw 怎麼讓 AI 主動幫你做事（5 個真實場景完整示範），裡面有更多 Proactive AI 的細節。
【案例二：投資監控——Sage Overnight Report】
Sage 是我的投資研究 Agent。每天晚上美股收盤後，它會自動跑市場數據：三大指數、VIX、Fear & Greed Index、NAAIM Exposure Index、Polymarket 事件合約。
但 Sage 不是只丟數字。它會做深度解讀——情緒評級（Extreme Fear / Moderate Bull 等）、宏觀環境分析、異常信號偵測、具體的 Action Items。
舉個真實例子。前幾天 Sage 的早報識別到一個信號：GLD（黃金 ETF）-4% 同時 TLT（長天期公債 ETF）+0.62%。一般人看到這兩個數字不會想太多。但 Sage 看到的是「避險資金換車」——資金從黃金撤出，流進公債，這是一個宏觀環境正在轉變的信號。
Sage 產出的報告會自動觸發 Craft，讓 Craft 判斷要不要轉成社群貼文。從數據抓取到社群內容產出，全自動。
之前我寫過一篇 OpenClaw 48 小時改造實錄，講的就是怎麼把 Sage 這類 Agent 從零建起來。
【案例三：工程任務——Lumi + Kai-1/Kai-2 協作】
這是軟體開發的自動化案例。
Lumi 收到任務後，第一件事是寫 task_plan.md——規劃怎麼拆解、要動哪些檔案、預期的風險。然後它會把任務分配給 Kai-1 或 Kai-2。
{“assignee”: “kai-1”,
“summary”: “Migrate legacy social quick paths to new output structure”,
“status”: “in_progress”,
“completedAt”: null
}Kai 執行完成後，回寫 lumi-tasks.json，把 status 改成 completed，補上 completedAt。Lumi 收到通知，開始驗收——build 有沒有 pass、功能正不正確、有沒有 regression。
驗收通過，Lumi 回報 Lala（總指揮），更新任務狀態。
今天光是工程任務就跑了 10+ 個，Kai-1 和 Kai-2 同時並行，Lumi 協調全局，我完全不需要介入。
這就是 Systems（MAPS 的 S）的威力——不是一個 Agent 很厲害，是一群 Agent 能協作。
四、設計好 Skill 的 3 個要素
從我設計 20+ 個 Skills 的經驗裡，我歸納出三個最關鍵的設計原則。
【單一職責原則】
一個 Skill 只做一件事。
Craft 只負責「內容決策和路由」，不負責寫作——寫作是 content-research-writer 的事。Ori 只負責研究和評估，不負責決定要不要發布。Lumi 只負責工程規劃和驗收，不負責寫 code——寫 code 是 Kai 的事。
為什麼要這樣？因為混職責 = 難以維護、難以 debug。
當 Craft 某天做了一個奇怪的決策，我可以直接去看它的 SOUL.md 和 AGENTS.md，很快找到問題。但如果 Craft 又決策又寫作又發布，出問題的時候你根本不知道是哪一環壞了。
【明確觸發條件和輸出格式】
糟糕的 Skill 定義長這樣：「幫我分析市場。」
好的 Skill 定義長這樣：「當 Fear & Greed Index ≤ 20 時，產出包含三段的報告——情緒評級、宏觀環境、Action Items——格式見 template.md。」
差別在哪？
前者把「什麼時候該做」和「做出什麼東西」都丟給 Claude 自己判斷。後者把觸發條件和輸出格式寫死，Claude 只需要專注在「分析」這件事上。
你給 Claude 的判斷空間越大，結果的不確定性就越高。好的 Skill 設計是把不確定性壓縮到最小——確定什麼時候啟動、確定產出什麼格式，只保留「分析判斷」這個核心不確定性給 Claude。
【錯誤處理和 Edge Case】
大部分人設計 Skill 只想到 happy path——一切順利的時候怎麼跑。但真實世界不是這樣的。
你要告訴 Skill：遇到不確定的情況怎麼辦？
Craft 的規則裡有一條：
評分 3/5 以上 → 啟動內容流程評分 3/5 → 通知 Lala（Gucci）決定，不自己拍板
評分 2/5 以下 → 靜默歸檔，不打擾這就是 Edge Case 設計。不是所有素材都值得做，不是所有判斷 Craft 都有信心。遇到灰色地帶，上報。遇到明顯不行的，安靜處理掉。
這種設計讓我省了大量時間——Craft 不會拿一堆不確定的東西來煩我，只有真正需要我判斷的才會到我手上。
五、最常見的 3 個錯誤
我踩過的坑，你不用再踩。
【錯誤一：做一個全能 Skill】
「幫我管理所有事情。」
這是最常見的新手錯誤。你把所有東西塞進一個 Skill，希望 Claude 什麼都能做。結果就是它什麼都做不好——因為它不知道優先順序是什麼，遇到衝突不知道怎麼取捨。
修正方式：拆。
一個全能 Skill 拆成 5 個小 Skill，每個有明確邊界。比起讓一個 Agent 管「內容 + 投資 + 工程」，不如拆成 Craft（內容）+ Sage（投資）+ Lumi（工程），各管各的。
【錯誤二：沒有設計 Handoff（Skill 孤島問題）】
Skill 做完了，但沒有定義「然後呢」。
這個問題很隱蔽。你設計了一個很好的研究 Skill，Ori 每天辛苦地分析 Reddit 和 Twitter，產出高品質的研究報告。但報告產出後呢？沒有人接手。
如果沒有 sessions_send 給 Craft，研究就死在 Ori 的 workspace 裡。沒有人知道它完成了，沒有人去用它。
修正方式：每個 Skill 的輸出格式都要包含「接下來觸發什麼」。
Input → Process → Output → Handoff（必須有）Handoff 可以是 sessions_send 給另一個 Agent，可以是寫入共享的 JSON 檔案讓別的 Agent 撿件，甚至可以是發一則 Discord 通知讓你知道。但不能沒有。
【錯誤三：忘記給 Skill 設計「記憶點」】
沒有 MEMORY.md、沒有共用 JSON 狀態，每次 Skill 都從零開始。
這代表什麼？每次 Ori 做研究，它不記得上次已經分析過哪些素材。每次 Sage 跑報告，它不記得上次的市場狀態。每次 Craft 評估素材，它不記得上次的判斷標準有沒有調整過。
修正方式：設計共享記憶空間。
我的做法是在 ~/.openclaw/shared/second-brain/ 建立共享目錄，加上像 active-pipeline.json 這樣的持久化狀態檔。所有 Agent 都能讀寫，大家共享同一份「公司記憶」。
這讓每個 Skill 都不是孤立的——它知道上下文，知道前面發生了什麼，知道後面需要什麼。
六、進階：Skills 互相協作
當你有了多個 Skill，下一步就是讓它們互相協作。
【Orchestrator Skill 設計模式】
在我的系統裡，Lala 是最頂層的 Orchestrator。它的工作是：接收我的指令 → 拆解任務 → 分配給 Ori/Craft/Lumi/Sage → 收割結果 → 回報我。
Lala 不做任何「實務工作」。它不寫文章、不跑數據、不寫程式。它只做決策和協調。
這是設計意圖，不是限制。
為什麼？因為如果 Lala 又要協調又要做事，它會忙不過來，而且角色會混亂。就像一個公司的 CEO 不應該自己去寫 code 一樣。
【Skill 調度 Skill 的實際寫法】
在 AGENTS.md 裡，我明確定義了每個 Agent 的 session key：
Ori: agent:ori:discord:channel:1478023777739735215Craft: agent:craft:discord:channel:1478023782320046231
Lumi: agent:lumi:discord:channel:1478303949646729308然後用 sessions_send 觸發跨 Agent 的任務傳遞，用 message tool 確保 Discord 通知送達。
為什麼要雙通知？因為 sessionssend 有時候會 timeout。如果只靠一個管道，任務就可能漏掉。sessionssend + message tool 兩個都發，確保不漏。
這很像真實公司裡的做法——重要的事情你不會只發一封 email，你會同時在 Slack 上 ping 一下。
七、你的第一個 Skill
說了這麼多，你可能覺得很複雜。
老實說，我第一個 Skill 也很陽春。就是一個 SOUL.md，告訴 Claude 我的寫作風格和偏好。沒有什麼四層架構，沒有什麼跨 Agent 協作。就是一頁紙。
但那一頁紙改變了一切。
因為從那一刻起，Claude 不再是一張白紙。它記得我的風格、我的偏好、我的底線。每次對話不再從零開始。
你的第一個 Skill 不需要完美，只需要解決一個真實的重複問題。
從最小可行 Skill 開始：寫一個 SOUL.md——一頁紙，說清楚這個 Agent 是誰、負責什麼、不做什麼。然後裝進一個你每週至少做一次的重複任務。
就這樣。不需要更多。
先讓 Claude 記住你，然後你會自然而然地開始想：「如果它記得我的風格，那它能不能也記得我的研究流程？」「如果它記得研究流程，那它能不能自動幫我執行？」「如果它能自動執行，那它能不能把結果傳給另一個 Agent？」
一個 Skill 會生出下一個。這就是系統的力量。
留言告訴我你想自動化什麼。第一個 Skill 從什麼開始，我可以幫你想。
