GitHub Copilot 在 4 月 20 日暫停了所有個人方案的新用戶註冊。同時，Pro 方案的用戶即將失去 Claude Opus 模型的存取權。

如果你是剛好要開新帳號的工程師，或者是衝著 Opus 去的 Pro 用戶，現在是個評估要不要換工具的時間點。

這篇是從 Copilot 遷移到 Claude Code 的操作指南，不是比較評測（已有一篇），也不是勸你換工具。你得自己決定值不值得換，但換之前至少要知道怎麼換、換了之後哪些習慣要調整。

先搞清楚兩個工具的根本差異

遷移前最重要的一件事不是「A 功能在哪裡」，而是「這個工具假設你怎麼工作」。不懂這個，你會用 Copilot 的思維用 Claude Code，然後覺得它很難用。

Copilot 的設計假設：你在 IDE 裡工作，AI 在旁邊輔助。你寫程式，AI 補全、提建議、回答問題。主導者是你，AI 是智慧自動補全。

Claude Code 的設計假設：你在 terminal 裡工作，AI 和你一起做事。你描述目標或問題，AI 讀檔案、跑指令、修程式碼。主導者更模糊——Claude Code 可以接管一個任務然後跑到完。

不是哪個好哪個壞，是不同的工作模式。如果你的主要工作是在 IDE 裡寫功能，Copilot 的 IDE 整合可能更順手。如果你做的事情需要 AI 跨多個檔案、理解整個 codebase、自己決定要改哪裡，Claude Code 的 agent 模式會更強。

設定對應：Copilot 的 X 在 Claude Code 叫什麼

.github/copilot-instructions.md → CLAUDE.md

這是最直接的對應。

Copilot 用 .github/copilot-instructions.md 設定 AI 的全域行為：這個 repo 的技術棧、coding 規範、哪些東西不要碰。Claude Code 用 CLAUDE.md，邏輯完全一樣。

遷移方式很簡單：把 copilot-instructions.md 的內容複製到 CLAUDE.md，語法格式都是 markdown，不需要改。

但這裡有一個值得停下來做的事：不要直接複製，要重寫。因為 copilot-instructions.md 通常是針對 IDE 補全優化的，強調「寫程式碼時要注意什麼」；CLAUDE.md 效果最好的寫法是針對 agent 優化的，強調「這個 project 是做什麼的、有哪些重要的架構決策、哪些操作需要先問我再動」。

兩者的差異在於：補全 AI 需要的是「程式碼風格提示」，agent AI 需要的是「脈絡和邊界」。

.github/prompts/*.md → .claude/commands/*.md

Copilot 的 slash commands 是放在 .github/prompts/ 目錄，每個 .md 檔對應一個 /command。Claude Code 的邏輯一樣，放在 .claude/commands/ 目錄。

檔名去掉 .md 就是 command 名稱，檔案內容是 Claude 執行這個 command 時的 prompt。

舉例，你在 Copilot 有一個 /code-review.md 叫 Claude 做 code review，遷移到 Claude Code 就是把這個檔案放到 .claude/commands/code-review.md，然後在 Claude Code 裡用 /code-review 呼叫。

語法上 Claude Code 支援在 prompt 裡用 $ARGUMENTS 接收你在 command 後面打的參數，這跟 Copilot 的行為一致。

.github/instructions/*.md → CLAUDE.md 或多層 CLAUDE.md

Copilot 的 instructions 可以用 applyTo 指定哪些目錄或檔案類型會自動載入哪個指令。Claude Code 用的是多層 CLAUDE.md：專案根目錄的 CLAUDE.md 全域生效，子目錄可以各自有一個 CLAUDE.md 只對那個目錄生效。

如果你的 Copilot instructions 是「後端程式碼要遵守 Java 規範，前端要遵守 React 規範」，遷移方式就是在 backend/CLAUDE.md 和 frontend/CLAUDE.md 分別放對應的規範，Claude Code 在處理那個目錄的檔案時會自動讀進來。

工作流轉換：最需要調整的三個習慣

1. 從「選取程式碼然後問 AI」到「描述目標然後讓 AI 決定範圍」

在 Copilot 裡，常見的工作模式是：選取一段程式碼 → inline chat → AI 針對這段程式碼回應。範圍是你決定的。

在 Claude Code 裡，更有效的模式是：描述你想達到的目標 → Claude 自己決定要讀哪些檔案、改哪些地方。

這兩種模式的差異，類比一下就是：前者像是你拿著報告去問顧問「這段話怎麼改好」，後者像是你跟顧問說「我想讓這份報告說服 CTO 批預算，幫我處理」。第二種模式需要你放更多的主控權給 AI，但結果往往更接近你真正想要的。

不是說 Claude Code 不能做精準的局部修改——可以，用 /edit 或者直接描述「只改 utils.py 的第 42 行」。但如果你一直用 Copilot 的模式，你會錯過 Claude Code agent 模式最強的地方。

2. 從「用 IDE 的上下文」到「主動管理 context」

Copilot 整合在 IDE 裡，它天然地知道你現在開著哪個檔案、游標在哪裡、選取了什麼。這些都是自動的 context。

Claude Code 在 terminal 裡，它知道整個 project 的結構（可以自己 ls、read 檔案），但你需要主動告訴它「從這個檔案開始」或者先用 /init 讓它讀一遍 project 結構建立 CLAUDE.md。

實際操作上，習慣 Copilot 的工程師常犯的錯是：打開 Claude Code，直接說「幫我修這個 bug」，然後 Claude Code 沒有足夠的 context 做出好的決定。

正確的開場方式之一：先描述 project（或讓 /init 做這件事），然後再說你要解決什麼問題。等 Claude Code 說它理解了，再開始工作。

3. 從「每個問題一次對話」到「session 管理」

Copilot 的每次 inline chat 或對話都是相對獨立的。你問完一個問題，解決了，繼續工作。

Claude Code 的設計更適合「一個任務一個 session」。你開始一個 session，Claude Code 在這個 session 裡記得你說過什麼、做過什麼。任務完成才結束 session，開新 session 就是全新開始。

這個設計的實際影響是：session 裡不要換話題。你在做 feature A，突然想到要問一個 feature B 的問題，最好新開一個 session 問，然後回來繼續 feature A 的 session。否則 Claude Code 的 context 會混在一起，後面的行為會變得難以預測。

不需要遷移的部分

Claude Code 和 Copilot 的 agents 功能——在 GitHub issue 上指派任務、讓 AI 在雲端跑——是完全不同的兩個東西，目前沒有直接的對應。如果你的工作流依賴 Copilot 的 GitHub Actions 整合（把 issue 指派給 Copilot agent 自動建 PR），這個功能在 Claude Code 有對應的做法但設定上不一樣。

Copilot > Agent > SDD（SpecKate）：如果你用 GitHub Copilot 的 SpecKate SDD 框架，這個框架是 Copilot 特定的整合，Claude Code 裡有類似理念的工具（OpenSpec、.spec/ 目錄慣例），但不是直接對應，需要獨立設定。

遷移值不值得的判斷框架

換工具的成本不只是時間，是習慣改變。你需要大概三到四週才能把 Claude Code 用得跟 Copilot 一樣順。

值得換的情況：你做的工作需要 AI 跨多個檔案做複雜的修改；你想要在 terminal 裡工作而不是只在 IDE 裡；你對 agent 模式感興趣（讓 AI 自己規劃、執行一個任務）；你的 Copilot 用量本來就不高，token 計費轉換後可能更貴。

不值得換的情況：你的主要工作是在 IDE 裡寫程式，inline 補全和 ghost text 是你最常用的功能；你的 team 整體都在用 Copilot，遷移成本需要乘以團隊人數；你不喜歡 terminal，或者你的 workflow 裡 IDE 整合是必需的。

暫時觀望的情況：GitHub Copilot 的暫停新用戶只是暫時的，如果你還沒有帳號只是想觀望，等幾個星期看一下情況再決定也完全合理。

一個工具的好壞是脈絡相依的。同樣的工程師，做不同類型的工作，最好用的工具可能完全不同。遷移前，先搞清楚你的工作模式跟哪個工具的設計假設更接近，比較好的工具往往就在那裡。

原文來源：GitHub Copilot pauses new sign-ups - Roboin Blog
參考來源：Claude Code Documentation - code.claude.com
參考來源：Changes to GitHub Copilot Individual plans - GitHub Blog