在 VS Code 專案中設置 AGENTS.md，常會讓開發人員產生一個困擾的問題：到底 AGENTS.md 與 copilot-instructions.md 兩者的定位與職責究竟是什麼？
檢視 AGENTS.md 的定位
在導入 AI Agent（GitHub Copilot、Coding Agent）進行專案輔助時，最關鍵的不是模型多聰明，而是它是否「知道這個專案該怎麼做事」。
因此，我們需要一個標準化、可被 Agent 讀取的入口文件，用來定義：
- 專案的建置與執行方式
- 目錄結構與開發邏輯
- Agent 的行為邊界與禁止事項
這個角色，就是 AGENTS.md。
AGENTS.md 的設計理念，可以視為：「給 AI Agent 看的 README，而不是主要給人類閱讀的說明文件。」
VS Code Copilot 設置 AGENTS.md
在 VS Code 使用 Copilot 時，專案中通常會同時設置 copilot-instructions.md 與 AGENTS.md，但兩者的職掌並不相同。
copilot-instructions.md（位於 .github\ 資料夾內）用來定義「這個專案是什麼，以及所有 AI 在任何情況下都必須遵守的基本規則」，例如使用的技術堆疊、程式碼風格、分層原則與回覆語言。可以將它視為專案層級的全域規範。
而 AGENTS.md（通常位於專案根目錄，作為全域 Agent 行為規範；也可以採用子資料夾的巢狀結構，為不同目錄定義不同的 Agent 行為規範）則用來規範「當 Copilot 以 Agent 模式協作時，應該如何行動」，重點在於行為邊界與協作方式，例如是否需要先提出修改計畫、一次修改的範圍、如何回報變更結果等。它關心的是 Agent 的行為與責任，而不是功能實作細節。
需要注意的是，這兩個檔案並非一次寫好就固定不變。隨著專案的演進、架構調整、或團隊對 AI 協作方式的理解逐漸成熟，copilot-instructions.md 與 AGENTS.md 的內容都應該被視為可持續調整的專案資產，適時反映當前的開發狀態與協作需求。
小結
簡單來說：
copilot-instructions.md 負責專案規則，AGENTS.md 負責 Agent 行為。
這樣的分工可以讓 AI 在專案中既「知道規則」，也「守好界線」，更符合實務開發與教學情境的需求。
以下為 AGENTS.md 與 copilot-instructions.md 的範本；另外，我也將與 Claude Code（置於同一專案內）所對應、具備相同功能的範本上傳到我的 Gist，有興趣的讀者可以下載參考。
# AGENTS.md（Agent 協作規範）
本文件定義了 AI Agent 在本專案中協作時的行為邊界，確保開發流程的可預測性。
## 1. 核心開發流程：先計畫、後實作
- **思考優先**：涉及跨檔案或架構變更時，必須先產出「修改計畫」供開發者審核。
- **最小變動**：以「可演示、可驗證」為目標。避免不必要的大規模重構。
- **透明假設**：若環境資訊不明，必須列出你的假設點，而非自行通靈。
## 2. 產出交付格式
每次請求的產出應包含以下區塊：
- **目標描述**：簡單說明你要解決的問題。
- **變更清單**：列出受影響的相對路徑與檔案名稱。
- **驗證步驟**：提供 `dotnet run` 之後的驗證方式，包含必要的 API 請求範例 (curl/http)。
## 3. 安全邊界
- **嚴禁行為**：未經討論不得修改全域套件版本（如 .NET 版本）或刪除防護腳本。
- **範圍侷限**：本課程僅聚焦「購物車模組」，請避免引入無關的會員或金流系統。# Copilot 專案指令（copilot-instructions.md）
> 本專案為課程示範用：寵物用品販售平台（聚焦購物車模組）
> 技術堆疊（Tech Stack）：C# / .NET 10 (LTS)、ASP.NET Core、SQLite
## 1. 架構約束 (DDD 簡化分層)
請遵守以下分層依賴規則：
- **Presentation**: Web / API：Controller、Endpoints、DTO）
- **Application**: （Use Cases / Services：流程協調、交易邏輯編排）
- **Domain**: 核心業務邏輯。不可依賴 Infrastructure。
- **Infrastructure**: （EF / SQLite 實作、Repository 實作、外部系統）
## 2. 編碼美學與慣例
- **C# 命名規約**：PascalCase（公開成員）、camelCase（私有欄位/區域變數）。
- **非同步**：I/O 密集操作（DB/網路）必須使用 `async/await`。
- **方法實作**：優先寫「小而清楚」的方法；避免一次塞太多責任。
- **程式註解**：使用 Java Style 風格，註解說明務必使用繁體中文。
## 3. SQLite 與資料存取
- 使用 Entity Framework Core 作為 ORM。
- 生成 Schema 時需考量 SQLite ，避免使用不支援的資料類型。
- 若生成資料表 / Migration：
- 請提供 `CREATE TABLE` 或 EF Core Migration 的等價方案（二擇一即可，依專案設定）。
- 若需要示範測試資料：
- 優先提供 `seed` 方式或簡單 SQL 插入語句。