在 GitHub Copilot 中使用
MCP、Skill、與 Hook

現在用 AI 寫程式，大家應該都駕輕就熟了。描述需求，讓它產生程式碼；遇到錯誤，把訊息貼回去，再請它修正。(是吧?別跟我說你還會自己手動去debug，我不信!!)

但當我們漸漸開始讓 AI 一次修改更多程式碼，問題也跟著來了。
當它跟你說修好了，就真的是修好了嗎？
能不能要求 AI 自己開瀏覽器去測試？
上次好不容易調整好的自動化測試流程，能不能保留下來，讓團隊其他人直接使用？
以後每次讓 AI 改完程式碼之後，還要不要再提醒它一句：「記得跑測試」？

最近，我錄了三部 GitHub Copilot 在 VS Code 裡的示範，分別介紹 MCP、Agent Skill 和 Hook。 三個功能分開看都很單純，但你把它們放進同一個開發情境，就會更容易理解，為什麼現在我們要開始認真看待 Agentic Development。

我上課一直以來，都用這個很簡單的範例，一個有 bug 的 BMI 網站。 當用戶輸入身高 170 公分、體重 70 公斤，正常應該算出約 24.22，程式卻算出 70，我們就從這個小問題開始，看看怎麼讓 AI 操作網站、發現問題，把流程保存下來，再把驗證放進它的工作節奏。

三部影片可以依序搭配閱讀：

MCP：讓 AI 有能力動手做測試

第一部影片裡，我先啟動 BMI 網站，再透過 Chrome DevTools MCP，請 Copilot 開啟網頁、輸入身高體重，然後按下計算。

你會看到瀏覽器自己開起來，欄位自己填好，按鈕也自己按下去。這個動作背後，是 Agent 根據我們的要求選擇 MCP 工具，再由工具執行操作，把結果交回給 Agent。

MCP，全名是 Model Context Protocol，是讓 AI 應用程式連接外部工具與資料的標準。以這個例子來說，Chrome DevTools MCP Server 提供瀏覽器操作能力，Copilot 就能透過它與實際運行中的網站互動。

影片中，我們把設定放在專案的 .vscode/mcp.json，類似底下這樣：

{
  "servers": {
    "chrome-devtools": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}

這個設定需要可使用的 Node.js、npm，以及 Chrome。 影片中我們另外指定了 Chrome 執行檔路徑；如果你的安裝位置需要手動指定，可以在 args 加入 --executablePath=Chrome實際路徑。

影片接著提供 TestCase/TestCases.md這個測試案例，裡面有正常與異常兩條路徑。正常案例輸入 170 公分、70 公斤，驗證 BMI；異常案例輸入負的身高，預期畫面顯示「輸入錯誤」。我請 Copilot 依照這份文件測試，並把結果寫回去。

結果兩個案例都失敗。正常案例算出 70，異常案例也沒有出現預期的錯誤訊息。

這正是我們要的效果，我們讓 AI 參考測試案例，進行自動化測試，甚至可以讓他在半夜自動化執行。

Chrome DevTools MCP 還能查看 Console 訊息、Network 請求，以及效能資料。若是進一步延伸，就可以要求 AI 在測試失敗時多收集一些證據。例如按鈕沒有反應，到底是前端 JavaScript 出錯，還是 API 回傳了錯誤？這些資訊能讓後續修正更有依據。

剛才的自動化測試跑起來之後，下一個問題是：明天寫完程式還要再打一遍提示詞嗎？當然不要。

正式專案的提示詞通常不會只有一句話。你可能要交代測試環境、案例位置、數值精度、失敗時要保留的證據，以及不能修改哪些檔案。團隊成員若是每個人自己各寫一套，不僅容易錯誤，最後產生的測試報告也可能各不相同。

第二部影片就是把前面已經操作過的流程，整理成 bmi-auto-test 這個 Agent Skill。

我在對話中使用底下這樣的提示詞：

/create-skill 把剛才的 BMI 網頁測試流程做成這個專案的 Skill，命名為 bmi-auto-test。

即可讓 Copilot 自動建立 Skill，存放於 .github/skills/bmi-auto-test/SKILL.md。

檢視過這個 Skill 符合你的需要，可以將其保留，未來在 Chat 輸入 /bmi-auto-test，就能再次要求它依照這個流程工作。

透過 /create-skill 來建立 Skill 以及使用斜線命令呼叫 Skill，都是目前 VS Code 中很好用的做法。　

Skill 的基本結構是 Markdown 搭配 YAML frontmatter，至少包含 name 和 description。也可以把腳本、範本、參考文件一起放在 Skill 目錄裡。

有了 Skill，我們已經可以用很短的指令完成一整套測試。不過還有一個問題：「你得記得叫它(AI)做」。

第三部影片則往前又推了一步。

我希望 Copilot 修完程式、準備結束工作時，能自動執行專案的單元測試。因此，我們透過 /create-hook，要求它建立一個對應 Stop 事件的 Hook。

Hook 的作用，是在 AI Agent (也就是GitHub Copilot) 工作生命週期的特定時間點執行動作。影片使用 JSON 設定搭配 PowerShell 腳本，在 Agent 準備停止時執行 dotnet test，並處理測試結果。

這個例子很小，但工作方式已經不一樣了。以前是人看完 AI 的修改，再想起要跑測試；現在可以把這個檢查直接寫進專案。

這裡有兩個技術細節，正式使用前一定要分清楚。

第一，Local 的 Stop 是「這一輪 Agent 執行準備停止」，Hook 還有很多的觸發時機(例如使用工具前後)，你可以在文件上找到相關資訊。第二，執行過測試，不等於測試失敗時就會自動要求 Agent 繼續修正。 腳本必須把測試結果轉換成該事件支援的回傳格式。

例如，Local Stop Hook 可以輸出下面這種 JSON，要求 Agent 暫時不要結束：

{
  "hookSpecificOutput": {
    "hookEventName": "Stop",
    "decision": "block",
    "reason": "BMI 單元測試失敗。請根據測試輸出分析原因，修正後重新驗證。"
  }
}

我在影片裡也特別要求避免無限重試。假設測試失敗，Hook 要求繼續；Agent 再試一次，又失敗；Hook 又要求繼續，那它就可能一直繞下去。Local 事件提供 stop_hook_active，用來辨識目前是否已因前一次 Stop Hook 而繼續執行。我的建議是再配合有限次數、逾時與明確的停止條件，最後如實回報未解決的問題。

不是所有錯誤都該叫 AI 改程式。例如，套件還原失敗、測試環境沒啟動、檔案被鎖住，都需要先分辨原因。測試腳本的責任之一，就是把這些做法保留下來。

前面提到過，除了 Stop，Local 還有工具執行前的 PreToolUse、工具成功執行後的 PostToolUse 等事件，可以用於操作檢查或後續驗證。

三個功能，怎麼放進同一個團隊流程？

把影片串起來，可以用這張表理解彼此的分工：

它們可以彼此配合，但並不是非得硬綁在一起的功能。Skill 可以使用內建工具，也可以使用 MCP；Hook 可以直接跑測試命令，不需要先經過 Skill。

因此不要把三者理解成「Hook 會自動呼叫 Skill，Skill 一定會呼叫 MCP」。影片示範的組合是：UI 測試 Skill 使用 Chrome DevTools MCP；Stop Hook 另外執行 .NET 單元測試。 這兩條驗證路徑各有作用。

如果要把這個範例帶進正式團隊，我會先把 acceptance criteria 寫清楚，再讓 Agent 修改程式。開發過程中，用 UI 測試 Skill 檢查使用者操作是否符合預期；Agent 準備結束時，由 Hook 執行適當範圍的單元測試。最後，提交 PR 仍然要經過團隊既有的 Review 與 CI 檢查。

如果團隊原本就在做 SDD，這些功能也可以很好的串接進來。Spec 定義行為與驗收條件，測試案例把它們具體化，Skill 保存驗證方法，Hook 提醒流程在適當的地方接受檢查。需求改了，就一起檢查 Spec、案例與驗證流程是否需要調整。

不過，Local Hook 依賴開發者的環境與設定，不適合單獨承擔團隊最後一道品質把關。我仍然會讓 CI 在受控環境重新建置、重新測試，並由儲存庫的合併規則要求必要檢查通過。Hook 能讓錯誤提早被發現，CI 則把驗證帶到共同的交付流程。

對於長期、頻繁執行的關鍵 UI 回歸測試，我也會考慮把探索過程整理成明確的自動化測試程式，交給 Pipeline 執行。Agent 可以協助探索、維護與分析結果；固定案例則比較容易追蹤每次執行的差異。這是當你要走向長期維運時，我會建議採取的分工。

從這三部影片中你大概可以發現，如今我們已經可以很自然地把許多開發經驗(流程)跟 AI 的工作整合在一起。

一次好用的提示詞，可以留下來成為團隊共用的 Skill；
一次容易被忘記的驗證流程，可以放進 Hook；
一個原本需要人手動操作的系統，可以透過 MCP 讓 Agent 參與。

當 AI 寫程式愈來愈快，我們更需要把「怎麼證明這件事做對了」一起設計進去。 工具已經能幫我們做很多事，接下來，就看我們能不能把自己的開發流程與AI自動化進行完美的整合了。