全面掌握 GitHub Copilot 代理人模式

打造專屬 AI 開發助手

學員課前注意事項

全面掌握 GitHub Copilot 代理人模式：打造專屬 AI 開發助手

課程簡介

GitHub Copilot 剛推出 Agent Mode (代理人模式) 的時候，我一開始還抱著懷疑的心態，覺得現在的前沿 AI 只要複雜一點的需求就很難一步寫到位，現在推出了一個全自動的 AI Agent 可以幫我們解決各種問題，可靠嗎？但是當我真正花時間下去瞭解後，我才發現這個功能真的太強大了，我相信這將徹底改變我們以往的開發方式。

前幾天在我公司內部分享 GitHub Copilot 代理人模式，我用了一個簡單的 Prompt 就可以全自動把整個專案環境架設好，再一個 Prompt 就可以自動寫出完整個後端 API，實作的過程中毫無意外的寫出了 Bug，但是 GitHub Copilot 的 AI Agent 竟然能自動識別錯誤內容，還在短時間內自動修復 Bugs，公司內部線上三十多人「親眼」看到我 Demo 這些操作，每個人都驚呆了！🤯

這門課是基於你對 GitHub Copilot 有一定瞭解的情況下，搭配著最新的代理人模式 (Agent Mode) 進行更深層的 AI 探索與學習，我將會在課堂上分享其背後的原理，讓你能夠真正理解 Agent Mode 背後的邏輯，並且能夠更好的掌握這個強大的工具。

我相信這堂課的學員將能夠體驗到前所未有的程式開發體驗，從精準的程式碼自動補全到強大的 AI 助手，協助你進行前後端開發與自動化部署，讓我們未來的每一步都讓開發過程更加流暢與高效。課程最後我也會分享在這強大工具的背後，應該用什麼樣的思維與態度來積極面對這個新的 AI 時代，讓我們的開發之路更加精彩！

雖然我教的是一套工具，但我更認為這是一次深刻的反思與轉型，讓每位開發人員都能夠掌握如何引導 Agent 完美執行任務，並且在日常開發中避免常見的錯誤。隨著 AI 助力，未來的開發工作將不再受限於傳統的手動操作，而是跨入一個更加智能、精準與高效的時代。

如果你曾經迷茫於如何提升自己的開發效率，這門課程將會是你的轉捩點。讓我們一同深入探索 GitHub Copilot 的無限潛能，讓我們的開發之路更加精彩！

課程特色

  • 學習如何運用 GitHub Copilot 最新的 Agent Mode 協助精準的開發
  • 課程全程錄影，學員可在課後 3 個月內免費無限次回放，反覆學習不遺漏！
  • 由 Will 保哥 全程線上授課，無地域限制，可即時回應學員任何疑惑
  • 提供專屬 Discord 頻道，課後持續交流與學習，打造長效社群

報名連結

我們過往的課程都可以到 Accupass 的「線上課程訂購區」課程訂購，如果想要推薦同事或朋友也想學習，可以請他們到這裡購買。有任何問題歡迎來信洽詢，加入課程的學員都可以參加本課程專屬的 Discord 學習社群！

給學員的話

各位同學大家好：

GitHub Copilot 越來越強大，在加入 Agent Mode (代理人模式) 之後，許多覺得不可能的事都漸漸變的可能，我將在本次課程好好跟大家分享如何好好迎接這個重大的改變。

由於目前 GitHub Copilot 的 Agent Mode 只有在 Visual Studio Code 的 Insiders 版本可用，所以要大家務必安裝 Visual Studio Code Insiders 來用。

注意: Visual Studio Code Insiders 與 GitHub Copilot Pre-release 幾乎「每天」都在更新，變動得很快，建議大家「每天」都自動更新到最新版，以免遇到一些奇怪的問題。

目前所有的 GitHub Copilot 問題都會被記錄在 microsoft/vscode-copilot-release 這個專案裡，目前已經累積了 1.2k 個 Issues，有大部分都是重複的抱怨貼文！這些抱怨貼文大家看看就好，因為 GitHub Copilot 有超過 2 百萬付費用戶，在加上最近推出免費方案，所以只要一不能用，就會有人上去留言，有些還很氣，哈！😅

總而言之，大家想要「許願」或「抱怨」也可以到這個 Repo 留言，請大家務必到班上分享連結，叫大家一起幫你「集氣」，也就是上去按讚，讚數越多，他們越容易看到。

本次課程完全不會示範 Visual Studio 2022 或 JetBrain IDE 的 GitHub Copilot 功能。但請不用擔心，因為你可以隨時用 Visual Studio Code 生成程式碼，然後再回到原本的 IDE 接續開發。

如果你不太會用 Visual Studio Code 的話，我有一部免費的 從頭打造 C#、.NET、ASP NET Core 開發環境 教學影片，該影片是以 Visual Studio Code 為開發工具進行 .NET 開發，裡面會分享一些 VS Code 的基本用法。

這堂兩小時的課程不會給大家練習的時間，但你依然可以先準備好上課所需的開發環境，隨時體驗 GitHub Copilot 帶來的強大功能，並且在課堂上隨時提出你的任何想法與疑問。

以下文件將說明學員上課前的注意事項，請詳細閱讀並提前準備，有任何疑問都歡迎隨時來信洽詢。

註冊 Discord 帳號

我們最近的課程都已經陸續將課程資訊集中到 Discord 伺服器管理，這是一個非常強大的社群工具，可以讓我們在課程之後也能夠持續交流，請大家先註冊一個 Discord 帳號，並且加入我們的多奇教育訓練 Discord 伺服器。

加入多奇教育訓練 Discord 伺服器

加入 Discord 伺服器之後，進入本次課程專屬頻道的步驟如下：

  1. 請至 規則 頻道仔細閱讀多奇教育訓練 Discord 伺服器的使用規約。

  2. 閱讀完畢後，請移駕到 加入課程 頻道，頻道中有加入課程專屬頻道的啟用說明。

    這個步驟主要是讓你輸入本課程的邀請碼，這組邀請碼我們會連同上課通知一併發出給學員，只要驗證正確即可看見本課程學員專屬的 Discord 頻道，請務必詳細閱讀 Discord 加入課程 頻道的相關說明。

以下是加入 Discord 課程專屬頻道的影片示範：

注意：若加入頻道的驗證次數錯誤超過三次，您的 Discord 帳號將自動被系統鎖定，如有失誤請來信解鎖: training@miniasp.com

註冊 GitHub 帳號

如果你還沒有 GitHub 帳號 (應該不太可能吧?)，請務必先註冊好一個 GitHub 帳號，並且在上課前先登入 GitHub 帳號。

註冊網址：https://github.com/signup

Join GitHub · GitHub

購買 GitHub Copilot 專業版訂閱方案

由於 GitHub Copilot 專業版 (Pro) 是個付費的訂閱服務，雖然目前已經有免費方案，但是額度非常少，上完課你是不可能不花錢的啦。😄

購買網址：https://github.com/features/copilot/

GitHub Copilot

使用 GitHub Copilot 商業版請記得先啟用功能

由於 GitHub Copilot 的商業版(Business)或企業版(Enterprise)都需要先在 GitHub 建立組織(Organization)才能使用，若你的 Copilot 授權是由公司統一管理的話，你還必須確認組織管理員是否有啟用 GitHub Copilot 相關功能，以下示意圖可以讓學員們提供公司管理者參考。

GitHub Copilot policies

安裝 GitHub 支援的開發工具

目前 GitHub Copilot 的 Agent Mode 僅支援 Visual Studio Code Insiders 開發工具，請安裝最新版本。

Visual Studio Code Insiders

切換 Visual Studio Code 顯示語言為繁體中文

Visual Studio Code 是一套跨平台的編輯器，支援 Windows、macOS 與 Linux，因此理論上所有人都可以順利安裝與使用，如果你真的有遇到什麼困難，歡迎隨時到 Discord 課程專屬頻道中發問。

由於 Visual Studio Code 是一套輕量級的編輯器，它的功能是透過安裝「擴充套件」來增強的。

首先，Visual Studio Code 支援完整的「繁體中文」介面，而且翻譯品質非常好，在首次安裝並啟動 Visual Studio Code 後，該軟體就會提醒你安裝繁體中文套件，建議英文不太好的朋友可以安裝繁體中文版。

Chinese (Traditional) Language Pack for Visual Studio Code

如果你的介面沒有自動切換到繁體中文版，那就請透過以下步驟手動切換：

  1. 按下 F1 並輸入 >display language 並選擇 Configure Display Language

    按下 `F1` 並輸入 `>display language` 並選擇 `Configure Display Language`

  2. 選擇 中文(繁體) (zh-tw) 並按下 Enter 鍵

    選擇 `中文(繁體) (zh-tw)` 並按下 `Enter` 鍵

  3. 按下 Restart 按鈕以重新啟動 Visual Studio Code

    按下 `Restart` 按鈕以重新啟動 Visual Studio Code

安裝 Visual Studio Code 擴充套件

GitHub Copilot 的功能是透過安裝擴充套件來實現的，你需要安裝以下擴充套件才能順利的使用 GitHub Copilot 工具：

  1. GitHub Copilot

    GitHub Copilot

  2. GitHub Copilot Chat

    GitHub Copilot Chat

  3. VS Code Speech

    VS Code Speech

  4. Chinese (Traditional, Taiwan) language support for VS Code Speech

    VS Code Speech

  5. Live Preview

    可以讓你在 Visual Studio Code 裡面的檔案隨時都能透過瀏覽器預覽網頁。

GitHub Copilot 在 Visual Studio Code 的建議設定

以下是我在精雕細琢之後，覺得最完美的 GitHub Copilot Chat 與 VS Code Speech 設定參數，可以讓你在使用 GitHub Copilot 時更加順暢，也可以讓你在使用語音輸入時更加自然舒適。

請先找到 Visual Studio Code 的左下角或右下角的 ⚙ 圖示，點開之後選擇 設定 與 鍵盤快速鍵 這兩項，依據以下說明調整設定。

Visual Studio Code 設定

你也可以打開 設定 與 鍵盤快速鍵 後，找到右上角的 開啟設定(JSON) 按鈕，你就可以開啟相對應的 settings.json 或 keybindings.json 檔案，直接合併我在下方整理的 JSON 設定也可以，這是最快速的設定方法。

Visual Studio Code 開啟設定(JSON)

  1. 使用者設定

    • GitHub Copilot - 一般設定

      • github.copilot.enable

        設定在所有檔案啟用 GitHub Copilot 功能，但停用「純文字」檔案類型。

      • github.copilot.editor.enableAutoCompletions 設定為 true

        啟用程式碼自動補全功能，也就是 Inline 自動完成功能。

        因為自動完成功能經常會提供錯誤的提示，有些人會選擇關閉這個選項。

      • github.copilot.editor.enableCodeActions 設定為 true

        控制 Copilot 命令在可用時是否顯示為 Code Actions (程式碼動作)

      • github.copilot.renameSuggestions.triggerAutomatically 設定為 true

        自動觸發重新命名建議

      • window.commandCenter 設定為 true

        如果要啟用 chat.commandCenter.enabled 設定，就必須啟用這個設定。

      • chat.commandCenter.enabled 設定為 true

        設定要不要在編輯器中啟用 Copilot Chat 指令中心按鈕。

      • workbench.commandPalette.experimental.askChatLocation 設定為 chatView

        當你按下 F1 之後詢問 Ask GitHub Copilot 的結果要顯示在哪裡，選 chatView 就會留下提問記錄，若選 quickChat 就不會留下。

      • github.copilot.chat.search.semanticTextResults 設定為 true

        在搜尋檢視中啟用語意搜尋結果。

      • github.copilot.nextEditSuggestions.enabled 設定為 true (預覽功能)

        在編輯器中啟用下一個編輯建議(NES)功能。

        NES = Next Edit Suggestions

    • GitHub Copilot Chat

      • github.copilot.chat.followUps 設定為 firstOnly 或 always

        是否要在聊天中建議跟進訊息，提供你下一個提示的建議。

      • github.copilot.chat.localeOverride 設定為 zh-TW

        設定 GitHub Copilot Chat 的回應語言預設為繁體中文

      • github.copilot.chat.useProjectTemplates 設定為 true

        使用 /new 時直接選用 GitHub 專案範本

      • github.copilot.chat.scopeSelection 設定為 true

        如果使用者使用 /explain 並且使用中編輯器沒有選取，是否提示使用者選取特定符號範圍。

      • chat.detectParticipant.enabled 設定為 false

        在 Chat View 聊天的時候自動偵測適合的聊天參與者來執行你的需求，因此你可以不用特別透過 @ 叫用聊天參與者。

        如果設定為 true 的話，如果呼喚出錯誤的聊天參與者，可以按下 rerun without 重跑一次，這時就會交給 Copilot 來回答。(說明)

        依照我的過往經驗，設定為 true 的時候，經常會叫錯聊天參與者，所以我個人是建議將該設定調整為 false 比較好。

      • chat.promptFiles 設定為 true (實驗性功能)

        啟用提示檔案(prompts)功能，讓您可以在 VS Code 建立可分享、可重複使用的提示指令，並附加額外的上下文。

        可運用在 Chat View, Edit View, Agent Mode, Inline Chat 等環境下。

        詳見 Reusable prompt files (experimental)

      • github.copilot.chat.languageContext.typescript.enabled 設定為 true (實驗性功能)

        在 Inline Chat 與 Inline Completion 啟用自動向 TypeScript Language Service 取用 Context 資訊的能力，以獲取更多附加額外的上下文。

      • github.copilot.chat.agent.thinkingTool 設定為 true

        啟用這個思考工具設定，能讓 Copilot 能夠在代理模式下深入思考您的請求，然後再生成回應。

    • GitHub Copilot Chat - 內嵌聊天 (Inline Chat)

      • github.copilot.chat.editor.temporalContext.enabled 設定為 true

        是否要在 Copilot 要求中包含最近檢視及編輯過的檔案。

      • inlineChat.holdToSpeech 設定為 true

        按住不放 Ctrl+U 或 Ctrl+I 開始語音對話

      • inlineChat.finishOnType 設定為 false

        在編輯器中輸入時，不會自動結束 Inline Chat 對話

    • GitHub Copilot Chat - 偵錯相關設定

      • github.copilot.chat.startDebugging.enabled 設定為 true

        在 Chat View 啟用實驗性的 /startDebugging 命令，幫你快速在 VS Code 初始化偵錯相關設定。

    • GitHub Copilot Chat - 測試相關設定

      • github.copilot.chat.setupTests.enabled 設定為 true

        啟用實驗性的 /setupTests 命令，幫你在 VS Code 快速初始化單元測試相關設定。

      • github.copilot.chat.generateTests.codeLens 設定為 true (實驗性功能)

        讓你在編輯器中遇到某一個函式或方法沒有涵蓋到測試範圍時，自動產生 Generate tests 的 Code lens 建議。

      • github.copilot.chat.testGeneration.instructions 設定為以下內容：

        "github.copilot.chat.testGeneration.instructions": [
  {
    "file": ".copilot-test-instructions.md"
  },
  {
    "text": "Always try uniting related tests in a suite."
  }
],

    • GitHub Copilot Chat - 自訂提示

      • github.copilot.chat.codeGeneration.useInstructionFiles 設定為 true

        使用 .github/copilot-instructions.md 文件來自訂程式碼生成邏輯

      • github.copilot.chat.codeGeneration.instructions 設定為以下內容：

        "github.copilot.chat.codeGeneration.instructions": [
  {
    "text": "Always response in #zh-tw."
  },
  {
    "text": "When outputing any text, use the following translation mappings: create = 建立, object = 物件, queue = 佇列, stack = 堆疊, information = 資訊, invocation = 呼叫, code = 程式碼, running = 執行, library = 函式庫, schematics = 原理圖, building = 建構, Setting up = 設定, package = 套件, video = 影片, for loop = for 迴圈, class = 類別, Concurrency = 平行處理, Transaction = 交易, Transactional = 交易式, Code Snippet = 程式碼片段, Code Generation = 程式碼產生器, Any Class = 任意類別, Scalability = 延展性, Dependency Package = 相依套件, Dependency Injection = 相依性注入, Reserved Keywords = 保留字, Metadata =  Metadata, Clone = 複製, Memory = 記憶體, Built-in = 內建, Global = 全域, Compatibility = 相容性, Function = 函式, Refresh = 重新整理, document = 文件, example = 範例, demo = 展示, quality = 品質, tutorial = 指南, recipes = 秘訣, byte = 位元組, bit = 位元"
  },
  {
      "file": ".copilot-instructions.md"
  }
],

      • github.copilot.chat.reviewSelection.instructions 設定為以下內容：

        "github.copilot.chat.reviewSelection.instructions": [
    {
        "file": ".copilot-review-instructions.md"
    }
],

      • github.copilot.chat.commitMessageGeneration.instructions 設定為以下內容：

        "github.copilot.chat.commitMessageGeneration.instructions": [
  {
    "file": ".copilot-commit-message-instructions.md"
  }
],

      • github.copilot.chat.pullRequestDescriptionGeneration.instructions 設定為以下內容：

        "github.copilot.chat.pullRequestDescriptionGeneration.instructions": [
  {
    "file": ".copilot-pull-request-description-instructions.md"
  }
],

    • GitHub Copilot Edit

      • github.copilot.chat.edits.suggestRelatedFilesForTests 設定為 true

        該功能會在你編輯程式碼時，建議與測試相關的檔案。這對於開發者來說非常有用，因為它可以幫助你快速找到並編輯與當前程式碼變更相關的測試檔案，從而確保程式碼的品質和可靠性。

      • github.copilot.chat.edits.suggestRelatedFilesFromGitHistory 設定為 true

        該功能會根據 Git 歷史紀錄來建議相關的檔案。這意味著當你編輯某個檔案時，GitHub Copilot Chat 會根據過去的 Git 提交紀錄，建議可能與當前編輯相關的其他檔案。這有助於你更全面地理解程式碼變更的影響範圍，並確保所有相關檔案都得到了適當的更新。

      • chat.editing.confirmEditRequestRemoval 設定為 true

        該功能會在你嘗試刪除由 GitHub Copilot Chat 生成的程式碼變更時，提示你確認是否要刪除。這樣可以避免意外刪除程式碼變更，並確保你的程式碼變更是正確的。

      • chat.editing.confirmEditRequestRetry 設定為 true

        該功能會在你嘗試重新生成由 GitHub Copilot Chat 生成的程式碼變更時，提示你確認是否要重新生成。這樣可以避免意外重新生成程式碼變更，並確保你的程式碼變更是正確的。

    • GitHub Copilot Chat - Agent Mode

      • chat.agent.enabled 設定為 true

        即便是 Visual Studio Code Insiders 版本，預設 Agent Mode 也是沒有啟用的，你必須手動啟用這個選項，才可以看見 Copilot Edit 中的功能。

      • chat.agent.maxRequests 設定為 50

        預設 Agent Mode 在讓 Agent 自動作業的時候，預設只有 15 次迭代，對於一些比較複雜的工作，可能會需要你不斷的確認是否繼續。建議可以調高到 50 即可。也建議不要調的更多，因為設定更高時，複雜工作一樣不會表現的更好。

      • github.copilot.chat.codesearch.enabled 設定為 true (預覽功能)

        這個選項用來啟用 #codebase 變數的「代理人」原始碼搜尋功能。

        傳統一般搜尋主要是透過關鍵字比對，搭配 github.copilot.chat.search.semanticTextResults 設定為 true 可以啟用搜尋時做語意比對，但在 GitHub Copilot Chat 聊天時，如果要透過 #codebase 變數找檔案，之前就只能做一次性的比對。

        當啟用了 github.copilot.chat.codesearch.enabled 設定後，就不會只搜尋一次，而是會多嘗試幾種不同的搜尋條件，幫你更好的找到需要的程式碼！👍

      • github.copilot.chat.newWorkspaceCreation.enabled 設定為 true (實驗性功能)

        這個選項用來啟用 @workspace /new 建立新專案的「代理人」功能。

      • github.copilot.chat.agent.runTasks 設定為 true

        這個選項感覺跟 Agent Mode 相關，實則完全無關。其設定值預設也為 true，所以理論上不用特別設定。

        這個選項的用途，主要是讓你可以在 GitHub Copilot Chat 呼叫 .vscode/tasks.json 定義的 Task 來執行。

    • Accessibility (Voice)

      • accessibility.voice.speechLanguage 設定為 zh-TW

        設定語音輸入的語言為繁體中文。

      • accessibility.voice.autoSynthesize 設定為 off

        在 Copilot 回應時自動合成語音，但有時候太吵了，建議關閉！XD

      • accessibility.voice.keywordActivation 設定為 chatInContext

        代表你在說 Hey Code 時會在 Copilot 聊天視窗互動。可設定 off 關閉此功能。

      • accessibility.voice.speechTimeout 設定為 1200

        設定語音輸入後可停頓的時間為 1200 毫秒。

        有些人講話比較慢，一句話講到一半會想很久，這時就要調高一點，不然只要停頓 1.2 秒就送出了！

      • accessibility.voice.ignoreCodeBlocks 設定為 true (Insiders)

        避免在合成語音的時候去讀程式碼區塊的內容

    以下是 settings.json 設定檔內容：

     {
   // Agent Mode 需要調高預設 Terminal 的捲軸行數
   "terminal.integrated.scrollback": 50000,

   // GitHub Copilot
   "github.copilot.enable": {
     "*": true,
     "plaintext": false,
     "markdown": true,
     "scminput": true,
     "yaml": true,
     "html": true,
     "powershell": true,
     "javascript": true,
     "aspnetcorerazor": true
   },
   "github.copilot.editor.enableAutoCompletions": true,
   "github.copilot.editor.enableCodeActions": true,
   "github.copilot.renameSuggestions.triggerAutomatically": true,
   "window.commandCenter": true,
   "chat.commandCenter.enabled": true,
   "workbench.commandPalette.experimental.askChatLocation": "chatView",
   "github.copilot.chat.search.semanticTextResults": true,
   "github.copilot.nextEditSuggestions.enabled": true,

   // GitHub Copilot Chat
   "github.copilot.chat.followUps": "always",
   "github.copilot.chat.localeOverride": "zh-TW",
   "github.copilot.chat.useProjectTemplates": true,
   "github.copilot.chat.scopeSelection": true,
   "chat.detectParticipant.enabled": true,
   "chat.promptFiles": true,
   "github.copilot.chat.languageContext.typescript.enabled": true,
   "github.copilot.chat.agent.thinkingTool": true,

   // GitHub Copilot Chat - 內嵌聊天 (Inline Chat)
   "github.copilot.chat.editor.temporalContext.enabled": true,
   "inlineChat.holdToSpeech": true,
   "inlineChat.finishOnType": false,

   // GitHub Copilot Chat - 偵錯相關設定
   "github.copilot.chat.startDebugging.enabled": true,

   // GitHub Copilot Chat - 測試相關設定
   "github.copilot.chat.setupTests.enabled": true,
   "github.copilot.chat.generateTests.codeLens": true,
   "github.copilot.chat.testGeneration.instructions": [
     {
       "file": ".copilot-test-instructions.md"
     },
     {
       "text": "Always try uniting related tests in a suite."
     }
   ],

   // GitHub Copilot Chat - 自訂提示
   "github.copilot.chat.codeGeneration.useInstructionFiles": true,
   "github.copilot.chat.codeGeneration.instructions": [
     {
       "text": "When outputing any text, use the following translation mappings: create = 建立, object = 物件, queue = 佇列, stack = 堆疊, information = 資訊, invocation = 呼叫, code = 程式碼, running = 執行, library = 函式庫, schematics = 原理圖, building = 建構, Setting up = 設定, package = 套件, video = 影片, for loop = for 迴圈, class = 類別, Concurrency = 平行處理, Transaction = 交易, Transactional = 交易式, Code Snippet = 程式碼片段, Code Generation = 程式碼產生器, Any Class = 任意類別, Scalability = 延展性, Dependency Package = 相依套件, Dependency Injection = 相依性注入, Reserved Keywords = 保留字, Metadata =  Metadata, Clone = 複製, Memory = 記憶體, Built-in = 內建, Global = 全域, Compatibility = 相容性, Function = 函式, Refresh = 重新整理, document = 文件, example = 範例, demo = 展示, quality = 品質, tutorial = 指南, recipes = 秘訣, byte = 位元組, bit = 位元"
     },
     {
       "text": "Always response in #zh-tw."
     },
     {
       "file": ".copilot-instructions.md"
     }
   ],
   "github.copilot.chat.reviewSelection.instructions": [
     {
       "text": "Always response in #zh-tw."
     },
     {
         "file": ".copilot-review-instructions.md"
     }
   ],

   // GitHub Copilot Chat - 自訂 Git Commit 訊息提示
   "github.copilot.chat.commitMessageGeneration.instructions": [
     {
       "text": "# Conventional Commits 1.0.0\r\n\r\n## Summary\r\n\r\nThe Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with [SemVer](http://semver.org/), by describing the features, fixes, and breaking changes made in commit messages.\r\n\r\nThe commit message should be structured as follows:\r\n\r\n* * * * *\r\n\r\n```\r\n<type>[optional scope]: <description>\r\n\r\n[optional body]\r\n\r\n[optional footer(s)]\r\n```\r\n\r\n* * * * *\r\n\r\nThe commit contains the following structural elements, to communicate intent to the consumers of your library:\r\n\r\n1. **fix:** a commit of the *type* `fix` patches a bug in your codebase (this correlates with [`PATCH`](http://semver.org/#summary) in Semantic Versioning).\r\n2. **feat:** a commit of the *type* `feat` introduces a new feature to the codebase (this correlates with [`MINOR`](http://semver.org/#summary) in Semantic Versioning).\r\n3. **BREAKING CHANGE:** a commit that has a footer `BREAKING CHANGE:`, or appends a `!` after the type/scope, introduces a breaking API change (correlating with [`MAJOR`](http://semver.org/#summary) in Semantic Versioning). A BREAKING CHANGE can be part of commits of any *type*.\r\n4. *types* other than `fix:` and `feat:` are allowed, for example [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (based on the [Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) recommends `build:`, `chore:`, `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others.\r\n5. *footers* other than `BREAKING CHANGE: <description>` may be provided and follow a convention similar to [git trailer format](https://git-scm.com/docs/git-interpret-trailers).\r\n\r\nAdditional types are not mandated by the Conventional Commits specification, and have no implicit effect in Semantic Versioning (unless they include a BREAKING CHANGE). A scope may be provided to a commit's type, to provide additional contextual information and is contained within parenthesis, e.g., `feat(parser): add ability to parse arrays`.\r\n\r\n## Examples\r\n\r\n### Commit message with description and breaking change footer\r\n\r\n```\r\nfeat: allow provided config object to extend other configs\r\n\r\nBREAKING CHANGE: `extends` key in config file is now used for extending other config files\r\n```\r\n\r\n### Commit message with `!` to draw attention to breaking change\r\n\r\n```\r\nfeat!: send an email to the customer when a product is shipped\r\n```\r\n\r\n### Commit message with scope and `!` to draw attention to breaking change\r\n\r\n```\r\nfeat(api)!: send an email to the customer when a product is shipped\r\n```\r\n\r\n### Commit message with both `!` and BREAKING CHANGE footer\r\n\r\n```\r\nchore!: drop support for Node 6\r\n\r\nBREAKING CHANGE: use JavaScript features not available in Node 6.\r\n```\r\n\r\n### Commit message with no body\r\n\r\n```\r\ndocs: correct spelling of CHANGELOG\r\n```\r\n\r\n### Commit message with scope\r\n\r\n```\r\nfeat(lang): add Polish language\r\n```\r\n\r\n### Commit message with multi-paragraph body and multiple footers\r\n\r\n```\r\nfix: prevent racing of requests\r\n\r\nIntroduce a request id and a reference to latest request. Dismiss\r\nincoming responses other than from latest request.\r\n\r\nRemove timeouts which were used to mitigate the racing issue but are\r\nobsolete now.\r\n\r\nReviewed-by: Z\r\nRefs: #123\r\n```\r\n\r\n## Specification\r\n\r\nThe key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).\r\n\r\n1. Commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc., followed by the OPTIONAL scope, OPTIONAL `!`, and REQUIRED terminal colon and space.\r\n2. The type `feat` MUST be used when a commit adds a new feature to your application or library.\r\n3. The type `fix` MUST be used when a commit represents a bug fix for your application.\r\n4. A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., `fix(parser):`\r\n5. A description MUST immediately follow the colon and space after the type/scope prefix. The description is a short summary of the code changes, e.g., *fix: array parsing issue when multiple spaces were contained in string*.\r\n6. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.\r\n7. A commit body is free-form and MAY consist of any number of newline separated paragraphs.\r\n8. One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a `:<space>` or `<space>#` separator, followed by a string value (this is inspired by the [git trailer convention](https://git-scm.com/docs/git-interpret-trailers)).\r\n9. A footer's token MUST use `-` in place of whitespace characters, e.g., `Acked-by` (this helps differentiate the footer section from a multi-paragraph body). An exception is made for `BREAKING CHANGE`, which MAY also be used as a token.\r\n10. A footer's value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed.\r\n11. Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the footer.\r\n12. If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., *BREAKING CHANGE: environment variables now take precedence over config files*.\r\n13. If included in the type/scope prefix, breaking changes MUST be indicated by a `!` immediately before the `:`. If `!` is used, `BREAKING CHANGE:` MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change.\r\n14. Types other than `feat` and `fix` MAY be used in your commit messages, e.g., *docs: update ref docs.*\r\n15. The units of information that make up Conventional Commits MUST NOT be treated as case sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase.\r\n16. BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer.\r\n\r\n## Why Use Conventional Commits\r\n\r\n- Automatically generating CHANGELOGs.\r\n- Automatically determining a semantic version bump (based on the types of commits landed).\r\n- Communicating the nature of changes to teammates, the public, and other stakeholders.\r\n- Triggering build and publish processes.\r\n- Making it easier for people to contribute to your projects, by allowing them to explore a more structured commit history.\r\n\r\n## FAQ\r\n\r\n### How should I deal with commit messages in the initial development phase?\r\n\r\nWe recommend that you proceed as if you've already released the product. Typically *somebody*, even if it's your fellow software developers, is using your software. They'll want to know what's fixed, what breaks etc.\r\n\r\n### Are the types in the commit title uppercase or lowercase?\r\n\r\nAny casing may be used, but it's best to be consistent.\r\n\r\n### What do I do if the commit conforms to more than one of the commit types?\r\n\r\nGo back and make multiple commits whenever possible. Part of the benefit of Conventional Commits is its ability to drive us to make more organized commits and PRs.\r\n\r\n### Doesn't this discourage rapid development and fast iteration?\r\n\r\nIt discourages moving fast in a disorganized way. It helps you be able to move fast long term across multiple projects with varied contributors.\r\n\r\n### Might Conventional Commits lead developers to limit the type of commits they make because they'll be thinking in the types provided?\r\n\r\nConventional Commits encourages us to make more of certain types of commits such as fixes. Other than that, the flexibility of Conventional Commits allows your team to come up with their own types and change those types over time.\r\n\r\n### How does this relate to SemVer?\r\n\r\n`fix` type commits should be translated to `PATCH` releases. `feat` type commits should be translated to `MINOR` releases. Commits with `BREAKING CHANGE` in the commits, regardless of type, should be translated to `MAJOR` releases.\r\n\r\n### How should I version my extensions to the Conventional Commits Specification, e.g. `@jameswomack/conventional-commit-spec`?\r\n\r\nWe recommend using SemVer to release your own extensions to this specification (and encourage you to make these extensions!)\r\n\r\n### What do I do if I accidentally use the wrong commit type?\r\n\r\n#### When you used a type that's of the spec but not the correct type, e.g. `fix` instead of `feat`\r\n\r\nPrior to merging or releasing the mistake, we recommend using `git rebase -i` to edit the commit history. After release, the cleanup will be different according to what tools and processes you use.\r\n\r\n#### When you used a type *not* of the spec, e.g. `feet` instead of `feat`\r\n\r\nIn a worst case scenario, it's not the end of the world if a commit lands that does not meet the Conventional Commits specification. It simply means that commit will be missed by tools that are based on the spec.\r\n\r\n### Do all my contributors need to use the Conventional Commits specification?\r\n\r\nNo! If you use a squash based workflow on Git lead maintainers can clean up the commit messages as they're merged---adding no workload to casual committers. A common workflow for this is to have your git system automatically squash commits from a pull request and present a form for the lead maintainer to enter the proper git commit message for the merge.\r\n\r\n### How does Conventional Commits handle revert commits?\r\n\r\nReverting code can be complicated: are you reverting multiple commits? if you revert a feature, should the next release instead be a patch?\r\n\r\nConventional Commits does not make an explicit effort to define revert behavior. Instead we leave it to tooling authors to use the flexibility of *types* and *footers* to develop their logic for handling reverts.\r\n\r\nOne recommendation is to use the `revert` type, and a footer that references the commit SHAs that are being reverted:\r\n\r\n```\r\nrevert: let us never again speak of the noodle incident\r\n\r\nRefs: 676104e, a215868\r\n```"
     },
     {
       "text": "請一律使用正體中文來撰寫記錄"
     },
     {
       "file": ".copilot-commit-message-instructions.md"
     }
   ],

   // GitHub Copilot Chat - 自訂 Pull Request 描述提示
   "github.copilot.chat.pullRequestDescriptionGeneration.instructions": [
     {
       "text": "請一律使用正體中文來撰寫記錄"
     },
     {
       "file": ".copilot-pull-request-description-instructions.md"
     }
   ],

   // GitHub Copilot Chat Edit
   "chat.editing.confirmEditRequestRemoval": true,
   "chat.editing.confirmEditRequestRetry": true,
   "github.copilot.chat.edits.suggestRelatedFilesForTests": true,
   "github.copilot.chat.edits.suggestRelatedFilesFromGitHistory": true,

   // GitHub Copilot Chat - Agent Mode
   "chat.agent.enabled": true,
   "chat.agent.maxRequests": 50,
   "github.copilot.chat.codesearch.enabled": true,
   "github.copilot.chat.newWorkspaceCreation.enabled": true,

   // Accessibility
   "accessibility.voice.speechLanguage": "zh-TW",
   "accessibility.voice.autoSynthesize": "off",
   "accessibility.voice.keywordActivation": "chatInContext",
   "accessibility.voice.speechTimeout": 1200,
   "accessibility.voice.ignoreCodeBlocks": true,
 }

  2. 鍵盤設定

    • 常用快速鍵 (內建)

      • 開啟 Copilot Chat 視窗，可以按下 Ctrl+Alt+I

      • 開啟 Copilot Edit 視窗，可以按下 Ctrl+Shift+I

      • 若在 Copilot Edit 視窗，可以按下 Ctrl+. 快速切換 Edit Mode 與 Agent Mode

      • 若在 Copilot Chat 或 Copilot Edit 可以按下 Ctrl+/ 連結內容 (Attach Context)

      • 若在 Copilot Chat 或 Copilot Edit 可以按下 Ctrl+L 清空現在的對話記錄

      • 若在 Copilot 的代理模式可以按下 Ctrl+Enter 讓終端機的命令自動執行 (不用碰滑鼠)

    • 語音對話 (Chat View)

      • 按下 Ctrl+U 開始語音對話

      • 按下 Ctrl+U 結束語音對話

      • 長按 Ctrl+U 可直接說話，放開快速鍵就可以送出提示

    • 語音指令 (Dictation)

      • 按下 Alt+L 開始語音輸入

      • 按下 Alt+L 或 Escape 結束語音輸入

    以下是 keybindings.json 設定檔內容：

     [
   {
     "key": "ctrl+u",
     "command": "workbench.action.chat.startVoiceChat",
     "when": "!voiceChatInProgress"
   },
   {
     "key": "ctrl+u",
     "command": "workbench.action.chat.stopListeningAndSubmit",
     "when": "voiceChatInProgress"
   },
   {
     "key": "alt+l",
     "command": "workbench.action.editorDictation.start",
     "when": "!editorDictation.inProgress"
   },
   {
     "key": "alt+l",
     "command": "workbench.action.editorDictation.stop",
     "when": "editorDictation.inProgress"
   },
   {
     "key": "tab",
     "command": "-markdown.extension.onTabKey"
   },
   {
     "key": "tab",
     "command": "markdown.extension.onTabKey",
     "when": "!tabShouldJumpToInlineEdit && !tabShouldAcceptInlineEdit && editorTextFocus && markdown.extension.editor.cursor.inList && !editorHasMultipleSelections && !editorReadonly && !editorTabMovesFocus && !hasOtherSuggestions && !hasSnippetCompletions && !inSnippetMode && !inlineSuggestionVisible && !markdown.extension.editor.cursor.inFencedCodeBlock && !markdown.extension.editor.cursor.inMathEnv && !suggestWidgetVisible && editorLangId =~ /^markdown$|^rmd$|^quarto$/"
   },
   {
     "key": "ctrl+l c",
     "command": "-extension.copyGitHubLinkToClipboard"
   },
   {
     "key": "ctrl+l g",
     "command": "-extension.openInGitHub"
   },
   {
     "key": "ctrl+l p",
     "command": "-extension.openPrGitProvider"
   },
   {
       "key": "ctrl+alt+l",
       "command": "workbench.action.editor.changeLanguageMode",
       "when": "!notebookEditorFocused"
   },
   {
       "key": "ctrl+k m",
       "command": "-workbench.action.editor.changeLanguageMode",
       "when": "!notebookEditorFocused"
   },
   {
       "key": "ctrl+backspace",
       "command": "-chatEditor.action.reject",
       "when": "chatEdits.hasEditorModifications && editorFocus && !chatEdits.isRequestInProgress"
   }
 ]

    上面有兩個 tab 鍵的設定是特別針對 Markdown All in One 所做的調整，因為該套件有個 markdown.extension.onTabKey 命令有特別針對 tab 鍵做一些功能，該功能會跟 GitHub Copilot 下一個編輯建議(NES)功能衝突，必須這樣改才能正常運作！詳見 The Tab key conflicts with GitHub Copilot’s Next Edit Suggestion (NES) #1497

    我們在編輯器中經常會用 ctrl+backspace 刪除一個單字，但是這個快速鍵在 GitHub Copilot 卻是「拒絕修改建議」的意思，他會將 Edit Mode 或 Agent Mode 做出的整個建議，全部一起還原，這太危險了，建議將此快速鍵綁定刪除！

建議調整 VS Code 的預設終端機

由於 GitHub Copilot 的 Agent Mode 只能跟指定的 Shell 環境搭配，尤其是在 Windows 作業系統下，各位同學更應該注意！

在 Windows 作業系統，我們有三種 Shell 環境可以選擇：

  1. Command Prompt (命令提示字元)

    這是每一台 Windows 都有內建的 Shell 環境。

    ❌ 這個是 GitHub Copilot 的 Agent Mode 不支援的 Shell 環境，如果你目前選到這個的話，一定要改。

  2. Windows PowerShell 5.1

    這是每一台 Windows 都有內建的 Shell 環境，啟動命令為 powershell.exe。

    ✅ 這是 Visual Studio Code 預設的終端機，理論上不用調整就能用。

    但是第一次使用前，建議執行以下命令，解除一些執行限制。請用「系統管理員」身份開啟 Windows PowerShell 並執行以下命令：

     Set-ExecutionPolicy RemoteSigned

  3. PowerShell (舊名為 PowerShell Core)

    這是微軟下一代 PowerShell 執行環境，支援 Windows, macOS, Linux 等作業系統，必須額外安裝才能使用，啟動的命令為 pwsh.exe。

    ✅ 你可以手動調整 Visual Studio Code 讓終端機預設採用這個環境。

    先按下 F1 並輸入 Terminal 搜尋，找到 Terminal: Select Default Profile 命令

    Terminal: Select Default Profile

    然後選擇執行檔為 pwsh.exe 的選項，如下圖示：

    Select a profile

  4. Git Bash

    這是在你安裝 Git for Windows 之後，預設就會有的 Shell 環境，啟動命令為 bash.exe。

    ❌ 這個是 GitHub Copilot 的 Agent Mode 不支援的 Shell 環境，如果你目前選到這個的話，一定要改。

如果你使用 Windows 作業系統，我強烈建議採用 PowerShell 為你主要的 Shell 執行環境，問題會比較少！🔥

如果你使用 macOS 或 Linux 作業系統，選用 Bash 或 Zsh 應該不會有什麼問題，如果遇到無法讓 Agent 呼叫命令的情況，請到 Discord 頻道回報，或直接到 microsoft/vscode-copilot-release 這裡反應問題。

GitHub Copilot 相關連結

  1. GitHub Copilot 官網
  2. GitHub Copilot Plans
  3. GitHub Copilot 快速上手
  4. GitHub Copilot Extensions
    1. Copilot Extensions marketplace
  5. GitHub Copilot documentation
  6. GitHub Copilot in Visual Studio Code

上課前注意事項

由於我們上課時會採用 Zoom Workplace 桌面應用程式 軟體進行授課，因此請學員在上課前先安裝好 Zoom Workplace 桌面應用程式 軟體的最新版，並且測試好麥克風與喇叭是否可以正常運作，以免上課時無法順利聽到課程內容。

以下幾點請在上課前確認完畢：

  1. 檢查 Zoom 是否為最新版本

    我這邊目前最新的 Zoom 版本為 6.3.0

    Zoom 版本

  2. 檢查 Zoom 麥克風與喇叭是否正常運作

    你可以透過 Zoom 的測試功能來檢查麥克風與喇叭是否正常運作，如果你的麥克風與喇叭都正常運作，你會看到以下畫面：

    Zoom 麥克風與喇叭測試

上課時的注意事項

🔥 請不要在最後一刻才進入教室 🔥

🔥 請不要在最後一刻才進入教室 🔥

🔥 請不要在最後一刻才進入教室 🔥

  1. 你可以在課程開始前 30 分鐘進入 Zoom 會議室

    我會在讓大家進入會議室時播放背景音樂，請確認可以聽的到聲音。

    若聽不到聲音，可以先檢查 Zoom 麥克風與喇叭的設定是否正確，或是重新退出 Zoom 會議室後再次進入。

    建議大家盡量不要使用「手機」進入 Zoom 會議室，因為手機的螢幕太小，上課體驗會比較差。但如果真的沒辦法，用手機也是可以上課，等日後看重播時用電腦看就好。

  2. 以下是進入會議室的步驟

    開啟 Zoom 軟體，點擊「加入會議」

    開啟 Zoom 軟體，點擊「加入會議」

    輸入我們課前通知的「會議號碼」與「顯示名稱」

    輸入我們課前通知的「會議號碼」與「顯示名稱」

    輸入會議密碼

    輸入會議密碼

    測試喇叭和麥克風

    測試喇叭和麥克風

    請務必測試一下麥克風與喇叭是否正常運作，以免上課時無法順利聽到課程內容。

    請務必測試一下麥克風與喇叭是否正常運作，以免上課時無法順利聽到課程內容。

    進入會議室之後，如果聽的到聲音，就按下「回應」的 ✅ 按鈕。

  3. 多利用「回應」功能給予課程回饋

    過往有許多同學都找不到 Zoom 的「回應」功能，我特別截圖跟大家說明怎樣操作。

    Zoom Reactions

    基本上在 Zoom 最下方的工具列上，會有個「回應」的按鈕，按下去之後會有三排的表情符號可以按：

    第一排：這些表情符號按下之後可以表達你在課堂上的心情，而且 10 秒之後就會自動消失。這些表情非常重要，因為這可以讓講師知道你當下的心情，感覺開心的時候可以選 😂 (大笑)，聽到很厲害的內容時可以按下 👍 (讚)、❤ (愛心)、👏 (拍手)、🎉 (獻花) 等表情，這可以讓課程變的相當活絡有趣！

    第二排：這些符號按下去之後不會自動消失，主要用來回應講師的提問，方便大家回答問題。例如講師問「大家都聽的到我的聲音嗎？」，你可以按下 ✅ (打勾) 來代表「聽的到」，或是按下 ❌ (打叉) 來代表「聽不到」，這樣講師就可以得知你的狀態。

    第三排：只有一顆「舉手」的按鈕，按下去代表你想要開麥克風發言，講師會看到你的舉手，然後依序讓你發言。先按「舉手」的人會排在最上面，講師會更容易看到你的舉手狀態。

    以下有幾個好用的鍵盤快速鍵給大家參考，上課時可以盡情使用，增加上課的趣味性：

    功能 Windows macOS
    快速開啟「回應」選單 Ctrl+Shift+Y Command(⌘)+Shift+Y
    傳送會議回應 [鼓掌] Alt+Shift+4 Option+Command(⌘)+4
    傳送會議回應 [讚] Alt+Shift+5 Option+Command(⌘)+5
    傳送會議回應 [愛心] Alt+Shift+6 Option+Command(⌘)+6
    傳送會議回應 [大笑] Alt+Shift+7 Option+Command(⌘)+7
    傳送會議回應 [驚訝] Alt+Shift+8 Option+Command(⌘)+8
    傳送會議回應 [慶祝/拉炮] Alt+Shift+9 Option+Command(⌘)+9
    舉手/放下手 Alt+Y Option+Y
    將音訊靜音/取消靜音 Alt+A Command(⌘)+Shift+A

    表1: Zoom 鍵盤快速鍵參考

  4. 利用【聊天室】來向講師或學員傳達訊息

    Zoom 軟體有個「聊天」功能，但請不要在「所有人」的視窗聊天，因為很多人一起聊天的結果，就是大家都找不到訊息。

    這個「聊天室」功能主要用來讓學員與講師之間的溝通，如果你有任何問題，可以在「聊天室」中發問，講師、助教或其他學員都會盡量回答你的問題。

    留言時，請務必在一個訊息中把問題打完，不要像 LINE 一樣，想到一句打一句，否則可能會不同人發問的問題之間交錯出現，導致閱讀困難。

    回覆留言時，請多利用「回覆」功能，讓一個問題的討論可以聚焦在同一個討論串內，這樣大家閱讀起來會比較清楚。

  5. 利用【麥克風】使用語音提問

    進入會議室之後，麥克風會處於「鎖定」的狀態，如有問題想透過語音發問，請先點擊 Zoom 軟體的「舉手」按鈕，講師會開啟你的麥克風讓你線上發問。

    如果講師需要學員進行語音互動時，願意發言的人，也可以先按下「舉手」等候講師呼喚，並準備開啟麥克風，這樣才不會花太多時間等待學員回應。

  6. 不開放【視訊】使用

    原則上我們上課不需要開啟視訊鏡頭，以確保大家的個人隱私。

上課連結

由於我們上課時會採用 Zoom Workplace 桌面應用程式 軟體進行授課，而上課的 Zoom 會議室連結實際上是會透過另外的郵件通知學員，郵件主旨會是：

【上課通知】全面掌握 GitHub Copilot 代理人模式：打造專屬 AI 開發助手 0307

如果你在上課當天都還沒收到通知郵件，請立即寫信與我們聯繫！🔥