Claude Code skill 教學：把手動品管檢查變成 AI 自動驗證關卡，四種部署模式怎麼選

我每次叫 AI 幫我寫完一段商品描述，都會反射性再補一句：「退換貨規則有沒有寫錯？成分有沒有偷偷加了療效字眼？最低價這種字能不能寫？」

問到第五次，我才愣住。

這句話，我為什麼不寫下來，讓它每次自己跑？

上一篇我寫過〈用 AI 的高手不寫更長的 prompt，他們設計「驗收迴圈」〉，那篇講的是心法：為什麼你該讓 AI 檢查自己的工作，而不是拼命把 prompt（指令）寫更長。今天這篇不一樣，今天講的是實作。那個迴圈，具體怎麼變成一個 AI 每次都會自己跑的 Claude Code skill（Claude Code 的技能包）。

心法看那篇，怎麼做看這篇。

素材來自 Anthropic 官方部落格〈Building verification loops in Claude Code with skills〉，作者是 Claude Code 團隊的 Delba de Oliveira。我把裡面對工程師講的東西，翻成給電商經營者聽的話。

先講白：什麼是 verification loop（驗證迴圈）？

一句話：verification loop（驗證迴圈）就是 AI 做完事之後，自己跑一輪檢查、抓到問題就自己修，修好再往下走的循環。

Claude Code（Anthropic 的 AI 寫程式命令列工具）本來就會做一部分。你的程式碼裡有型別檢查、有測試、跑起來會報錯，這些「機器看得懂的訊號」它自己會讀、會據此修正。

問題是，剩下那一堆「機器看不懂、只能靠人肉檢查」的部分呢？

那就是每次你都得手動盯的地方。而這篇文章的重點，就是把這些手動步驟，變成 AI 自己會跑的關卡。

Anthropic 內建了哪些驗證迴圈？

在你自己動手寫之前，先看 Claude Code 已經內建了哪幾種。Anthropic 官方列了六種，我照原文標清楚哪些還在測試階段，你別把它們當正式功能用：

Toolchain 這個有一個超實用的小撇步：把你專案「確切的 build 指令、測試指令」直接寫進 CLAUDE.md（專案的設定說明檔），Claude 就不用每次猜，直接照跑。

但你注意到沒有？這六種再厲害，也只涵蓋「機器本來就看得懂」的那一半。

真正該被收編的，是另一半：你每天靠腦袋記得、靠資深員工盯著的那些手動檢查。

把一個手動檢查，寫成一個 skill

這就進到 agent skill 怎麼寫、skill.md 怎麼寫 這種你可能 Google 過的問題了。

Anthropic 給了兩條路。

第一條，最快：裝 skill-creator（技能產生器）這個外掛，讓 Claude 反過來訪談你。你只要打一句話：

/skill-creator 幫我做一個「上架前商品頁合規檢查」的 skill，訪談我的流程。

它會一路問你：你都檢查什麼？哪些字不能出現？漏了會怎樣？你把腦袋裡那份沒寫下來的清單講給它聽，它幫你整理成 skill。

第二條，手寫：在專案裡的 .claude/skills/<名字>/SKILL.md 丟一個 markdown 檔。最陽春的驗證 skill 就是幾行 frontmatter（前置設定）加一段 body（正文）：

---
name: verify-copy-compliance
description: 檢查商品文案是否違反合規規則。當文案要上架前使用。
allowed-tools: [Read, Edit, Grep]
---
讀取這次要上架的文案。
逐條確認：沒有宣稱療效字眼、沒有「最低價／第一」等比較性用語、
退換貨與七天鑑賞期措辭與公司標準一致。
每抓到一處違規，回報 檔案:行號，然後直接改掉。

看到 description 那行沒有？它就是在告訴 Claude「什麼時候該把這個檢查叫出來」。body 就是你交代它「怎麼查」。

這裡有一個原文的 Pro tip，我覺得對做電商的人最有感：

規則型、死板的檢查，一樣算。

原文舉的例子是工程的：「拒絕任何刪掉資料庫欄位、卻沒有做資料回填的 migration」。這種規則，通用的 linter（程式碼檢查工具）抓不到，因為它是你這個專案才在乎的事。

翻成電商語言就是：「檔期文案不得宣稱療效、不得寫最低價」這種只有你們公司、你們這個產業才在乎的合規規則，市面上沒有任何通用工具會幫你抓。這種「別人抓不到、只有你在乎」的檢查，才最值得寫成 skill。

那為什麼要寫成 skill，不直接塞進 prompt 就好？

因為 skill 是「漸進式載入」的（progressive disclosure）。平常它只佔幾個字的空間，Claude 知道有這個東西存在；真的用到才把完整內容讀進來。這代表兩件事：一，不佔你的 context（上下文）額度；二，每一次新對話它都自動在場，不靠任何人記得去貼。

想更完整理解 skill 這套機制，可以看我另一篇〈Agent Skills 是什麼？把團隊 SOP 變 AI 技能包〉，這篇就不重講基礎了。

四種部署模式怎麼選？這才是真正的分水嶺

好，假設你已經會寫一個檢查 skill 了。

先別急著開心。因為「寫得出檢查」只是入場券。

真正拉開差距的，是下一個決定：這個檢查，要在哪裡自動觸發？

Anthropic 給了四種部署模式，我做成一張表你先看全貌，再一個一個拆：

Standalone：手動叫用

你想到了、才把它叫出來。

適合那種「跨很多流程、但不是每次都要跑」的檢查。比如上架前的一次性合規總檢、每季做一次的 SEO 稽核、網站無障礙檢查。這種你不會希望它每改一個字就跳出來煩你。

它的代價是：每次都得你自己記得叫。

升級訊號很明確：如果你發現自己「每次改完都在手動叫同一個檢查」，那它已經不該是 standalone 了。該把它綁死。

Embedded：綁在產出流程的尾巴

這一階，是把檢查直接接在「產出用的 skill」屁股後面，讓那條流程自己跑完就自己檢查，不用你開口。

想像一下，你有一個「產生商品頁文案」的 skill。你在它的正文最後加一句：文案產完，立刻跑一次合規檢查，有問題先修好再回報。

從此，只要有人用這個 skill 生文案，合規檢查就自動在後面等著。這就像餐廳的出餐口。

以前是老師傅站在那，每一盤菜出去前用眼睛掃一遍。現在這道檢查變成產線上固定的一關，菜不過關就退回去，不靠老師傅今天有沒有精神。

但 embedded 有個限制你要記住：你只能改「你自己能編輯的 skill」。 內建的、外掛管理的 skill（那種一更新就被覆蓋的），你動不了它的內容。那些怎麼辦？看下一階。

還有，跨流程的檢查別 embed。合規總檢這種很多地方都要用的，你 embed 進其中一條流程，其他地方就叫不到了。那種留給 standalone。

Chained：串成一條龍

一個 skill 跑完，自己去叫下一個。好幾個檢查串成一條線，一路跑到底。

Anthropic 自己的 Claude Code 團隊每天就這樣用：/code-review（找 bug）跑完接 /simplify（精簡程式碼），再接 /verify（確認整體行為正常），如果這次動到了畫面，最後再接一個自訂的 /design 去對照 DESIGN.md（設計規範文件）。

翻成電商版，你完全可以串：文案草稿 → 合規檢查 → SEO 檢查 →（如果這次有改到價格）比價與庫存核對。一條龍跑完，你才需要看結果。

這一階最漂亮的地方，是它讓「習慣」變成「契約」。

以前是「我每次都記得在 A 之後跑 B」。現在是「A 跑完，它自己一定會跑 B」。差別在於，前者靠你的記性，後者靠系統。

不過有兩個雷要先講。第一，串鏈會增加 token（運算計費單位）花費，一次跑一整串當然比較貴，所以先小範圍測，別一口氣全串上去。這點我在〈為什麼你的 Agent Skills 越加越多、AI 卻越不聽話〉裡講過，skill 不是越多越好，串鏈也一樣，要克制。第二，剛剛說內建 skill 你改不動對吧？chained 就是解法：你做一個「外包裝」skill，讓它先叫那個改不動的原始 skill，跑完再叫你自己的驗證 skill。改不動的東西，用外面包一層的方式補上檢查。

On every PR：從個人習慣，變成公司制度

最後一階，也是格局最大的一階。

當你這條鏈在自己身上跑順了，就可以把它搬到「每次上架、每次改動都自動跑」。這代表什麼？代表不只你的東西要過這關，你同事的東西、外包的東西、任何人的改動，通通得過同一道關卡，不管他今天有沒有記得。

這就是 Anthropic 說的，驗證從「個人的基礎設施」變成「團隊的基礎設施」。

你當初只是為了省自己每次兩分鐘寫下的一個檢查，現在幫全公司每一次改動都省下那兩分鐘。

這種「讓一套關卡自動守著所有人的產出」的思路，其實就是 Agent 管 Agent 的雛形。我在〈Cursor 自我改善飛輪解碼〉裡把這條「內外迴圈、防作弊考核」拆得更細，你這一階想再往深走，可以接著看。

但這一階最需要忍住。鏈還在調整的時候，先別急著上全域關卡。 因為一旦變成全團隊的關卡，你每一次微調，都變成一個全團隊都會被影響、都看得到的事件。等它穩了再上。

看懂這四階沒有？

Standalone → Embedded → Chained → On every PR，這根本不只是四種技術選項。

這是一條路徑：你一個人腦袋裡記得的檢查，怎麼一步步長成全公司每次都自動過的制度。

從今天開始：六步走一遍

Anthropic 原文收尾給了一套流程，我翻成經營者版，你照著走就行：

► 第一：挑出你這週最常重複的那個手動跟進。 就是那個你每次都要多問一句、多檢查一遍的動作。頻率最高的，優先。

► 第二：先試內建的 /verify。 別急著自己造輪子，說不定內建的就夠用。

► 第三：用大白話把這個檢查寫下來。 想像你在交代一個報到第一天的新人，把「要查什麼、什麼算過、什麼算不過」講清楚。寫不出來，就先叫 Claude 給你一版最佳實務，再改成你們公司真正在乎的樣子。

► 第四：交給 skill-creator，或自己手寫丟進 .claude/skills/。 兩條路都行，看你習慣。

► 第五：在下一個新任務上叫用它，確認檢查真的有跑。 沒跑，多半是 description 沒寫清楚它該在什麼時候出場，回去改。

► 第六：試著把它串成一條龍。 等單一檢查穩了，再往 chained、往 on every PR 那個方向走。

如果你問我，這件事的價值到底在哪？

你能寫下來、交給 AI 自己跑的檢查越多，AI 第一次就命中你要的樣子的機率就越高。那些你以前得一次次手動修的小毛病消失了，你的注意力，才終於能留給那些沒有任何 skill 寫得下來的判斷。

那才是只有你能做的事。

常見問題 FAQ

Q1：Claude Code skill 是什麼？怎麼寫一個？

Claude Code skill 是一個放在專案 .claude/skills/ 資料夾裡的技能包，核心是一個 SKILL.md 檔案，裡面用 frontmatter（前置設定，含 name、description、allowed-tools）告訴 AI「什麼時候用」，用正文告訴它「怎麼做」。最快的寫法是裝 skill-creator 外掛讓 Claude 訪談你，最陽春的寫法是手寫幾行 markdown。

Q2：什麼是 verification loop（驗證迴圈）？

verification loop 是 AI 做完事後自己跑檢查、抓到問題自己修、修好再往下走的循環。在 Claude Code 裡，它可以被包成 skill，讓每一次對話都自動套用同一套檢查，不用靠人記得。

Q3：Standalone、embedded、chained、每個 PR，四種部署模式怎麼選？

看這個檢查「該在哪裡自動觸發」。偶爾才跑、跨很多流程的，用 standalone 手動叫；只屬於某一條流程、每次都該跑的，用 embedded 綁在那條流程尾巴；要好幾個檢查連著跑的，用 chained 串成一條龍；全團隊每次改動都該過的標準，用 on every PR。判斷原則：你越常手動重複它，就越該往後面那幾階升級。

Q4：不是工程師、電商團隊也能用 skill 做檢查嗎？

可以。skill 的本質是「把你腦袋裡的檢查清單寫下來，讓 AI 每次自動跑」，跟寫不寫程式無關。上架前的商品欄位檢查、檔期文案合規、退換貨措辭一致性，這些都能寫成 skill。你需要的是講得清楚「要查什麼」，不是會寫 code。

Q5：skill chaining 會不會很燒 token？

會，串起來一次跑一整串一定比單跑一個貴。所以官方建議先小範圍測，確認這條鏈真的每一環都有價值，再逐步擴大，別一口氣把所有檢查全串上去。

Q6：skill-creator 是什麼？

skill-creator 是一個外掛，你裝了之後可以用 /skill-creator 叫它反過來訪談你的工作流程，再幫你把回答整理成一個 skill。適合你腦中有一套檢查、但懶得自己從零手寫 SKILL.md 的情況。

協作聲明與免責

這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 [來源名稱](URL) 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。

內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。