AI 工具與 Vibe Coding 企業內訓：從 Claude Code 到 Skills、MCP、Agent

曾思遠受邀為某企業資訊服務團隊進行為期兩天的 AI 工具與 Vibe Coding 內訓課程。課程對象是熟悉後端開發與系統維運的工程團隊，目標不只是介紹工具，而是讓大家在兩天之內，從「知道 AI 能做什麼」走到「用 AI 打造出一個可以 Demo 的內部服務原型」。這篇文章把課程內容整理出來，分享給有意在企業內部導入 Claude Code、Skills、MCP 與 Agent 的團隊參考。

為什麼這堂課要兩天

企業內部的工程團隊，每天都會接觸到各種 AI 工具的新聞，但真正在工作中把 AI 用起來的人並不多。原因通常不是「不會用 ChatGPT」，而是以下幾件事：

• 不知道 AI 工具之間的關係（LLM、RAG、RPA、Vibe Coding、Agent 到底差在哪？）
• 對 Claude Code、Skills、MCP 這些新概念還停留在「聽過」的階段
• 缺少從頭到尾打造一個可運作產品的實戰經驗
• 不清楚要怎麼把 AI 嵌進既有的開發流程與規範裡

兩天的課程分成兩個主題：第一天著重在「AI 工具地圖」與 Claude Code 的基本使用；第二天則進入 Skills、MCP、Agent 與本機端伺服器的整合，最後以一個 Vibe Coding 實戰題目收尾。

AI 使用的四個層次

課程一開始，我先幫大家把 AI 的使用方式拆成四個層次，讓後面的每個工具都能對應到一個位置：

1. （入門）選定 AI 模型
   依任務選擇合適的模型：Gemini 系列適合深度研究與多模態、Claude Opus / Sonnet 擅長長文推理與程式碼、GPT 系列則在日常對話與工具整合上成熟，Sora、Nano Banana、Veo 則分別處理影片與圖片生成。
2. （中階）提示詞優化
   透過 System Prompt 與 User Prompt 的分工，讓 AI 扮演特定角色，輸出更穩定、更精準。
3. （進階）提供補充資料（RAG）
   讓 AI 能讀到公司內部的法規、合約、產品型錄，把既有的知識資產再利用，同時降低「幻覺」風險。
4. （高階）RPA + Vibe Coding
   用 RPA 建立自動化流程與 AI Agent，用 Vibe Coding 直接打造產品與工具，讓不是工程師的人也能把流程變成產品。

這個分層的好處是，每個人都可以誠實地問自己：「我目前停在哪一層？下一步要往哪裡走？」

PTCF：寫出穩定提示詞的基本功

即使進到 Vibe Coding 時代，「寫一個好的提示詞」仍然是最基本的能力。課程中我特別花時間介紹 PTCF 這個結構：

• P – Persona（角色）：先告訴 AI 它是誰，例如「你是一位資深的科技業人資招募專家」。
• T – Task（任務）：明確描述要它做什麼，例如「幫我撰寫一份後端工程師的招募文案」。
• C – Context（背景）：補上公司、產品、技術棧、流量規模等背景資訊，讓 AI 有立足點。
• F – Format（輸出格式）：規定輸出結構，例如「請分成職位名稱、公司簡介、工作內容、必備條件、加分條件、福利」。

同樣的需求，有沒有 PTCF，輸出品質差距非常大。現場我們實際操作了「用 PTCF 撰寫工程師職缺」、「用 PTCF 寫一份測試工程師 JD」等練習，讓學員體會結構化提示的威力。

AI 工具地圖：除了 ChatGPT，還有什麼值得用

課程的第二個段落，我帶大家快速走過一輪目前值得掌握的 AI 工具：

• 通用對話模型：ChatGPT、Gemini、Claude，作為每天的第一個問答入口。
• Gemini Canvas：用一段自然語言就能產出互動式的學習或說明頁面，很適合拿來做內訓教材或教學原型。
• NotebookLM：上傳 PDF、投影片、YouTube 連結，幫你整理成摘要、投影片、語音摘要、心智圖。對「寫論文」、「讀長文」、「競品分析」、「新人 onboarding 手冊」特別有用。
• Notion + Mermaid：用文字語法畫流程圖、架構圖、ER diagram，和 AI 搭配起來就是「一句話畫出整段流程」。
• RAG 工具：Dify、Pinecone 等，讓企業內部資料變成 AI 的知識庫。
• RPA 工具：Make、n8n、Dify、Opal，把 AI 串進既有流程，做自動化 Agent。
• Vibe Coding 工具：Lovable、Firebase Studio 以網頁操作為主，Claude Code、Codex、Antigravity 則以 CLI / IDE 為主，能直接落地到真實專案。

我反覆提醒一件事：不管是哪種檔案格式、哪種程式語言，在 AI 時代都不需要自己從零寫。我們要做的是認識這些格式的用途與邊界，然後學會指示 AI 幫我們產出。

什麼是 Vibe Coding

Vibe Coding 的最高指導原則只有一句：「一行程式都不要自己改」。任何錯誤、任何部署問題、任何 UI 調整，都丟回給 AI。

和傳統開發比較一下：

傳統寫一個待辦清單工具：選框架 → 設計資料結構 → 手寫排版 → 寫新增／刪除邏輯 → 處理邊界情況 → 整合後端 → 寫測試，預估 4–8 小時。

Vibe Coding 寫一個待辦清單工具：用自然語言描述完需求，預估 5–15 分鐘（含微調）。

Vibe Coding 的優勢在於：

• 極速原型開發：從想法到可執行程式，幾分鐘內完成。
• 降低學習門檻：不需要精通所有技術棧，也能實現複雜功能。
• 專注核心價值：把時間花在解決商業問題，而不是處理技術細節。
• 快速實驗：嘗試不同方案的成本大幅下降。
• 學習加速器：透過 AI 生成的程式碼回頭學習最佳實務。

我也提醒有工程背景的學員：把角度從「寫程式的人」拉高到「管理與規劃 AI 的人」。把 AI 當成 Junior 或 Senior Programmer 來指揮，工程師的價值會從「熟悉語法」轉變成「問題分析與拆解能力、系統架構設計、可維護性與可擴充性」。

Claude Code 實戰：六大核心原則

第一天的重頭戲是 Claude Code。安裝只要一行：

curl -fsSL https://claude.ai/install.sh | bash

接著就能用 claude 進互動模式、用 claude -p 做單次指令，甚至把它嵌進任何 CI/CD 系統當成 CLI 工具使用。

但真正的重點不在指令本身，而是使用 Claude Code 時的六個核心原則：

1. 給上下文，不給結論：告訴它「現況是什麼」，不要直接告訴它「你要改哪一行」。
2. 說明約束條件：效能限制、相容性、不能動的模組，都要講清楚。
3. 指定邊界，不要讓它自由發揮：明確說「只改這個檔案」、「不要新增依賴」。
4. 要求它說明再動手：先用 --print 或互動模式問計畫，確認方向再放手。
5. 用專案裡既有的東西當參考：叫它模仿現有寫法、命名風格、資料夾結構。
6. 一次一件事：不要一個指令觸發一連串連鎖修改。

這六個原則對應到常見的四個風險：產出錯誤且不易察覺、機密外洩、Token 成本失控、與既有流程整合困難。把原則變成肌肉記憶，Claude Code 才會真的成為加速器，而不是風險製造機。

CLAUDE.md：把團隊規範寫成 AI 看得懂的指令

Claude Code 之所以能在企業內穩定使用，關鍵在 CLAUDE.md。它是一份持久化的指令檔，Claude 在每次對話開始時會自動載入，裡面可以寫：專案架構、建置指令、編碼規範、禁止事項、版控流程。

它有三層架構：

1. Managed Policy（組織層級）：IT 統一部署，所有使用者共用，優先度最高。
2. 專案層級（Project）：放在專案根目錄 ./CLAUDE.md，隨 Git 版控與團隊共享。
3. 使用者層級（User）：放在 ~/.claude/CLAUDE.md，是個人偏好、本機私有。

實務上幾個重點：

• 在專案根目錄用 /init 一鍵產生 CLAUDE.md，Claude 會自動偵測技術棧、建置指令、Lint 規則、測試框架。
• 控制在 200 行以內，太長會降低指令遵循度。
• 寫具體可驗證的規則，例如「用 2-space 縮排」，不要寫「格式化好一點」。
• 用 @ 語法引入 README、套件設定檔、git 流程文件，把上下文組合起來。
• 配合 .claude/rules/ 做模組化規則，依路徑條件式載入，節省 Token。
• 如果公司用 GitLab，要在 CLAUDE.md 裡明確寫「用 glab mr create 不要用 gh pr create」、「MR 不叫 PR」等提醒。

這一段我讓學員實際替自己團隊的技術棧（含語言、框架、ORM、測試工具、訊息佇列等）寫一份 CLAUDE.md，並現場用 Claude Code 驗證效果。

Skills：給 AI 看的工具使用手冊

如果說 CLAUDE.md 是「公司規範」，那 Skills 就是「專業領域的 SOP 手冊」。Skill 是 Claude Code 的可擴充能力模組，每個 Skill 都是獨立、自包含的單元，包含 SKILL.md、scripts/、assets/、references/。

Skill 採用三層漸進式載入機制：

1. Metadata（~100 字）：名稱 + description，永遠在上下文中，用來判斷何時觸發。
2. SKILL.md 本體（< 500 行）：被觸發後才載入完整操作指令。
3. Bundled 資源（無限制）：scripts/、references/、assets/ 只在需要時才讀取。

官方內建了六個核心 Skills：docx、pdf、pptx、xlsx、schedule、skill-creator。在課堂上我讓學員用 /plugin install skill-creator@claude-plugins-official 安裝 skill-creator，然後現場各自生出一個「寫技術文件」或「寫 API 文件」的 Skill，再用這個 Skill 去幫先前的練習專案補上技術文件。

5 種 Agent Skill 設計模式

Skill 的格式已經標準化，但怎麼設計內部邏輯才是難題。課程中我帶大家認識 Google ADK 整理出的 5 個設計模式：

1. Tool Wrapper（工具包裝器）：把特定函式庫或框架的知識封裝起來，Agent 只在需要時動態載入。適合框架慣例、API 設計、內部 SDK 指南。
2. Generator（生成器）：透過範本 + 風格指南，強制每次輸出結構一致。適合 API 文件、Commit 訊息、專案骨架。
3. Reviewer（審查器）：把「檢查什麼」和「如何檢查」分離，替換 checklist 就能從程式碼審查變成安全稽核。適合 PR Review、安全掃描、合規稽核。
4. Inversion（反轉模式）：不急著生成，先用結構化提問收集完整需求，所有階段完成前禁止開始建構。適合需求規劃、系統設計、專案啟動。
5. Pipeline（管線模式）：強制多步驟順序執行，透過「鑽石閘門」要求使用者確認才能進下一步。適合文件生成、部署流程、資料處理 Pipeline。

這五個模式不是互斥的，可以組合使用：Pipeline + Reviewer 做品質把關、Generator + Inversion 做缺欄補問、Pipeline + Tool Wrapper 做按步載入知識庫。別再把複雜指令塞進單一 system prompt，學會拆解工作流程，套用正確的設計模式，才能打造可靠的 Agent。

MCP 入門：讓 AI 真的接上你的工具

Model Context Protocol（MCP）是 Anthropic 發起的開源標準，用來把 AI 工具接到外部服務。MCP Server 的組成和 Skill 很像：

• Tools：AI 可呼叫的函式，類似 API endpoint（類比 Skill 的 scripts/）。
• Resources：可用 @ 引用的資料來源（類比 assets/）。
• Prompts：預設的提示模板，會變成 /mcp__xxx 指令（類比 SKILL.md）。

課程中我帶大家實作了幾個案例：

1. Sentry 錯誤監控：裝完 MCP Server 後，直接問「過去 24 小時最常見的錯誤？」、「顯示錯誤 ID abc123 的堆疊追蹤」，不用再切換到 Sentry 儀表板。
2. GitHub 程式碼審查：「審查 PR #456 並建議改進」、「為我們發現的錯誤建立新問題」。
3. PostgreSQL 自然語言查詢：「本月我們的總收入是多少？」、「找到 90 天未購買的客戶」，讓 AI 自動產生 SQL。
4. Notion MCP：驗證帳號後，直接用自然語言查詢與新增 Notion 頁面。
5. GitLab API 整合：用 Personal Access Token 存到 .env，請 Claude 自動建 repo、commit、push。

一旦把 MCP 想成「AI 的外部工具延伸」，你會發現整個開發流程的節點都可以被自然語言接起來。

Agent 與 Subagent：什麼時候該分工

Agent Tool 是 Claude Code 的核心委派機制，可以啟動獨立的 Subagent，每個 Subagent 擁有自己的 Context Window，完成任務後只回傳摘要給主對話。這帶來四個優勢：隔離性、專業化、平行化、可控性。

Claude Code 內建三種 Subagent 類型：

• Explore（Haiku，唯讀）：快速搜尋、程式碼探索、檔案發現。
• Plan（繼承主對話，唯讀）：架構規劃、實作策略設計。
• General-purpose（繼承主對話，全工具）：複雜多步驟任務、研究與修改。

什麼時候適合用 Subagent？

• 任務會產生大量輸出（測試、日誌）
• 需要特定的工具權限限制
• 自包含任務，只需回傳摘要
• 需要平行研究不同模組
• 需要專業領域知識（資安、效能、code review）

什麼時候不適合？需要頻繁來回互動、多階段共享大量上下文、快速針對性的小修改、對延遲敏感的操作，這些用單一 Claude Code 對話就好。

現場我們實作了兩個 Agent 練習：一是用官方的 pr-review-toolkit:code-reviewer 來 review 一段 Python 程式碼；二是自己建立 UIUX Agent 與 Frontend Agent，讓 UIUX Agent 根據 plan.md 規劃流程，再把結果傳給 Frontend Agent 產出對應的前端畫面，完成一個會議室預約介面。

本機端伺服器：WSL + FastAPI 的小小坑

第二天有一部分專門處理學員在 Windows 上用 WSL 跑 FastAPI 的問題。關鍵指令是：

uvicorn main:app --host 0.0.0.0 --port 8000

如果綁 127.0.0.1，Windows 的瀏覽器連不進去；綁 0.0.0.0，WSL2 會自動幫你把 port forward 到 Windows 的 localhost。Windows 11 + WSL2 還支援更進階的 mirrored 網路模式，在 %USERPROFILE%\.wslconfig 寫上 networkingMode=mirrored，localhost 就完全互通。這些細節平常不會寫進教科書，但在企業內訓的現場，常常就是卡住學員一整個下午的地方。

從點子到產品：Vibe Coding 的完整工作流

課程最後我整理出一個 Vibe Coding 的標準流程，讓學員回去就能照著跑：

1. 開啟一個新資料夾，進到 Claude 互動模式。
2. 先請 Claude 規劃功能與技術棧（建議：Python + React.js + SQLite），把結果寫到 plan.md 與 tech.md。
3. 用 Gemini Canvas、Firebase Studio 或 Lovable 做出初版畫面，流程另外寫到 uiux.md。
4. 把畫面、plan.md、tech.md 一起丟回給 Claude，請它產出 todo.md，裡面包含兩層階層的執行順序，每個階段都是低耦合、可以單獨測試，前面用 [ ] 標記完成狀態。
5. 依 todo.md 逐項開發，每做完一個就打勾、跑測試。

實戰題目我們提了幾個方向：會議室預約系統、內部智能查找服務、工作流程優化工具、既有產品的功能上架流程。每組同一題目，每個人都要實際開發過一輪，最後一組交出一份產品規劃簡報：包含產品介紹、實際 demo、競爭分析、痛點分析、績效提升預估與下一步方向。

企業內訓的幾個觀察

兩天下來，我有幾個滿具體的觀察：

1. 工程團隊的角色正在轉變：從「熟悉語法的人」變成「懂得怎麼指揮 AI 的人」。拉高視角、把 AI 當成 Junior/Senior Programmer 來管理，會比鑽研單一工具更重要。
2. 把規範寫下來比想像中還重要：CLAUDE.md、Skill、MCP，這些機制的共同前提都是「你的團隊規範能被寫下來」。很多公司第一次用這些工具，才發現連自己的編碼風格、分支策略、命名規則都沒正式文件化。
3. Vibe Coding 不是只給非工程師用：對既有工程團隊來說，Vibe Coding 是「打造內部工具、快速驗證商業點子」的新管道，而不是取代正規開發。小團隊用 Vibe Coding 完成一個新服務原型，往往比走完整專案流程快十倍。
4. AI 是加速器，不是替代者：最危險的依賴方式是「看不懂 AI 產出也照貼」。原則四「先說明再動手」的好處是，你每次 review AI 的計畫時，都在練自己的架構思考。

如果你的團隊也在思考要怎麼把 Claude Code、Skills、MCP、Agent 這些新工具導入日常開發，或者想把企業內既有的開發規範、SOP、流程，變成 AI 看得懂的指令，非常歡迎一起交流。AI 對企業來說，從來不是一次性的系統建置，而是一個持續探索與迭代的過程。

← 返回文章列表