GH-300 GitHub Copilot 認證 — 第二天課程筆記（進階工程化實踐）

Day 1 講的是上下文工程的觀念，Day 2 就進入實戰了——怎麼把上下文管理、結構化提示詞、自定義指令這些東西落地到團隊的日常開發裡。

上下文管理的三個核心符號

第一天介紹了 @ 跟 #，第二天把它們的底層機制講得更清楚：

使用建議很直白：精確操作用 #，找檔案用 @workspace，要理解跨檔案依賴關係用 @codebase。

要注意 @codebase 需要事先建好索引，大型專案第一次用可能要等一下。

自定義 Slash Commands

系統內建的 /fix、/explain、/tests、/doc 很方便，但更有價值的是自定義指令。

做法很簡單：在 .github/prompts/ 底下放 .md 檔案，檔名就是指令名稱。

1
2
3
4
5

.github/
└── prompts/
    ├── init-project.md      → /init-project
    ├── setup-database.md    → /setup-database
    └── generate-api.md      → /generate-api

這樣做有三個好處：團隊共享標準化提示詞、隨 Git 版本控制、而且 .md 裡面可以分 section，執行時指定只跑某個區塊。

Copilot Instructions：隱式參考機制

這是 Day 2 最實用的部分。你可以在 .github/ 底下建立一整套 instruction 檔案：

1
2
3
4
5
6

.github/
├── copilot-instructions.md          # 全域規範
└── instructions/
    ├── project-setup.md              # 專案設置
    ├── frontend.md                   # 前端規範
    └── backend.md                    # 後端規範

關鍵是 applyTo 機制。每個 instruction 可以設定生效範圍：

「隱式參考」的意思是：你不需要明確告訴 Copilot「去參考這個 instruction」，只要改動的檔案落在 applyTo 範圍內，對應的規範就會自動載入。

課程示範了三層設計：全域 instruction 管目錄結構跟架構、前端 instruction 管 React 跟 CSS 規範、後端 instruction 管 API 跟序列化。前端的 applyTo 設成 ** 而不是 frontend/**，因為前端改動經常連帶影響後端。

有個坑要注意：模型的 reference list 不一定會顯示它參考了哪些 instruction。建議養成習慣主動問一句：「你是否參考了 frontend.md 和 backend.md？」

Prompt Engineering 進階技巧

Few-Shot Learning

直接在 instruction 或 prompt 檔案裡提供範例，讓模型學你要的輸出格式：

1
2
3
4
5
6

## 範例
輸入：建立使用者 API
輸出：
- POST /api/users → 建立使用者
- GET /api/users/:id → 查詢使用者
- PUT /api/users/:id → 更新使用者

結構化提示詞要素

四個必備：模式指定（agent / ask / plan）、模型指定（支援逗號分隔的 fallback 列表）、步驟拆解、驗收準則。最後一個最容易被忽略，但也最重要。

三種互動模式

Custom Prompt vs Custom Agent

選擇原則：步驟固定用 Prompt，需要推理和多方協作用 Agent。

Validation 驗收機制

每個多步驟任務都必須包含驗收。三個層次：

1. 過程驗收：每一步完成後檢查結果
2. 最終驗收：所有步驟完成後整體驗證
3. 反向對齊：程式碼改完後，檢查跟原有架構規則有沒有衝突

反向對齊會碰到三種情況：規則跟需求矛盾（調整需求或更新規則）、實作偏離（修正實作）、規則過時（更新 instruction）。

用 SDD/TDD 框架的話，這些驗收步驟會自動化——框架會在每次命令執行後確認參考了哪些 instruction，然後輸出確認報告。

Coding Agent 雲端協作

工作流程長這樣：

1
2

Issue 建立 → Assign 給 Coding Agent → 自動建 Branch（copilot/ 開頭）
→ 自動建 Draft PR → Agent 改程式碼 → 設定 Reviewer → 人工 Review → Merge

幾個關鍵特性：PR 始終保持 Draft 狀態直到人工轉正式、每次改動起新 Session 可切換模型、雲端 Sandbox 有完整環境（含 MCP、Playwright 等）。

而且 Coding Agent 能看到所有 Issue 和 PR 作為參考，但不會主動去改其他的東西。

安全與權限控制

權限建議：

Coding Agent 有幾道安全閘門：無權將 Draft PR 轉正式、所有改動在獨立分支、觸發的 GitHub Actions 自動進入 pending for approval。

課程中有個實際案例蠻值得警惕的：Agent 更新 3 個 instruction 檔案時遇到寫入失敗，直接刪除原檔再重建。沒有設好 permission 的話，這種高危操作可能造成資料遺失。

CLI 作為 Agent 介面的趨勢

越來越多能力以 CLI 形式開放，Agent 透過 CLI 呼叫其他系統比自然語言更可靠。原因很直白：指令產生確定性結果，不像自然語言有歧義。而且 Agent 遇到不會的指令，可以自己查 --help 跟文件。

考試重點

Day 3 預告：自定義 Agent（.github/agents/）、SDD 規格驅動開發、TDD 框架、多 Agent 協作重構實戰。

來源：GH-300 GitHub Copilot 認證課程第二天筆記