在複雜專案中，當有人回報了一個問題（bug、安全漏洞、不良使用方式等）時，維護者常面臨的第一道難關並不是寫 code，而是「找」——必須翻查歷史 PR、瀏覽設計／安全文件、追溯哪個檔案可能有錯。這搜尋階段往往耗時又耗精神。
這正是 Copilot Spaces 的價值──它能把專案的「知識背景」（files, issues, PRs, 設計或安全規範文件……）整合成一個「context space」，讓 GitHub Copilot 不再只是 AI 的通用預測，而是真正能理解你的 codebase、進行有根據的判斷與修復。本文將帶你了解如何運用 Copilot Spaces，加速問題偵錯與修復流程。
Copilot Spaces 是什麼？──專案知識的整合包
Copilot Spaces 就像是一個「專案知識 bundle／空間」：
- 你可以 把整個 repo、或只有關鍵檔案、設計文件、安全／最佳實踐文件加入其中。
- 除了程式碼，也能包括 issues、pull requests、設計文件、架構文件、規範、備註、對話紀錄等。
- 一旦設定完成，Spaces 會自動同步：當 repo 更新、PR merge、新的 issue 被加入時，context 也一併更新。
- 這樣，Copilot 在回答問題、建議修復、產出 PR 時，就能「依據真實背景」做判斷，而不是「空泛地猜」。
換句話說，你不是讓 Copilot「猜」可能怎麼改；而是給它整個 project 的知識＋約束，讓它「理解」專案現況，再提方案。
實踐流程：如何用 Spaces 快速 debug／修復 issue
以下是從官方文章整理出的步驟 — 適合你在實務中直接套用：
1. 從 issue 開始
假設有人在 repo 裡回報了一個安全性問題 —— 例如某處使用不當的 check_call。這時你可能暫時不確定怎麼修，但你可以：
- 建立一個 Space，
- 把該 issue URL 加進去，
- 再把與安全規範、過去類似修復、有關檔案加入。
這樣 Copilot 就能「看到」整個 relevant context。
2. 建立 Space，選擇加入哪些內容
在建立過程中，你可以把以下內容加入 Space：
- 設計模式／架構文件（如
architecture-overview.md） - 安全規範或公司內部的安全指南（如
/docs/security/check-patterns.md） - 可及性建議、設計原則文件（視專案需求）
- 整個 repo，或精選重要檔案（依你想要的覆蓋範圍決定）
- 該 issue 的 URL
建議採取「有意識地選擇檔案範圍」而不是純粹 dump 整個 repo — 有助於提高效率、降低 noise。
3. 撰寫 Instruction 給 Copilot
在 Space 的 Instruction 面板中，你要告訴 Copilot「你希望它如何工作」。例如（官方建議）：
You are an experienced engineer working on this codebase. Always ground your answers in the linked docs and sources in this space. Before writing code, produce a 3–5 step plan that includes: - The goal - The approach - The execution steps Cite the exact files that justify your recommendations. After I approve a plan, use the Copilot coding agent to propose a PR.
4. 問 Copilot：「幫我 debug 這個 issue」
一旦 context 和 instructions 設置好，就可以直接問 Copilot：「Help me debug this issue」──它就會根據整個 Space 的內容，產出具體的 3–5 步驟規劃。
例如：
- 目標（Goal）：修正
runBinaryCheck中不安全的使用，確保輸入路徑被驗證。 - 方法（Approach）：在 repo 中搜尋所有
runBinaryCheck的使用、比對安全規範、確認哪些需要重構、準備 diff。
這不再是一般 LLM 的「泛泛建議」，而是根基於你的 codebase 的「有依據方案」。
5. 產生 Pull Request
若你同意 Copilot 的 plan，就可以請它用「Copilot coding agent」直接生成 PR：
- 每個被修改的檔案都會顯示「before / after」版本，
- 有清楚說明「改了什麼、為什麼改」的註釋，
- 也會標明是根據哪些具體檔案或文件產生變更。
如此你可以很清楚地審查 — 而不是「好像修改了，但我不知道為什麼」那種黑盒式變更。
6. 若需要，可迭代修正
如果你對某次 PR 不滿意，可以在 PR Comment 中用 @copilot 標註，讓 Copilot 根據回饋修改；或直接回到 Space，調整 context／instruction，再重新生成新的方案。
7. 與團隊分享 Space
Space 預設是私密的，但你可以依組織政策分享給其他人／整個團隊。這對安全性與協作都很重要。
在 IDE 中直接使用 Space —— 無需切換瀏覽器
除了在 Web 上操作，你也可以安裝 GitHub MCP Server，讓 Copilot Spaces 能在你慣用的 IDE 中使用（例如 VS Code、其他支援 Copilot 的編輯器）。
這樣一來，你可以在編輯器內直接呼叫你的 Space，執行 debug／檢視 context／生成代碼／PR，更順、專注，不需頻繁在瀏覽器與 IDE 間切換。
為什麼這很重要？Teams 的三種主要用法
根據官方，現階段團隊已經用 Copilot Spaces 做以下三種用途：
- 程式碼生成與除錯：用 Copilot coding agent 產出符合團隊風格、安全規範、架構設計的 PR。
- 功能規劃／開發計畫：把 issue、設計文件、PR、repo link 起來，讓 Copilot 幫你規劃 feature 實作或 draft 技術規格，再直接產生 PR。
- 知識分享與新人成長：將設計決策、架構、最佳實踐、過去 bug 修復紀錄都整合起來，方便新成員快速上手、減少重複詢問，也讓團隊知識成為「living document」。
實務建議與注意事項
- 有意識地 curated content：不需要把整個 repo 全丟進去，精選關鍵文件（安全／設計／核心模組），能讓 Copilot 更聚焦、降低噪音。
- 撰寫清楚、穩健的 instructions：建議明確要求 Copilot 引用來源、列出步驟、產生 plan，再經人 review；避免讓 AI 自行「亂改」。
- 善用 IDE 整合：安裝 MCP Server，把 Copilot Space 帶入你日常開發流程中，有助於提高效率與流暢度。
- 審慎審查 AI 生成的 code：AI 雖可生成代碼，但合併前仍需人類確認邏輯、測試、邊界條件、安全性等。
結語與未來展望
對於專業開發團隊來說，Copilot Spaces 有潛力讓「context 收集／搜尋」這種繁瑣、耗時但必要的前置工作自動化，讓開發者可以更專注於「真正重要的工作」──分析、設計、驗證、改善。
特別是對於大型、多人維護的專案、或需遵守安全／合規規範的團隊，Spaces 的背景綁定 + 可重現 plan + PR 產出流程，非常契合 DevOps／DevSecOps 的實務需求。
建議你在下一個 bug 或 feature 開工時嘗試：建立一個 Copilot Space，把相關 issue + 文件 +設計文件加入，寫個清楚 instruction，再讓 Copilot 幫你生成 plan 或 draft。你會很快看出到底節省了多少時間。
