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

講師第一句話就打破了一個常見誤解：Copilot 的輸出品質不是取決於你 prompt 寫得多好，而是你給的上下文夠不夠精準。Day 1 整天的核心只有一件事——上下文工程（Context Engineering）。

自然語言描述就好，不需要寫什麼 role/workflow/markdown 結構化 prompt。關鍵在你有沒有把對的東西餵進去。

AI / LLM 的基本概念

先快速帶過幾個底層概念：

Token 是 LLM 處理的最小單位。中文大約 1 字 = 1-2 tokens。Tokenization 就是把你的輸入拆成 token 序列的過程。

Embedding 是把 token 映射成高維向量，語意接近的詞在向量空間裡距離也近。這是模型理解語意的基礎。

上下文窗口是模型單次能處理的 token 上限。超過之後品質會下降，所以管理上下文的用量很重要。講師建議使用量到 70-80% 就該主動處理——合併提示詞、回退 checkpoint，不要等系統自動壓縮。

Copilot 支援多模型切換

GitHub Copilot 不只用一個模型。目前支援的有：

有個實用的切換策略：零到一（新建專案）的時候可以混著用，但重構的時候不要切模型。讓同一個模型完整理解 codebase 之後再動手，效果比較好。

上下文工程：顯式 vs 隱式

Copilot 的上下文分兩種。你主動給的叫顯式，它自動蒐集的叫隱式。

顯式上下文（優先權高）：

• @ — 範圍指定（@workspace 限本地、@github 觸發雲端 Agent）
• / — 指令觸發（/explain、/test、/fix、/doc）
• # — 精確引用（#file、#method、#selection、#usage）

隱式上下文（自動蒐集）：

• 當前開啟的檔案
• 最近編輯的檔案
• 工作區結構
• Codebase Index

顯式的優先權比隱式高。所以你想讓 Copilot 專注在某些檔案上，用 # 明確指定比「我先開個 tab 希望它看到」靠譜得多。

@ 機制：範圍指定

@workspace 把搜索範圍限定在你本地 VS Code 開啟的根目錄。@github 會觸發雲端 Coding Agent，範圍拉到整個 GitHub 倉庫——含 issue、PR、branch 的關聯。

一個實用技巧：如果你的 workspace 裡面有多個專案並列，加 # 指定子目錄可以避免 Copilot 跨專案抓錯東西：

1

在 @workspace #mr 目錄下描述專案結構

/ 機制：Slash Commands

系統內建四個常用的：/explain（解釋程式碼）、/test（生成測試）、/fix（修 bug）、/doc（生成文件註解）。

更有意思的是自訂指令。你可以把團隊的結構化提示詞封裝成自訂 slash command，這樣做的好處有三個：上下文管理更精確、團隊標準統一、省上下文空間。

# 機制：精確引用

#usage 在重構的時候特別好用。你想知道某個 class 在整個 workflow 裡的位置，一行搞定：

1

@workspace #MyService #usage 說明這個類在 workflow 中的位置

Workspace vs Codebase

這兩個名字很像但差異很大。

Workspace 就是你本地的檔案系統，純檔案結構，沒有額外的理解。

Codebase 是建立索引之後的程式碼庫。它不只看檔案結構，還會追蹤引用頻率、修改頻次、哪些檔案常一起開。本地的 Codebase 會追蹤你的開啟/修改行為，雲端的則利用 branch、issue、PR 的關聯來加強理解。

換句話說，Codebase 比 Workspace 聰明得多。用了一段時間之後，它推薦的上下文會越來越精準。

指令檔案

兩個關鍵檔案：

**AGENTS.md**（專案根目錄）：各家 AI 工具通用的全域規範。

**copilot-instructions.md**（.github/ 目錄）：Copilot 專屬，每次對話自動載入。

最佳實踐：

• AGENTS.md 控制在 100 行以內
• copilot-instructions.md 控制在 300 行以內
• 這些檔案的規則優先於對話中的指令（所以寫在裡面的東西是最高優先級）
• 全域規範放指令檔案，特定任務的 override 放對話中

本地 Agent vs 雲端 Coding Agent

本地 Agent 跑在你的 IDE 裡面，透過 Chat 面板對話，直接改本地檔案，你可以即時 Accept 或 Reject。

雲端 Coding Agent 用 @github 觸發（或把 issue assign 給 Copilot），它會自動建 Branch、改程式碼、開 PR。一定要經過人工 Code Review 才能合併——這是刻意設計的安全閘門，不是缺漏。

工作流程大概長這樣：

1
2

你下指令 → Agent 建 Branch → Agent 改程式碼 → 自動建 PR
  → 你 Review → 通過就合併 / 不行就在 PR 留言，Agent 繼續改

日常寫程式用本地 Agent 就好。雲端 Agent 適合「assign 一個 issue 讓它自己去做，明天來看結果」的場景。

上下文管理策略

講師花了不少時間講這塊。兩種做法：

多段疊加：一步一步追加需求，邊試邊改。適合探索階段，但很吃上下文。

單段合併：把驗證過的多段提示合成一段重跑。效果通常更好，也省上下文。

推薦流程：探索階段先多段疊加 → 確認滿意 → 回退 Checkpoint → 單段合併重跑。

為什麼單段更好？因為模型對一段精確描述的理解，比你分好幾次東拼西湊的理解更完整。而且合併後的提示詞可以封裝成自訂指令，團隊都能用。

正確的重構姿勢

這段是整天最有價值的觀念。講師直接說：「不要直接叫模型重構」。原因是模型的理解來自你給的上下文，不是它自己真的懂你的架構。

正確步驟：

Step 1：強制模型理解。先問它：「你對這個架構怎麼理解？」讓它先說。

Step 2：挑戰模型。告訴它「你有一點理解錯了」，讓它反覆挑戰自己，找出思維鏈的偏差。

Step 3：糾正與對齊。確認雙方的理解一致。

Step 4：基於對齊的理解重構。然後把糾正過程寫進 instruction 檔案，下次就不用再走一遍。

整個流程的核心是「先理解再重構、挑戰而非灌輸、對齊後才執行」。而且重構全程要用同一個模型，不要切換。

考試重點

Day 2 預告：Prompt Mutation 進階技巧、PR + Coding Agent 深度整合、copilot-instructions.md 進階用法、SDD（規格驅動開發）結合重構實作。

來源：GH-300 GitHub Copilot 認證課程筆記（講師：高山 Martin，微軟認證培訓講師 MCT）