訪問和策略
解釋組織和企業如何用 Copilot feature、privacy、model policies 控制功能、模型和成本邊界。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| Access policies | 訪問策略 | 控制誰能用哪些 Copilot 功能。 |
| 功能開關 | toggle | 按組織需要開關能力。 |
| 最小授權 | least-priv | 只開必要功能。 |
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你設計 Copilot 的訪問策略，按最小授權開放功能。
你是 Copilot 訪問策略顧問。
【角色】
Copilot 訪問策略顧問，按最小夠用、安全優先的原則給可落地方案，每條結論都落到能照做的步驟或示例，不停留在空泛建議。
【輸入】
- 組織里有哪些角色：___
- 各角色該用什麼功能：___
- 絕不能開放的能力：___
- 合規約束：___
- 經驗水平：___
【工作流程】
1. 梳理可控的策略項
2. 按角色定功能開放
3. 標出預設應關閉的
4. 說明怎麼驗證策略生效
5. 給維護建議
【輸出規範】
▌一、策略項
▌二、按角色開放
▌三、預設關閉項
▌四、生效驗證 + 維護
【硬約束】
- 按角色最小授權，不預設全開
- 高風險能力預設關閉
- 策略改動後驗證生效
- 不要替我臆測情況或編造不存在的功能，資訊不全先問清
- 不確定的設定或許可權一律以官方文件為準，禁止照搬過時寫法
- 給的每條結論都要落到具體可照做的步驟或示例，不停留在「建議」「考慮一下」這類沒法直接執行的空泛表述訪問和策略是 Copilot 的控制面（control plane）。沒有這一層，團隊只是各自在 IDE 裡使用 AI，管理員很難解釋功能可用性、模型成本和企業邊界。
策略要先於推廣。先定義誰能用、用哪些功能、用哪些模型，再做團隊培訓。反過來——先開放使用再補策略——會讓企業級控制變得無效，因為使用者已經形成習慣。
1. 三類 policy
GitHub 官方把 Copilot policies 分為三類：
- Feature policy（功能策略）：控制某個 Copilot 功能（IDE / CLI / Cloud Agent / Code Review / MCP 等）是否可用。
- Privacy policy（隱私策略）：控制潛在敏感動作是
Allowed（允許）還是Blocked（阻止）。 - Models policy（模型策略）：控制基礎模型之外的模型是否可用，可能帶來額外成本。
flowchart TD
License["分配 Copilot license"] --> Policy["Copilot policies"]
Policy --> Feature["Feature policy"]
Policy --> Privacy["Privacy policy"]
Policy --> Model["Models policy"]
Feature --> IDE["IDE / CLI / cloud agent / code review / MCP"]
Privacy --> Sensitive["敏感動作 allowed / blocked"]
Model --> Cost["模型可用性和額外成本"]
style Policy fill:#dbeafe,stroke:#2563eb,stroke-width:2px
style Privacy fill:#fef3c7,stroke:#d97706,stroke-width:2px
style Cost fill:#fee2e2,stroke:#dc2626,stroke-width:2px2. 組織級控制
Organization owners 可以為由該組織分配 Copilot license 的成員設定功能和模型可用性。
官方文件裡的組織級選項：
Unconfigured：佔位狀態；定義設定前，該組織會把該 policy 當作 disabled。Enabled：分配到該組織 Copilot 的成員可用。Disabled：分配到該組織 Copilot 的成員被阻止。
Privacy policy 使用 Allowed 和 Blocked，語義更直接。
3. 企業級控制
Enterprise owners 可以在企業層定義 policy，也可以把決策委託給 organization owners。
關鍵邊界：
- 企業級 policy 一旦定義，會應用到所有使用者，並停用組織級控制。
- 某些功能支援 granular organization selection，例如 cloud agent 可以只對特定組織開放。
- 如果企業選擇 No policy，結果取決於使用者是從組織獲得 license，還是直接從企業獲得 access。
- 使用者透過多個組織獲得 Copilot 時，policy 衝突可能按最寬或最嚴策略執行，具體看政策型別。
4. 建議預設策略
小團隊可以保守起步：
- IDE completions 和 Chat：預設啟用。
- Content exclusion：上線前設定。
- Advanced models：先按角色啟用，避免所有人預設消耗高階模型。
- Copilot code review：先在試點儲存庫啟用。
- Cloud agent、CLI、MCP、third-party agents：先小範圍試點。
- Public preview 或 pre-release 能力：只給試點團隊。
這不是固定模板。原則是先低風險、可觀察、可回復，再擴大範圍。
5. 變更流程
每次改 policy，都應該記錄：
- 變更前後狀態。
- 涉及組織或企業範圍。
- 對應的使用者群體。
- 預期影響。
- 驗證方式。
- 回復方式。
策略不是一次設定後不再看。模型、功能、計費和 preview 狀態變化很快，月度覆盤時必須檢查。
深讀：模型策略和成本是同一個問題
Models policy 不只是“哪個模型更聰明”。高階模型可能有 multiplier、premium request 消耗或額外成本。
如果管理員只開放模型，不管理 budget 和 usage analytics，就很難解釋月底費用從哪裡來。
本章自檢
- 是否知道每個使用者從哪個組織或企業獲得 Copilot access？
- 是否設定了 feature、privacy、model policies？
- 企業級 policy 是否覆蓋了組織級決策？
- 高成本模型是否和預算、用量報表一起管理？
- preview 功能是否只在試點團隊開放？
透過標準：任何一個功能或模型為什麼可用、誰能用、如何停用，都能解釋。
官方來源
- GitHub Copilot policies —— GitHub 官方 policy 型別、組織級和企業級控制。
- Managing policies and features for GitHub Copilot in your organization —— GitHub 官方組織策略管理入口。
- Managing policies and features for GitHub Copilot in your enterprise —— GitHub 官方企業策略管理入口。