---
title: "個人和組織指令"
description: "解釋 Copilot personal、repository、organization instructions 的職責、優先順序、適用範圍和治理邊界。"
verifiedAt: "2026-05-06"
---

個人和組織指令解決的是**偏好與治理的層級**問題。個人指令用於個人回答偏好，組織指令用於跨儲存庫原則，儲存庫指令用於專案事實。把這三層混在一起，最常見的結果是組織級規則被某個儲存庫的具體命令汙染，所有儲存庫都背上無關上下文。

> [!TIP]
> **閱讀目標**：讀完本章，你應該能判斷一條規則該放在個人、儲存庫、路徑級還是組織層。

## 1. 層級分工

- **Personal instructions**：個人回答偏好，例如語言、解釋深度、常用風格。
- **Repository instructions**：專案事實，例如 build、test、目錄職責。
- **Path-specific instructions**：區域性規則，例如前端、後端、測試目錄差異。
- **Organization instructions**：組織級原則，例如安全知識庫、統一語言、審查紅線。

```mermaid
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:2px
```

## 2. 優先順序

官方 response customization 文件說明，多種 instructions 可以同時適用於一次請求。優先順序從高到低：

1. Personal instructions。
2. Path-specific instructions。
3. Repository-wide `.github/copilot-instructions.md`。
4. Agent instructions，例如 `AGENTS.md`。
5. 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 管。
- 個人指令由個人自行負責。
- 每季度清理過期規則。

<details>
<summary>深讀：為什麼組織指令應該寫原則，不寫細節</summary>

組織指令覆蓋範圍大，一旦寫錯，會影響多個儲存庫和團隊。越靠上層，越應該寫穩定原則；越靠近程式碼，越應該寫具體命令和目錄事實。

這樣既能保持統一，又不會讓所有專案都背上不相關上下文。
</details>

## 本章自檢

完成本章後，用這 4 個問題檢查：

1. 這條規則是否隻影響個人？
2. 如果是專案事實，是否放在儲存庫或路徑級？
3. 如果是組織原則，是否足夠穩定且不依賴某個儲存庫？
4. 多層規則之間是否衝突？

透過標準：每條規則都能解釋 owner、範圍和優先順序。

## 官方來源

- [About customizing GitHub Copilot responses](https://docs.github.com/en/copilot/concepts/prompting/response-customization) —— 官方響應定製概念頁。
- [Adding custom instructions for GitHub Copilot](https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions) —— 官方個人和組織指令入口。
- [Customization cheat sheet](https://docs.github.com/en/copilot/reference/customization-cheat-sheet) —— 官方定製速查表。

## 接下來去哪

<Cards>
  <Card title="儲存庫自定義指令" description="繼續落到專案級檔案結構和驗證方式。" href="/zh-Hant/docs/github-copilot/official/06-context-customization/repository-instructions" />
  <Card title="安全、治理與計費" description="繼續學習組織策略、usage 和訪問控制。" href="/zh-Hant/docs/github-copilot/official/08-security-governance" />
</Cards>
