🔧 阿川の電商水電行

Shopify 顧問、維護與客製化

💡

小任務 / 單次支援方案

單次處理 Shopify 修正／微調

⭐️

維護方案

每月 Shopify 技術支援 + 小修改 + 諮詢

🚀

專案建置

Shopify 功能導入、培訓 + 分階段交付

👉 瞭解詳情 / 免費諮詢

小編精選 - 技術文章翻譯 · 02月20日

利用標準功能讓 GitHub Copilot 更智能

結論

在 VSCode 中，使 GitHub Copilot 更加智能化需要進行以下設置。

創建聊天指令
創建自訂代理
利用子代理

我曾經也試過使用預設設置進行編碼，感到失望，會想「這樣而已嗎？」。不過，進行這些設置後，它的實用性便提升到了可以實際使用的程度。

創建聊天指令

角色

可以對 Copilot 加入以下前提，依據資料夾或檔案類型進行設定。

整體儲存庫的前提及角色
不包含於儲存庫的外部連接規範
資料夾或檔案類型的程式碼規範
用例

作法

在 VSCode 中開啟 GitHub Copilot 的聊天介面，從右上角的 ⚙️ 標誌選擇「創建聊天指令」開始。

系統會詢問是否要創建新檔案或生成代理指令，選擇「新命令檔案」。

「生成代理的指示」會自動讀取當前儲存庫的狀態來生成，這聽起來十分棒，但實際生成的內容往往無法使用。

這是因為自動生成是將儲存庫的內容統整成一個龐大的檔案。這類龐大且複雜的檔案處理是 AI 的弱項，無論多麼努力創造傑作，前提的輸入階段就無法準確識別。

因此，即使是透過 AI 生成，與其全權交給 AI 處理，不如先手動定義大框架，然後再讓其幫忙填充內容會更好。

當系統詢問要在哪裡創建時，選擇「.github/instructions」。

在「.github/instructions」中將會創建在儲存庫下。
「使用者資料」則會位於本機的 VSCode 設定資料夾中。

如果在「使用者資料」中創建，雖然可以在其他儲存庫中使用，但由於它創建在儲存庫外部，將無法作為儲存庫進行管理，無法與原始碼一同更新。
在個人開發中若不進行儲存庫管理的情況下，這種做法的適用性將會受到限制。

接著決定聊天指令的名稱，只要簡單易懂即可，如果是第一次創建，不妨將整體的共同設定定義為 common。

確定後，將會生成一個檔案 .github/instructions/<指定名稱>.instructions.md，並應在編輯器中開啟。

應該撰寫的內容

規範

在聊天指令中僅有一條規範，那就是在檔頭填寫適用範圍。

.github/instructions/common.instructions.md

---
description: 提供整個儲存庫的指導方針。
applyTo: "**/*"
---

如果要定義設計文件資料夾的角色，可以考慮如下所示的資料夾做為對象。

.github/instructions/docs.instructions.md

---
description: 提供編寫設計文件時的指導方針。
applyTo: "docs/**/*"
---

如果希望為程式碼指定編碼規範，也可以依據檔案類型進行設定。

.github/instructions/python.instructions.md

---
description: 提供 Python 編碼時的指導方針。
applyTo: "**/*.py"
---

可以創建不限數量的聊天指令，根據希望適用的規則決定需要哪些 applyTo 來進行檔案分割。

指令的細節

後續內容則無特殊格式約定，依照前提指示想要的內容進行撰寫。
不過如果完全自由，可能不知從何下手，因此建議撰寫的內容如下。
以下所有內容並非必須，只需撰寫必要的部分即可。

例子

假設有一個儲存庫，包括前端、後端，並創建一個互相轉換 YAML/TOML/JSON 的工具。
那麼可以創建以下內容。（這只是範例，因此止步於必要的最低限度）

.github/instructions/common.instructions.md

---
description: 提供整個儲存庫的指導方針。
applyTo: "**/*"
---

# 概要

提供在創建軟體時需遵守的指導方針。

# 使用者情境

本系統允許用戶通過瀏覽器輸入 YAML/TOML/JSON，並於後端轉換為其他格式供用戶使用。

# 資料夾結構

各資料夾的角色如下所示。

| 資料夾名 | 角色 |
| - | - |
| docs | 儲存所有設計文件 |
| frontend | 儲存前端專案 |
| backend | 儲存後端專案 |

# 安全需求
- 通訊必須透過 TLS 進行。

.github/instructions/frontend.instructions.md

---
description: 提供前端的指導方針。
applyTo: "frontend/**/*"
---

# 前端指導方針

## 概要

提供在創建前端時需遵守的指導方針。

## 使用者情境

用戶將輸入的數據發送至後端，並將轉換後的數據提供給用戶。

## 資料夾結構

資料夾結構必須遵循 Atomic Design 規範。

## 技術堆疊

請使用以下技術。
- TypeScript
- React
- Material UI

## 編碼規範
- 首先重視可讀性和可維護性，其次重視擴展性。
- 每個檔案必須少於 500 行，建議保持在 300 行以下。
- 每個函數、類別、介面必須少於 100 行。
- 型別註釋必須存在，禁止使用 any 型別。

.github/instructions/backend.instructions.md

---
description: 提供後端的指導方針。
applyTo: "backend/**/*"
---

# 後端指導方針

## 概要

提供在創建後端時需遵守的指導方針。

## 使用者情境

使用 REST API 接收的 YAML/TOML/JSON 格式資料轉換為其他格式。

## 技術堆疊

請使用以下技術。
- Rust
- actix-web

## 編碼規範
- 首先重視可讀性和可維護性，其次重視擴展性。
- 每個檔案必須少於 500 行，建議保持在 300 行以下。

.github/instructions/docs.instructions.md

---
description: 提供設計文件的指導方針。
applyTo: "docs/**/*"
---

# 設計文件指導方針

## 概要

提供在創建應用程序設計文件時需遵守的指導方針。

## 資料夾結構

各資料夾的角色如下所示。

| 資料夾名 | 角色 |
| - | - |
| docs/frontend | 儲存前端的設計文件 |
| docs/backend | 儲存後端的設計文件 |

## 技術堆疊

請使用以下技術。
- Asciidoc
- PlantUML
- OpenAPI

## 編碼規範
- 設計文件必須使用 Asciidoc 創建。
- 圖表必須用 PlantUML 創建。
- REST API 規範必須用 OpenAPI 創建。
- 每個檔案必須少於 500 行，建議保持在 300 行以下。
- 按功能將檔案進行分割，並使用 include 將其讀入以形成層次結構。

概要

以幾行簡述聊天指令的檔案概要會是個好主意。
例如針對 docs 資料夾的聊天指令可以描述為「提供在記載設計文件時需遵守的指導方針」。

情境/用途

明確指出這個程式將如何透過什麼方式協助使用者解決問題，這屬於 AI 的薄弱認知部分。

資料夾結構

由於對所有資料夾創建聊天指令在實際上不太現實，因此應僅將聊天指令限制於一兩層，並在此之後在資料夾內進行註明。
如果資料夾有設計模式，也應該註明遵循哪種設計模式。

技術堆疊

列舉內部所使用的框架。
不必列出所有使用的開源軟體，僅列出對於程式架構決定具有重大意義的項目，以免內容過於繁冗。

編碼規範

在此提及的編碼規範並非指格式上的機械性要求，而是撰寫程式時重視的方面。

連接來源/連接目標

如果有連接至儲存庫外的 API 伺服器或數據庫，需明確說明。
一般來說，如果不是公開的，則應記載其規範等文件的文件路徑。

安全性

列明必須滿足的安全要求。
不僅包括通訊必須經過 TLS 加密，也應註明在撰寫程式時不得將用戶名、密碼、安保令牌寫入原始碼等事項。

創建自訂代理

角色

可以創建具有不同操作行為的特殊代理，以區別於預設的代理。

定義儲存庫特有的建置和測試操作
將代理專注於特定處理

常有人誤以為擁有更廣範圍的知識和比較多的功能會提升 AI 的表現。事實上，像編碼代理這類用途稍具專門化的職能，專精於特定領域反而能提升準確性。
因此，比起創建一個既能進行後端也能進行前端的代理，創建獨立的後端用與前端用代理，更能提高輸出的準確性。

作法

在 VSCode 中開啟 GitHub Copilot 的聊天介面，從右上角的 ⚙️ 標誌選擇「創建聊天指令」開始。

系統會詢問是否創建新的自訂代理或更改現有代理，選擇「創建新的自訂代理」即可。

Plan 在 VSCode 中看似是一種新的模式，但實際上它是一種自訂代理。
因此，選擇 Plan 時，便可對 VSCode 中預設的 Plan 進行自訂。

系統會詢問要在哪裡創建時，選擇「.github/agents」。

在「.github/agents」中將會創建於儲存庫下。
「使用者資料」則會位於本機的 VSCode 設定資料夾中。

對於不需要用於編碼，而僅僅用於調查或文書處理的與儲存庫內容無關的檔案，可以考慮在「使用者資料」中創建。

接著命名代理，可以依據角色命名，如 backend 或 frontend。

確定後，將生成一個檔案 .github/agents/<指定名稱>.agent.md，並於編輯器中開啟。

在設計代理時，應針對軟體功能進行分割，盡量減少代理所需持有的知識量。
若將用戶情境、編碼、測試等過程進行分割，則無法充分減少所有代理應該持有的知識，進而無法提升準確性。
因此，應該依據專業知識分割，如前端與後端、API 介面與DB 介面等。

應該撰寫的內容

規範

主要需要指明的內容如下。

---
description: "後端開發代理用於支持後端相關任務。"
tools: ["vscode", "execute", "read", "agent", "edit", "search", "web", "todo"]
model: Claude Sonnet 4.5 (copilot)
---

tools

選擇代理可使用的工具。
即使不清楚有哪些功能，如果已安裝 GitHub Copilot Chat 的擴充功能，也可以透過「工具的配置」選項以勾選形式進行選擇。

點選上述工具配置後，將可進行如下選擇。

基本上僅指定內建的工具，對於擴充功能中添加的工具則僅增加必要的部分。
這是出於權限管理的考量，但如前所述，代理的功能越少，準確性越高。

model

指定代理的 AI 引擎。
即使不清楚正式名稱，只要安裝了 GitHub Copilot Chat 擴充功能，系統就會提供建議。

description

撰寫代理的描述。
這可用於自訂代理的佔位符等用途。

指令的細節

接下來的內容無特殊格式限制，依據前提撰寫想要指示的內容即可。
但如果完全自由，可能不知從何下手，因此建議撰寫的內容如下。
以下所有內容並非必須，只需撰寫必要的部分即可。

例子

.github/agents/frontend.agent.md

---
description: "前端開發代理用於支持前端相關任務"
tools: ["vscode", "execute", "read", "agent", "edit", "search", "web", "todo"]
model: Claude Sonnet 4.5 (copilot)
---

# 前端開發代理

## 角色

這個代理針對前端開發任務提供支持。
包括以下工作內容：
- 程式碼生成與修改
- 錯誤定位與修復
- 性能優化
- 文件創建與更新
- 測試程式碼的編寫與執行

## 行動規則

執行角色時，需遵守以下規則。
- 進行程式碼生成時，必須同步更新設計文件。
- 每當生成/修改程式碼時，必須生成測試程式碼，並確保測試正常通過。

## 建置方式

建置時使用 `npm build`。

## 測試方法

測試時執行 `npm test`。

## 禁止事項
- 使用 `npm dev` 會導致終端機無回應，因此不應使用。
- 執行測試時，避免直接對測試執行命令進行 grep、head、tail 等過濾，應先將內容輸出至 `*.log` 檔案，然後再分析該內容以提取所需信息。
- 禁止直接編輯檔案，應用命令進行檔案編輯時，需清除代理快取，並重新讀取檔案。
- 進行專案初始化或包的添加時，必須使用套件管理器命令，切勿直接編輯設定檔。

.github/agents/backend.agent.md

---
description: "後端開發代理用於支持後端相關任務。"
tools: ["vscode", "execute", "read", "agent", "edit", "search", "web", "todo"]
model: Claude Sonnet 4.5 (copilot)
---

# 後端開發代理

## 角色

這個代理針對後端開發任務提供支持。
包括以下工作內容：
- 程式碼生成與修改
- 錯誤定位與修復
- 性能優化
- 文件創建與更新
- 測試程式碼的編寫與執行

## 行動規則

執行角色時，需遵守以下規則。
- 進行程式碼生成時，必須同步更新設計文件。
- 每當生成/修改程式碼時，必須生成測試程式碼，並確保測試正常通過。

## 建置方式

建置時使用 `cargo build`。

## 測試方法

測試時執行 `cargo test`。

## 禁止事項
- 測試執行時，避免對測試執行命令進行 grep、head、tail 等過濾，應先將內容輸出至 `*.log` 檔案，然後再分析該內容以提取所需信息。
- 禁止直接編輯檔案，應用命令進行檔案編輯時，需清除代理快取，並重新讀取檔案。
- 進行專案初始化或包的添加時，必須使用套件管理器命令，切勿直接編輯設定檔。

角色

簡短列出此代理將進行哪些操作。
這樣可以讓依賴於此代理的請求能夠按照模式進行處理。

行動規則

撰寫操作時須遵循的步驟等。
若能針對角色作出具體說明，將有助於提高準確性。

建置方式/測試方式

每個儲存庫的建置與測試方式各不相同，因此需於此明確說明。
若有需要在測試模式中進行篩選或更改日誌等級的指定方法、測試執行前需設定的環境變數或需啟動的環境，均需做標示。

禁止事項

在代理進行操作過程中，通常有些做法在一般情況下是應遵循的，但在自身環境中不希望這樣進行，例如無限期等待 gdb 等進行互動。
因此需明確指示應避免的事項。

利用子代理

角色

為了提高準確性，可以從其他自訂代理中調用已創建的自訂代理，將整個自訂代理視為團隊來操作。
這樣我們便能解決使用 AI 時人類必須繁瑣分配處理問題的反效果。

本功能目前在 2026 年 2 月時為預覽功能，使用的 runSubagent 功能。
因此，未來 VSCode 的更新可能會改變設置方法。

作法

與一般自訂代理類似，創建用於配置自訂代理的專用自訂代理，例如 .github/agents/manager.agent.md。

不過，相較於普通代理，這裡能做的事情（tools）將進一步縮小，僅指定 agent/runSubagent。

---
description: "經理代理用於支持項目管理相關任務"
tools: ["agent/runSubagent"]
model: Claude Sonnet 4.5 (copilot)
---

由於從自訂代理中調用自訂代理的功能目前是預覽功能，因此預設是關閉的，需要手動啟用。
打開 VSCode 的設置，搜索 chat.customAgentInSubagent.enabled，應能找到「Chat > Custom Agent In Subagent: Enable」的設置，將其啟用即可。

應該撰寫的內容

例子

---
description: "經理代理用於支持項目管理相關任務"
tools: ["agent/runSubagent"]
model: Claude Sonnet 4.5 (copilot)
---

# 經理代理

## 概要

此代理專注於支持與專案管理相關的任務。
包括以下工作內容：
- 將任務分解並分配給各代理
- 整合並審查各代理的回覆
- 根據各代理的成果重新分配其他任務

## 任務分配

經理代理將使用 #tool:agent/runSubagent 來將任務分配給各專業代理。
- 與前端相關的任務
  - agentName - frontend
- 與後端相關的任務
  - agentName - backend
- 與品質保證相關的任務
  - agentName - qa
- 與部署相關的任務
  - agentName - deployer
- 與 UX 設計相關的任務
  - agentName - ux_designer

## 流程

請按照以下流程進行任務分配。

### 創建新功能
1. agentName - ux_designer 進行新功能的 UX 設計
2. agentName - backend 進行新功能的後端實作
3. agentName - frontend 進行新功能的前端實作
4. agentName - qa 實現新功能的 E2E 測試並進行驗證
5. 若測試中發現問題，則將反饋信息給後端和前端
6. agentName - deployer 進行新功能的部署

### 修復故障的情況
1. agentName - qa 準備故障的重現步驟
2. agentName - backend 確定故障原因並修復
3. agentName - frontend 確定故障原因並修復
4. agentName - qa 執行修復後程式碼的 E2E 測試並進行驗證
5. 若測試中發現問題，則將反饋信息給後端和前端
6. agentName - deployer 進行修復後程式碼的部署