內容排除
說明 GitHub Copilot 內容排除能保護什麼、不能保護什麼，以及如何設定、測試和審計。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| Content exclusion | 內容排除 | 指定不讓 Copilot 讀的檔案。 |
| 敏感目錄 | sensitive | 金鑰 / 設定 / 私有資料。 |
| 生效範圍 | scope | 排除在哪些功能上生效。 |
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你設定 Copilot 內容排除，擋住敏感檔案不被讀取。
你是 Copilot 內容排除顧問。
【角色】
Copilot 內容排除顧問，按最小夠用、安全優先的原則給可落地方案，每條結論都落到能照做的步驟或示例，不停留在空泛建議。
【輸入】
- 哪些檔案 / 目錄絕不能被讀：___
- 敏感資料型別：___
- 適用範圍（儲存庫 / 組織）：___
- 現有 .gitignore 情況：___
- 經驗水平：___
【工作流程】
1. 梳理該排除的敏感內容
2. 給排除設定寫法
3. 說明生效範圍和限制
4. 驗證排除是否真生效
5. 給維護建議
【輸出規範】
▌一、該排除什麼
▌二、設定寫法
▌三、生效範圍 / 限制
▌四、驗證 + 維護
【硬約束】
- 敏感檔案一律排除
- 設定後實測驗證生效
- 不依賴排除代替真正的金鑰管理
- 不要替我臆測情況或編造不存在的功能，資訊不全先問清
- 不確定的設定或許可權一律以官方文件為準，禁止照搬過時寫法內容排除（content exclusion）解決的是“哪些內容不該被 Copilot 使用”。它應該在 rollout 前設定，而不是洩露、誤用或 code review 之後再補。
內容排除是必要防線，但不是萬能防線：Copilot CLI、Cloud Agent、IDE Chat 的 Agent Mode 目前都不支援內容排除。把"機密程式碼也寫進了儲存庫"和"用內容排除擋 Copilot"看作同一道防線，是這一節最常見的錯誤。
1. 排除後會發生什麼
GitHub 官方文件說明，內容被排除後：
- 受影響檔案不會獲得 inline suggestions。
- 受影響檔案內容不會影響其他檔案裡的 inline suggestions。
- 受影響檔案內容不會用於 Copilot Chat 響應。
- 受影響檔案不會被 Copilot code review 審查。
flowchart TD
File["敏感檔案"] --> Exclusion["內容排除策略"]
Exclusion --> Inline["Inline suggestions 不使用"]
Exclusion --> Chat["Chat 不引用"]
Exclusion --> Review["Copilot code review 不審查"]
Exclusion --> Limit["CLI / coding agent / Agent mode 不支援"]
style Exclusion fill:#fef3c7,stroke:#d97706,stroke-width:2px
style Limit fill:#fee2e2,stroke:#dc2626,stroke-width:2px2. 誰能設定
官方支援這些層級：
- Repository administrators：設定自己的儲存庫。
- Organization owners：設定組織級排除。
- Enterprise owners：設定企業級排除。
- Maintain role：可以檢視儲存庫內容排除設定，但不能編輯。
企業級規則和組織級規則的區別很重要：企業級規則適用於企業中所有 Copilot users；組織級規則隻影響由該組織分配 Copilot seat 的使用者。
3. 該排除什麼
優先排除：
.env、金鑰、證書、私鑰、token。- 客戶資料、合同、財務資料。
- 專有演算法、反作弊、風控策略。
- 內部安全策略和漏洞報告。
- 尚未公開的產品路線圖。
- 訓練資料、評測集、付費內容。
不要把內容排除當成懶惰的許可權系統。真正不該被開發者讀取的內容，本身就不應該出現在他們能訪問的儲存庫或檔案系統裡。
4. 設定格式
儲存庫級設定是在儲存庫 Settings 的 Copilot content exclusion 頁面填寫路徑，每行一個模式。
組織級或企業級可以按儲存庫和路徑寫模式。官方示例支援 fnmatch 風格匹配。
"*":
- "**/.env"
octo-repo:
- "/src/sensitive/**"
https://github.com/primer/react.git:
- "secrets.json"
- "/src/**/temp.rb"寫規則時保守一點：
- 先排除明確敏感的路徑。
- 再排除敏感檔名模式。
- 避免大範圍排除導致 Copilot 在正常工程檔案裡不可用。
- 每次變更都留審計記錄。
5. 支援範圍和限制
官方限制必須寫清：
- GitHub website 和 GitHub Mobile 上的內容排除仍有 public preview 邊界。
- IDE Chat 的 Edit mode 和 Agent mode 目前不支援內容排除。
- Copilot CLI 和 Copilot coding agent 不支援內容排除。
- 內容排除不適用於 symbolic links。
- 遠端檔案系統上的 repository 不適用。
- IDE 可能間接提供型別資訊、hover 定義或 build 設定資訊。
- 設定變更在已載入 IDE 中生效可能需要最多 30 分鐘。
這意味著高風險內容不能只靠內容排除保護。要配合儲存庫許可權、secret scanning、least privilege 和本地檔案隔離。
6. 測試和審計
測試：
- 開啟未排除檔案，確認 inline suggestion 正常出現。
- 開啟應被排除檔案，做相同編輯，確認沒有 suggestion。
- 在 Chat 中只附加被排除檔案，提問
explain this file。 - 確認 Copilot 無法把該檔案作為引用來源。
審計：
- 儲存庫或組織頁面底部可以看到最近一次內容排除變更。
- 點選變更時間可以進入 audit log。
copilot.content_exclusion_changed事件可用於追蹤變更。- 如果
excluded_paths被截斷，需要展開看完整值。
深讀：為什麼內容排除不能替代儲存庫許可權
內容排除只控制 Copilot 是否使用特定內容，不控制開發者是否能開啟、複製、提交或透過其他工具讀取該內容。
如果一個檔案本身不應該被某個團隊訪問，就應該先解決儲存庫許可權和資料擺放問題，再設定 Copilot 內容排除作為額外防線。
本章自檢
- 是否已經排除金鑰、客戶資料、專有演算法和安全材料？
- 是否知道哪些 Copilot 入口不支援內容排除？
- 是否測試過排除規則生效？
- 是否能從 audit log 追蹤每次變更？
- 是否避免把內容排除當成唯一許可權控制？
透過標準：內容排除規則可解釋、可測試、可審計，並且和儲存庫許可權配合使用。
官方來源
- Content exclusion for GitHub Copilot —— GitHub 官方概念、支援範圍和限制。
- Excluding content from GitHub Copilot —— GitHub 官方設定和測試流程。
- Reviewing changes to content exclusions —— GitHub 官方審計流程。