整理一場兩天企業內訓的核心內容，從 AI 工具地圖、Vibe Coding、Claude Code，到 CLAUDE.md、Skills、MCP 與 Agent 實戰，幫團隊建立一條可落地的導入路徑。
這份內容的價值不只是介紹單一工具，而是把企業導入 Claude Code 時真正會遇到的問題串起來：工具很多、概念很散、流程不清、規範沒寫下來、以及不知道怎麼從「會聊天」走到「做出可 Demo 的內部服務」。
| Day 1 | Day 2 |
|---|---|
| AI 工具地圖、提示詞、Vibe Coding、Claude Code 基礎與六大原則 | CLAUDE.md、Skills、MCP、Agent、Subagent、整合本機服務與實戰開發流程 |
| 目標：理解 Claude Code 的角色與使用方式 | 目標：把 Claude Code 接進團隊規範與既有流程 |
文章一開始把 AI 的使用拆成四個層次，這個框架其實非常適合拿來當企業訓練的開場：
這個分層的好處是，團隊比較不會停在「我也有用 ChatGPT 啊」的表面階段，而能明確知道自己還缺什麼能力。
內訓裡特別提到 PTCF，這很適合直接放進 Claude Code 教學裡，因為它其實就是你和 AI 溝通的最小結構：
即使進入 Vibe Coding 時代，提示詞能力沒有消失，只是從「對話技巧」升級成「工作指令設計能力」。
文中帶到的工具版圖很完整，從 Claude、Gemini、NotebookLM、Notion + Mermaid、RAG 工具、RPA 工具，一路到 Vibe Coding 工具。這段最重要的提醒其實只有一句：
文章裡把 Vibe Coding 的精神講得很直白：一行程式都不要自己改。當然這比較像最高原則，不是所有專案都要這麼極端，但它對教學很有用，因為它逼你把角色從「寫程式的人」切換成「指揮 AI 的人」。
| 傳統開發 | Vibe Coding |
|---|---|
| 自己手寫功能、自己處理錯誤與細節 | 先描述需求、讓 AI 生出初版、再透過回饋疊代 |
| 重點在語法與實作細節 | 重點在問題拆解、約束設定、方向判斷 |
這篇最值得放進教學頁面的部分，就是 Claude Code 的六大核心原則。它們比安裝指令更重要，因為真正決定成敗的是你怎麼使用它，而不是有沒有裝起來。
先要求它說明再動手，這件事在企業環境裡超重要。因為你每次 review 它的計畫時，也是在做風險控管與架構思考。
文章對 CLAUDE.md 的定位非常準：如果說 Claude Code 是執行者，那 CLAUDE.md 就是讓它知道「我們公司怎麼做事」的文件。它可以寫專案架構、建置指令、編碼規範、禁止事項、版控流程，也可以分成組織層、專案層、使用者層三種範圍。
# 範例觀念
- 在專案根目錄放 ./CLAUDE.md
- 把技術棧、lint、test、禁止事項寫清楚
- 規則要短、具體、可驗證
- 善用 @ 語法引入 README、設定檔與流程文件
這裡其實點出很多公司導入 AI 時的盲點：不是 AI 不夠強，而是團隊自己根本沒有把規範正式寫下來。
文章把 Skills 形容成「給 AI 看的工具使用手冊」，這個說法很到位。CLAUDE.md 比較像全域規範，而 Skill 則是針對某個專業工作，把知識、腳本、範本和資源封裝成可重用模組。
文中提到的 5 種 Agent Skill 設計模式也很值得保留：
這五種模式的重點不是背名詞，而是學會：不要把所有複雜邏輯塞進一個超長 prompt，而要拆成可以重複使用的工作模組。
這段整理得很適合企業讀者。很多人第一次看到 MCP 會以為那是很學術的標準，但其實白話講就是：讓 AI 可以連外部系統，直接查資料、下指令、呼叫工具。
這篇也把 Subagent 的使用邏輯講得很清楚：適合大量輸出、自包含、需摘要回傳、或要平行研究的任務；不適合頻繁互動、小修改、或強依賴共享上下文的情境。
這種判斷其實非常實務。很多團隊不是不會用 Agent，而是什麼都想切成 Agent，結果反而增加延遲與溝通成本。
文章最後整理出一條很好的工作流：
plan.md、tech.mdtodo.md這段很值得放進教學課裡，因為它把「靈感」變成「能執行的步驟」，也比較符合企業要的是可複製流程，而不是一次性的 Demo。
如果把這篇當成 learning 內容，我會把它定位成一篇：
也就是說，它不是取代現有 1-1、2-1、5-1、6-1 這些章節，而是把它們串起來，變成一個完整的地圖。