梵熹 × Anthropic 學習手冊
把 14 門 Anthropic Academy 官方課程收成一本能翻的書：左邊點章節展開，右邊看那門課「講了什麼 / 我學到什麼 / 我們怎麼用」。每章內容依影片逐字稿（CC）加深，全部內嵌在這一個檔，不連外部散頁。
14
門課全數收錄
14 / 14
已領證（可公開驗證）
100%
全數測驗滿分完課
14 課證書進度總表
| # | 課程 | 軌別 | 是否領證 | 測驗分數 | 驗證連結 |
|---|---|---|---|---|---|
| 01 | Claude 101 | AI 素養 | 已領證 | 10 / 10（100%） | 開啟驗證 |
| 02 | AI Fluency 4D 框架 | AI 素養 | 已領證 | 6 / 6（100%） | 開啟驗證 |
| 03 | Claude Cowork | AI 素養 | 已領證 | 8 / 8（100%） | 開啟驗證 |
| 04 | Claude Code 101 | 開發者 | 已領證 | 5 / 5（100%） | 開啟驗證 |
| 05 | Claude Code in Action | 開發者 | 已領證 | 8 / 8（100%） | 開啟驗證 |
| 06 | Claude Platform 101 | 開發者 | 已領證 | 6 / 6（100%） | 開啟驗證 |
| 07 | Building with the Claude API | 開發者 | 已領證 | Final 23 / 23（100%） | 開啟驗證 |
| 08 | MCP（Model Context Protocol） | 開發者 | 已領證 | 7 / 7（100%） | 開啟驗證 |
| 09 | MCP 進階主題 | 開發者 | 已領證 | 10 / 10（100%） | 開啟驗證 |
| 10 | Introduction to Agent Skills | 開發者 | 已領證 | 無測驗 · 100% 完課 | 開啟驗證 |
| 11 | Introduction to Subagents | 開發者 | 已領證 | 無測驗 · 100% 完課 | 開啟驗證 |
| 12 | Claude with Amazon Bedrock | 雲端企業 | 已領證 | Final 21 / 21（100%） | 開啟驗證 |
| 13 | Claude with Google Cloud Vertex AI | 雲端企業 | 已領證 | Final 24 / 24（100%） | 開啟驗證 |
| 14 | AI 能力與極限 | AI 素養 | 已領證 | 11 / 11（100%） | 開啟驗證 |
簡報｜Claude 101
課程 Claude 101（Meet Claude 系列）
平台 Anthropic Academy（免費註冊）
定位 用 Claude.ai App 處理日常工作，非 Claude Code 開發課
依據 影片逐字稿（CC）重寫 · 2026-07-03
一句話：這門課教「一般人怎麼把 Claude 用進每天的工作」——13 課裡有 5 課嵌 YouTube 影片，其中 3 課有完整口白（第一次對話、資料分析、Projects），另 2 課是宣傳短片（只有配樂）。下面每一課的重點都直接來自影片逐字稿，不是官網一句話大綱。標「有CC」的是我實際聽了影片抓出來的重點；純文字/宣傳片會誠實標明。
一、課程講了什麼（13 課逐課重點，來自影片 CC）
| 課／來源 | 影片實際講了什麼 |
|---|---|
| 1 什麼是 Claude 純文字課 | 圖解介紹課，無口白影片。定位：把 Claude 當「放大你能力的協作夥伴」，AI 出智慧、你出脈絡與專業，兩者合起來工作才有意義。 |
| 2 第一次對話 有CC | 從側邊欄講起：new chat、Projects（帶持久脈絡與自訂指示）、Artifacts（把點子變可分享的 app/工具/內容）。核心觀念「像跟同事講話一樣自然、簡潔、口語」。好 prompt 三步驟：①設定舞台（你的角色、目標、該知道的背景）②定義任務（要它寫/分析/建什麼）③指定規則（語氣、格式、附範例）。示範用「投資人 pitch deck for 獨立串流 app」。進階：上傳文件當脈絡捷徑（PDF/CSV/docs 都吃）、search and tools 選單開 web search 或接 Google Drive、model selector 選 Opus（最複雜多步驟如財務分析）/Sonnet（日常預設）/extended thinking（複雜分析但增延遲）、Research 模式自動多輪查數百來源、5–45 分鐘出附引用報告。收尾金句：真正的威力來自「持續且頻繁互動」，不是一次性 prompt。 |
| 3 問到更好結果 有CC | 本課實際嵌入「用 AI 做資料分析」影片，教委派勤勉迴圈（delegation-diligence loop）：先拿你已知答案的舊資料，讓 AI 重現你手做過的分析，逐次比對它哪裡對、哪裡漏，refine 後再測；能穩定重現就信任、幾輪都做不到就別委派。案例主角 Rio（退伍軍人服務中心專案主任），每季手算出席率 vs 就業成果要花好幾小時；AI 抓到出席與就業的相關，卻漏了「住房補助＋就業」組合的關鍵洞見，Rio 提醒它注意 program type 才補上，也學到之後要主動餵 enrollment dates 才能做 cohort 分析。金句：「validation builds confidence, but it doesn't eliminate responsibility」——驗證建立信心，但責任還是你的。不熟資料的人可反過來請 AI 幫寫 Excel 公式、重整亂資料。 |
| 4 桌面 App：Chat / Cowork / Code 純文字課 | 圖解教學課，無口白影片。同一個桌面 App 三種入口：Chat 問答、Cowork 協作辦公、Code 寫程式，依任務切換。 |
| 5 認識 Projects 有CC | Project ＝自成一體的環境，有自己的 chat 歷史、知識庫、設定。Project knowledge：上傳的文件每次對話都自動納入考量，回答貼你的術語與背景。資料多到快撞 context 上限時，會自動啟用 RAG擴容。Project instructions：定語氣、專業程度、回答視角，每次對話都套用。團隊協作（Claude for work）可分享給組織——例：品牌團隊建一個「voice/tone 指南」Project，全公司都能寫得像行銷。建立三步驟：new project→命名→描述目標→create。三種權限：can view（唯讀＋討論）、can edit（改指示/知識/成員）、creator（全控＋決定誰能看）。臨時上傳的檔案不進知識庫、只在該對話用。範例：新產品開發、內容創作、教育課程（連 Anthropic 自己的 AI Fluency 課都用 Project 管）、個人財務、居家裝修。 |
| 6 用 Artifacts 產出成品 純文字課 | 圖解教學課，無口白影片。文件/程式/網頁/圖表開在獨立視窗，可即時預覽、反覆改、直接拿去用。 |
| 7 使用 Skills 宣傳片 | 嵌入 99 秒宣傳短片，只有配樂無口白。官方說明：看 Claude Opus 4.5 處理真實工作——做董事會簡報、轉換試算表資料、對合約做 redline，產出的是可直接下載使用的成品，不是要丟掉的草稿。 |
| 8 連接你的工具 純文字課 | 圖解教學課，無口白影片。透過連接器／MCP 接 Google Drive、行事曆、Notion 等，讓 Claude 讀你的實際資料辦事。 |
| 9 企業搜尋 純文字課 | 圖解教學課，無口白影片。企業版跨內部知識庫搜尋，答案根據公司自己的文件而非泛泛而談。 |
| 10 Research 深度研究 純文字課 | 圖解教學課，無口白影片。大問題交給研究模式：自動拆解、多輪搜尋、跨數百來源比對，5–45 分鐘產出附出處報告。 |
| 11 各職務用法 純文字課 | 圖解教學課，無口白影片。依角色（行銷/業務/營運/HR/工程）示範可照抄的情境。 |
| 12 其他協作方式 宣傳片 | 嵌入 61 秒宣傳短片，只有配樂與零星呼喊。官方說明：介紹 Claude Code on the web——直接從瀏覽器委派 coding 任務，在 Anthropic 雲端執行，可平行派多個任務，適合清 bug backlog、例行修復。 |
| 13 下一步 結業導引 | 結業導引課，無口白影片。總結學習路徑、指向進階課程（Claude Code 101 / Platform 101）。 |
二、我學到、且對我們最有用的 5 點（從 CC 萃取）
| 影片講的觀念 | 為什麼對我們重要 |
|---|---|
| 好 prompt 三步驟：設定舞台→定義任務→指定規則 | 影片把它拆成三段，正好對上你「具體大於模糊、用數字時間案例取代形容詞」的品質基準——每次派工前先把角色、任務、格式範例交代清楚。 |
| 委派勤勉迴圈：拿已知答案的舊資料驗 AI，再決定信不信 | Rio 的做法就是「報成功前必親自驗證」的白話版——先用有標準答案的案子測到準，才敢拿它跑新資料。這條可直接寫進我們的驗收 SOP。 |
| 「驗證建立信心，但不免除責任」 | 官方親口講的紅線，跟你「工具回 ok 不等於成功、要分清送達≠通知」完全同調——AI 做完我仍要為結果負責、要透明標註 AI 的角色。 |
| Projects＝知識庫＋指示＋權限，資料多會自動 RAG | 對上我們「重開機不准忘、開頭先讀 CLAUDE.md＋記憶」；三種權限（view/edit/creator）也提示我們的交付看板該分清誰能看、誰能改。 |
| 威力來自持續互動，不是一次性 prompt | 越常互動它越懂你的風格——這就是我們每小時對折存檔、把糾正史萃成規則的複利邏輯。 |
三、我們怎麼用（影片概念對到梵熹現有系統）
| 影片概念 | 梵熹已經在用 / 可補強 |
|---|---|
| 好 prompt 三步驟 | 已在用CLAUDE.md 第 6 節品質基準＋派工前先交代角色/任務/格式。補強把「設定舞台→定義任務→指定規則」做成派工檢查表。 |
| 委派勤勉迴圈 | 補強把「先用有標準答案的舊案測到準再上線」明訂進驗收流程，避免謊報。 |
| Projects 收攏知識＋RAG | 已在用工作台三層結構＋一專案一 repo＋各案 客戶資料/。補強常用主題建成 Claude.ai Project，桌面手動作業更順。 |
| Project 三種權限 | 補強交付看板／分享連結比照 view/edit/creator 分權，客戶只給唯讀＋討論。 |
| Artifacts 成品化 | 已在用簡報／儀表板／落地頁都以 HTML 成品交付（如本簡報）。 |
| model selector 按任務挑 | 已在用pick_model()：對話 Sonnet、瑣事 Haiku、高難度 Opus——跟影片「Opus 最複雜、Sonnet 日常預設」一致。 |
| 接工具 / MCP | 已在用Notion／Google Drive／Higgsfield／Canva 等 MCP 已接。 |
| Research 深度研究 | 已在用social-listening／deep-research skill 做多來源查證報告。 |
| 持續互動累積 | 已在用每小時對折存檔成記憶＋每週從糾正史自萃規則（self-optimize）。 |
本課帶來的優化（萃取自「課程優化提案」／落地狀態）
這門課我們學完，實際拿去改進的重點如下。綠＝已回灌團隊鐵律、可立刻生效；橘＝待 Norick 拍板；藍＝程式類由工程同事另辦或未來自建才用。
| 本課萃取的優化點 | 落地狀態 | 落在哪份規則／流程 |
|---|---|---|
| 回歸測試信任法：新 skill／cron／扇出上線前，先拿「已知正確答案的舊案例」端到端跑、比對吻合才切 live；對不上就這件先別全交、人工留著。 | 已套進鐵律 G 段 | 團隊鐵律 G 段第 7 條；make-skill 收尾加此關卡 |
簡報｜AI Fluency：4D 框架
課程 AI Fluency for Educators
發行 Anthropic Academy（YouTube 嵌入）
來源 4 支影片 CC 逐字稿全抓
核心 4D 框架：Delegation / Description / Discernment / Diligence
一句話：這門課不教你按哪個按鈕，教你「怎麼跟 AI 一起工作才會又快又準又不出包」。它把跟 AI 協作拆成四個能力（4D）——先想清楚誰做什麼（Delegation）、講清楚你要什麼（Description）、看得出它做得好不好（Discernment）、把關能不能負責地交出去（Diligence）。這四樣，正好可以變成我們梵熹「派工前的自檢清單」。
一、課程講了什麼（4 支影片逐字稿重點）
| 影片 | 這一支實際講了什麼（取自 CC） |
|---|---|
| 1 課程導論 Introduction | 主旨：學生早就在用 AI、雇主也期待畢業生會用，老師的角色是示範怎麼跟 AI 明智協作。目標是把 AI 當「思考夥伴」幫你設計課程、做教材、出作業與評量，同時守住教學價值不被稀釋。講師強調「沒人知道 AI 會走到哪，我們是一起摸索」，重點不是變專家，是學會問更好的問題。 |
| 2 4D 框架複習 Framework review | 把「用 AI」跟「精通 AI」分開：fluency＝當個負責任的 human in the loop，是增強你已經做得好的事，不是叫 AI 替你做（尤其學習場景，我們不要 AI 替學生做，要 AI 幫學生做得更好）。逐一拆四個 D，每個 D 各有三個子項（下表），並點出描述↔判別是持續迴圈。 |
| 3 用在課程設計 Course design | 核心是建立豐富的共享脈絡——把你的教學目標、對象、限制餵給 AI，它就從通用助理變成「懂你教法的同事」。三件事：定內容概念、排學習旅程、寫學習目標。神招：叫 AI 切換角色扮演你的學生「我會在哪裡卡住？每一段需要什麼背景？」等於隨時有一個學生焦點團體。範例貫穿全課：幫新聞系學生設計統計課（他們怕數學、又懷疑統計有用）。 |
| 4 用在教材與作業 Materials & assignments | 靠前面累積的脈絡，AI 已經知道你第四週的學習目標、學生的痛點，出的每份學習單／作業都能接上前面的鋪陳。示範把「虛無假設 vs 對立假設」出成作業：先講產品／過程／表現三種描述（格式、答案另頁、先打中誤解、用日常情境開頭、控制在十年級閱讀程度），AI 生出來後用判別挑好壞並「告訴 AI 為什麼好／壞」把脈絡養大。最後點出教育界最大挑戰：AI 已能寫出及格作業，沒有簡單解，得靠 diligence 跟同事、學生把標準講清楚。 |
4D 各是什麼（每個 D 拆三個子項，這是全課精華）
| D | 核心問題 | 三個子項（照官方拆法） |
|---|---|---|
| Delegation 分工 | 這件事，誰來做、怎麼拆？ | 目標與任務意識：先想清楚要達成什麼。 平台意識：知道各 AI 工具的能力與極限，選對的。 任務分配：整個專案裡人機各做哪段最划算。 |
| Description 描述 | 怎麼把要什麼講清楚？ | 成品描述：講清最終產出要有的特徵與品質。 過程描述：跟 AI 一來一回、逐步逼近。 行為描述：講清這東西該怎麼跟使用者互動。 |
| Discernment 判別 | 它做得好不好、我看得出來嗎？ | 成品判別：評產出的品質、相關性、有沒有效。 過程判別：這段人機協作到底有沒有效率。 行為判別：AI 自動做的事有沒有帶來好體驗。 |
| Diligence 盡責 | 能不能負責地交出去？ | 製作盡責：守法守倫理、注意偏差。 透明盡責：講清楚哪些是 AI 參與做的。 部署盡責：交付前查證、測準確、測穩定。 |
最該記住的一條：Description ↔ Discernment 是個迴圈。影片原話：描述完不是就好了，要用判別去看產出、調整、再改描述，「就像任何一場好對話，你們一起把理解建起來」。看不對就回頭修描述，一圈一圈逼近你要的東西——這正是我們「動手前先對齊、看結果再修、別打補丁」的骨架。CC 也點名三件補充：人類帶來的是創意、判斷、真實世界脈絡；AI 帶來的是速度、一致性、吞大量資訊的能力；「AI 起草了 email，但按下寄出的是你」。
教育者版對梵熹的直接用途（我們自己就在做課）：這門課教老師用 4D 備課、出教材，正好對上我們的 Namoh 變現課、胡沛琳排列課。影片那招「叫 AI 扮演你的學生，問它哪裡會卡」，做課綱、寫銷售頁、排學習旅程時可以直接拿來壓測；「先建共享脈絡再產出」對上我們讀完專案 01–06＋語氣準則才動手；「AI 已能寫出及格作業」的警示，也提醒我們課程的評量與練習要設計得考驗真理解，不是背名詞。
二、對梵熹最有用的 4 點
| 重點 | 為什麼對我們重要 |
|---|---|
| 4D 就是「派工前自檢表」 | Max 派任何一件事之前，先過四關：分工對不對、描述夠不夠清、驗收怎麼判、交付前查了沒。一張表就把我們一堆鐵則串起來。 |
| Delegation 治「亂派」 | 對上你的「看任務挑對模型／該不該先問人」。先問這活該人做、該 Haiku、該 Opus，還是要你點頭，省 token 也少翻車。 |
| Discernment 治「謊報」 | 判別＝報成功前要看得出好壞。正好對上你最在意的「報成功前必親自驗證」，把「工具說 ok」跟「真的成了」分開。 |
| Diligence 治「出包」 | 透明盡責＋部署盡責＝對外發佈前查證＋講清是 AI 做的。對上你的「發佈後附上線連結」「危險/對外動作要點頭」。 |
三、我們怎麼用（把 4D 套進派工前自檢）
| 4D 關卡 | 派工前先自問（過了才動手） | 對到梵熹現有機制 |
|---|---|---|
| Delegation 分工 | 目標講清了嗎？該人做還是 AI 做？該用哪個模型？要不要先問 Norick？能不能拆給多員工並行？ | 已在用挑模型階梯＋一次派多員工並行＋刪送付鑰先問人。 |
| Description 描述 | 成品長怎樣、行為怎樣講清了嗎？有沒有讀專案 01–06 資料＋語氣準則？台灣口吻紅線交代了嗎？ | 已在用CLAUDE.md／團隊鐵律自動繼承＋品牌語氣檢查。補強把「先講清成品規格再開工」明訂進 SOP。 |
| Discernment 判別 | 有可跑的 pass/fail 檢查嗎？我親自看過證據沒？糾正兩次還沒解，是不是該清掉重來？ | 已在用報成功前必驗證＋驗收關卡。補強每個 skill 交付都掛一條可驗證的判別條件。 |
| Diligence 盡責 | 對外／危險動作有沒有等 Norick 點頭？發佈後附上線連結了嗎？有沒有 push 備份？禁用詞掃過沒？ | 已在用遠端授權閘＋晚安 push 備份＋發佈附連結＋AI 對比句式掃描。 |
一句話收尾：我們梵熹這套（Max、多員工並行、挑模型、驗證關卡、授權閘、每小時存檔）本來就是 4D 的實作版。這門課的價值是給了一張四格自檢表，讓每次派工前都能快速對一遍，少忘、少錯、少打補丁。
本課帶來的優化（萃取自「課程優化提案」／落地狀態）
這門課我們學完，實際拿去改進的重點如下。綠＝已回灌團隊鐵律、可立刻生效；橘＝待 Norick 拍板；藍＝程式類由工程同事另辦或未來自建才用。
| 本課萃取的優化點 | 落地狀態 | 落在哪份規則／流程 |
|---|---|---|
| 交付前紅隊自審：銷售頁／課綱／客服稿交出前，先叫 Claude 扮「懷疑的目標客戶／學員」走一遍，指出哪裡看不懂、不買單、卡住，補完再交。 | 已套進鐵律 G 段 | G 段；sales-page-copy／course-brand-audit／brand-voice-check／client-intake 收尾 |
簡報｜Claude Cowork
課程 Introduction to Claude Cowork
來源 15 課；2 支有完整口白 CC＋官方影片說明
整理 2026-07-03
對到我們 Max ＋ 31 位員工的多員工協作
一句話：Chat 是「聊」，Cowork 是「一起做工」。你交代一件任務，Claude 直接動你的檔案、資料夾、App 去讀、去改、去產出真的成品，你在旁邊掌舵修方向。這正是我們讓 Max 帶 31 位員工做事的模式。這份把每一章重點列給你，並標我們已在用還是可補強。
一、課程講了什麼（逐課重點）
| 課 | 這一段的重點 |
|---|---|
| 4 交出第一個任務 口白 CC | 全課骨幹在這支。Cowork 讓你把整件任務丟給 Claude：在電腦上的它能找到並改、在雲端的走 Google Drive／Notion／Slack 連接器、在瀏覽器的走 Claude in Chrome。設定三步：①給它一個資料夾的存取權（改檔前會先問你）②接上工具連接器③接 Chrome。實測示範：一個塞滿幾個月 PDF／試算表／截圖／重複檔的 downloads 夾，你叫它「先掃描提計畫、分類、命名規則、標出可疑重複檔，動手前給我看計畫」，它提案後你發現兩個「重複檔」其實是要留的版本，改叫它移到 review 夾別刪，它就照調。核心迴圈：它提計畫→等你核准→才在你檔案系統動手。金句：「你外包的是工作，不是判斷（You're delegating the work, not the judgment）。」注意：session 存在本機、桌面 App 得開著它才跑得動。 |
| 9 Claude in Chrome 口白 CC | 把 Sonnet 4.5（電腦操作最強模型）帶進瀏覽器。示範幫忙裝潢：預算散在一份規劃文件＋好幾封包商往來 email，Claude 自己去把相關 email 與收據撈齊、即時更新試算表補上缺的數字，最後幫你草擬一封 email 給另一半——但寄出前的最後修改權還在你手上。安全是內建的：granular 權限控制它能做什麼、內建防 prompt injection、限制可用網站，遇到買東西這類敏感動作一定先問過才做。 |
| 1 什麼是 Cowork 官方說明 | 把最耗時的任務交給 Claude，回來就拿到成品：描述你要什麼、把它指向資料來源、走開。它從本機檔案、雲端工具、網路取材，綜合成試算表／簡報／文件／PDF 等精緻交付物，可同時跑多個任務。現於 Desktop 對所有付費訂閱者開放。 |
| 3 它能幫你做什麼 官方說明 | 排程任務：描述一次，Claude 就照每時／每日／每週／工作日或隨需執行。排程任務存下 prompt 週期跑，且能用一般 session 的一切（連接器、外掛、skill）。用 /schedule 或側欄 Scheduled 頁建立，可隨時暫停、編輯、隨需執行。 |
| 7 Skills：教它你的做法 官方說明 | skill-creator 會反問釐清、幫你把任何工作流建成 skill，免手動編檔（示範建一個圖片編輯 skill）。skill 可跨 Claude.ai／Claude Code／API 使用，開放 Pro／Max／Team／Enterprise。 |
| 8 Plugins：封裝團隊專業 官方說明 | plugin＝把整組能力＋規範打包給全團隊共用。官方以虛構 Silvern Capital 示範：跨多團隊用 Claude／Cowork，比以往大幅更快回應市場挑戰。 |
| 10 Claude for Microsoft 365 官方說明 | 跨 Outlook／Word／Excel／PowerPoint 在同一連續 session 工作、四個 App 間保留完整脈絡：分類收件匣→用公司範本起草備忘→用真實公式建市場規模模型→放進品牌簡報→排審查會議，一次對話完成。Excel／PowerPoint／Word 已上線，Outlook 為 beta。 |
| 2·5·6·11–14 純文字課 | 安裝設定、更快拿到好結果（任務越具體背景越清楚結果越準）、常駐背景（全域指令＋專案）、安全使用最佳實務、驗證 plugin 裡的 skill、分享給團隊、收尾——這 6 課為純文字教學，無影片。第 15 課為測驗。 |
二、對梵熹最有用的 4 點
| 重點 | 為什麼對我們重要 |
|---|---|
| Cowork 任務迴圈 | 「描述任務→它規劃執行→你掌舵」正是 Max 帶 31 位員工的運作骨架，官方把它講成標準工作法，我們照著收斂更順。 |
| 全域指令＋專案＝常駐背景 | 對上我們的 CLAUDE.md／團隊鐵律／每小時對折記憶——把該遵守的釘成常駐背景，不靠每次重講。 |
| Plugin 封裝團隊專業 | 「一人做、驗過、全隊共用」對上我們 121 個 skill 正本共用；驗證後再分享的紀律值得補進 make-skill 流程。 |
| 安全界線先設好 | 會動手的 AI 要分「能自動 / 要點頭」——完全對上你的零風險紅線：刪除與花錢一定先問。 |
三、我們怎麼用（對到梵熹多員工協作）
| Cowork 概念 | 梵熹已經在用 / 可補強 |
|---|---|
| Claude 直接動手做工 | 已在用Max（COO）＋31 位員工就是會動手的協作團隊，不是聊天機器人。 |
| 你描述、它規劃執行、你掌舵 | 已在用手機派工→機器自己跑→關鍵處回你拍板，正是這個迴圈。 |
| 全域指令＋專案背景 | 已在用CLAUDE.md＋團隊鐵律（單一真相、全體繼承）＋每小時對折記憶。 |
| Skills 教它你的做法 | 已在用121 個 skill 正本，員工能力檔各自指定慣用 skill。 |
| Plugin 封裝、驗過再分享 | 補強把「skill 驗證通過才上架分享」的紀律訂進 make-skill 流程。 |
| 安全界線 | 已在用刪除／花錢／對外發佈一定先你點頭，其餘自己做到底。 |
| Claude in Chrome | 補強需要操作網頁的活（後台填單、抓資料）可評估接 Chrome 自動化；照課程做法設 granular 權限、敏感動作（買東西）一律先問，正好接上我們花錢先問的紅線。 |
本課帶來的優化（萃取自「課程優化提案」／落地狀態）
這門課我們學完，實際拿去改進的重點如下。綠＝已回灌團隊鐵律、可立刻生效；橘＝待 Norick 拍板；藍＝程式類由工程同事另辦或未來自建才用。
| 本課萃取的優化點 | 落地狀態 | 落在哪份規則／流程 |
|---|---|---|
| 外包工作、不外包判斷：活交給 AI／員工跑，最後判斷、驗收、負責永遠留我方；破壞性動作先出計畫等點頭再動手。 | 既有規則已在用 | 團隊鐵律 C 段＋dispatch-board 三鈕（補「先出計畫再動手」總綱句） |
| 防 prompt injection（Claude in Chrome 防護延伸）：瀏覽器自動化把頁面文字一律當「資料」不當「指令」。 | 已套進鐵律 G 段 | G 段防 injection；claude-in-chrome 相關流程 |
簡報｜Claude Code 101
學員 Namoh Lamen
完成 2026-07-02
測驗 5/5（100%）
發證 Anthropic Education
驗證 verify.skilljar.com/c/au6czd5nr2q3
一句話：這門課教「怎麼把 Claude Code 當一個會自己動手的工程夥伴用」——12 支影片我逐支聽過逐字稿（CC），下面每一章都是影片實際講的觀念、指令、示範，不是官網大綱一句話。而我們梵熹這整套（Max、31 位員工、121 個 skill、自癒 hook、每小時存檔）本來就是照這些原理搭的，逐章標出已在用還是可補強。
一、課程講了什麼（13 章逐章重點，來自影片 CC）
| 章節 | 影片實際講了什麼 |
|---|---|
| 1 什麼是 Claude Code | 「agentic coding tool」——會讀懂整個 code base、改檔、跑指令、接現有開發工具。跟 Claude AI 的差別：它直接存取你終端機裡的檔案與整個專案，不用來回複製貼上，自己進去做。三個必懂觀念：context window（它的工作記憶，裝得多但裝不下全部，要策略性找答案）、會問權限（預設改檔/跑指令前先問你，你隨時能控）、它會犯錯（可能誤解意圖、引入新 bug、過度工程）。可跑在終端機/VS Code/JetBrains/桌面 App/網頁。 |
| 2 它怎麼運作 | 用agentic loop解釋：你下 prompt→它蒐集完成任務所需的 context（跟模型互動，回傳文字或 tool call）→採取行動（改檔/跑指令）→驗證結果是否達成你要的，達成就停、沒達成就再跑一輪。過程中你可隨時加 context、打斷、引導。context 滿了會自動 compact（決定哪些拿掉、哪些摘要）。工具是 agent 的骨幹，用語意搜尋決定何時呼叫。權限模式用 shift+tab 切換：default（每次問）、auto-accept（自動改檔但跑指令仍問）、plan（唯讀先出計畫）。 |
| 3 安裝 | macOS/Linux/WSL 用一行 curl 裝；Homebrew 也行但不會自動更新；Windows 用 PowerShell 的 Invoke-RestMethod 或 curl 或 winget。裝好進專案目錄跑 claude，選色系、登入（Pro/Max/Enterprise 帳號或 API key）。它能存取你啟動所在目錄及所有子資料夾。VS Code 裝有藍勾的 Anthropic 官方擴充、JetBrains 裝 plugin。要最新功能用終端機（功能先上）；想跟編輯器綁一起用 IDE；想背景跑用桌面；網頁版 claude.ai/code 只限 GitHub repo、可平行多 session。 |
| 4 你的第一個 prompt | 像跟任何 AI 助理講話一樣下 prompt。用 shift+tab 在 auto-accept 與逐次問之間切；plan mode 會用唯讀工具分析 code base、對不清楚的地方反問你，再回一份詳細計畫。影片實際示範：在專案根目錄按 shift+tab 進 plan mode，下 prompt「幫整個 app 加 dark mode、在 header 放一個切換開關、依現有 light 主題找對比色」，讓 Claude 先規劃再執行，最後可看到它做了什麼、怎麼推論的。金句：prompt 越具體越好。 |
| 5 Explore→Plan→Code→Commit | 「這門課只帶走一個東西，就帶這個工作流」。多數人直接叫 Claude 寫 code，結果後面一直得修正。Explore＋Plan 用 plan mode 最快（此時它不能改檔、只讀檔做研究）。示範 prompt：「我要在圖片上傳流程加 webp 轉換，找出該在哪做、要不要新依賴、怎麼下手」，它讀相關檔＋上網查＋出行動計畫。計畫階段是最好的糾正點（還沒寫任何 code）。技巧：給它測試套件當 source of truth 持續驗證、建 UI 時裝 Claude-in-Chrome 讓它自己開分頁測、同一問題一直卡就叫它把解法存進 CLAUDE.md。commit 前先跑一個 subagent code reviewer，再讓 Claude 用你的風格產 commit message。 |
| 6 Context 管理 | context 是工作記憶：每讀一個檔、跑一個指令、每則訊息都佔空間，且有限，所以要極力優化。快滿會自動 compact（摘要重點、丟掉不必要的 tool 結果，但可能掉細節）。指令：/compact 手動壓縮並保留記憶、/clear 從零開始無記憶、/context 看目前 context 有多大、哪類佔最多。判準：同一功能做不完但要續→compact；做完換新功能→clear（免舊對話帶偏見）。要跨 session 記得的放 CLAUDE.md。反直覺重點：prompt 寫太短反而更耗 context（逼它到處翻），講清楚一兩句更省。MCP server 預設把所有工具載進 context，不相關的關掉；skill 只載名稱與描述更省；subagent 跑在獨立 context，只要答案不要過程的活派給它。 |
| 7 Code review 宣傳片 | 嵌入 45 秒宣傳短片，只有配樂無口白。官方說明：Code Review 會在每個 PR 派一組 agent 平行找 bug、逐一驗證濾掉誤報、依嚴重度排序。 |
| 8 CLAUDE.md 檔 | 「Claude Code 最有用的部分之一」，給它對專案的持久記憶。沒有它時每次都得重新探索 code base、猜依賴。它是放在專案根目錄的 markdown，每次開 session 自動讀，內容等於接在你 prompt 前面——像 code base 的 onboarding 腳本。用 /init 讓 Claude 依 code base 自動生一份。示範內容：技術棧（Next.js 15 app router+Tailwind+Drizzle ORM）、指令（dev server/測試/lint）、code style（兩格縮排、優先 named export、API route 放哪、盡量用 server actions）。有記憶層級：專案級（根目錄，進版控給團隊）、使用者級（設定資料夾，跨所有專案，放個人偏好）。技巧：糾正它時明講「存進記憶」、用 @檔案路徑引用專案內文件、建議一開始先不放 CLAUDE.md、看它一直被糾正在哪再補，保持精簡只放必要。 |
| 9 Subagents | 專門化的助手，各跑在自己的 context window＋自訂 system prompt，做完只回一份摘要給主線、中間過程全部隔離丟棄。最大好處是省主線 context。經典例：在不熟的 code base 查「哪個 service 處理退款」——沒 subagent 的話 Claude 可能讀 15 個檔、跑多次搜尋、追多個函式呼叫，全塞進你的 context，就算你只要一個事實。用 subagent 就「有答案、沒有旅程」（代價是主線看不到它怎麼得出結論）。內建幾個：general-purpose（多步驟探索＋行動）、explore（快速搜 code base）、plan（plan mode 時研究分析）；也可自建。 |
| 10 Skills | 「每次跟 Claude 解釋團隊的 coding 標準、每次 PR 重講你要的回饋格式、每次提醒 commit message 格式——skill 解決這個」。skill 是一份 markdown，教 Claude 一次，之後相關時自動套用。Claude 讀你的請求、比對所有 skill 的描述、啟用符合的。存放：個人 skill 放 home 的 .claude/skills（跨專案）、專案 skill 放 repo 根的 .claude/skills（clone 的人自動拿到，放團隊標準/品牌指南/字型色票）。跟別的機制差別：CLAUDE.md 每次對話都載入（放「永遠用 TS strict」這種）、skill 只在符合請求時按需載入（只載名稱＋描述，不塞爆 context）、slash command 要你手打、skill 不用它自己認情境。金句：「如果你發現自己一直對 Claude 重複解釋同一件事，那就是一個等著被寫下來的 skill」。 |
| 11 MCP | Model Context Protocol 是開放標準，讓 Claude Code 接外部工具與資料源；你的 context 很多其實在別處（資料庫、生產力工具、公開 repo）。例：團隊用 Linear，加 Linear MCP server 就能帶進特定 issue；要某依賴的最新文件用 Context7 MCP。用 claude mcp add 加。兩種型態：HTTP（遠端、服務商託管）、STDIO（本機程序）。用 /mcp 看連了什麼、狀態、關掉不用的。三種 scope：local（只本專案）、user（跨所有專案）、project（.mcp.json 進版控，全隊自動拿到一樣的 server）。重點警語：MCP server 就算沒用也把 tool 定義加進 context，配太多會吃掉可用空間；有 CLI 版的（gh、aws）用 CLI 更省；MCP 工具超過 context 10% 會自動切 tool search mode（按需找工具但可能沒那麼準）。 |
| 12 Hooks | 讓你在 Claude Code 生命週期不同點自動跑指令。跟其他機制最大差別：hook 是確定性的、一定會跑。「你在 CLAUDE.md 叫它每次改檔後跑 prettier，大多會、但有時不會；hook 讓它每次都跑、無例外」。配在 settings.json：挑事件、選 matcher（哪個工具）、給指令。事件：UserPromptSubmit、PreToolUse（工具呼叫前）、PostToolUse（完成後）、Notification、Stop。最常見：PostToolUse 配 matcher Edit/MultiEdit 自動格式化（TS 用 prettier、Go 用 gofmt、Python 用 ruff）。PreToolUse 可擋 tool call：hook 收到工具名與輸入的 JSON，exit code 2 ＝擋下（stderr 訊息回饋給 Claude 讓它知道為何被擋）、exit 0＝放行。用來把硬規則變「保證」而非「建議」：擋寫生產設定、擋含 rm -rf 的 bash、擋 commit 到 main。放 .claude/settings.json 進版控全隊共用，用 CLAUDE_PROJECT_DIR 引用專案內腳本。金句：「要每次都發生、不容失手的事，別放 prompt，放進 hook」。 |
| 13 課末測驗 測驗 | 無影片。7 題（5 知識＋2 問卷），知識題 5/5 全對通過發證。 |
二、我學到、且對我們最有用的 5 點（從 CC 萃取）
| 影片講的觀念 | 為什麼對我們重要 |
|---|---|
| 「只帶走一個就帶 Explore→Plan→Code→Commit」，計畫階段是最好的糾正點 | 影片明講「多數人直接叫它寫 code、結果一直修正」——正是你最厭惡的「邊做邊改打補丁」。plan mode 唯讀先出計畫，就是「動手前先檢查、一次做對」。 |
| prompt 寫太短反而更耗 context | 反直覺但關鍵：講不清逼它到處翻檔、更燒 context。對上你「具體大於模糊」——講清楚一兩句既省 token 又做得準。 |
| subagent「有答案、沒有旅程」，各跑獨立 context | 查退款走哪個 service 這種活派 subagent，只收摘要不污染主線——這就是我們「一次派多員工並行、保護主線」的官方原理。 |
| hook 是確定性的、exit code 2 擋危險操作 | 「要每次都發生的事別放 prompt、放進 hook」——正是我們自癒 hook、授權閘、擋 rm -rf、每小時存檔的底層邏輯，官方認證這條路對。 |
| CLAUDE.md 要精簡、被糾正在哪才補 | 影片建議「先不放、看它一直被糾正在哪再補、保持精簡」——直接點名我們的 MEMORY 該剪枝，別讓記憶塞爆 context。 |
三、我們怎麼用（影片概念對到梵熹現有系統）
| 影片概念 | 梵熹已經在用 / 可補強 |
|---|---|
| Agent 會動手＋會問權限＋會犯錯 | 已在用Max（COO）＋31 位員工就是會動手的 agent；危險/對外動作要 Norick 點頭＝影片的「會問權限」。 |
| Explore→Plan→Code→Commit | 補強把「大任務先進 plan mode、計畫階段先對齊再動手」明訂進派工 SOP。 |
| CLAUDE.md 自動讀＋記憶層級 | 已在用工作台/CLAUDE.md＋團隊鐵律（單一真相、全體繼承）＋使用者級 MEMORY。補強依影片建議剪枝瘦身。 |
| Subagents 獨立 context 平行 | 已在用「一次最多派 13 位並行、只收摘要」鐵則。 |
| Skills 按需載入 | 已在用121 個 skill，個人 skill 在 ~/.claude/skills、員工能力檔各自指定慣用 skill。 |
| Hooks 確定性自動化 | 已在用自癒 hook、遠端授權閘、每小時存檔、擋危險命令 hook。 |
| MCP 接外部＋控 context | 已在用Notion／Higgsfield／Canva 等 MCP。補強依影片「沒用的 server 關掉、超 10% 會切 tool search」定期清點。 |
| Context 指令（/compact /clear /context） | 已在用每小時對折存檔成記憶。補強換新任務前 clear、續同任務用 compact 的判準寫進 SOP。 |
| Code review 當守門 | 補強commit 前跑 subagent code reviewer，讓「測試交付官／資安守門員」照這套 PR 審查法運作。 |
本課帶來的優化（萃取自「課程優化提案」／落地狀態）
這門課我們學完，實際拿去改進的重點如下。綠＝已回灌團隊鐵律、可立刻生效；橘＝待 Norick 拍板；藍＝程式類由工程同事另辦或未來自建才用。
| 本課萃取的優化點 | 落地狀態 | 落在哪份規則／流程 |
|---|---|---|
| MCP 瘦身、CLI 優先：每個 session 只開該任務要的 MCP、有 CLI 版（gh／aws／wrangler）優先 CLI 或包 skill、tool 佔比別超 context 10%。 | 待 Norick 拍板 | reference-mcp-inventory 加「預設關、按需開」 |
| 硬鐵則改用 hook 落地：禁刪除／禁 push main／每小時存檔提醒改 pre-tool-use hook 強制，別只靠 prompt 自律。 | 危險命令部分 既有規則已在用 · 其餘 程式類·工程另辦 | ~/.claude/settings.json hooks |
| 新專案 CLAUDE.md 從空起手：別預塞規則，先跑、真的一直 course-correct 到的才寫進去。 | 待 Norick 拍板 | CLAUDE.md 新專案 SOP |
簡報｜Claude Code in Action
課程 Claude Code in Action
講師 Stephen Grider
來源 影片 CC 逐字稿（非大綱推測）
整理 2026-07-03
一句話：講師 Stephen Grider 開場就講明分四段——「什麼是 coding assistant → Claude Code 憑什麼突出 → 真的在專案上跑一遍 → 怎麼榨出最大價值」。這門課的骨幹是工具使用（tool use）：他花很大篇幅拆給你看，語言模型本身只會吃文字吐文字，是 coding assistant 在你的請求後面偷偷加上「你想讀檔就回
read file: 檔名」這種格式化指令，模型照回、助手才真的去讀檔——這就是 tool use。而 Claude（Opus／Sonnet／Haiku）最強的就是這件事。以下每一課都用他影片實際講的例子重寫，不是大綱猜的。
一、逐課實際重點（照影片 CC 內容）
| 單元 / 課 | 影片實際講的（含他舉的真實例子） |
|---|---|
| 什麼是 coding assistant | 助手做事三步：蒐集情境 → 擬定計畫 → 採取行動。頭尾兩步都要「對外界做事」（讀檔／抓文件、跑指令／改檔）。關鍵洞見：語言模型單獨存在時「take in text, return text，就這樣」，沒有讀檔能力。tool use 就是助手在請求後追加格式化指令、模型回 read file: main.go、助手真的去讀再把內容餵回。Claude 系列特別擅長判斷工具何時用、怎麼組合。他點名三個好處：更強工具使用能扛更複雜任務、Claude Code 可擴充（隨時加新工具）、更好的安全性（靠搜尋 codebase 而非把整個 codebase 上傳到外部伺服器做索引）。 |
| Claude Code in action（實測 demo） | 他當場跑四個 demo 證明工具使用威力： ① chalk 效能優化——JS 生態第 5 名下載量套件、上週 4.29 億次下載；Claude 自建 to-do、跑 benchmark、用 CPU profiler 找慢因、改完某操作吞吐量提升 3.9 倍。 ② CSV 流失分析——串流平台使用者資料丟進 Jupyter notebook，Claude 逐格寫、逐格執行、看結果再調下一格找流失原因。 ③ UI 產生器 App + Playwright MCP——給 Claude 開瀏覽器的工具，它自己截圖看現況樣式再改 CSS，反覆迭代。 ④ GitHub PR 審查抓資安——Terraform 定義 AWS 基礎設施，DynamoDB 每晚拉使用者資料存進「跟外部行銷夥伴共享的 S3 bucket」；工程師幾個月後加一行把 email 也寫進去＝洩漏 PII，Claude 在自動 PR 審查裡看懂整條資料流、標出洩漏給外部夥伴。 |
| Adding context（餵情境） | 首次進專案先跑 /init，Claude 深讀整個 codebase 後生成 CLAUDE.md（每次請求都會帶上）。三層 CLAUDE.md：專案級（進 git 共享）、local 級（不進版控、只給自己）、機器級（全機所有專案套用）。改規則可手動，也可打 # 進 memory mode 讓 Claude 智慧合併（他示範叫它「別那麼常寫註解」）。用 @檔名 直接把某檔內容帶進請求；甚至可在 CLAUDE.md 裡 @ 掉 schema.prisma，之後問資料結構免再讀檔。 |
| Making changes（動手改） | 截圖後用 Ctrl+V（不是 Mac 慣用的 Cmd+V）貼進 Claude Code 指定位置。示範把 placeholder 置中、把技術味的「String Replace Editor」字樣換成使用者友善提示。兩招加強火力：Plan mode（按 Shift+Tab 兩次）讓它多讀檔、先出計畫再實作；thinking（觸發詞 think／ultra-think，字愈重給的 token 預算愈大）。心法：planning 管廣度（要橫跨多處、多步驟時用）、thinking 管深度（鑽一段難邏輯／抓 bug 時用），兩者可疊用，但都額外燒 token。改完可叫它 stage + commit，自動寫描述式 commit message。 |
| Controlling context（控情境） | 四個實戰技巧：Escape 打斷 Claude 當下動作、改指路；Escape 兩下倒帶對話歷史，跳回前一則訊息、把中間那串（例如卡在裝套件的來回）丟掉，保留它已讀懂 auth.ts 的情境；compact 把目前對話摘要壓縮（學到很多、想帶進下個任務時用）；clear 整段清空重來（要換完全無關的新任務時用）。他把 Escape+memory 搭起來根治 Claude 重複犯的錯（例如老是去讀一個不存在的測試設定檔）。 |
| Custom commands（自訂指令） | 在 .claude/commands/ 下建 audit.md，檔名就是指令名，建完要重啟 Claude Code。示範 /audit：掃依賴、有漏洞就修、再跑測試確認沒壞。指令可收參數：文字裡放 $ARGUMENTS 佔位，跑 /write-test 某檔路徑 時就替換進去（參數不限檔路徑，任何字串都行）。 |
| MCP servers（接外部工具） | 在終端機（不是 Claude Code 裡）跑 claude mcp add playwright ... 裝好、給 Claude 控瀏覽器的能力。嫌每次都要按同意，可在 .claude/settings.local.json 的 allow 陣列加 mcp__playwright（兩條底線）免權限彈窗。實戰：叫 Claude 開 localhost:3000、自己生一個元件、看產出原始碼評估樣式、再回頭改 generation.tsx 裡的 prompt——結果比他預期好很多。 |
| GitHub integration（GitHub 整合） | 跑 /install-github-app 走流程，會裝 Claude Code app、填 API key、自動開一個 PR 塞進兩個 GitHub Action：① 提及支援（在 issue／PR 用 @claude 交辦）、② PR 審查（開 PR 就自動審）。可客製：他示範讓 mention 流程先 setup、起 dev server，再讓 Claude 用 Playwright MCP 在 Action 裡開瀏覽器。重要坑：在 Action 裡要逐一列出每個權限，MCP 每個工具都要個別列，沒有 mcp__playwright 那種一次全放的捷徑。 |
| Hooks（介紹 + 定義 + 實作） | hook 讓你在工具執行「前 PreToolUse／後 PostToolUse」跑指令。設定寫在 settings 檔（全域／專案／個人三種），或用 /hooks 指令。實作案例：擋讀 .env——因為要「阻止」所以必用 PreToolUse；matcher 要同時抓 Read 和 Grep（grep 也能讀檔內容），用 | 分隔；指令跑 node ./hooks/read_hook.js，從 stdin 拿到 JSON（含 tool_name、tool_input），判斷路徑含 .env 就 console.error 提示 + process.exit(2)（退出碼 2＝擋下並把 stderr 當理由回饋給 Claude；退出碼 0＝放行）。改 hook 後一定要重啟。 |
| Useful hooks（實用 hook） | 兩個進階範例：① 型別檢查 hook——改完 TypeScript 檔就跑 tsc --noEmit，把型別錯誤在 PostToolUse 立刻回饋給 Claude（解決它改了函式定義卻不去更新其他呼叫點的老毛病）；沒型別的語言可改用「每次編輯就跑測試」達到同效果。② 防重複查詢 hook——動到 queries 目錄時，用 Claude Code SDK 另起一個 Claude 去看這次改動跟現有查詢有沒有重複，有就回退出碼 2 叫主 Claude 改用既有查詢、別造重複程式碼與新檔。代價是每次改都多花時間與費用，建議只盯少數重要目錄。 |
| The Claude Code SDK | SDK 讓你程式化呼叫 Claude Code，有 CLI／TypeScript／Python 三種，跟你在終端機用的是同一個 Claude Code、同一組工具。最適合當更大流程／工具的一環（前面那個 hook 就是）。一個坑：SDK 預設只有讀權限（read／grep／list），要寫檔得在呼叫的 options 加 allowedTools: ['edit'] 或在 settings 檔開權限。 |
二、我學到、對梵熹最有用的 5 點
| 學到什麼 | 為什麼對我們重要 |
|---|---|
| tool use 才是核心，不是「會寫字」 | 模型只會吃文字吐文字，真正做事靠工具。這解釋了為什麼我們整套 121 skill＋MCP＋員工 agent 的價值在「工具編排」而非文字生成——選對工具、組合對，比堆詞重要。 |
| 控 context 是一整套主動動作 | Escape 打斷、Escape 兩下倒帶丟掉無關來回、compact 壓縮、clear 清空——正好對上你「每小時對折存檔成記憶」「換任務就清乾淨」「糾正兩次就重開」。我以前只會 compact，現在知道倒帶保情境更省。 |
| planning 管廣度、thinking 管深度 | 這條分工很實用：跨多檔多步驟的派工開 Plan mode，鑽單一難題／抓 bug 用 ultra-think。直接可寫進派工 SOP，不再一律硬開兩個燒 token。 |
| hook 用退出碼 2 擋動作＋回饋理由 | PreToolUse 擋 .env、PostToolUse 跑型別檢查回饋——這正是我們自癒 hook／授權閘的官方機制。退出碼 2 同時「擋下＋給理由」的設計，值得對照我們的授權閘寫法。 |
| hook 裡用 SDK 另起 Claude 當守門 | 防重複查詢那招（hook 內用 SDK 開第二個 Claude 審查）＝「用一個 agent 守另一個 agent」。對上我們多員工並行時，可設一個把關員工審其他員工產出。 |
三、我們怎麼用（課程實招對到梵熹現有系統）
| 課程實招 | 梵熹已經在用 / 可補強 |
|---|---|
| tool use / 工具編排 | 已在用121 skill＋Notion／Higgsfield／Canva／Airtable 等 MCP 已串，本質就是給 Claude 更多工具去組合。 |
| /init 生 CLAUDE.md、三層情境 | 已在用工作台 CLAUDE.md＋MEMORY.md 就是專案級＋機器級情境，開頭先讀再接手。補強MEMORY 已過肥，照課程「只餵相關」精神剪枝。 |
| @檔名 精準指路 | 補強大任務派工時，直接 @ 相關檔給員工，少讓它盲搜、省 context。 |
| 控 context 四招（Escape/倒帶/compact/clear） | 已在用每小時對折存檔＋換任務清空。補強把「倒帶丟無關來回」納入長對話操作習慣。 |
| 自訂 slash command | 已在用121 skill＋觸發詞（一句話喚起）。補強高頻派工流收斂成原生 .claude/commands 指令。 |
| Playwright MCP 開瀏覽器自驗 | 已在用官網 E2E 驗證、發文前預覽已走 Playwright。對上你「報成功前必親自驗證」。 |
| GitHub Action 自動開/審 PR | 已在用晚安流 push gh 備份＋launchd 自動同步。補強裝 /install-github-app 讓它自動審 PR 當守門。 |
| hooks（PreToolUse 擋 / PostToolUse 檢查） | 已在用自癒 hook、遠端授權閘、每小時存檔 hook。補強照「擋 .env」思路加一條擋敏感檔／金鑰外洩的 PreToolUse hook。 |
| Claude Code SDK 程式化 | 已在用Max／hermes-agent 就是把 Claude Code 包成前台工頭的實作。補強注意 SDK 預設只讀，寫檔要顯式開權限。 |
本課帶來的優化（萃取自「課程優化提案」／落地狀態）
這門課我們學完，實際拿去改進的重點如下。綠＝已回灌團隊鐵律、可立刻生效；橘＝待 Norick 拍板；藍＝程式類由工程同事另辦或未來自建才用。
| 本課萃取的優化點 | 落地狀態 | 落在哪份規則／流程 |
|---|---|---|
| 擋金鑰明文的 pre-tool-use hook：exit 2 擋掉對 .env／.vault_key／.enc／金鑰夾的 Read／Grep（Grep 也讀得到內容要一起擋）。 | 程式類·工程另辦 | reference-claude-safety；settings.json preToolUse |
| 改檔後自動語法檢查 hook：改 .py 跑 py_compile、.json 跑 json.tool、.sh 跑 bash -n，錯了 exit 2 回灌 Claude 自己修。 | 程式類·工程另辦 | settings.json postToolUse；鐵律 B |
| GitHub Action 自動 PR 審查：關鍵 repo（fansi-brand-site）部署前先抓洩鑰／PII／後台斷線。 | 待 Norick 拍板（要花 API 額度） | system-autosync-pipeline，先報成本待點頭 |
簡報｜Claude Platform 101
課程 Claude Platform 101（開發者平台）
依據 影片逐字稿（CC）重寫 · 2026-07-03
來源 anthropic.skilljar.com 課內嵌 YouTube
發證單位 Anthropic Academy
一句話：Claude Code 101 教「怎麼把 Claude 當工程夥伴用」；這門 Platform 101 更底層，教「怎麼用 Claude Developer Platform（API）自己蓋一個會動手的 agent」。全 14 課、12 支影片我逐支聽過逐字稿（CC），下面每一課都是影片實際講的觀念、程式示範與案例（不少課用同一個「建築法規合規審查 agent」貫穿示範），不是官網大綱一句話。逐課標出我們已在用還是可補強。
一、課程講了什麼（14 課逐課重點，來自影片 CC）
| 單元 A：平台是什麼、怎麼發第一個呼叫 | |
| 課／來源 | 影片實際講了什麼 |
|---|---|
| 1 什麼是開發者平台 有CC | 平台＝用程式方式建構 Claude 的基礎建設：REST API＋各語言 SDK＋CLI＋console（管金鑰、看用量、部署 managed agents、測 prompt）。三層心法：primitives（messages API、tool use、files、web search、code execution、MCP、skills 這些你實際呼叫的積木）→ infrastructure（managed agents、retries、queues、observability，一個呼叫變一千個時撐住場面的管線）→ controls（dashboards、evals，上線後團隊在轉的旋鈕）。口訣「build with primitives, scale on infrastructure, run with control」。示範：help desk app 用 messages.create 依工單草擬回覆——定 client、選 model（簡單任務用 Haiku）、max_tokens 限長度、system prompt 放角色與語氣、messages 陣列放 user 工單內容。金句：你不是從零蓋聊天機器人，是「把 Claude 接進已存在的產品」。 |
| 2 你的第一個 API 呼叫 純文字課 | 純程式碼教學課，無口白影片。動手組 messages 結構、送出、讀回傳——所有後面東西的地基，先讓最小呼叫跑通。 |
| 單元 B：教會你的 agent（挑模型 / loop / tool use / thinking） | |
| 3 挑對模型 有CC | 「預設用最聰明的，帳單會嚇到你；挑最便宜的，output 可能撐不住」。三階：Opus（最聰明最慢最貴，深度推理/複雜分析/多步驟 coding/細膩寫作）、Haiku（最快最便宜，高量低複雜度如分類/抽取/路由）、Sonnet（夠快夠強、多數 production 用、成本中段）。核心方法：寫 code 前先建 eval（20–30 個真實工作的代表例子＋你對「好」的評分），從 Haiku 往上試，品質過就省一大筆、不過再升 Sonnet、真的需要才 Opus。示範把同一 prompt 送三個模型看 latency 與 token：Opus 最慢最漂亮但對「兩句定義」是浪費、Haiku 常一秒內給稱職答案。金句：「對的模型＝output 你真的敢出貨的最便宜那個」。真實 app 會在同一 endpoint 內按任務路由（文件分類 Haiku、客戶更新 Sonnet、RFP 回覆才 Opus）。 |
| 4 Agent loop 拆解 有CC | 單一 API 呼叫只回一個回應；要取代工作流程，Claude 得「行動→看結果→決定下一步→繼續」＝agentic workflow。agent＝自動跑訊息迴圈兩端、無人介入的 Claude。最簡實作：①送帶工具的訊息給 Claude →②它回最終答案或呼叫你定義的工具 →③你的 code 執行工具 →④結果送回 Claude →重複直到 stop_reason ＝ end_turn。示範接一個假的 get_weather、問「Austin 今天穿什麼」：turn 1 stop_reason＝tool_use（它要呼叫 get_weather）、你的 code 回溫度與天況、turn 2 stop_reason＝end_turn 給最終建議。金句：「agent 就是 loop 裡的 Claude——觀察、決策、行動、重複；你擁有 loop 與工具，Claude 擁有推理」。不想自己管 loop 時，managed agents 幫你在 Anthropic 基礎建設上跑同一個 loop。 |
| 5 什麼是 tool use 有CC | tool ＝你定義並暴露給 Claude 的函式：描述它做什麼、吃什麼輸入，Claude 決定何時呼叫、但執行的是你的 code（Claude 請求→你執行→結果回 Claude）。工具是含 name／description／input schema 的 JSON schema，description 是 Claude 判斷要不要呼叫的依據，寫得含糊是 agent 誤觸/抓不到工具的頭號原因。示範多工具（get_weather＋get_forecast），用 switch 依 name 分派，加第三個工具就「陣列加一個、switch 加一個 case」。痛點：手寫一堆 code＋為每個函式手刻 JSON schema＝寫兩次。解法 tool runner（TS/Python/Ruby SDK 內建）：把你真正的函式丟給它，它讀型別與 docs 自動生 schema、內部處理整個 tool-use/tool-result 迴圈，程式碼縮到「描述工具→送 prompt→等結果」，runner.untilDone 回最終訊息。 |
| 6 什麼是 thinking 有CC | extended thinking：Claude 回答前先一步步推理，產生內部 reasoning tokens（chain of thought），你能在回應裡看到推理過程再看最終文字。Opus 4.7 起 thinking 是adaptive——不用挑 token budget，開了它自己動態決定何時想、想多久；用 effort 參數調深度（low/medium/high/extra high/max，放在 output config 內、預設 high）。適合：數學、多步邏輯、code debug、法規分析、任何要權衡取捨/比較選項的事；分類、抽取、樣板這種跳過它（只增延遲與成本、不改善結果）。示範規劃舊金山出發、兩個停點、權衡天氣與車程的公路旅行——看得到 thinking blocks 在權衡。案例：合規審查 app 開 adaptive thinking，能抓出「第三節風載規格與材料規格衝突」這種跨段落矛盾。 |
| 單元 C：擴充你的 agent（內建工具 / Skills / MCP / context） | |
| 7 內建工具 有CC | 有些能力夠常見，Anthropic 直接出廠內建，你不寫 code、不架 sandbox，只要宣告工具、Anthropic 幫你跑。這些 server tools 跑在 Anthropic 基礎建設上、不需要 agent loop（Claude 自己呼叫、結果回在同一個 response 裡）：web search（搜網、帶引用）、code execution（在 sandbox 寫並跑 Python）、web fetch（抓 URL 全文）。回應會多 server_tool_use、code_execution_tool_result 等新 block 型別。另一類 client tools 跑在你的 code 端（SDK 內建 schema），例：memory（跨 session 讀寫記憶）、bash（持久 shell 跑指令）。案例：web search 撐一個 fact-check endpoint 對照即時網路驗證草稿裡每個數字與法規宣稱——但提醒「網路驗證過不代表就是真的，永遠複查 Claude 的結果」。 |
| 8 Skills 有CC | skill ＝一包指示（skill.md，可帶 helper 檔）上傳一次、之後 attach 到任何 messages.create；你在教 Claude「你怎麼做這件事」（你的狀態報告格式、審查清單、release notes），它讀了照你的 shape 產出。skill vs tool：tool 是「Claude 能做什麼」（連資料與動作、別的東西去執行）；skill 是「你要它怎麼做」（一份 playbook，它讀了照著走，有時會自己跑 bundle 腳本）。skill 也不會全載進 context，只載 name＋description，agent 決定要用時才載入。示範狀態報告產生器：規則（章節/語氣/怎麼摘要 blocker）放在 skill、活動 log 只是一個字串傳入；用 client.beta.messages.create＋beta header（skills 當時是 beta）、container.skills 掛上（可疊多個）、常搭 code execution。價值：整個 feature 標準化 output，每個 PM 拿到同結構同語氣，沒人再複製貼模板。 |
| 9 MCP 有CC | 「有 tools、skills、connectors 了，為何還要 MCP？」情境：agent 要同時從 Asana 拉任務、查 Google 日曆、搜 Slack——用自訂工具你得寫三個整合還要每次某服務 API 變就維護，恭喜你在養一堆第三方 wrapper。MCP 把維護責任移給服務商：Asana/Slack/Google 各自發布 MCP server，透過標準協定暴露自己的工具、schema、驗證，你什麼都不用改。一句話分工：tools 給你自己的東西、skills 給你的流程、MCP 給別人的東西。示範接 Linear MCP：mcp_servers 宣告連線（type/url/name/選填 auth token），完全沒寫任何 tool schema——Claude introspect server、拿工具清單自己挑（當時 beta，注意 beta header）。重點：MCP server 常暴露超多工具、且會佔 context，可預設全關再只開需要的（例：能搜 Slack、列頻道，但不能貼文/刪除），避免 Claude 手滑替你寫東西。 |
| 10 Context 管理 有CC | 「一百萬 token 聽起來很多，但你在跑真的 agent 時比想像中更快用完」。context ＝Claude 每一輪看到的全部（system prompt、訊息歷史、工具定義、工具結果、附檔、skills、thinking blocks），進出都要付費、滿了請求直接失敗，目標不是塞下全部、是「塞對的進去」。Anthropic 公布四個 pattern（三個是 API 一級功能、一個是設計法）：①just-in-time（別預先載全部，agent 要時才用工具拉——合規 agent 不把整本建築法規塞 system prompt，要哪節才 lookup）②server-side compaction（對話變長時把舊輪摘要成一塊，設 context management key＋type，跨門檻自動摘要）③prompt caching（標記穩定部分如 system prompt/工具定義/長文件跨呼叫重用、成本一小截；system prompt 4000 token 一小時叫 100 次，caching 是「能用的帳單」與「財務打電話來」的差別）④memory tool（跨 session 存活的偏好/筆記/上週決定，Claude 用 tool 讀寫 memories 目錄、後端你自己實作、Anthropic 自動注入「開工前先查 memory」的系統指示）。真實 app 四個一起疊，按「壞在哪」挑對應的。 |
| 單元 D：Managed agents 與用 Claude Code 落地 | |
| 11 什麼是 managed agents 有CC | managed agents ＝一套「大規模建構與部署 agent」的 API：你定義 agent（工具/人設/能力）、配 sandbox 環境（套件與網路控制）、從自家 app 觸發 session，Claude 在隔離容器裡做事（完整檔案系統、bash、web search）。底層還是 agent loop，只是託管在 Anthropic 基礎建設。示範 Kanban board：把工單拖到 in progress 自動觸發 session——「優化網站效能」工單指向預裝 Lighthouse+Puppeteer 的環境、掛上 GitHub repo，Claude 跑稽核、壓圖、inline CSS、defer script，每個 tool call 即時串回看板；一個獨立的 grader（自己的 context window）依 rubric（Lighthouse >90、無 render-blocking、圖片 lazy load）評分、Claude 讀回饋再修到 96；還能同時拖第二張工單＝兩個 session 兩個容器平行。另示範 SaaS 訂閱調價追蹤 agent（搜網比價→Python 成本分析→Excel skill 寫摘要→MCP 貼 Slack＋建 Asana 任務→memory 記上週數據，這週報「雲端運算比上週降 15%」）與多 agent 事故協調（coordinator 分派三個專家、各自 context、memory 認出「像兩週前 TTL 設錯那次」）。金句：「你定義 done 長什麼樣，Claude 做到那裡為止」。 |
| 12 建你的第一個 managed agent 有CC | 手刻 loop（while、stop_reason switch、tool 執行）對很多 feature 是對的 shape；但當 loop 要跑很久（幾分鐘甚至幾小時、跨多工具、要存狀態、網路斷了要能續）就別跑在自己 server、委派出去＝managed agent。四個 primitive（有順序）：agent（人設/model/system prompt/工具集，可重用）→ environment（跑的地方，雲/本機/網路設定）→ session（一次執行）→ events（進出的訊息：你的 prompt、agent 動作、tool call、結果、回覆）。你不再跑 while loop，而是「送 events、讀 events」。示範最小 agent（建檔→數行數→回報）用 agent 內建 file/bash/web 工具集免自定義；關鍵細節：先開 event stream 再送 kickoff 訊息（stream 只送開啟後的事件）。要看的三種事件：agent.message（Claude 文字）、agent.tool_use（挑了哪個工具）、session.status_idle（做完）。每個 API 帳號預設就開通、免申請。案例：檔案清理 agent 讀目標結構規格、走亂資料夾、歸位、封存重複與 0 byte 垃圾、放不準的標記出來，一個 session 對上千檔案跑幾分鐘。取捨：loop 會太長/做太多/要抗中斷就用 managed；要完全掌控就手刻 loop。 |
| 13 用 Claude Code 建構 有CC | 手寫呼叫 API 的 code 沒問題，但更快的路是讓 Claude 幫你寫。示範：一個 TS 檔有兩個 stub（get_weather 接城市回天況、run 想用 TS SDK 的 tool runner），Claude Code 有內建 skill「Claude API」（用 /claude-api 呼叫，或偵測到你在用 TS SDK 時自動觸發；沒有的話 /plugin marketplace anthropic/skills）。給一句 prompt（點名檔案、pattern、end state），Claude Code 就填好 get_weather 與 run、對著型別跑、在檔尾追加呼叫、執行腳本、報 output，錯了讀錯誤訊息原地修——它建了 Zod 工具解析輸入輸出、照要求做出 tool runner。金句：多數對 Claude API 寫的東西 shape 都一樣（定工具→交給 runner→回結果），不必每次憑記憶手打，stub 好檔案交給 Claude Code、你只 review diff。 |
| 14 課末測驗 測驗 | 無影片。驗收對 API 請求結構、agent 決策、context 限制、工具權限、成本控制的理解。 |
二、我學到、且對我們最有用的 5 點（從 CC 萃取）
| 影片講的觀念 | 為什麼對我們重要 |
|---|---|
| 「對的模型＝output 你真的敢出貨的最便宜那個」，用 eval 從 Haiku 往上試 | 官方把「按任務挑模型」講成用 20–30 個真實例子先跑 Haiku、不行才升——正好對上你定版的「看任務挑對模型」鐵則與 pick_model()／claude_ladder.py。 |
| agent loop：跑到 stop_reason＝end_turn 為止，「你擁有 loop，Claude 擁有推理」 | Max 與 31 位員工每天跑的就是這個迴圈；理解 tool_use/end_turn 的切換，才調得動並行派工與驗收。 |
| 工具的 description 寫含糊＝agent 誤觸的頭號原因 | 直接點名我們自訂工具/skill 描述要寫清楚——這也是「一次做對、不打補丁」在工具層的體現。 |
| context 四 pattern：just-in-time／compaction／caching／memory | 官方把「省 context」拆成四招，對上我們「每小時對折存檔成記憶＋重開不准忘」；prompt caching 更是直接的省錢招（穩定的 system prompt 重用）。 |
| managed agents：「你定義 done，Claude 做到那裡」，長活委派出去 | Kanban 拖工單自動觸發＋grader 依 rubric 評分再修——這正是我們交付看板＋驗收關卡的官方版；長活（剪片、清檔）可評估交平台託管。 |
三、我們怎麼用（影片概念對到梵熹現有系統）
| 影片概念 | 梵熹已經在用 / 可補強 |
|---|---|
| 三層心法（primitives/infrastructure/controls） | 已在用Max、員工、skill 底層都靠 Claude API；claude_ladder.py 統一呼叫＝我們的 infrastructure 層。 |
| 挑對模型＋eval 從 Haiku 往上 | 已在用pick_model()：對話 Sonnet、瑣事 Haiku、高難度 Opus、資安封頂 Opus，塞車自動退。補強建幾組真實 eval 例子定期校準。 |
| Agent loop（tool_use↔end_turn） | 已在用Max＋員工就是一群在跑 agent 迴圈的執行體。 |
| Tool use＋清楚的 description | 已在用發 IG／剪片／查金鑰／推 LINE 全靠工具呼叫。補強依影片把工具描述寫更清楚、權限白名單收緊。 |
| Thinking（adaptive＋effort） | 補強明訂「高難度派工開 thinking、瑣事關掉省 token」進派工 SOP。 |
| 內建工具（web search/fetch/code exec） | 已在用social-listening、market-watch、deep-research 靠上網蒐集與查證。 |
| Skills 按需載入（教流程） | 已在用121 個 skill＝「教 Claude 你怎麼做」的 playbook，員工各自指定慣用 skill。 |
| MCP 接外部＋預設關再開 | 已在用Notion／Higgsfield／Canva／Gmail 等 MCP。補強依影片「預設全關、只開需要的」收斂寫入權限。 |
| Context 四 pattern＋prompt caching | 已在用每小時對折存檔成記憶＝compaction＋memory。補強評估對穩定 system prompt 開 prompt caching 省錢、MEMORY 剪枝。 |
| Managed agents（定義 done＋grader） | 已在用交付看板＋驗收關卡＝rubric 評分精神。補強評估把 Max 後端長活的 loop 交平台託管，省維護。 |
| 用 Claude Code 建構 | 已在用整套梵熹系統就是用 Claude Code＋Agent SDK 蓋出來的，也用內建 Claude API skill。 |
本課帶來的優化（萃取自「課程優化提案」／落地狀態）
這門課我們學完，實際拿去改進的重點如下。綠＝已回灌團隊鐵律、可立刻生效；橘＝待 Norick 拍板；藍＝程式類由工程同事另辦或未來自建才用。
| 本課萃取的優化點 | 落地狀態 | 落在哪份規則／流程 |
|---|---|---|
| 常駐 bot 開 prompt caching 省 API 成本：把穩定的 system prompt／人設／工具定義標 cache，重複呼叫只付零頭。 | 程式類·工程另辦 | claude_ladder.py 共用送出層 |
| 從 Haiku 往上跑 eval 定模型：高頻自動化任務備 20–30 個代表樣本，從 Haiku 實測、品質夠就鎖，不夠才升。 | 程式類·工程另辦 | feedback-model-token-efficiency；~/.fansi-bot/evals/ |
| 獨立評分員＋rubric 自動 QC：複審前先把「done 的條件」寫成可量化 rubric，不過自動退回重做。 | 對抗式複審 既有規則已在用 · rubric 化 待 Norick 拍板 | avatar-consistency／course-brand-audit／verify |
簡報｜Building with the Claude API
課程 Building with the Claude API
平台 anthropic.skilljar.com
整理日 2026-07-03
依據 74 課影片 CC 逐字稿全文
一句話：Claude Code 101 教你「怎麼指揮 AI 工作夥伴」，這門課教「怎麼親手用程式接 Claude」——從發第一個 API 請求、寫 prompt、科學評測 prompt、串工具（tool use）、接私有資料（RAG）、省錢（prompt caching）、到組自動化流程（workflow／agent）。全程在 Jupyter notebook 手刻，證明「不用一開始就上重量級框架」，課程主要用 Claude Sonnet。對我們梵熹來說，這正是 Max、每支自動化腳本、每個 skill 底層在跑的東西。以下逐模組列逐字稿裡真的講到的做法、參數、數字、例子，並標出哪幾條對我們最有用。
一、課程講了什麼（依逐字稿的實際重點）
模組 1–2 模型總覽＋Messages API 基本功
| 主題 | 逐字稿實際講的重點 |
|---|---|
| 模型三線 | 三顆模型共用同一批能力，差在最佳化方向：Opus 最聰明、能自己跑複雜多步驟專案好幾小時、支援 reasoning，但延遲中等、成本高；Sonnet 智慧／速度／成本的甜蜜點，強在對複雜 code base「精準改而不弄壞」；Haiku 最快最便宜、為即時互動與高流量設計，明講 Haiku 不支援 reasoning。實務常混用（Haiku 顧前台、Sonnet 跑主邏輯、Opus 啃最難的），本課多用 Sonnet。 |
| 請求生命週期 | 五步：使用者→你的 server→Anthropic API→生成→回傳。絕不可從前端直接打 API（會外洩 secret key，key 只能放自己 server）。每次請求必帶 model、messages、max_tokens。文字生成內部四階段：tokenization→embedding→contextualization→generation，且「不是選最高機率的字，是機率＋隨機性混著挑」讓回答更自然。 |
| 發第一個請求 | pip install anthropic python-dotenv；金鑰放 .env（好被版控 ignore、不誤 commit）；client.messages.create 三必填 model／max_tokens／messages。max_tokens 是安全上限不是目標值——設 1000 不會硬湊 1000 字，只是超過就截斷。取文字要 message.content[0].text。 |
| 多輪對話 | 鐵則：Anthropic API 完全不存任何訊息。要有上下文得自己維護整份 messages list、每次把「整份」送出。示範：問完量子運算再單獨送「再寫一句」，因沒帶歷史會答到不相干的東西。修法：每次把 assistant 回覆 append 回 list。建三個貫穿全課的 helper：add_user_message／add_assistant_message／chat。 |
| System prompt | 客製語氣風格，傳給 system 參數、第一行通常指派角色。例：數學家教 chatbot 只給提示不直接給答案。重構陷阱：不能傳 system=None（會報錯），要組 params dict、有 system 才加進去、再 **params 展開。 |
| Temperature | 0–1 的小數，影響下一字的機率分布。0＝確定性（永遠選最高機率字），調高提高選到低機率字的機會。資料抽取用低溫、腦力激盪／創意寫作用高溫。chat 預設 1.0。示範：溫度 0 反覆生「時間旅行」電影點子，調到 1.0 才跳出別的題材（但講師提醒調高「不保證」每次差很多）。 |
| 串流 streaming | 一次請求可能等 10–30 秒，光轉圈圈體驗差。低階：stream=True 迭代 event，含文字的是 content_block_delta；高階（SDK）：with client.messages.stream(...) 再 for text in stream.text_stream，print(..., end="")。串完 get_final_message() 組回完整訊息存庫。 |
| 結構化資料 | 只想要純 JSON（如生 AWS EventBridge rule 給人一鍵複製），解法＝stop sequences ＋ assistant message prefilling 併用：prefill 一個 assistant 訊息內容為 ```json、stop sequence 設三個反引號，Claude 以為 code block 已開就直接寫 JSON、想補收尾反引號時撞 stop 立即停，只拿回中間純 JSON。殘留換行用 json.loads 或 strip() 清。 |
模組 3 提示評測 Prompt Eval（改 prompt 別憑感覺）
| 主題 | 逐字稿實際講的重點 |
|---|---|
| 為何要 eval | 寫完 prompt 三條路：測一兩次就上線／自己塞幾個 input 微調／跑 eval pipeline 拿客觀分數。講師說前兩者是「所有工程師（含他自己）都會掉的陷阱」，力推第三條。 |
| 典型流程 | ①寫 V1 prompt ②建 eval dataset（一堆 input，可手工可用 Claude 生）③每個 input 灌進 prompt 拿實際回答 ④用 grader 逐一評分（常見 1–10）⑤全部取平均 ⑥改 prompt 重跑、比 V1 vs V2 分數。示範 V1 三題平均 7.66，V2 結尾加「answer with ample detail」再比。生 dataset 這種事「很適合用較快的 Haiku」。 |
| 三種 grader | Code grader（你寫程式檢查：長度、含不含某字、JSON／Python／regex 語法驗證、可讀性分數）、Model grader（丟給另一個模型評，最彈性，可評整體品質與指令遵循）、Human grader（最彈性但最花時間）。重要 tip：只跟模型要分數常拿到中庸的「6」，要它同時給 strengths／weaknesses／reasoning 才會逼出具體分數。 |
| Code grading | 三個 validator（validate_json／validate_python／validate_regex，成功回 10、出錯回 0），dataset 加 format key 決定用哪個。最後把 model score 與 syntax score 平均。示範平均 8.166，講師說「好不好還不知道，改 prompt 再比分才知道」。 |
模組 4 提示工程 Prompt Engineering（四招，看分數一路漲）
| 招式 | 逐字稿實際講的重點＋實測分數 |
|---|---|
| 整體做法 | 先寫一版超爛 prompt（生運動員一日餐單，V1 只問「what should this person eat?」）→ eval 拿到 2.32（講師故意用較弱模型放大改善幅度）→每學一招就套上去重跑 eval 看分數升。 |
| ① 清楚直接 | 重點在 prompt 第一行＋一個動作動詞明講任務。餐單第一行改「generate a one day meal plan for an athlete that meets their dietary restrictions」→ 2.32 升到 3.92。 |
| ② 具體 | 兩種 guideline：Type A 列輸出該有的屬性（1000 字內、要 rising action、至少一配角）、Type B 列該跟的步驟逼它思考。套 Type A → 衝到 7.86；改 Type B 反而 7.3，講師 revert 回 Type A。建議：幾乎每個 prompt 都值得列 Type A，複雜問題才用 Type B。 |
| ③ XML 標籤 | 插入大量內容（貼 20 頁銷售紀錄）時用 XML 標籤分段。標籤名自己取、越具體越好（<sales_records> 比 <data> 好）。示範 debug 時用 <my_code> 與 <docs> 分開，Claude 才知 debug 哪段。 |
| ④ 給範例 | 「最有效技巧之一」，一個叫 one-shot、多個叫 multi-shot，專治 corner case（如諷刺語氣的 tweet 情緒判斷）。搭 eval 特別強：打開 output.html 找滿分案例，直接把它的 input/output 當範例貼進 prompt；進階把 grader 說明「為何理想」的 reasoning 也貼上。套用後升到 7.96。 |
模組 5 工具使用 Tool Use（Max 的本體）
| 主題 | 逐字稿實際講的重點 |
|---|---|
| 五步流程 | ①送初始請求＋附「怎麼拿外部資料」的工具說明 ②Claude 回一個「我要什麼資料」的請求 ③你的 server 跑程式去拿（如打天氣 API）④帶資料 follow-up 回 Claude ⑤Claude 用原 prompt＋新資料生成最終答。招牌例：問「舊金山現在天氣」Claude 沒即時資料，靠工具補。課堂專案：教 Claude 設提醒，做三工具 get_current_date_time／add_duration_to_date_time／set_reminder（一次做一個）。 |
| 工具函式＋schema | 工具＝一個 plain Python 函式＋一份 JSON schema。schema 最上層 name／description，底下 input_schema 才是真正的 JSON schema。description 三到四句講清做什麼、何時用、回什麼。best practice：參數命名描述性、驗證輸入、錯誤訊息要有意義（Claude 看得到 error，可自己修參數再呼叫一次）。小撇步：把函式＋官方 tool use 文件貼給 Claude.ai 叫它生 schema。 |
| 訊息區塊處理 | 首次遇到 multi-block：assistant 回的訊息同時含 text block（給人看）＋ tool_use block（要呼叫的工具名＋input）。維護歷史要 append({"role":"assistant","content":response.content})，整串 content blocks 塞回去、不能只塞 text。 |
| 回傳工具結果 | follow-up 尾巴 append 一個 user 訊息含 tool_result block，三個 key：tool_use_id（對回 response.content[1].id）、content（工具輸出、通常 json.dumps）、is_error。tool_use_id 用來對位：同時問 10+10 與 30+30 會回兩個 tool_use（各自 id），回結果必須用 id 對回去、不能靠順序。 |
| 多輪＋多工具 | 判斷要不要用工具看 response.stop_reason == "tool_use"（比翻 content 找 block 乾淨）。run_conversation while loop：不要工具就回、要就跑工具把 tool_result 併成 user 訊息再回圈。run_tools 用 try/except 包，出錯回 is_error=True 讓 Claude 重試。示範「177 天後設提醒」：Claude 先 add_duration 算日期、再 set_reminder。 |
| 細粒度呼叫 | 串流工具參數時，API 會 buffer chunks 做 JSON 驗證、等某個 key/value 生成完才一次送下。Fine-Grained Tool Calling ＝關掉這道驗證，能更早拿到參數（如 word_count），代價是可能收到 invalid JSON、要自己做錯誤處理。 |
| 兩個內建工具 | Text editor tool（str_replace_editor）：給 Claude 開檔／看範圍／取代／建檔／undo 的編輯器能力，但只送 schema stub，函式實作要你自己寫（Claude 說建檔你得真的建）；stub 的 type 帶日期、隨模型版本不同。Web search tool（web_search，max_uses:5）：上網找即時資訊，整個由 Claude 執行、你不用寫實作；回應含 server_tool_use（看得到查詢字串）＋web_search_tool_result＋citations。強推 allowed_domains：例限 nih.gov，避開 AI 生成的爛部落格、只採學術來源。 |
模組 6 RAG 與代理式檢索（讓 Claude 讀我們自己的資料）
| 主題 | 逐字稿實際講的重點 |
|---|---|
| 為何要 RAG | 情境：一份 100–1000 頁財報問「有哪些風險因素」。全文塞進 prompt 三缺點：超上限報錯、越長越不準、越長越貴越慢。RAG＝①預處理把文件切 chunk ②提問時只找最相關的 chunk 連同問題進 prompt。優點：專注、可擴到超大／多文件、更小更快更省。 |
| 切塊三策略 | 「整條 RAG 最複雜的步驟之一」。①size-based（等長＋overlap，overlap 補回被切斷的字與上下文，代價是重複）②structure-based（照標題／章節切，markdown 用 \n## 切最漂亮，但純 PDF 沒結構難落地）③semantic-based（用 NLP 把相關句組成 chunk，較進階）。實測：使用者文件無結構保證→退回 chunk_by_sentence；切程式碼→退回最可靠的 chunk_by_character。 |
| Embedding＋語意搜尋 | embedding＝一段文字「意義」的數值表示（-1～+1 的一長串數字），每個數字代表某種特質分數（講師誠實說我們其實不知道每個數字對應啥）。Claude 不提供 embedding，官方推薦 Voyage AI（另辦 key，VOYAGE_API_KEY）。完整 flow：切塊→產 embedding→存 vector DB→問題也產 embedding→找最相似 chunk。相似度算 cosine similarity（-1～1，越近 1 越像；vector DB 常用 cosine distance＝1−similarity，越近 0 越像）。 |
| BM25 詞彙搜尋 | 純語意搜尋會漏罕見識別碼（如事件編號 INC-2023-Q4-011）。解法＝語意搜尋＋lexical search 並行再合併。BM25（Best Match 25）：tokenize query→算各詞在各 chunk 頻率→高頻常見詞低權重、低頻罕見詞高權重→找高權重詞用得多的 chunk。改用 BM25 後 incident 那題大幅改善。 |
| 多索引混合 | 用一個 Retriever 包住 vector index＋BM25 index，問題同時轉發兩邊、收兩組結果再合併。合併用 reciprocal rank fusion（RRF）：每個 chunk 在各索引的名次 rank 套 1/(1+rank) 加總排序。實測混合後把先前語意搜尋漏掉的 section 2 撈回來了。因每索引同一套 API（add_document／search），未來可再塞新索引 merge 進來。 |
模組 7 Claude 進階功能
| 功能 | 逐字稿實際講的重點 |
|---|---|
| 延伸思考 | 開法：params 塞 thinking:{type:"enabled", budget_tokens:預算}。硬規則：budget 最小 1024、且 max_tokens 必須大於 budget。回傳多一個 thinking block，帶 signature（加密 token）防竄改、回傳時不能改。何時開：靠 eval 判斷——prompt 已優化過、準確度仍不夠才開，代價是思考 token 要付費＋延遲增加。 |
| 看圖 | 單一 request 跨所有 message 最多 100 張圖，依像素換算成 token 計費。user message 放 image block，source 用 base64 或 URL。關鍵在 prompting：示範「數 12 顆彈珠」簡單問句答成 13（錯），改成「先逐顆數→換方法再數一次驗證→比對」就數對。實戰案例：丟衛星圖做野火保險評估，prompt 分步驟給 1–4 級評分。 |
| 讀 PDF | 程式跟看圖幾乎一樣，block type 改 document、media_type 改 application/pdf。Claude 不只讀文字，PDF 裡的圖、圖表、表格也能讀，是一站式抽取工具。 |
| 引用出處 | document block 加 citations:{enabled:true}。回傳的 text block 帶 citations，含 cited_text／document_title／start_page／end_page，可拿去建「滑過就跳出處 popup」的 UI，讓使用者確認說法來自真實文件。不限 PDF，純文字也行（回的是字元位置而非頁碼）。 |
| Prompt caching | 原理：正常請求 Claude 對輸入做大量內部計算、回完就丟；快取把首次計算存起來，後續送「完全相同」內容時直接讀取，加速並降低成本。規則：快取只存 1 小時；非預設，要手動加 cache_control（type: ephemeral）當斷點、且要用 text block 長寫法；斷點之前的前綴必須一模一樣，多一個「please」就失效整段重算；合併順序固定 tools → system prompt → messages；最多 4 個斷點；至少 1024 token 才會寫入快取。實測 usage：首次 cache_creation_input_tokens 1700（寫入），立即重送變 cache read 1700（讀取）；改任一 tool description 就失效回到寫入。 |
| 程式執行＋Files API | Files API：先單獨上傳檔案（PDF／圖／CSV），拿到 file ID，之後用 ID 引用。Code execution 是 server-based tool（不用自己實作），Claude 在隔離 Docker container裡跑 Python、可跑多輪。關鍵限制：container 沒網路，資料進出靠 Files API＋container_upload block。示範上傳 streaming.csv 叫 Claude 分析客戶為何流失並畫圖，生成的圖存 container、透過 code_execution_output 拿 file ID 再下載。 |
模組 8–9 MCP ＋ Anthropic 現成應用
| 主題 | 逐字稿實際講的重點 |
|---|---|
| MCP 接外部 | 用標準協定接外部工具與資料：設 MCP client、定義 tool／resource／prompt 三基元、用 server inspector 除錯、寫一個 client。（另有兩門專課「Introduction to MCP」「MCP: Advanced Topics」深挖，見同系列簡報。） |
| Claude Code＋MCP | 官方現成應用怎麼用：Claude Code 安裝與操作、用 MCP server 加掛能力，把前面學的落到現成工具上。 |
模組 10 Agents 與 Workflows（壓軸）
| 類型 | 逐字稿實際講的重點 |
|---|---|
| 核心判斷準則 | 都是處理「單次請求做不完」的策略。rule of thumb：很清楚任務、也知道確切步驟序列 → 用 workflow；不確定任務細節、不知道要哪些步驟 → 用 agent。講師點破：辨識 workflow 本身不會自動做事，還是得自己寫 code，講這些模式是因為很多工程師照同 pattern 做出成效。 |
| 平行化 Parallelization | 把任務拆成多個 subtask 同時跑，再用 aggregator 彙整。例：判斷零件用什麼材料，與其塞一個超大 prompt，改成金屬／聚合物／陶瓷…各發一個專門化平行請求，最後彙整選材。三好處：一次專注一件、每個 subtask 好單獨評測、易擴充。 |
| 串接 Chaining | 把大任務拆成一連串獨立步驟逐一送，讓 Claude 一次專注一件。例：社群工具（搜趨勢→選題→web research→寫腳本→生影片→發佈）。最實用場景：寫文章塞一堆「不要」（別說自己是 AI、別用 emoji）常不聽，解法是接受第一版、再發 follow-up 把它貼回去叫 Claude「刪掉自稱 AI 處、移除 emoji、用專業口吻重寫」。 |
| 路由 Routing | 使用者輸入先送 routing 步驟（叫 Claude 分類），再依類別轉給專屬管線（各有自己的 prompt／工具）。例：programming 屬教育類要資訊多、surfing 屬娛樂類要輕鬆；先歸類再用該類 prompt 生對應調性腳本。 |
| Agent 與工具 | 給 Claude 任務＋一組工具，靠它自己規劃組合。工具要合理抽象、別給超專用工具：Claude Code 只有 Bash／web fetch／write 等抽象工具，要 refactor 就自己拼、要裝依賴就讀設定檔再跑 bash，沒有「一鍵 refactor」這種專用工具。 |
| 環境檢視 | agent 做完一個動作要能評估結果、了解新環境，光靠 tool 回傳值不夠。源自 computer use（每個動作後緊接一張截圖）。Claude Code 類比：改檔前先讀檔。社群影片 agent：用 Bash 跑 Whisper 產字幕核對配音位置、用 FFmpeg 每秒抽截圖檢查畫面。 |
| Workflow vs Agent | Workflow：步驟固定→準確度較高、更容易測試評估。Agent：彈性（能自造輸入、能反問使用者），但成功率較低、較難測評。講師明確結論：使用者只想要 100% 能用的產品、不在乎你做了炫 agent，能用 workflow 就優先用 workflow，只有真的必要才動用 agent。 |
模組 11 收尾
講師收尾反覆強調三件事：①prompt evaluation 是最重要的實踐（自己跑 10 次覺得 OK、上線使用者不一定 OK；eval 不必用花俏框架，可直接叫 Claude 幫你生 eval 程式）；②prompt engineering 首要是講清楚、直接告訴 Claude 你要什麼；③他本人主要在終端機跑 Claude Code 寫程式。建議延伸研究：agent orchestration（多 agent 協作）、agentic RAG、tool evaluation（像 prompt eval 一樣驗 tool description 有沒有真幫到 Claude）。
二、我學到、且對我們最有用的 6 點
| 重點 | 為什麼對梵熹重要 |
|---|---|
| Prompt Eval：改 prompt 別憑感覺 | 課程從頭到尾最重的一課——寫測試集＋自動評分，V1→V2 比分數再上線。直接對上你最恨的「邊做邊改打補丁」：我們核心文案／腳本 skill 該建小 eval，一次調對再上線。講師還教「懶人法」：直接叫 Claude 幫你生 eval 程式，門檻很低。 |
| Prompt caching 的真規則 | 把固定前綴（系統提示、品牌設定、範本）快取，重複請求那段直接讀取、加速又省成本。眉角要記牢：存活 1 小時、前綴改一個 byte 就失效、最少 1024 token、最多 4 斷點、合併順序 tools→system→messages。我們天天重跑同一批設定的自動流，把穩定前綴做成快取能省一截；但別把時間戳／亂數塞進前綴。 |
| Tool Use 是 Max 的本體 | Max 發文、剪片、查金鑰、推播底層全是 tool use。看懂 stop_reason=="tool_use" 的迴圈、tool_use_id 對位、is_error 讓 Claude 自癒重試，就看懂 Max 每個動作怎麼被驅動、哪裡該加審批閘。web search 的 allowed_domains 更直接可用——要抓權威資訊就鎖定可信網域，避開 AI 生成的爛內容。 |
| RAG 混合檢索才準 | 只靠語意搜尋會漏罕見識別碼（客戶編號、案號、專有名詞），要語意＋BM25 併行再用 RRF 合併。我們的記憶層／客戶資料庫要走這條才會準，而且切塊策略要看資料性質選（有結構照章節切、沒結構退回按句切、程式碼按字元切）。 |
| Workflow 先於 Agent | 講師的準則很硬：知道步驟就用 workflow（準、好測），不知道才用 agent（彈性但成功率低、難測）；使用者只要 100% 能用的東西。對上我們「先規劃再動手、一次做對」——先用三型 workflow（平行／串接／路由）把流程釘死。 |
| 抽象工具，不要一鍵專用工具 | Claude Code 只給 Bash／讀寫檔這種抽象工具就能改整個 codebase。啟示：我們給 agent 的工具也該通用可組合，別為每個小動作各刻一個超專用工具，否則擴充性差、Claude 也難靈活組裝。 |
三、我們怎麼用（每個概念對到梵熹現有系統）
| 課程概念 | 梵熹已經在用 / 可補強 |
|---|---|
| Messages API 基本功 | 已在用claude_ladder.py 共用模組、pick_model() 都是直接打 Messages API；多輪要自己維護 messages list 這條我們也在做。 |
| 挑對模型 | 已在用「看任務挑模型」鐵則已落地（對話快模型／瑣事 Haiku／派工 Opus／最難 Fable5），對上課程「重智慧選 Opus、重速度選 Haiku、要平衡選 Sonnet」。 |
| 結構化輸出 | 補強要模型只吐純 JSON／指令時，用 stop_sequences＋assistant prefilling，比事後 regex 清乾淨。 |
| Prompt Eval 評測 | 補強核心文案／腳本 skill 建小型測試集＋model/code grader，改版前先跑分再上線；可請 Claude 直接生 eval 程式。 |
| Tool Use 工具使用 | 已在用Max 發佈／剪片／推播／查金鑰全是 tool use。補強對外動作按 is_error／審批閘設計，web search 用 allowed_domains 鎖權威來源。 |
| Prompt caching | 補強把品牌設定、skill 系統提示、範本做成穩定前綴快取（記住 1 小時、順序 tools→system→messages、別動前綴），天天重跑的自動流能省一截。 |
| RAG 檢索 | 補強把客戶六書／過往作品／MEMORY 做成 vector＋BM25 混合索引（RRF 合併），輸出更貼品牌、少幻覺、撈得到專有名詞。 |
| 看圖／讀 PDF／引用 | 補強形象驗收、看衛星圖評估這類分步驟 prompt 可直接借用；讀 PDF＋citations 可做「有出處可查」的客戶資料問答。 |
| MCP 接外部 | 已在用Notion／Higgsfield／Canva／Gmail 等一票 MCP 服務都掛好了（細節見 MCP 兩門專課簡報）。 |
| Workflows 工作流 | 已在用content-fanout（輿情扇出四平台）就是串接＋路由型 workflow。補強更多產線照三型明訂、各步驟單獨可測。 |
| Agents 代理 | 已在用Max＋員工 agent 團隊。補強照課程準則「能 workflow 就先 workflow」，給 agent 的工具保持抽象可組合，並加環境檢視（改檔前先讀檔、產出後回抽截圖／字幕核對）。 |
本課帶來的優化（萃取自「課程優化提案」／落地狀態）
這門課我們學完，實際拿去改進的重點如下。綠＝已回灌團隊鐵律、可立刻生效；橘＝待 Norick 拍板；藍＝程式類由工程同事另辦或未來自建才用。
| 本課萃取的優化點 | 落地狀態 | 落在哪份規則／流程 |
|---|---|---|
| Prompt caching：tools→system 打 cache breakpoint，命中省約 90% 輸入費又更快（≥1024 token 才有效、1 小時 TTL）。 | 程式類·工程另辦 | claude_ladder.py＋天天重跑的自動流 |
| Eval 評測管線：給 prompt 打客觀分再上線（先叫模型列優缺點再給分，分數才拉得開）。 | 程式類·工程另辦 | ~/.fansi-bot/evals/；先拿 brand-voice-check 開刀 |
| Workflow 優於 Agent：步驟已知一律 workflow（準、好測、可靠），只有步驟真的未知才用 agent。 | 已套進鐵律 G 段 | G 段 |
| Chaining 二段式改寫：長禁令壓不住時，第二段把成品丟回叫它「找出並移除 X」。 | 待 Norick 拍板 | brand-voice-check 升級 |
| Temperature 分級：抽取／掃禁用詞／做帳＝0，文案／腦力激盪＝0.7–1。 | 待 Norick 拍板 | 各 skill 加一行建議值 |
| Web search 鎖 allowed_domains：鎖可信網域避 AI 農場文。 | 待 Norick 拍板 | social-listening／benchmark-research／deep-research |
| Structured output：prefill assistant＋stop sequence 拿乾淨 JSON／YAML。 | 待 Norick 拍板 | ig-yaml-build／tracking-design |
| 動作後自檢環境：寫檔前先讀、動作後用 ffprobe／whisper／截圖驗結果。 | 既有規則已在用（禁謊報） | 團隊鐵律 B；IMG_8212 recut |
簡報｜MCP（Model Context Protocol）
課程 Introduction to Model Context Protocol
講師 Stephen Grider
整理 2026-07-03
依據 每課影片 CC 逐字稿全文
一句話：MCP 是一層「溝通協定」，讓 Claude 拿到外部工具與資料去做事，而你不用自己刻一大堆繁瑣的整合程式碼。課程用一個具體例子貫穿：想做一個「能聊 GitHub 資料」的聊天機器人，光 GitHub 就有 repo、PR、issue、專案一堆功能，你要自己寫、測、維護成千上百個 tool schema 跟函式——這正是 MCP 要解決的痛。MCP 把「定義工具、執行工具」的擔子從你的主程式，搬到專責的 MCP server 上；一次寫好，任何支援 MCP 的 AI 都能接。我們梵熹接的 Notion／Higgsfield／Canva 就是別人寫好的 MCP server，我們直接用。這份依逐字稿把整門課列給你，並標我們已在用或可補強。
一、課程講了什麼（依逐字稿的實際重點）
| 章節 | 逐字稿裡實際講的重點 |
|---|---|
| 1 認識 MCP | MCP＝給 Claude「情境＋工具」的溝通層。核心痛點：做 GitHub 聊天機器人要自己寫海量 tool schema 與函式，還要測、要維護；MCP 把這擔子搬到 MCP server，它就是「某個外部服務（如 GitHub）的封裝介面」。三個常見問題：①誰寫 server？任何人都能寫，但服務商常出官方版（例：AWS 官方 MCP server）②跟直接呼叫 API 差在哪？差在你不用自己刻 schema 跟函式，省時間 ③「MCP＝tool use？」錯，兩者互補不同物——都在講工具，但 MCP 講的是「這活由誰做」（別人幫你封裝好）。 |
| 2 MCP 客戶端 | Client 是你的程式與 MCP server 之間的溝通橋，也是你存取 server 所有工具的入口。MCP 傳輸無關（transport agnostic）：client 與 server 可走多種協定；最常見是兩者跑在同一台機器、走標準輸入輸出（STDIO）。連上後靠交換「訊息」溝通，本課重點四種：list_tools request/result（要／回全部工具清單）、call_tool request/result（要求跑某工具帶參數／回結果）。 |
| 整條呼叫流程 | 逐字稿用一個完整例子走一遍：使用者問「我有哪些 repo」→ 我方 server 先透過 MCP client 向 MCP server 要list_tools→ 把工具清單＋問題送給 Claude → Claude 回一個 tool_use 說要跑工具 → 我方 server 請 MCP client 發 call_tool → MCP server 去打 GitHub 拿 repo 清單 → 包成 call_tool_result 回來 → 我方 server 把結果當 user message 再送 Claude → Claude 產出最終文字回覆。重點：工具不是你的 server 在跑，是 MCP server 在跑。 |
| 3 專案設定 | 整門課動手做一個 CLI 文件聊天機器人：文件是假的、只存記憶體；用 uv 管理 Python 專案，uv run main.py 起服務。刻意在同一專案同時做 client 與 server（真實情況通常只做一邊），是為了讓你兩邊都看懂。 |
| 4 定義工具 Tools | 三大基元之一。用官方 MCP Python SDK：一行建 server，工具只要標 @mcp.tool 裝飾器＋函式即可，SDK 自動幫你生 JSON schema，不必手刻。課堂做兩個工具：read_document（吃 doc_id、回內容）、edit_document（find-replace 取代字串）；參數用 pydantic Field 加描述，找不到文件就 raise ValueError。描述寫得越清楚，Claude 越知道何時該呼叫。 |
| 5 伺服器檢查器 | 用 SDK 內建的 MCP Inspector：終端機跑 mcp dev mcpserver.py，開瀏覽器（預設埠 6274／6277）就有除錯介面。點 Connect 啟動 server，在 Tools 頁 List Tools、手動填參數 Run Tool，不用接真應用就能驗工具通不通。講師提醒：Inspector 還在開發中，你看到的 UI 可能跟影片不同。 |
| 6 實作客戶端 | MCP client 是一個類別，包住 SDK 的 ClientSession（真正對 server 的連線），並處理連線關閉的清理工作。課堂實作兩個函式：list_tools、call_tool，供專案其他地方「拿工具清單餵 Claude」「Claude 要跑工具時去跑」。 |
| 7 定義資源 Resources | 第二個基元＝唯讀資料。做法用 @mcp.resource＋一個 URI（像路由，例 docs://documents）＋ MIME type（application/json 或 text/plain 給 client 提示資料型別）。分兩種：direct／static（固定 URI，回全部文件名）與 templated（URI 帶萬用參數 docs://documents/{doc_id}，SDK 自動把 doc_id 當關鍵字參數傳進函式）。課堂用它做 @ 提及文件的自動補全＋抓單篇內容。 |
| 8 存取資源 | client 端加一個 read_resource：發 read_resource 請求、拿回 contents[0]，照 MIME type 決定怎麼解——是 application/json 就 json.loads，否則當純文字直接回。抓回來的內容注入 prompt，Claude 這次就不必再呼叫工具去讀文件了（省一趟）。 |
| 9 定義提示 Prompts | 第三個基元＝預先寫好、測過、調校過的指令範本。做法 @mcp.prompt，回一串 user／assistant 訊息。課堂做 /format 斜線指令：把文件重寫成 Markdown。重點：使用者其實自己打字也能叫 Claude 轉 Markdown，但由 server 作者事先寫好、評測過的高品質 prompt，效果更穩——這就是 prompt 基元的價值：把「該服務最擅長的工作流」打包好給人一鍵套用。 |
| 10 客戶端裡用 prompt | client 加 list_prompts／get_prompt（帶參數如 doc_id，會被插進 prompt 函式）。接進 CLI 就成了斜線選單：打 / 選 format、選文件，整段 prompt 直接餵 Claude。 |
| 11 總複習 | 三大基元的控制權收束：Tools＝模型控制（Claude 自己決定何時呼叫）、Resources＝應用控制（你的程式決定去讀、拿去做 UI 或注入 context）、Prompts＝使用者控制（使用者按鈕／斜線指令觸發）。講師拿 Claude.ai 對照：輸入框下方的建議按鈕＝prompts、加 Google Drive 檔＝resources、叫 Claude 跑 JavaScript 算數＝tools。 |
三大基元一句話記（依講師總複習）：
Tools（工具）＝模型控制，Claude 自己決定何時「做事」（查庫、發 API）
Resources（資源）＝應用控制，你的程式決定去讀的唯讀資料（餵 UI／注入 context）
Prompts（提示）＝使用者控制，使用者按鈕／斜線指令一鍵套用的範本
Tools（工具）＝模型控制，Claude 自己決定何時「做事」（查庫、發 API）
Resources（資源）＝應用控制，你的程式決定去讀的唯讀資料（餵 UI／注入 context）
Prompts（提示）＝使用者控制，使用者按鈕／斜線指令一鍵套用的範本
二、我學到、且對梵熹最有用的 5 點
| 重點 | 為什麼對我們重要 |
|---|---|
| 省下海量整合程式碼 | 課程的核心痛點就是「自己接一個服務要寫、測、維護一堆 tool schema」。我們現在的 Notion／Higgsfield／Canva 全是別人寫好的 MCP server，一個接法 Max、31 位員工、各 skill 共用同一套工具——正是 MCP「一次寫、到處用」的紅利。 |
| 三大基元＝三種控制權 | Tools 模型控制、Resources 應用控制、Prompts 使用者控制。這條剛好對上你最在意的零風險：會動手改的（Tools）才設審批閘、只能讀的（Resources）放心接、常用工作流打包成 Prompts。分權清楚，關卡才設得準。 |
| Inspector 先驗再上 | mcp dev 起個瀏覽器介面，不接真應用就能手動 Run Tool 驗通。完全對上你的「動手前先驗、一次做對、別打補丁」——新接一個服務先用 Inspector 測通再放進產線。 |
| Resources 注入 context 省一趟 | 課堂示範用 @ 提及文件、事先把內容塞進 prompt，Claude 就不必再呼叫工具去讀。對我們＝把品牌六書、客戶資料做成 resource 預先注入，少一次 tool 往返、少一次幻覺。 |
| Prompts 打包常用工作流 | server 作者事先寫好、評測過的 prompt 比使用者臨場打字穩。把「發 IG 一條龍」「輿情扇出」這類流程做成 MCP prompt，跟我們的 skill 庫互補、一鍵喚起。 |
三、我們怎麼用（對到梵熹現有系統）
| MCP 概念 | 梵熹已經在用 / 可補強 |
|---|---|
| 用現成 MCP server | 已在用Notion（台賬／記憶）、Higgsfield（生圖生片）、Canva（設計）都是別人寫好的 server，我們直接接。 |
| Tools（模型控制） | 已在用Higgsfield 生圖生片、Notion 寫台賬＝Claude 自己決定何時呼叫的工具。補強對外／會改動的工具照課程分權加審批。 |
| Resources（應用控制） | 已在用Notion 讀台賬、Drive 讀檔當背景資料。補強把品牌六書／客戶資料做成 resource 預先注入 context。 |
| Prompts（使用者控制） | 補強把最常跑的產線（IG 一條龍、輿情扇出）試做成 MCP prompt，跟 skill 互補。 |
| Inspector 驗證 | 補強訂進接服務 SOP：新服務先 mcp dev 手動 Run Tool 測通再上產線。 |
| STDIO 同機直連 | 已在用本機自動流（launchd／cron）本質就是同機直連、走最省事的 STDIO 這類路。 |
| 金鑰安全 | 已在用MCP 接服務所需 token 統一走金鑰倉庫、不落地、不回顯——對上我們的 vault 鐵則。 |
本課帶來的優化（萃取自「課程優化提案」／落地狀態）
這門課我們學完，實際拿去改進的重點如下。綠＝已回灌團隊鐵律、可立刻生效；橘＝待 Norick 拍板；藍＝程式類由工程同事另辦或未來自建才用。
| 本課萃取的優化點 | 落地狀態 | 落在哪份規則／流程 |
|---|---|---|
| 閒置 MCP server 關掉：server 的 tool list 每次請求都拼進 context 送給 Claude＝吃 context 吃錢，沒用到的關掉。 | 待 Norick 拍板 | reference-mcp-inventory 12 服務盤點 |
| 三原語分工：tool＝模型控制、resource＝app 控制、prompt＝使用者控制；自建 server 時照此分。 | 設計指引（未來自建） | 自建 MCP server 時 |
簡報｜MCP 進階主題
課程 MCP: Advanced Topics
講師 Stephen Grider · Anthropic
整理 2026-07-03
依據 每課影片 CC 逐字稿全文
一句話：基礎課教「MCP 是什麼、怎麼接外部工具」；這門進階課教「怎麼自己寫一台上得了正式環境的 MCP server」。三大進階能力：Sampling（server 反過來借客戶端的模型來用）、Notifications／Logging（長工作邊做邊回報進度）、Roots（授權 server 只能碰某幾個資料夾）。後半整門課花大力氣講底層：JSON-RPC 訊息型別 → STDIO 傳輸 → StreamableHTTP 傳輸 → 無狀態部署——講師直說前面訊息與 STDIO 那幾段「看起來有點枯燥」，但不懂它就看不懂 StreamableHTTP 為何有些功能會壞掉。這份依逐字稿把每章列給你，並標我們用得到的地方。
一、課程講了什麼（依逐字稿的實際重點）
| 章節 | 逐字稿裡實際講的重點 |
|---|---|
| 開場 | 講師 Stephen Grider（Anthropic 技術幕僚）預告：Sampling → Logging/Progress → Roots → 訊息格式 → STDIO → StreamableHTTP → 無狀態。要求你至少看得懂 Python、已懂基礎 MCP（client／server／tools）。 |
| Sampling | 讓 server「透過連上的 client 去借語言模型」。實例：一個 Next.js 研究助理，MCP server 有個 research 工具，會去抓 Wikipedia 一堆文章，然後要把內容綜合成報告。方案二選一：①server 自己直連 Claude（要綁 API key、要付 token、要寫抽取回應的程式，複雜）②Sampling——server 寫好 prompt 丟給 client：「幫我餵給 Claude」，client 跑完把生成文字回傳。好處：API key 與費用都留在 client，公開 server 不必替陌生人付 token。做法：server 端在工具函式裡呼叫 create_message 帶一串 messages；client 端寫一個 sampling callback 接收訊息、去跑模型、回一個 create_message result。 |
| Sampling 走一遍 | 程式碼互動 walkthrough（無影片）：實地把 server 的 create_message 與 client 的 callback 串起來跑一次。 |
| Log 與進度通知 | 長工作最怕「按下去沒反應、以為當掉」。同一個研究 app：關掉通知時使用者乾等；開通知後出現進度條＋log 訊息，而且不是假資料，是工具函式裡實際 emit 的。做法：工具函式收一個自動帶入的 context 物件，用 ctx.info(...) 記 log、ctx.report_progress(...) 回報進度；client 端寫 logging callback（掛到 client session）與 progress callback（掛到 call_tool）。要不要顯示、怎麼顯示都由你決定，純粹是體驗加分。 |
| Notifications 走一遍 | 程式碼互動 walkthrough（無影片）：把一個耗時任務接上進度回報。 |
| Roots | 一套授權邊界。反例先講痛點：一個 convert_video 工具（MP4→MOV），使用者只說「轉 biking.mp4」，Claude 不知道檔案在哪個資料夾，會回「找不到檔案」。硬要使用者每次打完整路徑又很煩。解法：加兩個工具 read_directory（列某夾檔案）、list_roots（回傳使用者事先授權的資料夾清單，啟動時用命令列參數給），Claude 就能自己 list_roots → read_directory 找到檔案。關鍵警告：Roots 是「鬆散」概念，SDK 不會自動幫你擋存取！必須你自己在工具裡寫一個像 is_path_allowed(path) 的檢查，比對請求路徑是否落在授權 roots 內，否則拒絕（示範：desktop 授權可轉、documents 沒授權就擋掉 swimming.mp4）。 |
| Roots 走一遍 | 程式碼互動 walkthrough（無影片）：實作命令列宣告開放目錄、工具內界線檢查。 |
| JSON 訊息型別 | MCP 底層走 JSON-RPC，這些 JSON 片段叫「訊息」。分兩類：①request／result 成對（如 call_tool_request 一定配 call_tool_result、initialize 配 initialized result）②notification（像事件、單向、不需回應，如 progress、logging、tool 變更）。全部型別定義在 MCP 規格 repo 的 schema.ts（用 TypeScript 只是方便描述型別，從不被執行，也不含在任何 SDK）。檔尾分 client messages 與 server messages 兩區。本章最大重點：有一批訊息是由 server 主動發給 client（server request／server notification）——先記住，講 StreamableHTTP 時這點會變超關鍵。 |
| STDIO 傳輸 | 「傳輸（transport）」＝真正在 client／server 間搬 JSON 的方式。STDIO：client 把 server 當子行程啟動，寫 server 的 標準輸入（stdin）送訊息、看 標準輸出（stdout）收訊息。優點：任一方都能隨時主動發起溝通。缺點：只能同機。示範：直接在終端機貼 JSON（即寫入 stdin）就能跟 server 對話——先貼 initialize request（回 result）、再貼 initialized notification（無回應，因為 notification 不需回）、連線才算初始化完成，之後才能貼 call_tool。四種情境 STDIO 都好處理：client→server 寫 stdin、server 回寫 stdout；server 主動發起（如 sampling 的 create_message）寫 stdout、client 回寫 stdin。 |
| StreamableHTTP 傳輸 | 走 HTTP，能遠端託管 server（如 mcpserver.com），任何人可連。但會有兩個旗標限制功能：stateless_http 與 json_response（預設 false）。同一個研究 app 示範：把 stateless_http 設 true → 進度條不見了、請求最後整個失敗；再把 json_response 也設 true → log、進度全消失。根因回顧：純 HTTP 裡「client 發 request、server 回 response」很容易；但server 想主動對 client 發 request 很難（server 不知道 client 位址、client 也未必公開）。所以 sampling、list roots、progress、logging 這些「server→client」的訊息，在 HTTP 世界天生難做——這正是上面壞掉的東西。 |
| StreamableHTTP 深入 | StreamableHTTP 的解法／魔法：連線初始化時，server 在回應 header 塞一個 MCP session ID（一串隨機字元，示範裡以 EAA 開頭），之後每個請求都要帶它。接著 client 可（可選）發一個 GET 請求 → 拿到一個 SSE（Server-Sent Events）長連線，這條會一直開著，專門讓 server 隨時把訊息推下來（sampling 等 server 主動請求走這條）。之後 client 發 call_tool（POST）會再開第二條 SSE，專跑這次工具呼叫的訊息、拿到 result 後自動關閉。一個 SDK 怪癖：progress notification 會被歸在第一條 GET SSE送，而 log 與 call_tool_result 走 POST 那條回。 |
| 狀態與部署 | 為何要把 stateless_http 設 true？水平擴充：server 爆紅、單機扛不住，就多開幾台＋load balancer 隨機分流。但每個 client 有兩條連線（長開的 GET SSE ＋ 各次 POST），若 sampling 請求要走的 GET SSE 是另一台建立的，跨機協調極痛苦。設 stateless_http=true → 不發 session ID → server 無法辨識 client → 不能用 GET SSE 那條 → sampling／progress／logging／訂閱全失效（講師用「銀行沒有帳號 ID 就不知道錢是誰的」比喻）；好處是不必做初始化三訊息、流量更省，適合水平擴充。json_response=true → POST 不串流，只回最終 JSON 結果、中間 log／進度全沒。忠告：開發時就用你上線要用的傳輸，別本機 STDIO 開心、上線 HTTP 才發現壞。 |
| 結尾 | 下一步：逛 GitHub 上 MCP 討論區、追 MCP 首頁改版、動手自己寫一台 server 練 Sampling／Roots／進度回報。 |
二、我學到、且對梵熹最有用的 5 點
| 重點 | 為什麼對我們重要 |
|---|---|
| Sampling：費用留客戶端 | 將來自己寫工具給客戶用，server 不用綁我們的 API key、不必替客戶付 token——費用跟客戶自己帳號走，成本責任清清楚楚。公開 server 一定要走這條，不然等於開放讓陌生人燒我們的錢。 |
| Notifications：長工作要吐進度 | 剛好對上你「視覺型工作者要看到進度」＋「任務沒做完也要回報到哪了、別已讀不回」。ctx.report_progress 這種邊做邊吐百分比，正是剪片、生圖這類久活該有的樣子。 |
| Roots：SDK 不會自動擋，要自己寫檢查 | 對上你的資安紅線與「絕不亂刪、絕不亂動他設定」。但講師明講 Roots 是鬆散的、SDK 不強制——所以我們自寫工具時務必自己實作 is_path_allowed 這種界線檢查，把可碰目錄從機制面鎖死，不能只當它會自動安全。 |
| 先懂 server→client 才懂為何會壞 | Sampling／進度／log 全靠「server 主動對 client 發請求」；純 HTTP 做不到，得靠 SSE 長連線補。這條看懂了，日後我們自建遠端 server 遇到「本機好好的、上線就沒進度條」才知道是 stateless_http 在搞。 |
| STDIO vs StreamableHTTP 選型 | 本機自動化用 STDIO（省事、同機、雙向都能主動）；遠端手機派工用 StreamableHTTP（能遠端、多人、可擴充）。正對上你「遠端全自動」的北極星——選錯傳輸整條流程會卡，且要開發階段就用上線的傳輸。 |
三、我們怎麼用（每個概念對到梵熹）
| 課程概念 | 梵熹已經在用 / 可補強 |
|---|---|
| 用現成 MCP 接外部 | 已在用Notion／Higgsfield／Canva／Airtable／Slack 等一堆 MCP，早就在借力。 |
| Notifications 進度回報 | 已在用派工看板五狀態、TG／LINE 進度推播。補強把久活（剪片、生圖）改成 report_progress 邊做邊吐百分比。 |
| Roots 授權邊界 | 已在用授權閘＋「刪除／花錢才問」＋絕不亂動設定。補強自寫工具一定加 is_path_allowed，別靠 SDK 自動擋（它不會）。 |
| Sampling 借客戶端模型 | 補強日後給客戶的 MCP 工具用 create_message＋sampling callback，費用走客戶帳號，我們不墊 API 成本。 |
| STDIO 傳輸 | 已在用本機 launchd／cron 那些自動流，本質就是本機直連、走 STDIO 這類最省事的路。 |
| StreamableHTTP 傳輸 | 補強遠端手機派工、LINE 接雲端這條，未來自建 server 就走 StreamableHTTP，能主動推、能多人；記得開發就用它測。 |
| 無狀態、可水平擴充 | 補強派工量大時把自建 server 設 stateless_http 多台一起扛——但要知道這會關掉 sampling／進度／log，取捨想清楚。 |
| 自己寫 production MCP server | 補強把金鑰倉庫、發佈鏈、剪片鏈包成正式 MCP server，讓 Max 與員工用標準協定調用，並驗 Sampling／Roots／進度三件事跑得通。 |
本課帶來的優化（萃取自「課程優化提案」／落地狀態）
這門課我們學完，實際拿去改進的重點如下。綠＝已回灌團隊鐵律、可立刻生效；橘＝待 Norick 拍板；藍＝程式類由工程同事另辦或未來自建才用。
| 本課萃取的優化點 | 落地狀態 | 落在哪份規則／流程 |
|---|---|---|
| MCP roots 授權目錄鎖死：roots 是明文授權清單，但 SDK 不會自動擋，要自己寫 is_path_allowed 逐次比對。 | 待 Norick 拍板（未來自建） | 自建 MCP server；呼應路徑鎖 /Users/fansi |
| Sampling：公開 MCP server 別自己叫 LLM，改請 client 代跑（不用擺 API key、不用替陌生人付 token）。 | 設計指引（未來自建） | fansi-cut 若做成 MCP server |
| Stateless／JSON 兩旗標：stateless=true 會打斷 sampling／progress／logging；開發就用上線同一種 transport。 | 設計指引（未來自建） | 遠端 MCP 上 Cloudflare 擴充時 |
簡報｜Introduction to Agent Skills
課程 Introduction to Agent Skills
來源 影片 CC 逐字稿（非大綱推測）
整理 2026-07-03
對照 梵熹現有 121 個 skill
一句話：影片開場就戳中痛點——「每次跟 Claude 解釋一次團隊的規範、每次 PR review 重描述一次你要的回饋格式、每次 commit 重提醒一次你偏好的訊息格式，你都在重複自己。Skill 就是來解決這個。」Skill 是一份 markdown，教 Claude 一次某件事怎麼做，之後只要情境對上，Claude 自動套用。它是「資料夾裡的指令、腳本、資源」，靠
description 被語意匹配喚起。這正是我們梵熹 121 個 skill 的底層原理。以下每支影片用它實際講的內容重寫。
一、逐支影片實際重點（照 CC 內容）
| 影片 | 影片實際講的 |
|---|---|
| 1 什麼是 Skill | Skill＝一份 markdown，教 Claude 一次、之後自動套用。description 是 Claude 決定用不用它的依據——你說「review 這個 PR」，Claude 拿你的話去比對所有 skill 的描述、匹配到就啟用。存放地點決定誰能用：個人 skill 放家目錄 .claude/skills（跟著你跨所有專案，放你的偏好、commit 風格、文件格式）；專案 skill 放 repo 根目錄的 .claude/skills（clone 的人自動得到，放團隊規範、品牌指南、慣用字型色）。跟其他機制比：CLAUDE.md 每次對話都載入、slash command 要你自己打，而 skill 是自動＋任務特定，只載入 name 和 description，不佔滿 context。「如果你發現自己一直對 Claude 重複解釋同一件事，那就是一個等著被寫出來的 skill。」 |
| 2 建立你的第一個 Skill | 只要 name＋description 就能動，但進階欄位讓它更好用。依 agentskills.io 開放標準：name（只用小寫、數字、連字號，最多 64 字元，要對上目錄名）；description（必填、最多 1024 字元、最重要，Claude 靠它匹配，要答兩問：這 skill 做什麼、何時該用）；沒觸發就加更多使用者實際會講的關鍵詞。選填：allowed-tools（限制啟用時能動哪些工具，可做成唯讀、不許編輯/寫/bash，適合資安敏感或唯讀工作；不填就走正常權限）、model（指定用哪個模型）。漸進式揭露（progressive disclosure）：核心指令放 skill.md、細節拆到別的檔，Claude 需要時才讀（像目錄而非把整本塞進 context）。skill.md 保持 500 行內，超過就該拆。腳本可執行而不載入內容——只有輸出吃 token，叫 Claude「跑」腳本而非「讀」它，適合環境驗證、資料轉換這種要一致、當成測過的程式碼比即興生成更可靠的事。 |
| 3 設定與多檔 Skill | 實作：建 技能名/ 目錄、放 skill.md，第二組破折號後就是 Claude 要遵循的指令。Claude Code 開機時載入 skills，改完要重啟 session，再驗證清單裡看得到。運作原理：啟動時掃四個位置（企業 enterprise、個人、專案、外掛 plugins），只載 name 和 description、不載全文；你發請求時 Claude 拿它去比對描述、意圖重疊就啟用，並先問你要不要載入（讓你清楚它在用什麼 context），確認後才讀全文照做。名稱衝突的優先權：企業 > 個人 > 專案 > 外掛（同名時企業版蓋過個人版）。所以要用描述性名字，別叫 review，改叫 front-end PR review 或 security review。更新＝改 skill.md，移除＝刪目錄，改完都要重啟。 |
| 4 Skill 與其他功能的差別 | Claude Code 有 skills／CLAUDE.md／subagents／hooks／MCP，解決不同問題，選錯就會蓋錯東西。CLAUDE.md：每次對話都載入（要 TypeScript strict mode、never modify DB schema 這種永遠適用的專案級規範放這）。Skill：按需載入，匹配才啟用（PR review 清單寫新 code 時不必在 context）；適合任務特定、只有時候相關、放進每次對話會太雜的細節程序。Subagent：另開獨立 context 跑、拿任務自己做完回傳結果，跟主對話隔離（要委派、要不同工具權限、要隔離時用）。Hooks：事件觸發（存檔跑 linter、某工具呼叫前驗證），是 event-driven；skill 是 request-driven。典型組合＝CLAUDE.md 放常在規範＋skills 放任務特定專長＋hooks 放自動化操作，別硬把全部塞進 skill。 |
| 5 分享 Skill | 「只有你用的 PR review skill 有用，全隊共享的同一份能標準化 review、體驗一致，好得多。」三種散佈：① commit 進 repo（放 .claude/skills，clone 就自動有、push 更新大家下次同步就拿到，適合團隊規範）；② plugin（在外掛的 skills 目錄照同結構放，散佈到 marketplace 讓別人下載，適合不太專案特定、社群可用的）；③ 企業 managed settings（管理員全組織部署、最高優先權、蓋過個人/專案/外掛，用於必須一致的強制標準、資安、合規）。重點警告：subagent 不會自動看到你的 skills！委派給 subagent 是全新乾淨 context；內建 agent（explorer/plan/verify）完全不能用 skills，只有你自訂的 subagent 能、且要在它的 skills 欄位明確列出（開機就載入、不是按需）。所以只列「對它職責永遠相關」的 skill。 |
| 6 除錯 Skill | 問題不外乎：不觸發／不載入／衝突／執行時失敗。先跑 agent skills verifier 驗證器（建議用 UV 裝最快）。存在卻不觸發＝幾乎都是描述問題（Claude 靠語意匹配，重疊不夠就不中），照你實際講法加觸發詞、用變體測試（「幫我 profile 一下」「為什麼這麼慢」「讓它快一點」）。問「有哪些 skill」看不到＝檢查位置與結構：skill.md 要在具名目錄裡（不能在 skills 根）、檔名必須正好是 SKILL.md（大寫 SKILL、小寫 md），跑 claude --debug 看載入錯誤。用錯／混淆＝描述太像，改得更獨特。個人被忽略＝可能有同名企業/高優先權 skill 蓋過，改個更獨特的名字或找管理員。裝了外掛看不到＝清快取、重啟、重裝，還不行就是結構錯，用驗證器。執行失敗＝外部套件要先裝好（寫進描述）、腳本要有執行權限、路徑一律用正斜線（連 Windows 也是）。 |
二、我學到、對梵熹最有用的 5 點
| 學到什麼 | 為什麼對我們重要 |
|---|---|
| 「一直重複解釋的事＝一個該寫的 skill」 | 影片這句話直接是我們做 skill 工廠的判準。我們 121 個 skill 正是把每個重複交代的工作環節固化下來——這門課給了官方版本的判斷準則。 |
| description 是最重要欄位、最多 1024 字元 | 我們全靠「使用時機」描述被喊起，含糊就漏觸發。課程明講「照使用者實際講法加觸發詞、用變體測試」——這正是我們該定期對 121 個 skill 做的描述體檢。 |
| 漸進式揭露＋skill.md 500 行內＋腳本只吃輸出 | 把重活寫成腳本、細節拆檔、需要才載入，主線 context 不被塞爆——對上你最在意的「精簡省上下文」。編排型 skill（如 ig-one-click）正是這樣設計。 |
| allowed-tools 可做成唯讀、不許寫/bash | 危險或發佈類 skill 只給必要工具、甚至鎖成唯讀——對上你「零風險、危險動作要點頭」的紅線，是可直接落地的權限收斂。 |
| subagent 不自動繼承 skill、內建 agent 完全不能用 | 這條最容易踩雷！我們多員工並行時，若靠 subagent 卻假設它會自動有 skill 就會出錯——要在自訂 agent 的 skills 欄位明確列出。這修正了一個我原本會犯的假設。 |
三、我們怎麼用（課程實招對到梵熹現有系統）
| 課程實招 | 梵熹已經在用 / 可補強 |
|---|---|
| Skill＝可重用能力包（description 驅動） | 已在用~/.claude/skills 底下 121 個 skill、一句話喚起，全靠「使用時機」描述被匹配。 |
| 描述含糊會漏觸發，要加實際講法變體 | 補強用 make-skill 對 121 個 skill 做一輪描述體檢，補上使用者真實會講的觸發詞。 |
| 漸進式揭露／腳本只吃輸出 | 已在用ig-one-click、content-fanout 等編排型 skill 內含腳本，用時才載入，不塞爆 context。 |
| allowed-tools 縮權限、做唯讀 | 補強把 fb-publish／ig-publish／刪除類 skill 明確限縮工具，發佈前仍走三鈕核准。 |
| 優先權：企業>個人>專案>外掛、名稱要獨特 | 已在用我們 skill 命名有鐵則（新英文命名、避免撞名）。補強照課程掃一次有無過於相似、會混淆的描述。 |
| Skill 與 CLAUDE.md/hooks 分工 | 已在用CLAUDE.md 放鐵律、自癒 hook 事件觸發、能力走 skill。補強MEMORY 過肥，能移進 skill 的移出去。 |
| 用 repo/plugin/企業層共享 | 已在用skill 正本進 git，全體員工 agent 繼承同一套。 |
| subagent 要在 skills 欄位明列 skill | 補強替常派的員工 agent 檢查有沒有把該用的 skill 明確列進 skills 欄位，別假設自動繼承。 |
除錯：驗證器＋claude --debug＋檔名 SKILL.md | 補強把「沒觸發／優先權打架／檔名錯」排錯清單收進 make-skill，遇到不靈時照跑。 |
本課帶來的優化（萃取自「課程優化提案」／落地狀態）
這門課我們學完，實際拿去改進的重點如下。綠＝已回灌團隊鐵律、可立刻生效；橘＝待 Norick 拍板；藍＝程式類由工程同事另辦或未來自建才用。
| 本課萃取的優化點 | 落地狀態 | 落在哪份規則／流程 |
|---|---|---|
| 員工不自動繼承 skill、要在 agent.md skills 欄明列（內建 explore／plan／verify 完全讀不到 skill）。 | 待 Norick 拍板（可能是員工用不到 skill 的根因·P0） | 31 人編制各 agent.md |
| skill progressive disclosure 稽核：SKILL.md < 500 行、細節塞 references／腳本用「跑」不用「讀」。 | 待 Norick 拍板 | make-skill 產出檢查；file-archive-lint |
| agent-skills verifier 進 make-skill 驗收：每產／改一個 skill 自動驗檔名／YAML／description。 | 待 Norick 拍板 | make-skill 收尾 |
| 稽核類 skill 用 allowed-tools 鎖唯讀：file-archive-lint／course-brand-audit 等「只稽核不刪改」在定義層砍掉 edit／write。 | 部分 已套進營運鐵則三條（最小權限） | 各稽核 skill 的 allowed-tools |
簡報｜Introduction to Subagents
課程 Introduction to Subagents
來源 影片 CC 逐字稿（非大綱推測）
整理 2026-07-03
對照 梵熹多員工並行 + 31 位員工編制
一句話：Subagent 是「Claude 可以委派任務的專門助手」，每個都跑在自己的 context 視窗、有你定義的自訂 system prompt，做完只把摘要回傳主線，中間的過程全部丟棄。影片的核心金句：「你能問的最關鍵一題是——中間過程對主線重不重要？不重要，就委派出去。」它舉的例子很具體：想在陌生 codebase 查「哪個服務處理退款」，沒 subagent 時 Claude 可能讀 15 個檔、跑好幾次搜尋、追多個函式呼叫，全塞進你的主 context；有 subagent 就「拿到答案、不用經歷那段旅程」。這正是我們「一次派多員工並行、主線保持乾淨」鐵則的官方版本。以下每支影片用它實際講的內容重寫。
一、逐支影片實際重點（照 CC 內容）
| 影片 | 影片實際講的 |
|---|---|
| 1 什麼是 Subagent | Subagent 跑在自己的 context 視窗、有自訂 system prompt，做完回摘要、中間全隔離。主要好處是管理 context 用量：你跟主線每次工具呼叫與結果都堆進主 context；subagent 另開視窗、收兩個輸入（你設定檔裡的自訂 system prompt＋父代理照你需求寫的任務描述），自主做完，讀檔改檔用工具都不出現在主對話，只回摘要，然後整段 subagent 對話被完全丟棄。代價：主線失去對「它怎麼得出結論、沿路發現什麼」的可見性。內建 subagent 可直接用：general-purpose（要探索＋行動的多步驟任務）、explore（快速搜 codebase）、plan（plan 模式下先研究分析再出計畫）；也可自建帶自訂 system prompt 與工具權限的。 |
| 2 建立 Subagent | 自訂 subagent 是帶 YAML frontmatter 的 markdown 檔。最簡單用 /agents 指令這個管理面板：選 create new agent → 問你要建「當前專案」還是「全機共用」→ 建議讓 Claude Code 自動幫你生（會生出 name、description、system prompt）→ 讓你調它可用的工具（例如 review 用的可禁編輯、但留執行以便看 diff）→ 選驅動模型 → 選顏色（UI 辨識用）。各欄位：name（唯一識別，用 @agent-code-reviewer 引用）；description（決定 Claude 何時用它，必須單行、含跳脫換行字元，想讓它更常自動用就加 proactively，可放範例對話）；tools（可用工具，可再手改）；model（Sonnet／Opus／Haiku／inherit——Haiku 快、Opus 複雜分析、Sonnet 中間、inherit 跟主對話同一個）；檔案主體＝system prompt（指導它怎麼做、怎麼回報）。沒被用到就檢查 description、加更具體範例。 |
| 3 設計可靠的 Subagent | 原理：你每對主線發訊息，每個 subagent 的 name 和 description 都被塞進主代理的 system prompt；主代理啟動 subagent 時也拿 description 當指引寫任務 prompt。所以想控制「何時自動啟動、主線交辦時說什麼」，就改 name/description（例如在 description 寫「必須明確告訴 agent 要 review 哪些檔」，主線就會照傳；給 web 搜尋 agent 的描述加「回傳可引用的來源」，交辦時就會帶這指令）。最重要的改進：在 system prompt 定義輸出格式——這給 subagent 自然的停止點，沒有輸出格式它很難判斷「研究夠了沒」、常常跑超久。要求主動回報障礙：碰到解法（相依問題、某指令要特定 flag、import 出錯）要寫進摘要，否則主線得重新發現一次。限制工具權限：只研究就唯讀（glob/grep/read，不會誤改檔）；reviewer 要跑 git diff 給 bash 但不給編輯；只有真要改碼的（如套 CSS 的 styling agent）才給 edit/write。 |
| 4 有效運用 Subagent | 差別就一句：中間過程對主線重不重要。探索與執行分得開時 subagent 發光；每步都依賴前一步的發現時，資訊會在交接中流失。適合：① 研究型（只要答案不要旅程，例如「JWT 在哪驗證」→ 主線只收「在 middleware/auth.js 第 42 行、由 route/api.js 呼叫」）；② review（Claude 對自己多輪寫的 code 難有新鮮眼光，reviewer 在獨立 context 看 diff 更客觀，還能把團隊 review 標準寫進它 system prompt）；③ 需要不同 system prompt（Claude Code 預設偏簡潔技術語氣，寫文案要另設 tone/audience/style 的 copywriting subagent；styling subagent @ 你的設計系統檔就自動載入色票間距）。該避開：① 宣稱專家沒用（「你是 Python 專家」加不了價值，Claude 本就會）；② 循序管線會出問題（重現 bug→除錯→修復這種每步依賴前步的會失敗）；③ test runner 會藏掉你要的資訊（測試失敗你要完整輸出診斷，它只回「測試失敗」逼你另寫 debug script，實測是所有配置裡表現最差的）。 |
二、我學到、對梵熹最有用的 5 點
| 學到什麼 | 為什麼對我們重要 |
|---|---|
| 唯一判準：中間過程對主線重不重要 | 這是影片反覆強調的一題。派員工並行前先問這句：研究型/掃檔型（不要旅程只要答案）就大膽派；每步依賴前步的別拆。直接對上你「多員工並行、主線精簡」。 |
| 在 system prompt 定義輸出格式＝停止點 | 沒定輸出格式，subagent 會跑超久、不知何時算完。要求員工回固定格式——正好對上你「給我表格分類、禁文字牆」，還順便省 token。 |
| 模型分級：Haiku 快 / Opus 複雜 / Sonnet 中間 / inherit | 這條直接對上我們 pick_model() 的選模型鐵則。subagent 的 model 欄位就該照任務難度挑，瑣事 Haiku、難的 Opus，不是一律最貴。 |
| 限制工具＝唯讀/給 bash/才給 edit 三級 | 只研究就唯讀（不會誤改）、reviewer 給 bash 看 diff、只有改碼的才給 edit/write——對上你「零風險、危險動作要點頭」，是可直接落地的權限分級。 |
| 三個反例：別宣稱專家、別循序管線、別 test runner | 這修正了會踩的雷：以前可能想串「重現→除錯→修復」管線，課程明說每步依賴前步會失敗；test runner 更是實測最差。並行要拆「真獨立」的活。 |
三、我們怎麼用（課程實招對到梵熹現有系統）
| 課程實招 | 梵熹已經在用 / 可補強 |
|---|---|
| Subagent 隔離 context、只回摘要 | 已在用「一次最多派多位並行」鐵則，各自獨立 context，只收結論回主線。 |
用 /agents 建自訂 subagent | 已在用31 位員工編制、5 大產線，每位有自訂 system prompt 與職責。 |
| description 決定何時自動啟動、加 proactively | 補強替常自動派的員工在 description 加 proactively、放範例對話，讓路由更準。 |
| model 欄位照難度挑（Haiku/Opus/Sonnet） | 已在用pick_model() 已落地按難度挑模型。補強對照課程把每位員工預設模型再校一次。 |
| system prompt 定義輸出格式 | 已在用員工回報走固定格式。補強統一成表格模板當「停止點」，收攏更快、也止住跑超久。 |
| 主動回報障礙（解法/flag/相依） | 已在用「卡在哪＋我的解法」回報鐵律。補強照課程把「工作繞道/特殊 flag/相依問題」明列進回報格式，免主線重發現。 |
| 工具權限三級（唯讀/bash/edit） | 補強替發佈／刪除類員工做權限分級，研究型鎖唯讀。 |
| 該派 vs 不該派（別循序管線/test runner） | 已在用hermes-route 做四維路由。補強把「有依賴不硬拆並行、別串 test runner 管線」寫進派工 SOP。 |
本課帶來的優化（萃取自「課程優化提案」／落地狀態）
這門課我們學完，實際拿去改進的重點如下。綠＝已回灌團隊鐵律、可立刻生效；橘＝待 Norick 拍板；藍＝程式類由工程同事另辦或未來自建才用。
| 本課萃取的優化點 | 落地狀態 | 落在哪份規則／流程 |
|---|---|---|
| 並行的反面守則（「13 員工並行」的但書）：①別派空殼「你是 X 專家」agent ②有前後依賴的序列別硬拆多 agent ③跑測試／要看完整輸出的別丟 subagent。 | 已套進鐵律 G 段 | G 段 |
| 員工工具權限最小化：研究型只給 read-only、審查型才加 bash、只有改碼才給 edit／write。 | 已套進營運鐵則三條 ＋待補 agent.md | 營運鐵則三條；各 agent.md tools 欄 |
| 員工 system prompt 必含「輸出格式＋回報障礙」：沒定義輸出格式的 subagent 會跑不完、拖很久。 | 待 Norick 拍板 | 員工人設範本；team-dispatch |
| 員工 agent.md 補 model 欄把模型分級寫死（瑣事 Haiku／一般 Opus／最難 Fable5／資安封頂 Opus）。 | 程式類·工程另辦 | 各員工 agent.md；員工產生器 |
簡報｜Claude with Amazon Bedrock
課程 Claude with Amazon Bedrock
平台 Anthropic Academy（Skilljar）
整理 2026-07-02
來源 課程大綱＋Claude 官方 Bedrock 文件實查
一句話：這門課教「怎麼把 Claude 接到公司既有的 AWS 帳號裡跑」——一樣的 Messages API、prompt engineering、tool use、RAG、MCP、agent 全套，只是換成走 Bedrock 這個門，帳單併進 AWS、資料留在你選的雲區。對梵熹來說，這是客戶如果本來就在 AWS、或要求資料落地／合規時才用得上的路，平常我們走 Claude 直連就好。這份簡報列每一模組重點，並標出哪些要另外花錢上雲。
一、課程講了什麼（10 模組逐段重點）
| 模組 | 這一段的重點（取自 API 課 CC） |
|---|---|
| 1 課程導論 | 三個模型家族的真實取捨：Opus 最聰明，能獨立跑數小時的複雜多步任務、支援 reasoning，但成本較高延遲中等；Sonnet 是甜蜜點，coding 強、能對複雜 codebase 精準改動不弄壞既有功能，本課大多用它；Haiku 最快最省、不支援 reasoning，適合即時面向使用者的場景。挑法：先確認你最在意智慧／速度／成本哪一個；很多團隊同一應用混用三種。 |
| 2 用 API 工作 | 五步請求生命週期＋核心基本功。鐵則：別從前端直呼 API（密鑰要藏在你自己的 server）；官方 SDK 有 Python／TS／JS／Go／Ruby。API 無狀態、不幫你存任何訊息——要有記憶就得自己維護 messages 清單、每輪整包送回（課程手把手寫 add_user_message／add_assistant_message／chat 三個 helper）。max_tokens 是安全上限不是目標值；system prompt 定角色語氣（患者數學家教例）；temperature 0–1（0 幾乎決定性、資料抽取用低、腦力激盪／創意用高）；streaming 逐塊回（真正要的是 content_block_delta 事件）；結構化資料用 assistant 訊息 prefill ＋ stop sequence 逼出純 JSON，不要多餘的開頭結尾。 |
| 3 Prompt 評估 | 講師直說「寫完只測一兩次就上線」是所有工程師都會掉的陷阱，該走選項三：跑評測管線拿客觀分數再迭代。三種 grader：code（驗語法，把輸出當 JSON parse／編成 Python AST／compile 成 regex）、model（模型當評審，常輸出 1–10 分）、human。對上我們最在意的「報成功前先驗證」。 |
| 4 Prompt 工程 | 四招：講清楚講直接（第一行最重要，用動作動詞講死任務，如「寫三段說明太陽能板怎麼運作」）、講具體（列出步驟／準則把發散收斂）、XML 標籤（把大段貼進來的內容分區，讓 Claude 認得哪段是哪段）、給範例（one-shot／multi-shot，講師說這是最有效的技巧之一，如示範推文情緒分類）。 |
| 5 Tool Use（工具使用） | 讓 Claude 取外部世界資訊——預設它只有訓練資料、不知即時事（問「舊金山現在天氣」它答不了）。用 JSON Schema 定義工具、接工具回傳、多輪帶工具、一次掛多個、批次工具、text editor 工具改檔、web search 工具。這是 agent 的地基。 |
| 6 RAG 檢索增強 | 讓 Claude 讀外部知識庫（例：一份幾百到上千頁的財報，只問特定段落如「有哪些風險因子」）：文件切塊、embedding 語意向量、BM25 關鍵字、混合搜尋、重排序（rerank）、多索引 pipeline。 |
| 7 Claude 的特色功能 | extended thinking（先想再答，複雜題更準，但思考 token 要付費、延遲增加，該按需開）、圖片與 PDF 輸入、citations 引用出處、prompt caching（快取輸入處理階段，重複長前綴後續呼叫更快更省）、程式碼執行與 Files API。 |
| 8 MCP | Model Context Protocol＝通訊層，免你寫一堆膠水碼就能餵 Claude 脈絡與工具。client／server 架構，server 內含 tools／resources／prompts（例：一個聊你 GitHub 資料的 app）；用 inspector 除錯。 |
| 9 Agents | 處理「單一請求做不完」的任務。判準：步驟已知就用 workflow（預定義一串呼叫、把大任務拆小、更專注更準）；步驟未知就用 agent（給一組基礎工具，讓 Claude 自己組合完成）。含平行化／串接／路由三種 workflow、Claude Code 設定與實戰、MCP server 增強、Computer Use（操作螢幕），最後有結業測驗。 |
| 10 總結 | 重點回顧、再次強調「上線前一定要測」、workflow 與 agent 的取捨與 agentic 趨勢走向。 |
Bedrock 專屬部署重點（官方文件實查）：
| 環節 | 怎麼做 |
|---|---|
| 開通 | AWS Console → Bedrock → Model Access 申請 Anthropic 模型存取；各區（region）分開開通，模型可用性看區。 |
| 驗證身分 | 裝 AWS CLI（≥2.13.23）跑 aws configure，用 aws sts get-caller-identity 驗；SDK 走 pip install "anthropic[bedrock]" 或直接用 boto3。 |
| 三種認證 | ① 標準 AWS 憑證（~/.aws/credentials 或環境變數）② 臨時憑證（session token）③ 企業免管 IAM：Bearer token（AWS_BEARER_TOKEN_BEDROCK），讓團隊不必碰 IAM 角色就能用。 |
| 呼叫 | AnthropicBedrock() → client.messages.create(model="global.anthropic.claude-opus-4-6-v1", ...)，跟直連 API 幾乎一樣。 |
| 端點與落地 | global 端點（動態路由、最高可用、不加價）；regional / CRIS 端點（US／EU／日本／亞太，保證資料走特定區、供合規落地，加價 10%）。 |
| 合規稽核 | Bedrock 內建 invocation logging，官方建議至少 30 天滾動記錄 prompt 與回覆以查濫用；開 log 不會讓 AWS 或 Anthropic 看到你的內容。新模型 context 達 100 萬 token，單一請求上限 20MB。 |
二、對梵熹最有用的 4 點
| 重點 | 為什麼對我們重要 |
|---|---|
| Prompt 評測管線 | 「模型當評審＋程式碼規則打分」正好落地我們的「報成功前必親自驗證」，可套進交付前的品質關卡，防謊報。 |
| Prompt caching 省錢 | 重複的長前綴（品牌規則、語氣準則、範本）可快取，之後每次呼叫更快更省——我們的 skill 大量重複同一段品牌 context，這招直接省成本。 |
| Bearer token 免管 IAM | 之後若有客戶案要接他們的 AWS，用 AWS_BEARER_TOKEN_BEDROCK 就能給團隊存取，不必幫每個人配 IAM 角色，交接乾淨。 |
| regional 端點＝資料落地牌 | 接到要求「資料不能出某區」的客戶（金融、醫療、政府），regional/CRIS 端點是現成解法，談案時是加分籌碼。 |
三、我們怎麼用（雲端部署參考｜含花錢與否）
結論先講：梵熹現在用 Claude 是走 Claude Code／Claude API 直連（訂閱與 API 額度），這條路現況免另外上雲。上 Bedrock 屬於「額外把 Claude 接進 AWS」，要另開 AWS 帳號、按 token 走 AWS 帳單付費，要花錢＋要 Norick 點頭。目前沒有非上不可的理由，除非出現下面情境。
| 情境 | 要不要上 Bedrock ＋ 花錢與否 |
|---|---|
| 梵熹自己日常產內容 | 維持現況Claude 直連就夠，不必上 Bedrock，零額外雲費。 |
| 客戶本來就重壓 AWS | 值得上把 Claude 併進他既有 AWS 帳單與權限體系，交付與計費都乾淨；費用走客戶的 AWS，按 token 計。 |
| 客戶要求資料落地／合規 | 要上用 regional／CRIS 端點指定資料走哪區（加價 10%），滿足金融醫療政府類合規，這是 Bedrock 的主打價值。 |
| 要接 AWS 上其他服務 | 可上要跟 S3、Lambda、既有 AWS 資料流串一起時，同帳號同 IAM 較順。 |
| 只是想試看看 | 先別學習用途在直連 API 或 Claude Code 就能全試（tool use／RAG／MCP／agent），不用先燒 AWS 帳單。 |
本課帶來的優化（萃取自「課程優化提案」／落地狀態）
這門課我們學完，實際拿去改進的重點如下。綠＝已回灌團隊鐵律、可立刻生效；橘＝待 Norick 拍板；藍＝程式類由工程同事另辦或未來自建才用。
| 本課萃取的優化點 | 落地狀態 | 落在哪份規則／流程 |
|---|---|---|
| Bedrock／Vertex 選型：梵熹自用一律走 Anthropic API／Claude 訂閱，只有客戶要求資料落在他自己 AWS、或企業合規／資料落地才上 Bedrock。 | 已套進鐵律 G 段 | G 段；agent-mvp-planner／proposal-doc 選型段 |
簡報｜Claude with Google Cloud Vertex AI
課程 Claude with Google Cloud Vertex AI
平台 Anthropic Academy（Skilljar）
整理 2026-07-02
來源 課程大綱＋Claude 官方 Vertex 文件實查
一句話：這門課跟 Bedrock 版是同一套 Claude API 課程，只是換成走 Google Cloud 的 Vertex AI（現稱 Agent Platform）這個門——一樣教 Messages API、prompt engineering、tool use、RAG、MCP、agent 全套，帳單併進 GCP、資料留在你選的雲區。對梵熹來說，這是客戶本來就在 Google Cloud、或要求資料落地／合規時才用得上的路。這份簡報列每一模組重點，並標出哪些要另外花錢上雲。
一、課程講了什麼（10 模組逐段重點）
| 模組 | 這一段的重點（取自 API 課 CC） |
|---|---|
| 1 課程導論 | 三個模型家族的真實取捨：Opus 最聰明，能獨立跑數小時的複雜多步任務、支援 reasoning，但成本較高延遲中等；Sonnet 是甜蜜點，coding 強、能對複雜 codebase 精準改動不弄壞既有功能，本課大多用它；Haiku 最快最省、不支援 reasoning，適合即時面向使用者的場景。挑法：先確認你最在意智慧／速度／成本哪一個；很多團隊同一應用混用三種。 |
| 2 用 API 工作 | 五步請求生命週期＋核心基本功。鐵則：別從前端直呼 API（密鑰要藏在你自己的 server）；官方 SDK 有 Python／TS／JS／Go／Ruby。API 無狀態、不幫你存任何訊息——要有記憶就得自己維護 messages 清單、每輪整包送回（課程手把手寫 add_user_message／add_assistant_message／chat 三個 helper）。max_tokens 是安全上限不是目標值；system prompt 定角色語氣（患者數學家教例）；temperature 0–1（0 幾乎決定性、資料抽取用低、腦力激盪／創意用高）；streaming 逐塊回（真正要的是 content_block_delta 事件）；結構化資料用 assistant 訊息 prefill ＋ stop sequence 逼出純 JSON，不要多餘的開頭結尾。 |
| 3 Prompt 評估 | 講師直說「寫完只測一兩次就上線」是所有工程師都會掉的陷阱，該走選項三：跑評測管線拿客觀分數再迭代。三種 grader：code（驗語法，把輸出當 JSON parse／編成 Python AST／compile 成 regex）、model（模型當評審，常輸出 1–10 分）、human。對上我們最在意的「報成功前先驗證」。 |
| 4 Prompt 工程 | 四招：講清楚講直接（第一行最重要，用動作動詞講死任務，如「寫三段說明太陽能板怎麼運作」）、講具體（列出步驟／準則把發散收斂）、XML 標籤（把大段貼進來的內容分區，讓 Claude 認得哪段是哪段）、給範例（one-shot／multi-shot，講師說這是最有效的技巧之一，如示範推文情緒分類）。 |
| 5 Tool Use（工具使用） | 讓 Claude 取外部世界資訊——預設它只有訓練資料、不知即時事（問「舊金山現在天氣」它答不了）。用 JSON Schema 定義工具、接工具回傳、多輪帶工具、一次掛多個、批次工具、text editor 工具改檔、web search 工具。這是 agent 的地基。 |
| 6 RAG 檢索增強 | 讓 Claude 讀外部知識庫（例：一份幾百到上千頁的財報，只問特定段落如「有哪些風險因子」）：文件切塊、embedding 語意向量、BM25 關鍵字、混合搜尋、重排序（rerank）、多索引 pipeline。 |
| 7 Claude 的特色功能 | extended thinking（先想再答，複雜題更準，但思考 token 要付費、延遲增加，該按需開）、圖片與 PDF 輸入、citations 引用出處、prompt caching（快取輸入處理階段，重複長前綴後續呼叫更快更省）、程式碼執行與 Files API。 |
| 8 MCP | Model Context Protocol＝通訊層，免你寫一堆膠水碼就能餵 Claude 脈絡與工具。client／server 架構，server 內含 tools／resources／prompts（例：一個聊你 GitHub 資料的 app）；用 inspector 除錯。 |
| 9 Agents | 處理「單一請求做不完」的任務。判準：步驟已知就用 workflow（預定義一串呼叫、把大任務拆小、更專注更準）；步驟未知就用 agent（給一組基礎工具，讓 Claude 自己組合完成）。含平行化／串接／路由三種 workflow、Claude Code 設定與實戰、MCP server 增強、Computer Use（操作螢幕），最後有結業測驗。 |
| 10 總結 | 重點回顧、再次強調「上線前一定要測」、workflow 與 agent 的取捨與 agentic 趨勢走向。 |
Vertex AI 專屬部署重點（官方文件實查）：
| 環節 | 怎麼做 |
|---|---|
| 開通 | 要有一個能用 Vertex AI 的 GCP 專案；到 Model Garden 搜「Claude」啟用 Anthropic 模型；模型可用性看區。 |
| 驗證身分 | 跑 gcloud auth application-default login（或用 service account 憑證）；SDK 走 pip install -U google-cloud-aiplatform "anthropic[vertex]"。 |
| 呼叫（跟直連兩點差異） | AnthropicVertex(project_id, region) → model="claude-opus-4-8"。差異：① model 放在端點 URL、不放 body ② anthropic_version 放 body 且固定 vertex-2023-10-16。 |
| 三種端點 | global（動態路由、最高可用、不加價）；multi-region（us 或 eu，一個地理區內動態調度、加價 10%）；regional（單一區如 us-east1，資料落單區、供 provisioned throughput、加價 10%）。 |
| 合規稽核 | 資料治理由 Google Cloud 管，支援 zero data retention；內建 request-response logging，官方建議至少 30 天滾動記錄以查濫用；開 log 不會讓 Google 或 Anthropic 看到你的內容。新模型 context 達 100 萬 token，單一請求上限 30MB。 |
二、對梵熹最有用的 4 點
| 重點 | 為什麼對我們重要 |
|---|---|
| Prompt 評測管線 | 「模型當評審＋程式碼規則打分」正好落地我們的「報成功前必親自驗證」，可套進交付前的品質關卡，防謊報。 |
| 已在 Google 生態 | 梵熹本來就重壓 Google（Gmail／Drive／Calendar／帳號體系），若要把 Claude 接進 GCP，Vertex 與既有 Google 登入、專案權限最順，不必再開一套雲。 |
| zero data retention＋落地 | 接到在意隱私的客戶，Vertex 的 zero data retention 與 regional 端點是現成的資料治理牌，談案加分。 |
| multi-region 彈性 | 要「資料留在美國或歐盟這個大區、又要高可用」時，multi-region（us／eu）比單區更穩，是 Bedrock 沒有的中間檔。 |
三、我們怎麼用（雲端部署參考｜含花錢與否）
結論先講：梵熹現在用 Claude 是走 Claude Code／Claude API 直連（訂閱與 API 額度），這條路現況免另外上雲。上 Vertex 屬於「額外把 Claude 接進 GCP」，要有 GCP 專案、按 token 走 Google Cloud 帳單付費，要花錢＋要 Norick 點頭。目前沒有非上不可的理由，除非出現下面情境。
| 情境 | 要不要上 Vertex ＋ 花錢與否 |
|---|---|
| 梵熹自己日常產內容 | 維持現況Claude 直連就夠，不必上 Vertex，零額外雲費。 |
| 客戶本來就重壓 GCP | 值得上把 Claude 併進他既有的 Google Cloud 專案與 IAM，交付與計費乾淨；費用走 GCP 帳單，按 token 計。 |
| 客戶要求資料落地／隱私 | 要上用 regional／multi-region 端點指定資料走哪區（加價 10%）＋zero data retention，滿足隱私與合規要求。 |
| 要接 GCP 上其他服務 | 可上要跟 BigQuery、Cloud Storage、既有 Google 資料流串一起時，同專案同 IAM 較順。 |
| 只是想試看看 | 先別學習用途在直連 API 或 Claude Code 就能全試（tool use／RAG／MCP／agent），不用先燒 GCP 帳單。 |
本課帶來的優化（萃取自「課程優化提案」／落地狀態）
這門課我們學完，實際拿去改進的重點如下。綠＝已回灌團隊鐵律、可立刻生效；橘＝待 Norick 拍板；藍＝程式類由工程同事另辦或未來自建才用。
| 本課萃取的優化點 | 落地狀態 | 落在哪份規則／流程 |
|---|---|---|
| Bedrock／Vertex 選型：同 Bedrock——別被客戶帶著無腦上雲多背一手雲帳單＋設定成本；有落地／合規需求才上 Vertex。 | 已套進鐵律 G 段 | G 段；client-intake／proposal-doc 技術選型 |
簡報｜AI 能力與極限
課程 AI Capabilities and Limitations
來源 Anthropic Academy
來源 9 支 YouTube 影片 CC 全抓
整理人 Claude（替 Norick）
一句話：這門課是 AI Fluency（4D）的姊妹課——4D 是「你（人）該做什麼」，這門是「機器被你 prompt 後到底在做什麼、為什麼」。它教你在腦裡裝一個耐用的心智模型：AI 怎麼想、記多少、被什麼牽著走、什麼時候會掰。搞懂就能自己判斷一個任務落在 AI 的能力區還是極限區，不被它一本正經講錯話騙到。骨幹是兩段訓練（預訓練＋微調）＋四大特性（下一個字預測、知識、工作記憶、可導引性），最後教你這些特性「兩兩相撞」時怎麼診斷。講師群：Kristen、Maggie、David、Matt。
重點提示（影片金句）：AI 的強項與弱點常來自同一個機制——它寫得流暢是因為是預測引擎，它會幻覺也是因為是預測引擎；變的只是你的任務落在那條線的哪一端。
一、課程講了什麼（9 支影片逐字稿重點）
| 影片 | 這一支實際講了什麼（取自 CC） |
|---|---|
| 1 課程導論 Intro | Kristen 開場：這是 4D 的姊妹課，4D 是人的能力、這門是「機器在做什麼」。你不知道模型哪強哪弱，就沒法 delegate；不知道輸出怎麼來的，就沒法 discern。課程刻意聚焦「AI 怎麼被造出來」，所以模型再怎麼改版都還適用。強調：做練習的人才在學，請拿你自己是專家的領域的真實任務去測，才感覺得出哪裡不對。 |
| 2 什麼是生成式 AI What we mean by AI | 先劃清界線：推薦引擎、垃圾信過濾、盜刷偵測、客服路由都是 AI，但都不是生成式（它們分類、排序，不產生新內容）。生成式 AI 才是這門課主角，靠兩段打造：預訓練學 pattern、微調變得安全有用。核心一句：它本質是預測系統，強弱沿著可預測的軸線分布，而且強弱常來自同一個機制。目標不是叫你不信任 AI，是校準過的信任。 |
| 3 AI 怎麼有個性 How AI gets its character | Maggie 講兩段訓練的指紋。預訓練＝「給定目前所有內容，猜下一個」，重複幾十億次，產出一個「文件接寫機」——問它法國首都，它不回答，它接寫「巴黎。德國首都？柏林…」。微調才把它變成助理。但微調靠人類偏好，會留下四個陰影：①諂媚（你一反駁它就退讓，哪怕它本來對）②囉唆（訓練時完整得高分，就愛長篇）③過度謹慎（把安全的請求也擋掉）④信心校準鬆（它講得多有把握跟實際準不準只是鬆散相關）。這些不是單一模型的 bug，是所有模型都有。 |
| 4 下一個字預測 Next token prediction | David 講最核心機制：它像超強 autocomplete，不是搜尋引擎——「一個長得像真引用的引用，能滿足 pattern，跟指向真論文一樣好」。走過千遍的路（摘要、改寫、解釋常見概念）落在能力區；冷門邊緣（某小領域研究者的三篇論文）它照樣講得很順很自信，但可能是掰的。特異性越高越要查：名字、日期、統計、引用、引號、URL。自信的語氣不代表正確——流暢與正確是兩個獨立變數。產品補救：citations／source grounding、訓練過的不確定訊號、constrained generation／skills、generator-verifier 迴圈。 |
| 5 知識 Knowledge | David 講知識邊界。知識全來自訓練資料、凍結在知識截止日——問「光合作用怎麼運作」答得又準又深（出現過上千次、沒變）；問「Toledo 現任市長是誰」它可能給你兩年前的人，還分不出差別。五種極限：截止日、資料過時、覆蓋不均（冷門／小語種／近期都差）、繼承偏差（對「醫生長什麼樣」的預設）、來源健忘（說不出哪來的）。要問的不是「它知不知道」，是「這在它讀過的東西裡出現得多充分」。補救：web search、MCP 接你私有文件、工具、明示截止日。 |
| 6 工作記憶 Working memory | Matt 講 context window：你的指令、它的回話、上傳的文件、來回對話全塞在一個固定大小的容器，超過就有東西掉出去（通常是最舊的、而且悄悄地掉，不會警告你）。預設每個 session 之間會清空。跟其他三個特性不同，這個有「懸崖」——它一路正常直到突然不行。還有「中間迷失」效應：埋在超長輸入正中間的資料權重最低。補救：memory 跨 session、compaction 壓縮、projects／workspaces 常駐、skills、多代理各有自己的視窗。技巧：重要的放最前、長文分段跑、品質掉了就開新對話。 |
| 7 可導引性 Steerability | Matt 講「聽話但不等於懂」。你說「給我表格」它給表格、「用懷疑者角度寫」它就換視角——這是微調給的。但它照的是 pattern，不是你腦裡的意圖，兩者間永遠有縫。金句例子：「100 字內、要精悍」——它照做了，卻把你真正需要的那個但書給砍了（照字面、丟精神）。縫大的地方：長推理鏈（第二步小錯一路帶到五步）、抽象指令（「要有洞見」）。還有prompt injection：藏在文件／網頁裡的惡意指令也會被照做。補救：system prompt、可見推理、結構化輸出。技巧：把目標跟步驟一起講、用檢查點打斷長鏈、指令沒中就重講目標而不是把指令講更大聲。 |
| 8 特性相撞 When properties collide | 把四支合起來看：真實世界的怪答案多半是兩個特性同時發作，能叫出是哪兩個，解法就明顯了。①冷門主題給你一篇不存在的論文＝下一個字預測 × 知識缺口（它生出引用形狀的字，底下有洞它自己不知道）→ 獨立查證或用 source grounding。②長對話 20 則後它無視你早先設的一半限制＝工作記憶 × 可導引性（早期脈絡淡出、它照最新最顯著的指令走）→ 補回關鍵脈絡或開新對話把重點放前面。動手前先問「這任務碰到哪些特性」——先診斷再修，別急著改 prompt 用猜的。 |
| 9 下一步 Next steps | Kristen 收尾把兩套框架縫起來：4D 是「你做的事」，四大特性是「你在回應的對象」。懂下一個字預測讓你更會 discern（流暢≠正確）；懂工作記憶讓你更會 description（脈絡是槓桿、別假設它記得）；懂可導引性讓你更會 delegation（哪裡控制力高哪裡低）。校準過的信任是一種習慣不是態度：交任務前快速自問（這是熟路還稀疏？主題新還穩？脈絡在視窗內嗎？指令跟意圖有沒有縫？）再據此調整。數字會變、邊界會移，但這些特性的形狀會留著。 |
二、我學到、且對我們梵熹最有用的 5 點
| 重點 | 為什麼對我們重要 |
|---|---|
| 它追求「聽起來對」不是「事實對」 | 這正是謊報的根源。對上你最在意的紅線「報成功前必親自驗證」——AI 天生會把話講得很順很有自信，所以我一定要用可跑的證據驗過才回報，不能拿「聽起來完成了」當完成。 |
| 知識有截止日、私有資料會掰 | 寫輿情、報數據、引產業資訊時，不能只信它腦裡的舊知識。要嘛上網查證、要嘛讀我們自己的檔案餵給它。對上你「輿情先掃全民熱點」「需金鑰先查倉庫」的做法——用真資料，不用它的記憶。 |
| 工作記憶有上限，太長會忘 | 對上我們「每小時對折存檔成記憶」「糾正兩次沒解就重開」。長對話不能硬撐，重點要落成檔案（MEMORY／CLAUDE.md），不能靠它記在腦裡。 |
| 可導引＝指令越清楚越準 | 對上你「動手前先確認、一次做對」。派工把任務、驗收標準、禁忌講死，它就少腦補；含糊它就自己編。這是我們派 skill／子代理該有的規格紀律。 |
| 怪答案是多重極限疊加 | 它不會的東西，會用「很聽話＋很流暢」包裝成像對的。遇到成品怪怪的，要拆解是知識不足、記憶掉了、還是被我問法帶偏——別急著相信也別急著全丟。 |
三、我們怎麼用（重點：知道 AI 的極限，怎麼避免謊報／過度承諾）
| 課程極限 | 梵熹的對策（已在用 / 可補強） |
|---|---|
| 愛掰、講得很有信心（幻覺） | 已在用「報成功前必親自驗證」鐵則：commit≠push、送達≠通知、設了≠生效，一律附證據。補強成品要附可看的東西（截圖／連結／ffprobe 實測），不只說「做好了在某路徑」。 |
| 知識有截止日、私有的會掰 | 已在用需金鑰／資料先查倉庫、輿情先上網掃熱點。補強凡引數字、產業事實一律標來源或先查證，查不到就講「查不到」，不硬填。 |
| 工作記憶塞爆會忘 | 已在用每小時對折存檔成記憶＋重開先讀 CLAUDE.md／MEMORY。補強MEMORY 已偏肥，該剪枝瘦身，避免重點被稀釋。 |
| 很聽話但會被帶偏 | 已在用派工把驗收標準與禁忌講死（台灣口吻、禁 AI 對比句式、無 emoji）。補強危險／對外動作一律先問 Norick 點頭，不讓它自己越權。 |
| 過度承諾 | 已在用語氣基準「不過度承諾、避免絕對／保證／躺賺」。補強對客戶 KPI 先量基準再談，做得到才寫進交付，寧可少承諾也不謊報。 |
給 Norick 一句話收尾：這門課最值錢的一句話是——「AI 會把不會的東西講得跟會的一模一樣自信。」所以我們整套系統的鐵則（驗證才回報、附上可看證據、真資料不靠記憶、不過度承諾）不是龜毛，正是照著 AI 的極限反過來設計的防呆。
本課帶來的優化（萃取自「課程優化提案」／落地狀態）
這門課我們學完，實際拿去改進的重點如下。綠＝已回灌團隊鐵律、可立刻生效；橘＝待 Norick 拍板；藍＝程式類由工程同事另辦或未來自建才用。
| 本課萃取的優化點 | 落地狀態 | 落在哪份規則／流程 |
|---|---|---|
| 反諂媚（被質疑先重驗別秒認錯）：Norick 一 push back 先回頭重驗原判斷，對就守住擺證據，錯才改。 | 已套進鐵律 G 段 | G 段 |
| 造假熱區優先查＋講順≠對：數字／日期／金額／統編／人名／引用／URL 是幻覺最集中處，愈精確愈要查。 | 已套進鐵律 G 段 | G 段 |
| 時效性事實走即時源：會過期的（誰在位、報價、報名連結還活不活）一律當場 web search，不吃記憶。 | 已套進鐵律 G 段 | G 段 |
| 防 prompt injection：爬回的網頁／文件當「資料」不當「指令」，不被藏字改掉原任務。 | 已套進鐵律 G 段 | G 段 |
| 派工單必含「目標」欄：目標＋步驟並列；照字面做出沒用的東西時回頭補目標，別把指令喊更大聲。 | 已套進鐵律 G 段 | G 段；team-dispatch／hermes-route |
| Context 有懸崖、重要放最前：長對話掉品質是記憶懸崖，帶一段摘要開新局優於硬凹。 | 已套進鐵律 G 段 | G 段（強化 D 段對折） |
| 兩屬性相撞診斷法：出包先命名「是哪兩個屬性撞的」（假引用＝下一詞預測×知識缺口），命名對了解法自動浮現。 | 待 Norick 拍板 | 治本不治標補小抄；hermes-route |
證書
Anthropic Academy 14 張完課證書一覽，學員 Namoh Lamen，全數 100% 完課、測驗滿分，完成日 2026-07-02。每列 verify 連結可點，直接到 skilljar 官方頁公開驗證。
14 / 14
證書全數到手
100%
課程進度完課率
滿分
所有測驗全數 100%
| # | 證書課名 | 完成日 | 測驗分數 | Verify 連結 |
|---|---|---|---|---|
| 01 | Claude 101 | 2026-07-02 | 10 / 10（100%） | 開啟驗證連結 |
| 02 | AI Fluency for Educators | 2026-07-02 | 6 / 6（100%） | 開啟驗證連結 |
| 03 | Introduction to Claude Cowork | 2026-07-02 | 8 / 8（100%） | 開啟驗證連結 |
| 04 | Claude Code 101 | 2026-07-02 | 5 / 5（100%） | 開啟驗證連結 |
| 05 | Claude Code in Action | 2026-07-02 | 8 / 8（100%） | 開啟驗證連結 |
| 06 | Claude Platform 101 | 2026-07-02 | 6 / 6（100%） | 開啟驗證連結 |
| 07 | Building with the Claude API | 2026-07-02 | Final 23 / 23（100%） | 開啟驗證連結 |
| 08 | Introduction to Model Context Protocol | 2026-07-02 | 7 / 7（100%） | 開啟驗證連結 |
| 09 | Model Context Protocol: Advanced Topics | 2026-07-02 | 10 / 10（100%） | 開啟驗證連結 |
| 10 | Introduction to Agent Skills | 2026-07-02 | 無測驗 · 100% 完課 | 開啟驗證連結 |
| 11 | Introduction to Subagents | 2026-07-02 | 無測驗 · 100% 完課 | 開啟驗證連結 |
| 12 | Claude with Amazon Bedrock | 2026-07-02 | Final 21 / 21（100%） | 開啟驗證連結 |
| 13 | Claude with Google Cloud's Vertex AI | 2026-07-02 | Final 24 / 24（100%） | 開啟驗證連結 |
| 14 | AI Capabilities and Limitations | 2026-07-02 | 11 / 11（100%） | 開啟驗證連結 |
14 課優化總覽
這頁是「手冊＝我們實際做的事」的鏡子：14 門課各自萃取出的優化點，哪些已回灌 團隊鐵律 G 段（課程優化回灌 11 條） 與 營運鐵則三條 立刻生效、哪些還等 Norick 拍板、哪些屬程式類由工程同事另辦。點左側各章的「三 · 我們怎麼用」可看到該課的優化細節。
11 ＋ 3
已回灌鐵律 G 段 11 條＋營運鐵則 3 條
已生效
綠標項目全員即刻繼承
14 / 14
每門課都對到具體優化
| # | 課名 | 本課貢獻的優化重點 | 落地狀態 |
|---|---|---|---|
| 01 | Claude 101 | 回歸測試信任法（上線前拿已知答案舊案跑過才切 live） | 已套進鐵律 G 段 |
| 02 | AI Fluency 4D | 交付前紅隊自審（扮懷疑客戶找破綻） | 已套進鐵律 G 段 |
| 03 | Claude Cowork | 外包工作不外包判斷（總綱）、瀏覽器防 injection | 既有規則已在用 ＋ 已套進鐵律 G 段 |
| 04 | Claude Code 101 | MCP 瘦身 CLI 優先、硬鐵則改 hook、CLAUDE.md 從空起手 | 待 Norick 拍板 ＋ 程式類·工程另辦 |
| 05 | Claude Code in Action | 擋金鑰 hook、改檔語法檢查 hook、GitHub PR 自動審查 | 程式類·工程另辦 ＋ 待 Norick 拍板 |
| 06 | Claude Platform 101 | prompt caching、Haiku eval 定模型、rubric 自動 QC | 程式類·工程另辦 ＋ 待 Norick 拍板 |
| 07 | Building the Claude API | caching、eval 管線、workflow 優於 agent、二段式改寫、temperature、web 鎖域、結構化輸出、動作後自檢 | 已套進鐵律 G 段 ＋ 程式類·工程另辦 ＋ 待 Norick 拍板 |
| 08 | MCP | 閒置 MCP server 關掉、三原語分工 | 待 Norick 拍板 ＋ 設計指引（未來自建） |
| 09 | MCP 進階 | roots 鎖目錄、sampling、stateless 旗標 | 待 Norick 拍板 ＋ 設計指引（未來自建） |
| 10 | Agent Skills | 員工明列 skills 欄（根因）、progressive 稽核、verifier、稽核 skill 唯讀 | 待 Norick 拍板 ＋ 已套進營運鐵則三條 |
| 11 | Subagents | 並行反面守則、工具權限最小化、輸出格式＋回報障礙、model 欄 | 已套進鐵律 G 段 ＋ 已套進營運鐵則三條 ＋ 待 Norick 拍板 ＋ 程式類·工程另辦 |
| 12 | Claude with Amazon Bedrock | Bedrock／Vertex 選型（自用走 API，客戶合規才上雲） | 已套進鐵律 G 段 |
| 13 | Claude with Vertex AI | Bedrock／Vertex 選型（別被客戶帶著無腦上雲） | 已套進鐵律 G 段 |
| 14 | AI 能力與極限 | 反諂媚、造假熱區、時效即時源、防 injection、目標欄、context 懸崖、兩屬性相撞 | 已套進鐵律 G 段 ×6 ＋ 待 Norick 拍板 |
已回灌 G 段的 11 條規則：反諂媚、造假熱區＋講順≠對、時效走即時源、防 prompt injection、派工單目標欄、交付前紅隊、回歸測試信任法、workflow 優於 agent、並行反面守則、context 懸崖、Bedrock／Vertex 選型。營運鐵則三條：常駐服務掛看門狗／心跳、排程連失 2 次推 TG、headless claude 最小權限。上面橘標（待拍板）與藍標（程式類）尚未生效，等 Norick 點頭或工程同事排期。