GH-300 GitHub Copilot 認證 - 第五天課程筆記

課程走到最後一天，講師把前四天技術細節全部擺到一邊，丟出四個詞：人負責、流程優先、上下文工程、版本選擇。然後說：「記這四個就好。」

一開始以為是虛招。但把 GH-300 整份考綱攤開後會發現——這四個詞是骨架，前四天的所有 Copilot 功能、Coding Agent、SpecKit、TDD 三 Agent、自訂指令、企業治理，全部都是這四個骨頭上長出的肉。

這就是費曼式的學習：能把整門課壓成一句話的人，才真的學會了。

這篇是 GH-300 的課堂筆記，不是原創深度解析，重點是把第五天上到的東西整理清楚，對應到實務上可以拿去用的行動。

責任制的 AI：六大原則不是投影片上的裝飾

微軟 Responsible AI 框架有六個原則，在 GH-300 的考試跟企業導入場合反覆出現。一開始看會以為是 PR 用的官腔，但仔細讀會發現每一條都扣著工程師日常會踩到的坑。

把六條濃縮成一個類比：AI 就像實習生。很聰明、學得快，但沒有責任能力。六個原則都是為了回答同一個問題——這個實習生搞砸了，誰要負責？

公平性（Fairness）。模型對不同族群、不同程式風格、不同語言的反應要一致。Copilot 底層 LLM 在訓練時供應商已經多輪去偏，但工程師寫 prompt 時還是會不小心帶進歧視字眼。這一條在企業導入時會變成「提示詞稽核」的依據。

包容性（Inclusiveness）。跨 IDE、跨語言、跨技能水平都要能用。Copilot 支援 VS Code、Visual Studio、JetBrains、Eclipse、Xcode，中文提示詞能用、英文也能用——這不只是產品策略，是合規性考量。

可靠性與安全性（Reliability & Safety）。穩定、可預期、異常時有 fallback。工程師看到這條會想到單元測試——但在 AI 情境下它講的是「模型給出的建議不應該讓專案陷入風險」。

隱私與安全（Privacy & Security）。這條最實用：

• 設定裡把「允許用程式碼做訓練」關掉，私有程式碼不會流進 fine-tune
• Block suggestions matching public code 打開，超過 150 字元跟公共程式碼相似的建議會被擋下（避免授權地雷）
• 企業版用 Proxy、IP 白名單、Data Residency 鎖資料流向

問責制（Accountability、Human-in-the-loop）。這一條最重要。每一次 AI 輸出最後都是人負責。Draft PR 的設計就是為了這個——Coding Agent 寫完程式碼不會自己 merge，一律先開 Draft，人工 review 後才能 Ready。

透明性（Transparency）。提供引用來源、顯示匹配到的公開程式碼與授權、企業版有 Audit Log。讀者能追溯「為什麼 AI 給這個答案」，不是黑盒子。

把這六條串起來其實就是一句話：AI 可以寫 code，但不能承擔後果。承擔後果的永遠是人。

三層治理：個人 → 組織 → 企業

Copilot 的設定有三層：個人、組織、企業。企業覆蓋組織，組織覆蓋個人。導入順序跟這個相反——先讓 Enterprise Admin 把強制規則定好（公共程式碼阻擋、資料蒐集、模型存取），再讓個人按偏好微調。

企業層的五個關鍵設定值得背：

Allow GitHub to use my code snippets for product improvements：預設關，企業版幾乎都強制保持關。關掉 = 你的程式碼不會流進 GitHub 做產品改進。

Block suggestions matching public code：建議開。觸發門檻是 150 字元 + 相似度。合規風險的第一道防線。

Suggestions matching public code with references：顯示引用來源與授權。開了之後你會知道這段類似 GPL-3 的程式碼，貼進公司 codebase 之前要想一下。

Allowed models：企業可限定只能用特定模型（例如只允許 GPT-4.1 + Claude Sonnet 4.5）。這條看起來小，實際上是資料主權的防線。

Content exclusions：針對特定 Repo 或檔案 glob 排除 Copilot。密鑰檔、合約範本、法務文件都應該列進去。

加上 Audit Log（Business / Enterprise 才有），稽核鏈就完整了：誰、什麼時候、用哪個模型、問了什麼、改了哪個檔。這條鏈不只是合規，也是效益評估的數據來源。

Coding Agent 三個位置，選錯會受傷

第五天最容易混淆的考點在這裡：Copilot Chat、Coding Agent（雲端）、Codex / Claude Code（本機），三個概念都叫「AI 代理」，但設計目的完全不一樣。

類比一下辦公室：Copilot Chat 是你隔壁桌的資深同事，隨時可以轉頭問一句；雲端 Coding Agent 是你外派給遠端 contractor 的工作；本機 Codex / Claude Code 是你自己僱的助理，在你家裡直接開抽屜拿東西。

雲端 vs 本機的決策很單純：任務需要瀏覽網頁、跨 repo 查找、大量外部 API 互動 → 雲端。需要操作本機環境（terminal、Docker、IDE 外掛）→ 本機。

這條規則倒過來看更清楚——你會把什麼任務交給真的遠端 contractor？同理。你會把什麼任務交給真的住你家的助理？同理。

雲端 Coding Agent 還有一個容易被忽視的細節：它一次只處理一個 Issue，但你可以同時丟多個 Issue 讓多個 Agent 並行跑。想像成你同時發 email 給五個不同的 contractor，每個人負責一件事，全部都以 Draft PR 回來等你 review。這就是為什麼 SDD 的 task 顆粒度要拆小——顆粒度適合 Issue，才適合 Coding Agent。

Slash / @ / # 這三個符號決定了對話品質

Copilot Chat 的上下文不是魔法，是三個符號的組合：

**/**（Slash Command）把常用提示詞封裝成指令。/explain、/fix、/tests、/docs、/new。當同一個問題你連問三次同樣的 prompt，就該把它變成一個 slash command。

**@**（Participants）決定對話的上下文範圍：

• @workspace = 整個工作區
• @terminal = 當前終端機
• @vscode = VS Code 本身
• @github = Repo / Issues / PR

這四個裡最有用的是 @github——搭配雲端 Agent 時，它可以直接把 Issue 內容當成上下文，你不用手動貼過去。

**#**（Context Providers）細粒度指定檔案或狀態：

• #file:path/to/file 指定單一檔案
• #selection 當前選取範圍
• #codebase 整個專案索引
• #editor / #terminalLastCommand 編輯器或終端機狀態

上下文管理是 Copilot Chat 最大的隱性成本。長對話超過 Context Window 時用 /compact 把歷史摘要掉再繼續（Claude 用 /clear、Codex 用 /compress）。不處理的話，Chat 到後期會開始回答牛頭不對馬嘴——Context 被舊訊息擠爆了。

還有兩個提示技巧：Few-shot（在 prompt 裡附「輸入→輸出」樣本）和 Chain of Thought（要求模型先列推理再回答）。兩個都能直接在 Copilot Chat 用，對輸出品質的提升是立即可見的。

SDD / SpecKit：讓 AI 走在軌道上

Spec Kit 是 GitHub 推的 Spec-Driven Development 方法論。把「寫 code」拆成四段：規格 → 計畫 → 任務 → 實作。每一段一條 Slash Command 串起來。

整個流程的起點是 /constitution——產出一份 memory/constitution.md，是這個專案的「憲法」。後續每個階段都會反過來檢查是否符合憲法。這個設計跟寫程式的 assertion 很像：重要的原則先寫下來，後面每一步都檢查一次。

主要指令：

兩個官方沒寫但課程推薦的擴充：

• architecture.md：比 constitution 更具體，定義資料流、錯誤補償、跨服務通訊
• lessons.md：專案中學到的經驗獨立記錄，變成後續專案的 institutional memory

雲端 /implement 有個隱藏陷阱：預設會另開一條分支。如果你已經在 feature branch 上工作，要在提示詞加「stick to current branch」並指定任務編號，不然 Coding Agent 會建立平行分支造成混亂。

SDD 能維持一致性的核心機制是 /analyze 反覆跑。每完成一批任務就回頭跑一次，確保實作結果還符合 plan、spec、constitution。沒有這一步的 SDD 只是另一種 waterfall。

TDD 三 Agent：Red、Green、Refactor 各司其職

除了 SDD，課程還介紹另一套：TDD Three-Agent Pattern。把 TDD 的 Red-Green-Refactor 切成三個獨立 Agent。

Red Agent：讀需求，寫一個會失敗的測試。只寫測試，不寫實作。任務結束前會確認測試真的 fail，並把 fail 原因留在終端機記錄。

Green Agent：以 Red Agent 留下的失敗測試為目標，寫出最小化實作讓測試通過。這個 agent 以「通過測試」為唯一目的，可能不會完全對應原始需求。

Refactor Agent：測試綠燈後進行重構。提升可讀性、效能、結構，但不可改動測試行為。

這個設計最聰明的地方在於：同一個對話視窗，換 Agent 就換 system prompt。你不用手動改提示詞，切 Agent 下拉選單就好。Agent 的角色定位在 .github/agents/ 底下的檔案裡。

注意事項：使用者必須清楚目前在哪個階段。Agent 本身沒有狀態機，它只在自己的階段做自己該做的事。跳錯階段（在 Green Agent 階段要它改測試）會拿到奇怪的輸出。

.github/ 目錄：專案級自訂指令的公寓

所有 Copilot 的「專案級自訂」都住在 .github/ 底下。這塊是 GH-300 會考的四個子目錄：

**.github/copilot-instructions.md**：全專案的總則。每次 Copilot Chat / Coding Agent 啟動時自動載入。語言、框架、命名規範、Commit 風格都放這裡。

.github/instructions/：多個 instructions 檔案，每個 frontmatter 設定 applyTo glob（例如 applyTo: "src/backend/**"）。只有目標檔案被觸及時才載入——避免 Context 爆量。後端 Java、前端 React、資料庫 migration 各自一份，互不干擾。

**.github/agents/**：自訂 Agent（Persona）的定義檔。每個檔案描述一個 Agent 的 system prompt、工具權限、適用情境。TDD Three-Agent Pattern 的 red/green/refactor 就是以這種方式實作。

**.github/prompts/**：集中管理 Slash Command 對應的提示詞模板。每個檔案代表一條可在 Copilot Chat 用 / 呼叫的 Prompt（例如 /review-pr、/generate-migration）。

GitHub 官方有個 awesome-copilot 倉庫，收錄社群貢獻的 copilot-instructions、agents、prompts 範本。直接 fork 或拷貝到專案裡，不用自己從零寫。

分支保護：給 AI 戴上安全帶

雲端 Coding Agent 有個行為要特別知道：它會自動開新分支，預設命名 copilot/<task-name>。任務完成後以 Draft PR 呈現。

這個設計配合 GitHub 的保護機制才完整：

• 保護 main 和 release 分支，禁止直接推送
• Required Reviews + CI 檢查才能合併
• CODEOWNERS 指定 Copilot 產出必須由哪些人審查
• 對 Draft PR 套用相同規則，AI 不能直接寫入主線

這一層的設計有點像駕駛輔助系統。車自己開沒問題，但方向盤你一定要握著——出事了，坐在駕駛座的人還是要負責。

授權版本：選錯會綁錯手腳

Knowledge Base 是 Enterprise 獨有的殺手鐧：把內部文件、Wiki、Spec、ADR 納入，Copilot Chat 回答時優先引用組織內部資訊。企業有大量內部標準時值得用。

Fine-tuning 也只有 Enterprise 有，可以對自家程式碼做 fine-tune 產出組織專屬模型。但要評估成本——光是資料準備就會吃掉一兩個資深工程師。

Audit Log 是 Business 與 Enterprise 才有。合規部門會很在意這一條。

企業常見搭配：Codespaces + devcontainer.json，讓 Copilot 跑在標準化的雲端環境。避免本機環境差異、避免資安風險。這個組合是企業導入時的最佳實踐。

考試準備流程：從報名到通過

GH-300 是 GitHub 跟 Microsoft Learn 共同營運的認證，考試透過 Microsoft Learn 報名。

報名：搜尋「GH-300 GitHub Copilot」即可找到。英文姓名要跟護照或身份證一致——這是最常見的退件原因。先準備好證件再報名。

考試方式有兩種：

• OnVUE 線上應考：自家或辦公室用視訊監考。前置要拍 360 度環景、桌面清空、單機單螢幕。重點是網路穩定度而不是頻寬——家中 100M/300M 光世代都夠。但公司網路要注意 VPN、Proxy、防火牆會不會擋 OnVUE 的連線
• Pearson VUE 實體考場：設備跟網路考場提供，不用自己張羅

題型混合：

• 單選題（四選一或五選一）
• 複選題（題幹會明示「Choose 2 / 3」，少選多選皆錯，無部分分數）
• 排序題（步驟拖放，整題對才得分）
• 情境題（案例研究，2-3 題，測試「選哪個版本 / 工作流」）

計分規則：答錯不倒扣。遇到不會的題目先猜再 Flag，不要留空。

題數與通過分數：

• 40-50 題
• 90 分鐘
• 700/1000 通過
• 加權計分（題目難易度不同分值不同）

通過後：

• MS Learn 顯示數位徽章，可分享至 LinkedIn
• 證書有效期 1 年
• 到期前 6 個月可免費 Renew（25 題線上測驗）
• Renew 不用再到考場、不用再付費

備考推薦資源

最後這條最關鍵。考試知識點不難，難的是把課程裡的觀念落實到日常開發流程。

學完之後，帶走的不是技術，是判斷力

回到開頭那四個詞——人負責、流程優先、上下文工程、版本選擇。

人負責：不管 AI 多聰明，PR 最後的 merge 按鈕還是人按的。

流程優先：AI 只是放大器。放大的是你既有的流程品質。流程不好，AI 只會把錯誤放得更大更快。

上下文工程：Copilot 的 /、@、# 都是上下文工程的工具。提示詞寫得好不如上下文帶得準。

版本選擇：個人 Pro 跟 Enterprise Knowledge Base 不是同一個東西。選錯版本會把手腳綁住。

背後的認知框架更短：AI 的上限不是模型多強，是你把 AI 放進什麼流程。同一個 Claude Sonnet 4.5，在一個有 .github/copilot-instructions.md、有分支保護、有 SDD 流程的專案裡，產出品質會遠超過在一個 main 分支直推、沒有任何上下文設定的專案。

課程會結束，考試會通過，但流程設計的能力是你接下來每一個專案都在用的東西。

學完這個可以接著學什麼？兩個方向：

往深的走 —— 讀 awesome-copilot 裡的範本，挑一兩個借鑑後改寫成你公司的版本。先有共用規則，再談團隊導入。

往廣的走 —— GH-300 考完後，接著可以看 AZ-400（DevOps Expert）或 AI-102（Azure AI Engineer）。這三張加起來才是完整的「AI 時代工程師」技能棧。

願每個工程師都能把重複工作交給 Copilot，把判斷力、品味、架構力留給自己。