> ## Content Index
> Fetch the complete content index at: https://growthhackers.tw/llms.txt
> Use this file to discover other available public pages before exploring further.

# Claude Code skill 教學：把手動品管檢查變成 AI 自動驗證關卡，四種部署模式怎麼選
- URL: https://growthhackers.tw/blog/claude-code-skill-verification-loop/
- Published: 2026-07-24T17:25:45.000Z
- Updated: 2026-08-29T08:13:14.000Z
- Description: 把你每天手動的品管、上架前檢查、文案合規，寫成一個 Claude Code skill，讓 AI 每次自己跑驗證迴圈（檢查→修→再檢查）。解碼 Anthropic 官方文四種部署模式：手動叫用、綁流程自動跑、串一條龍、每個 PR 都跑，教你怎麼選、什麼時候升級，把個人習慣變成公司制度。
- Author: Lewis wang
- Tags: Claude Code, AI agent, Agent Skills, 自動化, AI 工作流

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

問到第五次，我才愣住。

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

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

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

素材來自 Anthropic 官方部落格〈[Building verification loops in Claude Code with skills](https://claude.com/blog/building-verification-loops-in-claude-code-with-skills?ref=growthhackers.tw)〉，作者是 Claude Code 團隊的 Delba de Oliveira。我把裡面對工程師講的東西，翻成給電商經營者聽的話。

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

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

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

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

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

![驗證迴圈的循環：gather context 收集脈絡、take action 動手做、verify 驗證，失敗就 loop back 退回重跑](https://growthhackers.tw/content/images/2026/07/ccsvl-inline1.png)

驗證迴圈：AI 收集脈絡、動手做、驗證，抓到問題就 loop back 退回自己修。

## Anthropic 內建了哪些驗證迴圈？

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

| 內建迴圈                  | 在做什麼                               | 狀態                         |
| --------------------- | ---------------------------------- | -------------------------- |
| /verify               | 幫你 build、跑起來、觀察改動後 app 的實際變化       | 正式                         |
| Toolchain（工具鏈）        | 讀你給的 linter、測試工具回報的錯誤碼並據此修         | 正式                         |
| Code Review（程式碼審查）    | 託管的多代理服務，自動幫你的 PR 跑一輪審查            | **research preview（研究預覽）** |
| GitHub Actions        | 讓你本地在跑的檢查，在每次 push/PR 自動觸發一次       | 正式                         |
| Spec validation（規格驗證） | 拿你 repo 裡的 markdown 規格文件逐項對照、抓違規並修 | 正式                         |
| Rubrics（評分準則）         | 用一個獨立的 grader（評分）代理打分，沒過就自動退回重做    | **beta**                   |

`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 後 AI 每次自動把關商品頁，攔截療效字眼與最低價等合規地雷](https://growthhackers.tw/content/images/2026/07/ccsvl-inline3.png)

手動檢查靠人記得，容易漏；寫成 skill 後，AI 每次自動把關商品頁的合規地雷。

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

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

想更完整理解 skill 這套機制，可以看我另一篇〈[Agent Skills 是什麼？把團隊 SOP 變 AI 技能包](https://growthhackers.tw/blog/agent-skills-andrew-ng-course/)〉，這篇就不重講基礎了。

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

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

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

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

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

| 模式                | 怎麼觸發             | 適合什麼檢查       | 升級訊號          |
| ----------------- | ---------------- | ------------ | ------------- |
| Standalone（手動叫用）  | 你自己想到才叫          | 跨流程、不是每次都要跑的 | 你每次改完都在手動叫它   |
| Embedded（綁在流程尾巴）  | 某個 skill 跑完自動接著跑 | 只屬於某一條流程的    | 這條流程每次都該檢查    |
| Chained（串成一條龍）    | 一個 skill 結束叫下一個  | 一整套要連著跑的關卡   | 你總是照同一個順序跑好幾個 |
| On every PR（每次都跑） | 每次上架／每次改動都跑      | 全團隊都該過的標準    | 不能只靠某個人記得     |

![四種部署模式階梯：Standalone 手動叫用、Embedded 綁流程尾巴、Chained 串成一條龍、On every PR 每次都跑，從 personal habit 個人習慣走到 team system 團隊制度](https://growthhackers.tw/content/images/2026/07/ccsvl-inline2.png)

四種部署模式是一條階梯：從 personal habit 個人習慣，一路長成 team system 團隊制度。

### 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`（設計規範文件）。

這種「串鏈」的另一個變形，是把人類核准也串進迴圈裡——我另外拆過 Anthropic 官方案例裡的 Warp，看它怎麼把[真正在改進的『人類核准關卡』](https://growthhackers.tw/blog/warp-self-improving-agent-review-gate/)做成可以看 diff、要簽名才能改的檔案。

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

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

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

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

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

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

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

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

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

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

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

看懂這四階沒有？

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)` 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。

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