TL;DR
學會用 Agent Skill 流水線自動化你的重複工作流——本文完整分享從 1 個 Skill 演化到 8 個的過程、模型選擇策略（Opus vs Sonnet），以及如何用一個橋接 Skill 串起整條流水線。
這篇文章適合：
- 已經在用 AI Coding 工具，每次都要重新貼一堆 prompt 覺得很煩的人
- 想把零散的 AI 指令系統化，打造自己專屬工作流的開發者
- 讀過 上一篇 Agent Skill 機制比較，想看實際應用的人
前言：一切從「每次都要重新教 AI」開始
上一篇文章我們比較了 Claude Code、Cursor、Antigravity 三家的 Agent Skill 機制。如果你還沒讀過，建議先看 那篇——了解機制本身，再回來看實戰會更有感覺。
這篇要聊的是：知道 Skill 能做什麼之後，實際上我怎麼用它？
故事的起點很單純。我用 Claude Code（Anthropic 推出的 AI Coding 工具）寫部落格文章，每次都要跟 AI 講同一套流程：「先幫我擬大綱、然後檢查術語、再潤色文字、最後做 SEO……」。講了十幾遍之後，我開始想——這些步驟每次都一樣，為什麼不寫成 Skill？
結果一寫就停不下來。從 1 個 Skill 變成 3 個，再變成 8 個，最後還加了一個「橋接 Skill」把整條流水線串起來。現在我寫一篇文章，只要打一個指令 /blog-intake，AI 就會自動跑完收斂、大綱、審查、潤色、SEO、入庫的全流程。
這篇文章會完整分享這個演化過程——不是教你照搬我的設定，而是分享我在設計 Skill 時踩過的坑和做過的取捨。希望能給你一些靈感，設計出屬於你自己的 Skill 工作流。
為什麼需要流水線？一個 Skill 不夠嗎？
把一個大型 Skill 拆分為多個小型 Skill 組成流水線，是解決 context window 溢出、角色衝突、無法中途介入三大問題的有效方法。 以下是我的親身經歷。
一開始我確實只有一個 Skill：一個超長的 blog-writer.md，把所有指令塞在一起——怎麼寫大綱、怎麼潤色、SEO 怎麼做、文字風格怎麼統一。
問題很快就來了。
第一個問題：Context Window 爆炸
一個 Skill 裡面塞了 3,000 字的指令，AI 光讀完規則就用掉一大塊記憶空間（context window 是 AI 一次能記住的內容上限）。加上文章本身的內容，到了後面的步驟，AI 已經記不住前面的指令了——你明明寫了「中英文之間要加空格」，它到第五段就忘了。
第二個問題：角色衝突
「審查術語是否解釋清楚」和「精簡冗長句子」這兩件事，放在同一個角色身上會打架。審查員覺得應該多解釋，編輯覺得應該精簡。寫在一起，AI 會在兩個指令之間搖擺不定。
第三個問題：無法中途介入
一口氣做完所有步驟，中間沒辦法暫停。如果大綱的方向就不對，後面的潤色和 SEO 全部白做——你只能砍掉重來。
所以我開始拆分。每個步驟獨立成一個 Skill，各自有明確的職責、獨立的記憶空間、可以單獨執行。
這就是專業分工的道理——不是讓一個全能的人從頭做到尾，而是讓編輯管文字、SEO 專家管關鍵詞、審查員管可讀性。AI 也是一樣的邏輯。
8 個角色是怎麼決定的？
Blog 編輯流水線需要哪些角色？ 經過多次迭代，我的流水線收斂為 8 個 Skill，每個負責一個獨立的編輯環節：
| 順序 | Skill | 角色 | 做什麼 |
|---|---|---|---|
| 1 | /blog-outline-architect |
大綱架構師 | 將靈感收斂為文章骨架 |
| 2 | /blog-pitfall-recorder |
踩坑記錄員 | 補充技術坑點（僅技術文） |
| 3 | /blog-beginner-reviewer |
小白審查員 | 用初學者視角找出看不懂的地方 |
| 4 | /blog-visual-advisor |
視覺顧問 | 建議圖片、表格、callout 的位置 |
| 5 | /blog-professional-editor |
專業編輯 | 文字潤色、用詞統一、排版規範 |
| 6 | /blog-seo-specialist |
SEO 專家 | 標題、關鍵詞、meta description、內鏈 |
| 7 | /blog-ai-quoter |
AI 引用優化師 | 讓文章更容易被 AI 搜尋引擎引用 |
| 8 | /blog-engagement-designer |
互動設計師 | CTA、思考題、社群分享文案 |
演化軌跡：從 3 個到 8 個
這不是一次設計出來的，是一步步長出來的。
v1.0：最早只有 3 個 — 大綱、編輯、SEO
v1.1：+ 小白審查員 — 發現編輯潤色完的文章，常常有術語沒解釋、邏輯跳太快的問題。編輯的職責是「改文字」，不是「檢查讀者能不能看懂」。於是加了「小白審查員」，專門用初學者視角找問題。
v1.2：+ AI 引用優化師 — SEO 優化只管搜尋引擎排名，但 2026 年流量有一大塊來自 AI 搜尋（Grok、ChatGPT 搜尋、Perplexity）。這些 AI 引用文章的邏輯跟 Google 不一樣——它們喜歡結構化的問答格式、明確的定義句型、TL;DR 摘要。
v1.3：+ 視覺顧問 — 我寫文章常常忘記配圖。文字寫完了，通篇沒有任何視覺元素。視覺顧問會告訴我哪裡適合加截圖、哪裡適合用表格取代文字敘述。
v1.4：+ 互動設計師 — 文章寫得再好，如果結尾只是「希望這篇文章對你有幫助」，讀者看完就關掉了。互動設計師負責設計 CTA（Call-to-Action，行動呼籲）、思考題、社群分享文案——讓文章不只被閱讀，還能產生互動。
「踩坑記錄員」有個特別的設定：它只在技術類文章啟動。 如果是觀點文或趨勢分析，流水線會自動跳過這一步。不是所有 Skill 都要每次都用。
想一想：回顧你最近一個月跟 AI 的對話，哪些指令是你重複貼了 3 次以上的？這些指令適合做成 Skill 嗎？
模型怎麼選？
Agent Skill 的模型該怎麼選？ 每個 Skill 的 model 欄位可以指定使用的 AI 模型。
補充說明：Opus、Sonnet、Haiku 是 Claude AI 的三種模型，從大到小、從強到快、從貴到便宜。
| 模型 | 成本 | 適合的任務 | 我用在哪些 Skill |
|---|---|---|---|
| Opus | 最高 | 需要深度思考、創意的任務 | 大綱架構師、AI 引用優化師 |
| Sonnet | 中等 | 平衡速度與品質 | 編輯、SEO、互動設計、踩坑記錄員、視覺顧問、小白審查員 |
原則：需要「從零創造」的用 Opus，需要「檢查改善」的用 Sonnet。
大綱架構師要從零開始建立文章結構，這需要創意和全局思考能力——用 Opus。踩坑記錄員逐段掃描有沒有技術錯誤，是相對明確的檢查任務——用 Sonnet 就夠了。
這也是 Agent Skill 的一個重要優勢：你可以在不同步驟使用不同模型，在品質和成本之間取得最佳平衡。如果全部用 Opus 跑完 8 個 Skill，一篇文章的費用會非常可觀。
動手試試：如果你有在用 Claude Code，打開你現有的 Skill，看看 frontmatter 有沒有設定
model欄位。試著把一個需要深度思考的 Skill 改成model: opus，看看效果有什麼不同。
兩種使用方式
設計好 Skill 之後，實際使用有兩種方式。
方式一：逐個呼叫
最直覺的用法——在 Claude Code 的對話中依序輸入指令：
/blog-outline-architect 主題：如何使用 Agent Skill等大綱產出，確認方向沒問題後，再輸入：
/blog-beginner-reviewer以此類推，一步一步走完流水線。
好處： 每一步都可以介入。大綱不對？改完再往下走。小白審查員說某段看不懂？先補充說明再交給編輯潤色。
壞處： 要記住流水線的順序，每次都要手動輸入 8 個指令。
方式二：Skill 管理頁面一鍵複製
我做了一個 Skill 管理頁面，把所有 Skill 按分類顯示出來。每個 Skill 旁邊顯示指令名稱和說明，點一下就複製到剪貼簿——貼進 Claude Code 按 Enter 就執行。
流水線的順序也直接畫在頁面上：
blog-intake → outline → pitfall → beginner → visual → editor → seo → ai-quoter → engagement → Insforge DB這樣我不用記順序，看著頁面依序點擊就好。
你會怎麼用？ 你比較喜歡逐個手動呼叫（可介入調整），還是一鍵跑完流水線（省時間）？或是有第三種方式？
`/blog-intake`：一個指令串起整條流水線
/blog-intake 是一個橋接 Skill（Bridge Skill），負責將非結構化的對話內容收斂為文章素材，並自動啟動 8 步編輯流水線。 它解決了手動整理素材的痛點。
手動逐個呼叫雖然靈活，但有個痛點：每次都要從「把討論整理成素材」開始。你跟 AI 討論了半小時的文章方向、核心觀點、案例故事——這些對話散落在聊天記錄裡，要手動整理成文章素材再餵給大綱架構師。這一步很麻煩。於是我做了一個橋接 Skill 來自動化這件事。
/blog-intake 的職責分三個階段：
階段一：收斂討論 — 自動從當前對話中擷取所有與文章相關的素材——核心觀點、技術細節、案例故事。過濾掉除錯過程、重複討論等雜訊，整理成結構化的「文章素材包」（主題、文章類型、目標讀者、核心觀點、語調）。
階段二：啟動流水線 — 確認素材後，自動依序呼叫 8 個 Skill。每完成一個，整合建議到文章中，再進入下一個。
階段三：寫入資料庫 — 流水線跑完，自動把成品以「草稿」狀態寫入我的 Blog 後台資料庫（Insforge）。我只需要到後台預覽、微調，然後按「發布」。
整個流程從「討論→收斂→8 步流水線→入庫」一氣呵成。
一個指令的背後：
用戶：/blog-intake
↓
收斂對話 → 產出素材包
↓
/blog-outline-architect → 大綱
↓
/blog-pitfall-recorder → 技術坑點（可跳過）
↓
/blog-beginner-reviewer → 可讀性審查
↓
/blog-visual-advisor → 視覺建議
↓
/blog-professional-editor → 文字潤色
↓
/blog-seo-specialist → SEO 優化
↓
/blog-ai-quoter → AI 引用優化
↓
/blog-engagement-designer → 互動設計
↓
自動寫入 Insforge 資料庫（草稿狀態）實戰建議： 目前我更常用的還是逐個呼叫。因為每一步的產出品質不一定完美，我會想在中間介入調整。
/blog-intake更適合主題已經很明確、不需要太多人工介入的情境——比如你已經有完整的素材，只需要 AI 幫你走完編輯流程。
讓 Skill 管理也變成自動化
Skill 數量變多後怎麼管理分類？ 答案是讓 Skill 自己管理自己——把分類資訊寫在 SKILL.md 的 frontmatter 裡，讓系統動態讀取，而非在前端程式碼中硬編碼（直接寫死在程式碼裡）。
Skill 從 3 個變成 8 個再變成 18 個（包含部署、程式碼品質、知識載入等其他類別），管理就成了問題。
一開始我在 Skill 管理頁面裡用硬編碼管理分類——每個 Skill 屬於哪個分類，寫死在前端程式碼裡：
硬編碼版本（已棄用）
const SKILL_CATEGORIES = {
'部署流程': ['ship', 'zeabur-setup', 'zeabur-debug'],
'程式碼品質': ['audit', 'code-health', 'security-review', 'refactor'],
'Blog 編輯流水線': ['blog-intake', 'blog-outline-architect', ...],
};問題很明顯：每次新增或刪除 Skill，都要同時改前端的分類列表。忘了改就會漏掉，改錯了 Skill 就會出現在錯誤的分類裡。
解法是把分類資訊放進 SKILL.md 的 frontmatter（一種用 --- 包起來的設定格式）：
---
model: opus
category: Blog 編輯流水線
---然後讓 API 動態讀取 category 欄位，前端根據 API 回傳的分類自動分組。Skill 自己知道自己屬於哪個分類——你新增一個 Skill 只要在 frontmatter 寫上 category，頁面就自動歸類，不用改任何前端程式碼。
動態版本
function groupSkills(skills: SkillInfo[]) {
const groups: Record = {};
for (const skill of skills) {
const category = skill.category || '其他';
if (!groups[category]) groups[category] = [];
groups[category].push(skill);
}
return groups;
}這件事本身也是 Skill 哲學的一部分：讓資訊住在離它最近的地方。 分類資訊跟 Skill 內容放在一起，不分散到其他檔案裡——這樣維護的心智負擔最低。
小練習：如果你有多個 Skill，試著在每個 SKILL.md 的 frontmatter 加上
category欄位，看看能不能用程式自動分組（不用改前端程式碼）。
結語：Skill 是活的，會跟你一起成長
回頭看這段過程，最大的感受是：Skill 不是一次設計好的系統，而是跟你的工作流一起演化的有機體。
一開始只有一個笨重的 blog-writer.md，拆成 3 個之後發現還不夠，再拆成 8 個。中間加了橋接 Skill 串流程、加了 frontmatter 分類管理、加了頁面視覺化。每一次迭代都是因為在實際使用中遇到了痛點。
想開始建立自己的 Skill 系統，應該從哪裡開始？ 這 4 點是我實際踩坑後的體悟：
- 從痛點開始 — 你最常重複貼給 AI 的 prompt 是什麼？先把它變成 Skill
- 先做一個，再拆分 — 不要一開始就設計完美架構。用了一段時間之後，你自然會知道哪裡該拆、哪裡該合
- 善用 frontmatter —
model選模型、category分類、description讓 AI 知道什麼時候該用——這些元資料看起來不起眼，但會讓管理變得輕鬆很多 - 保持彈性 — 流水線的每一步不一定要全自動。有時候手動介入、調整方向，反而比一口氣跑完的效果更好
Skill 就像你的個人知識庫——但不是放在那裡積灰塵的那種，而是 AI 每天都在用的活的知識。你投入的每一分鐘設計，都會在未來省下十倍的重複工作。
延伸思考：除了 Blog 編輯，你覺得 Skill 流水線還可以用在什麼場景？（程式碼審查、文件產生、測試自動化...？）
延伸閱讀
如果你對 Agent Skill 和 AI Coding 工具的實踐有興趣，以下文章也值得一看：
- Agent Skill 機制比較：Claude Code vs Cursor vs Antigravity：系列文第一篇，深入比較三家工具的 Skill 機制差異
- 用 Claude Code 的 /ship 指令一鍵部署到 Zeabur：Command 與 Skill 的實戰應用
- 在 Claude Code 中設定 Zeabur MCP：MCP（Model Context Protocol）與 Skill 機制的互補應用
- Vibe Coding 好像很危險，該如何上手？：AI Coding 的上手心法與常見迷思
- AI 寫程式的趨勢與機會：從趨勢分析看 AI Coding 的發展方向
你也有自己的 Skill 設計嗎？或是用不同的方式組織 AI 工作流？歡迎在留言區分享你的設計——說不定你的做法能啟發其他讀者，也能讓我知道 Skill 還可以怎麼用。
