我把一條內容生產線，寫成了一個 skill：給 AI 一張食譜卡，從此不必每次重打提示
▲ 一個構想，怎麼變成一個會動、而且每次都能動的 skill？我把這條思路拆解給你看。
前陣子在一場專門為創作者所開設的工作坊，一位學員趁中場休息走過來，有點不好意思地問：「老師，我每次叫 AI 幫忙寫東西，都得重打一大段提示——從研究方向、語氣到格式等等，每次都從頭來一遍。有沒有辦法只下一個指令，它就懂我要什麼？」
我笑了，並不是因為這個問題很基本，而是這個問題太棒了！因為這正是我半年前開發 content-pipeline 這個技能（skill）的理由。如果你想先理解我為什麼主張把 AI 從問答工具升級成一套產製系統，可以回頭讀這篇前傳：AI 時代真正拉開差距的，從來不是一問一答，而是建立內容產製系統。
我笑著告訴他，這是可行的，而且方法比你想的更平易近人。今天這篇文章，我想把這套系統的設計邏輯拆解給你看。我不打算說太多技術的東西，只想講清楚一件事：一個構想，怎麼變成一個會動、而且每次都能動的 skill。
先說清楚：skill 到底是什麼
打個比方，你可以把 skill 想像成一張食譜卡。
▲ skill 就是給 AI 的一張食譜卡：把你會重複做的流程封裝起來，需要時直接拿出來照著做。
舉例來說，你會煮紅燒肉，但你可能不會希望每次下廚都得從零回想：先汆燙、再炒糖色、火候幾分⋯⋯如果你抽空把它寫成一張卡片，以後有需要的時候再拿出來照著做就好。更棒的是，這張卡片還能交給別人執行。
是的，skill 就是給 AI 的食譜卡。說穿了，它把一段你會重複做的流程、或一套你腦中的專業判斷，封裝成可以被呼叫、被組合的單元。你不必每次重打那一大段提示，因為提示已經寫進卡片裡了。
在 Claude Code 裡，這種封裝有四種形式，定位各不相同：
- Command（放在 ~/.claude/commands/）：一支用 /指令 主動觸發的劇本。/content-pipeline 本身就是。
- Skill（一份 SKILL.md 配上開頭的描述）：能被 AI 自動發現、在對的時機自動載入的能力包。
- Subagent：有獨立工作脈絡的代理，適合並行或專責的任務。
- Hook：綁在事件上的自動動作，例如每次存檔後自動檢查錯字。
這四種我都用，但今天的主角 /content-pipeline 是第一種，也可視為是一支劇本。它的劇情，是一條六站的生產線。
這條生產線長什麼樣子
靈感捕捉 → 深度研究 → 文章撰寫 → 內容精修 → 多平臺分發 → 多語翻譯
[1] [2] [3] [4] [5] [6]
▲ 你餵進一個主題，它領著你一站一站走，每一站之間都有一個檢查點。
你餵進一個主題，它領著你一站一站走，每一站之間都有一個檢查點：做完停下來，把成果攤開給你看，問你要不要調整、能不能往下走。你點頭，它才前進。
這裡有一個關鍵的技術設計，值得說一下：這六站不是寫在同一支程式裡的六段程式碼，而是六個各自獨立的子 skill，被這支劇本串起來。（如果你想看這條生產線實際跑起來的樣子，我把整個流程錄在這篇：當 AI 不只幫你寫，還幫你研究、排版和發布：我用 Claude Code 打造的內容生產線。）
靈感捕捉是 idea-capture，深度研究是 deep-researcher，撰寫是 article-writer，精修是 content-refiner，分發是 content-distributor。/content-pipeline 自己一個字都不寫，它只負責編排——像一位餐廳的出菜總管，自己不炒菜，但決定誰先上、誰後上、哪一道要退回重做。
這在工程上叫關注點分離（Separation of concerns，SoC）。好處有兩個：每個子 skill 單一職責、好維護；而且哪天我把精修的演算法升級了，整條線立刻受惠，不必動到其他五站的程式架構。
重點來了：怎麼把一個構想變成 skill
假設你也想做一條自己的生產線，從零開始，大概可參考以下這三個步驟。
▲ 收斂流程、寫好描述、把規矩寫死進去——三步，把一個構想變成會動的 skill。
第一步：把模糊的構想，收斂成一個可重複的流程
原始的構想，通常長這樣：「我希望 AI 幫我把寫文章這件事變簡單。」不過，如果你真的這樣說，可能對 AI 來說會有點難以理解，做不成 skill。
所以，你得先問自己：這件事，我每次都會經過哪些固定步驟？把它列出來。我列出來，就是那六站。一旦流程清楚，skill 的骨架就有了。老實說，skill 不是憑空發明的，而是把你早就在重複做的事寫下來而已。這也呼應我一直強調的觀念：活用 AI 的起點不是挑工具，而是拆解工作流程。
第二步：寫好那段描述，這是整個 skill 的命脈
每個 skill 開頭都有一段描述（description）。很多人隨手寫，但這其實是最該斟酌的一行字。
為什麼？因為這段描述，是 AI 判斷「現在該不該把這個 skill 叫出來」的唯一依據。寫得模糊，它要嘛永遠召不到，要嘛在錯的時機亂入。
但凡一段好的描述，通常需要回答三件事：做什麼、何時用、使用者講什麼話會觸發？我給 /content-pipeline 寫的描述是：「一鍵啟動完整內容生產流程，從靈感到多平臺分發。當使用者想要一次跑完所有步驟、或提到 pipeline 時觸發。」你看——功能、時機、觸發詞，三件都在。
第三步：寫劇本，把規矩寫死進去
剩下的就是正文，也就是這支 skill 的劇本：角色設定、流程步驟、每一站的檢查點、輸出存到哪、格式長怎樣，還有約束。
對了，約束尤其重要。我在 /content-pipeline 裡寫死了兩條：等待使用者確認時，不要自動進入下一階段；所有輸出一律繁體中文。把規矩寫進 skill，而不是每次靠自己記得，這是品質能穩定的關鍵。畢竟人會忘，文件不會。
▲ 如果這類「把工作流變成系統」的拆解對你有用，歡迎訂閱 Vista AI 靈感補給站——我會定期把實測過的 AI 工具、流程與思考，第一手分享給你。
更難的一關：怎麼確保 skill 真的會動
寫出來還不夠，這只做了一半。老實說，之前我曾吃過暗虧。
還記得有一次我想在演講做即時示範，投影片上寫了一個我以為早就做好的功能。上臺前一晚隨手測試一遍，才發現那功能根本只活在投影片上，實際的 skill 裡是空的。嗯，還好發現得早，那一晚我還來得及補救。
▲ 可觸發、輸出契約對齊、可恢復、試跑驗證、失敗要紀錄——五條紀律，確保 skill 不是空殼。
從那之後，我給自己立了五條紀律，確保 skill 不是空殼：
- 可觸發：寫完先測一句話。我會故意用一句自然的講法，看這個 skill 會不會被正確叫出來。叫不出來，就回去改描述。
- 輸出契約對齊：每一站要講清楚成果存去哪、檔名怎麼取、格式長怎樣。這是生產線能成立的前提——上一站的產出，要剛好是下一站接得住的輸入。介面對不上，管線就斷了。
- 可恢復：每一站的成果都即時落地存檔，種子卡片、研究摘要、初稿各有其位。所以你跑到一半說「先到這，晚點再繼續」，明天回來從第四站接著跑，前面一個都不會掉。人生不會給你三小時不被打擾，工具得扛得住中斷。
- 試跑驗證：上線前、上臺前，實際走一遍。逐個確認——檢查點真的會停嗎？檔案真的生出來了嗎？路徑真的對嗎？別相信「應該會動」，要親眼看到它動。
- 失敗要紀錄：萬一某一站出錯，要記下我期望發生什麼、對照實際發生什麼，而不是默默重試。畢竟那些靜默的失敗，往往是代價最昂貴的失敗。
導入前 vs 導入後
▲ 把流程寫成 skill 之後，啟動成本、中斷、品質、升級這四件事都換了一個樣子。
| 導入前 | 導入後 | |
|---|---|---|
| 啟動成本 | 每次重打一大段提示 | 一個指令，主題餵進去 |
| 中斷 | 斷了就得重來 | 成果落地，隨時續跑 |
| 品質 | 靠當下記得多少規矩 | 規矩寫死在 skill 裡 |
| 升級 | 改一處要動全部 | 換零件，整線受惠 |
最後
回到工作坊那位學員的問題。他要的其實不是一個更聰明的提示，而是一個不必每次重來的系統。
skill 給你的，就是這個。它讓你把那些會重複、會疲乏、容易半途而廢的環節交出去，自己回到最該待的位置：那個下判斷、給靈魂的人。這也是我心目中理想的內容飛輪該有的樣子——靈感不枯竭，發布不費力。
如果你也想開始，我的建議很簡單：挑一件你這週重複做了三次以上的事，把步驟寫下來，給它一段清楚的描述，然後試跑一遍。你的第一個 skill，就誕生了。
是的，現在就開始。如果你想要有人帶著你，把屬於自己的內容生產線一站一站親手搭起來，歡迎報名我的線上課程——我會把這篇文章講的設計邏輯，變成你帶得走的實作能力。
親愛的朋友，讓我們在課堂上見。
📖 深入探索相關主題
