官方教學中文版上下文與定製
個人和組織指令
解釋 Copilot personal、repository、organization instructions 的職責、優先順序、適用範圍和治理邊界。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| Personal / org | 個人 / 組織指令 | 個人偏好與組織級策略。 |
| 適用範圍 | scope | 個人跟人，組織跟全員。 |
| 治理 | governance | 組織指令的統一管理。 |
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你分清個人指令和組織指令各放什麼、怎麼不打架。
你是 個人與組織指令顧問。
【角色】
個人與組織指令顧問，按最小夠用、安全優先的原則給可落地方案，每條結論都落到能照做的步驟或示例，不停留在空泛建議。
【輸入】
- 我是個人使用者還是管理員：___
- 想統一的偏好 / 策略：___
- 組織規模：___
- 和儲存庫指令的關係：___
- 經驗水平：___
【工作流程】
1. 區分個人和組織指令的職責
2. 把規則放到合適範圍
3. 說明和儲存庫指令的優先順序
4. 給治理建議
5. 給驗證
【輸出規範】
▌一、個人 vs 組織
▌二、規則歸位
▌三、與儲存庫指令優先順序
▌四、治理 + 驗證
【硬約束】
- 個人偏好不寫進組織策略
- 組織指令集中治理
- 優先順序衝突先排查再改
- 不要替我臆測情況或編造不存在的功能，資訊不全先問清
- 不確定的設定或許可權一律以官方文件為準，禁止照搬過時寫法
- 給的每條結論都要落到具體可照做的步驟或示例，不停留在「建議」「考慮一下」這類沒法直接執行的空泛表述個人和組織指令解決的是偏好與治理的層級問題。個人指令用於個人回答偏好，組織指令用於跨儲存庫原則，儲存庫指令用於專案事實。把這三層混在一起，最常見的結果是組織級規則被某個儲存庫的具體命令汙染，所有儲存庫都背上無關上下文。
閱讀目標：讀完本章，你應該能判斷一條規則該放在個人、儲存庫、路徑級還是組織層。
1. 層級分工
- Personal instructions：個人回答偏好，例如語言、解釋深度、常用風格。
- Repository instructions：專案事實，例如 build、test、目錄職責。
- Path-specific instructions：區域性規則，例如前端、後端、測試目錄差異。
- Organization instructions：組織級原則，例如安全知識庫、統一語言、審查紅線。
flowchart TD
Rule["一條規則"] --> Personal{"隻影響個人偏好?"}
Personal -->|是| P["Personal instructions"]
Personal -->|否| Repo{"是否專案事實?"}
Repo -->|是| R["Repository instructions"]
Repo -->|否| Path{"是否只適用部分路徑?"}
Path -->|是| PI["Path-specific instructions"]
Path -->|否| Org{"是否組織原則?"}
Org -->|是| O["Organization instructions"]
Org -->|否| Prompt["留在普通 prompt / issue"]
style P fill:#dbeafe,stroke:#2563eb,stroke-width:2px
style O fill:#fef3c7,stroke:#d97706,stroke-width:2px
style Prompt fill:#fee2e2,stroke:#dc2626,stroke-width:2px2. 優先順序
官方 response customization 文件說明，多種 instructions 可以同時適用於一次請求。優先順序從高到低：
- Personal instructions。
- Path-specific instructions。
- Repository-wide
.github/copilot-instructions.md。 - Agent instructions，例如
AGENTS.md。 - Organization custom instructions。
低優先順序不等於一定失效，但衝突時高優先順序更重要。
3. Organization instructions 的邊界
官方頁面說明，organization instructions 適合設定組織共同偏好，例如回答風格、知識庫連結、安全原則。它主要用於 GitHub.com 上的 Copilot Chat、Copilot code review 和 Copilot cloud agent 等場景，具體支援情況要看官方支援矩陣。
適合寫：
- 統一安全紅線。
- 團隊統一語言。
- 組織級參考文件連結。
- 審查時必須關注的風險類別。
不適合寫：
- 某個儲存庫的 test 命令。
- 某個人喜歡的回答風格。
- 臨時 bug 修復方案。
4. 個人指令不要汙染團隊
個人指令適合：
- 預設用中文解釋。
- 回答先給結論。
- 程式碼示例偏某種語言。
- 個人希望的解釋深度。
不適合：
- 團隊必須遵守的規則。
- 專案架構事實。
- 任何對 reviewer 有約束力的內容。
5. 治理方式
建議：
- 組織指令由平臺 owner 管。
- 儲存庫指令由 repo owner 管。
- 路徑級指令由模組 owner 管。
- 個人指令由個人自行負責。
- 每季度清理過期規則。
深讀：為什麼組織指令應該寫原則，不寫細節
組織指令覆蓋範圍大，一旦寫錯，會影響多個儲存庫和團隊。越靠上層，越應該寫穩定原則；越靠近程式碼，越應該寫具體命令和目錄事實。
這樣既能保持統一，又不會讓所有專案都背上不相關上下文。
本章自檢
完成本章後，用這 4 個問題檢查：
- 這條規則是否隻影響個人？
- 如果是專案事實，是否放在儲存庫或路徑級？
- 如果是組織原則，是否足夠穩定且不依賴某個儲存庫？
- 多層規則之間是否衝突？
透過標準：每條規則都能解釋 owner、範圍和優先順序。
官方來源
- About customizing GitHub Copilot responses —— 官方響應定製概念頁。
- Adding custom instructions for GitHub Copilot —— 官方個人和組織指令入口。
- Customization cheat sheet —— 官方定製速查表。