引言

個人而言，GitHub Copilot（以下簡稱：Copilot）讓我受益良多，因此我整理了一些自己的設定及認為不錯的地方作為備忘！（截至2025年10月）

可能這些都是基本的內容，但如果對某位讀者有所幫助，我會非常高興！

這裡所提到的提示和代碼可能內容較為粗略，若您打算使用的話，麻煩根據您的環境進行調整🙇

在此假設您是在VSCode中使用Copilot，另外本篇文中也包含了一些實驗性功能，請斟酌使用🙏

不適合的情況

• 主要想使用CLI
• VSCode不合適
• 回應速度慢造成困擾或壓力
• 充分利用Claude Code的各種功能（子代理、鉤子）

等等等等

喜歡使用Copilot的理由

有幾個原因！

最近其功能差距在減少，並且在一些細節上也感受到更易使用的部分，這也是原因之一。（部分功能比較會在後面提到）

在價格方面

相對較為便宜💰

如果您只是想稍微開發一下，應該可以輕鬆使用！
我最近的開發並不是特別密集，所以這對我來說很有幫助。

最終還是會查看編輯器

這是個人而言的問題，但即使在使用CLI工具時，最終在差異確認等情況下，還是會較常查看編輯器😇

我本身不太擅長多任務處理，因此使用的工具如果能相對集中，工作起來會更加順利，這也是原因之一。

可以使用多種模型

可以嘗試和比較各種模型，且不會依賴特定的模型，我認為這是一個不錯的優點。

通常會按照Claude Sonnet 4.5、GPT-5-Codex、Gemini 2.5 Pro的順序使用！
未來若有新的強大模型推出，也很有可能會追加支持！

Copilot的關鍵問題

在速度方面

與其他工具相比，感覺稍微慢了一些。
不過，由於有通知功能，常常在併行處理其他工作時使用，因此實際上感受到的困擾不多。
應用文件差異的時間相比以前有了相當的改善印象！

在精度方面

個人感受到Claude Code在上下文給予的方式（包括系統提示等）上可能較為優秀。
不過，兩者都可以使用相同的模型，所以在我的使用範圍內，並未感受到特別大的差異。

不久之前，其他工具的功能差異相當大，但最近則有追趕的跡象！
我最近也嘗試過從MCP中調用Codex CLI以提高精度（後述）

功能方面的比較

Claude Code常常被拿來比較，因為有很多用戶且容易理解，因此我也將進行比較。

僅供參考，以下僅為一例。
（此外，由於本篇是推銷Copilot的文章，可能會稍有偏頗）

在GitHub上的執行

Claude Code在GitHub Actions中可自由運行，因此具有較高的通用性。

目前Copilot無法嵌入GitHub Actions，因此在通用性上可能略顯不足。

不過，從VSCode輕鬆運行和單次執行時1個高級請求（$0.04）這樣的價格設定，在價格上似乎具有相當大的優勢。

根據任務的複雜程度來選擇使用可能是個明智的做法。

自訂提示

功能本身似乎沒有太大的差異。

Claude Code將文件內容作為提示，而Copilot則給出「Follow instructions in [文件名稱]」的指示，因此Claude Code在精度方面可能略有優勢。

不過，Copilot在UI上可選擇使用的工具等使用便利性上也有其優點。

子代理

雖然無法進行自訂，但最近新增的 executePrompt 與之有些相似。
（不知為何被悄悄新增）

Claude Code的子代理可以進行各種自訂。
不過，我對此並未完全掌握…（想努力學習）

鉤子

Copilot並沒有這個功能，但提供了桌面通知。

TODO清單

由於未能清楚區分差異，這裡將略過🙇

計畫模式

Copilot中並不存在。
若非要說的話，Ask模式可能最接近？
可以透過創建自訂聊天模式來進行替代。

MCP支持

Copilot可在工具層級上選擇使用的東西。因為很多工具都沒有用到，所以這點還是讓人感到高興。

另外，Copilot是為數不多完全支持MCP的工具之一。

搜尋

Claude Code有Search和Fetch功能，但Copilot只有Fetch。
可能可以透過使用如Gemini CLI的MCP來彌補這一點！

自動批准

Copilot允許使用正則表達式進行更細緻的規定，這讓我感到非常有幫助🙇
此外，還可以顯示由哪個規則自動批准了，以及編輯待批准的命令等，使用上非常便利。

<details>
<summary>範例</summary>

{
  // 允許 `mkdir` 命令，無論參數為何
  "mkdir": true,
  // 允許 `test/scripts.sh`，因為包含 `/`，所以也會允許 `\`
  // 以及可選的 `./` 或 `.\` 前綴
  "test/scripts.sh": true,
  // 允許 `git status` 和所有以 `git show` 開頭的命令
  "/^git (status|show\\b.*)$/": true,

  // 阻止 `del` 命令，無論參數為何
  "del": false,
  // 阻止任何包含文字 "dangerous" 的命令
  "/dangerous/": false,

  // 取消 `rm` 的預設規則以允許其他規則自動批准 `rm` 命令
  "rm": null,
}

</details>

自訂指示檔

Claude Code使用CLAUDE.md。
Copilot則可使用.github/copilot-instructions.md、AGENTS.md等。因為AGENTS.md可與Codex或Gemini CLI共用，所以其通用性也提高了。

設定相關

以下僅列出已更改的項目

chat.agent.maxRequests -> 100

在代理模式下，允許每回合的最大請求數量。當達到限制時，它會詢問是否要繼續。

預設似乎設置較少，在使用代理模式等時，必須設置得多一些，才能避免很快達到限制。

chat.agentSessionsViewLocation -> view

控制顯示代理會話菜單的位置。

會在側邊面板中顯示聊天會話。
可以開啟新的聊天標籤，對於並行運行有幫助。（後述）

chat.emptyState.history.enabled -> true

在空聊天狀態下顯示最近的聊天歷史。

這是個人的偏好設定。

chat.todoListTool.enabled -> true

在聊天中啟用ToDo清單。此清單供代理用於計劃複雜開發工作流程、跟蹤進度和上下文管理的工具。

這是一個常見的TODO清單功能✅

chat.tools.terminal.autoApprove -> 因數量較多而略過

控制是否需要明確批准來執行終端工具命令的命令或正則表達式的列表。這些用於與命令的開頭進行匹配。要指定正則表達式，請用 / 文字包裹字串，並在後面附上可選的（如 i）不區分大小寫的標誌。

這是個人的偏好設定。
如上所述，可以利用正則表達式進行更為細緻的指定，這一點相當便利。

accessibility.signals.chatUserActionRequired -> sound設置為on

當聊天需要用戶操作時，播放信號（聲音（音頻提示）或公告（警報））。

實質上是Copilot Chat的通知功能。
因為auto不會發出通知音，因此我將其設置為on。

github.copilot.enable -> 全部設為true

使能或禁用對特定語言的Copilot自動觸發完成。您仍然可以使用Alt + \手動觸發建議。

因為Markdown、Mojolicious（Perl）模板中也想要使用Copilot，因此設置為true。

github.copilot.chat.codesearch.enabled -> true

當使用'#codebase'時，是否啟用代理代碼搜索。

增強了代碼基的搜索功能！

github.copilot.chat.agent.thinkingTool -> true

在代理模式中，在生成回應之前，啟用Copilot深入思考請求的思考工具。

將使其能夠深入思考🤔

github.copilot.chat.alternateGptPrompt.enabled -> true

啟用用於GPT模型的實驗性替代提示，以取代預設提示。

GPT的提示似乎會變成Beast Mode🐻
尚未進行詳細的比較。

github.copilot.nextEditSuggestions.enabled -> true

是否啟用下一個編輯建議（NES）。
NES可以根據最近的更改來建議下個編輯。關於下一個編輯建議的詳細信息。

這是一個經典的功能。
如下面的圖片所示，會建議您進行編輯的地方，非常方便！

github.copilot.nextEditSuggestions.fixes -> true

是否使用下一個修正建議（NES）提供診斷修正。

似乎會建議添加NES中缺少的匯入（雖然我不太明白😇）

github.copilot.chat.executePrompt.enabled -> true

executePrompt工具使代理能在獨立隔離環境中執行任務。

似乎可以讓代理在不影響其他處理或上下文的情況下，在獨立的隔離環境中執行任務。

自訂提示

雖然可能使用英文會更好，但在精度上特別沒有困難，加上維護的便利性，我選擇了使用日語。

我會先簡單創建提示的基礎，然後幾乎不再編輯地將其丟給ChatGPT等使用。

即使是像/review這種不涉及編輯的提示，我也會指定editFiles等。
這是為了讓提示運行後能直接在同一聊天中進行編輯。
（似乎是因為自訂提示執行後，所使用的工具會是提示中所指定的那個？）

這可能不是最好的方法，但我重視便利性🙇

/init

提示的基礎是Claude Code的/init命令。
在附加照片部分的「指示文件生成」中，可以生成指示文件，但似乎無法指定參數作為提示，因此我另行創建了！

---
mode: agent
tools: ['usages', 'think', 'problems', 'changes', 'testFailure', 'openSimpleBrowser', 'fetch', 'githubRepo', 'todos', 'createFile', 'createDirectory', 'editFiles', 'runCommands', 'search']
description: 生成和改善使得編碼代理（GitHub Copilot和Codex）能夠有效工作的AGENTS.md文件
---
# AGENTS.md 生成與改善提示
## 角色
您是使得編碼代理（GitHub Copilot和Codex）能夠在此儲存庫中高效工作的**AGENTS.md維護者**。請分析代碼基，做到不捏造，避免重複，並概述要點。

## 規則
- **如已存在 `AGENTS.md`**: 不要完全替換該文件，只需提供**改善建議**（必要時可附上樣本差異）。
- **如不存在**: 則新生成**`AGENTS.md`的全文**。
- **使用日語**: 除非有特別指示，均以日語撰寫。
- **禁止捏造**：若未發現的指令或流程或規則，請予以標明「未發現/不明」。
- **不重複**：不要在不同的部分重複相同的信息。
- **顯性禁止**：不包含以下當然的一般論點
    - 「寫親切的錯誤信息」「新實用工具需寫單元測試」
    - 「不要提交敏感信息（如API金鑰）」
- **粒度**：**1~2頁相當**。以項目符號為主，僅限於實務關聯的具體信息。
- **在差分時的格式（若已存在AGENTS.md）**:
    - 「改善建議」（項目符號）→在必要時附上**短的替代範例**（before/after或統一diff風格）。**不可完全重複。**

/create-branch-commit-pr

這是一個支援從分支創建到整理提交，再到建立PR的全過程的命令。

雖然這可能不是最好的方法，但我往往在完成實作後再創建分支和堆疊提交，所以對我來說非常實用。

我通常是這麼做的↓

• 簡單任務→ /create-branch-commit-pr + 實作內容指示即可完成PR的創建
• 複雜任務→實作另行進行，在生成差異後再使用 /create-branch-commit-pr 創建PR

---
mode: 'agent'
tools: ['usages', 'think', 'problems', 'changes', 'testFailure', 'openSimpleBrowser', 'fetch', 'githubRepo', 'todos', 'createFile', 'createDirectory', 'editFiles', 'runCommands', 'search']
description: '作為熟悉Git/GitHub的AI助手，閱讀當前工作區內容，執行從創建分支到語義單位提交再到PR創建的完整流程'
---
# 提交與PR創建提示
## 角色
您是熟悉Git/GitHub的AI助手。
請閱讀當前工作區內容，執行從創建分支到語義單位提交再到PR的創建流程。
如有任務指示，請遵循該指示，若無變更則終了。

## 規則
- 本地操作僅使用標準的`git`和`gh`（GitHub CLI）。
- 在終端輸出時，請附加`cat`以避免用戶操作。
- 回應全部以日語進行。
- 若結果為空，則立即結束。

## 步驟

### 1. 變更確認
- 檢查未階段與已階段的變更
- 若有任務指示，則遵循該指示
- 若無變更且沒有任務指示，則結束

sh
git status
git add -N . # 將未階段的變更添加至索引（方便差異確認）
git diff HEAD # 詳細確認

### 2. 創建分支
- 從`git diff --name-only`與差異摘要中將變更的內容簡要總結為1~2行。
- 根據總結，生成描述性的分支名稱，限制在**kebab-case 20字以內**（僅限小寫字母和`-`。在名稱衝突時，末尾附上短的編號）。
- 創建並切換分支。

sh
git checkout -b "<分支名稱>"

### 3. 依語義單位提交
- 根據「關心事項」劃分變更（例如：新增UI／修正API／設定變更／重構／格式化／測試更新）。
- 針對每一項目對應的文件進行階段處理，並附上清楚的標題進行提交。標題限制在50字以內。必要時附上正文。
- 格式專用提交不與代碼變更混合。

例：

sh

例：新增組件

git add src/components/LoginForm.tsx src/styles/login.css
git commit -m "新增登入表單組件" -m "實作輸入驗證和提交事件"

### 4. 推送與PR創建
- 推送至遠端並創建PR。
- 標題為整體摘要的一句話。
- 正文以Markdown格式寫「概要」「變更原因」「參考」。
- 若給予PR編號，或已知存在PR的情況下，使用`gh pr edit`更新標題及正文。

sh
git push -u origin "<分支名稱>"

若存在PR

gh pr edit <PR編號> --title "<PR標題>" --body "<正文Markdown>"

若不存在PR

gh pr create --assignee "@me" --title "<PR標題>" --body "

概要

• <1~3行總結>

變更原因

• <背景及目的>

參考

• <Issue/文件URL等，標題可不加>
  "

/worktree

我創建這個命令是因為想學習git worktree的操作。
當進行不同的任務或代碼審查時經常使用。

---
mode: 'agent'
tools: ['usages', 'think', 'problems', 'changes', 'testFailure', 'openSimpleBrowser', 'fetch', 'githubRepo', 'todos', 'createFile', 'createDirectory', 'editFiles', 'runCommands', 'search']
description: '根據用戶指示，創建git worktree並在VS Code中打開。'
---
# 自動創建Git worktree & 開啟VS Code提示

## 角色
您是精通Git的Shell執行助手。
根據用戶的輸入（用途/目的或應該審查的對象）自動生成安全的分支名稱，使用`git worktree`創建新的作業目錄，並最終在VS Code中打開。

## 規則
- 使用`git worktree`
- 創建的目錄在`../<repository>.worktrees/<branch>`（基準為儲存庫根目錄）
- 分支名稱必須依用途以**kebab-case**形式且**限制在20字以內**（例如：「hoge的Bug修正用」→`hotfix-hoge-bugfix`、「新增登入功能」→`feature-login`、「審查: feature/search-v2」→`review-feature-search-v2`）
- 用於審查的話，若`origin/<branch>`存在時，應以其指定創建
- 初始時執行`git fetch origin --prune`以便與最新狀態同步

## 步驟
### 1. **檢測上下文**
```bash
# 確認儲存庫根目錄
git rev-parse --show-toplevel

# 作為前置準備獲取最新的origin資訊
git fetch origin --prune

2. 提取用途/概述 → 生成分支名稱（參考規則）

• 偵測審查術語（例如「審查」「review」「PR#」等）後進入審查模式，其餘則進入新模式。

  3. 決定創建路徑

• 採用../<repository>.worktrees/<branch>作為路徑。
• 若路徑衝突，則用-2、-3等編號避開或報告理由並中止。

4. 分支

審查模式：若origin/<branch>存在則以其指定。

git worktree add ../<repository>.worktrees/<branch> origin/<branch>

新模式：若不存在則創建新的分支。基於未指定時默認為origin/main。

git worktree add ../<repository>.worktrees/<branch> -b <branch> <base>

5. 開啟VS Code

open -a "Visual Studio Code" ../<repository>.worktrees/<branch>

/fix-review-comment

這個命令剛開始使用還在檢驗中！
最終的審查回覆內容會預期進行一些人工的精修。

---
mode: 'agent'
tools: ['usages', 'think', 'problems', 'changes', 'testFailure', 'openSimpleBrowser', 'fetch', 'githubRepo', 'todos', 'createFile', 'createDirectory', 'editFiles', 'runCommands', 'search']
description: '作為精通Git/GitHub的AI助手，獲取給定PR號碼的審查評論，進行修正，提交至PR → 推送 → 回覆。'
---
# PR審查評論處理提示
## 角色
您是精通Git/GitHub的AI助手。

## 規則
- 本地操作僅使用標準的`git`和`gh`（GitHub CLI）。
- 回應全部以日語進行。

## 步驟

### 1. 確認分支
- 檢查所給PR編號是否在相對應的分支上。
- 若非則切換至對應的分支。

sh
git checkout <分支名稱>

### 2. 獲取審查評論
- 獲取所給PR編號的審查評論。
- 解析評論以確定該修正之處。

sh
gh api repos/:owner/:repo/pulls/<PR編號>/comments --jq '.[] | {id: id, user: .user.login, file: .path, line: .line, body: .body}' | cat

### 3. 產生修正差異
- 根據指摘進行代碼修正。
- 確認更改內容，必要時追加修正。

### 4. 依語義單位提交
- 根據「關心事項」劃分變更（例如：新增UI／修正API／設定變更／重構／格式化／測試更新）。
- 對每一項目進行階段處理，並附上清楚的標題進行提交。標題限制在50字以內。必要時附上正文。
- 格式專用提交不與代碼變更混合。

例：

sh

例：新增組件

git add src/components/LoginForm.tsx src/styles/login.css
git commit -m "新增登入表單組件" -m "實作輸入驗證和提交事件"

例：API邏輯修正

git add src/api/auth.ts
git commit -m "修正認證API的錯誤處理" -m "明確化HTTP 401/403並添加重試邏輯"

例：測試更新

git add tests/auth.test.ts
git commit -m "更新認證API測試" -m "增加失敗案例和超時"

例：僅格式化Prettier/ESLint等

git add .
git commit -m "僅執行代碼格式化"

### 5. 推送與回覆審查
- 將變更推送至遠端，並對審查評論进行回覆。
- 需要包括提交ID。
- 換行以`<br>`表示。

sh
git push -u origin "<分支名稱>"

若忘記評論ID，重新獲取

gh api repos/:owner/:repo/pulls/<PR編號>/comments --jq '.[] | {id: id, user: .user.login, file: .path, line: .line, body: .body}' | cat

對於代碼行的審查評論

gh api --method POST repos/:owner/:repo/pulls/<PR編號>/comments/<comment_id>/replies -f body="<回覆內容>" | cat

對於普通的PR評論

gh api --method POST repos/:owner/:repo/issues/<PR編號>/comments/<comment_id>/replies -f body="<回覆內容>" | cat

## /review

此命令用於審查。  
雖然內容雜亂，但我也寫了一些可以進行本地審查的功能。

mode: agent
tools: ['usages', 'think', 'problems', 'changes', 'testFailure', 'openSimpleBrowser', 'fetch', 'githubRepo', 'todos', 'createFile', 'createDirectory', 'editFiles', 'runCommands', 'search']
description: 審查git diff main的結果，提供代碼改善的反饋。

Git Diff 審核提示

角色

您是一名經驗豐富的資深軟體工程師。
請審查origin/main的diff，並提供將代碼改善的具體意見。
請不要執行文件的編輯，專注於審查。

步驟

1. 確認差異

• 若指定了分支，則使用該分支
  • 若未附上origin，請附上
• 若未指定分支，則使用目前分支（git rev-parse --abbrev-ref HEAD）

sh
git log --name-only --pretty="" origin/main..<branch>

2. 確認變更內容

• 確認變更內容可使用以下命令：

sh
git diff origin/main -- <file_path1> [<file_path2> <file_path3> ...] | cat

3. 代碼審查

基於獲取的信息和差異，從以下觀點深入進行代碼審查。
請確保審查簡潔而完備，並採用明確的區塊與項目符號構成。

審查格式

• 變更概要：簡要說明進行了怎樣的變更。
• 代碼質量與樣式：分析代碼的質量（可讀性、可維護性等）及是否符合該項目的編碼規範。
• 改善建議：提出具體的改善建議。
• 潛在問題點與風險：指摘潛在的錯誤、性能下降、安全性漏洞等未來風險。

審查重點項目

請特別針對以下項目進行審查：

• 代碼的正確性：是否有bug或邏輯錯誤。
• 項目的規範遵循：命名規範、縮排、註釋書寫等是否統一。
• 性能：變更是否會對應用的性能產生不良影響。
• 測試覆蓋率：變更的代碼是否有充分的測試。
• 安全性：是否有潛在的安全風險。

其他

並行執行

若開啟多個聊天標籤，則可實現與開啟數量相同的並行執行。
最初我設定了按鍵綁定，但最近的更新新增了聊天會話標籤，只需從那裡按下+按鈕即可輕鬆實現。

在進行調查或撰寫文獻時，我經常使用Claude、Gemini、GPT等執行並採納良好結果。

Codex MCP

雖然官方MCP已經足夠好，但因為想限制選項（防止誤操作・簡化）所以我嘗試自製MCP！
而且，目前來看官方MCP的輸出似乎並不特別，並未感受到明顯的精度差距。
以下是我雜亂的代碼，供您參考🫠

<details>
<summary>MCP伺服器的代碼</summary>
概要
-內部執行codex exec
-沙箱固定
-cd限制在主目錄以下
-僅採用[datetime] codex以下（最重要的部分）
-因為有很多不必要的輸出，如提示或大量思考的日誌
-為網頁搜索創建了單獨的工具
-以便讓人聯想到可通過工具名稱進行網頁搜索
-使用mcp用的配置檔

import { spawn } from "node:child_process";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

type CodexCliExecutionResult = {
  stdout: string;
  stderr: string;
  exitCode: number | null;
};

type SandboxMode = "read-only" | "workspace-write";

const schema = z.object({
  cd: z.string().describe("Codex CLI啟動時所設定的工作目錄的絕對路徑"),
  prompt: z.string().describe("傳遞給Codex CLI的提示"),
});

const executeCodexCli = async (
  prompt: string,
  cd: string,
  sandbox: SandboxMode
): Promise<CodexCliExecutionResult> => {
  if (
    cd === "" ||
    !cd.startsWith(`${process.env.HOME}/`) ||
    cd.includes("..")
  ) {
    throw new Error("無效的'cd'路徑。必須是家目錄下的一個絕對路徑。");
  }
  return new Promise((resolve, reject) => {
    const child = spawn(
      "codex",
      ["exec", prompt, "--cd", cd, "--sandbox", sandbox, "--profile", "mcp"],
      {
        stdio: ["pipe", "pipe", "pipe"],
        env: { PATH: process.env.PATH },
      }
    );
    let stdout = "";
    let stderr = "";

    child.stdin.end();

    child.stdout.on("data", (data: Buffer) => {
      stdout += data.toString();
    });
    child.stderr.on("data", (data: Buffer) => {
      stderr += data.toString();
    });

    child.on("close", (code: number | null) => {
      const exitCode = code ?? null;
      if (exitCode === 0) {
        const match =
          /\[[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}\] codex[\s\S]*/.exec(
            stdout
          );
        resolve({
          stdout: match ? match[0] : stdout,
          stderr,
          exitCode,
        });
      } else {
        reject(
          new Error(
            `Codex CLI錯誤：${stderr || stdout || "未知錯誤"}（退出代碼：${exitCode}）`
          )
        );
      }
    });
  });
};

</details>

原文出處：https://qiita.com/Nozomuts/items/430261fa996cba5fd466