如何在 VS Code 中繼續 GitHub Copilot App 的對話工作階段

從 AI 輔助到人工精修，不必中斷

GitHub 近日發布教學指南，說明開發者如何把 GitHub Copilot App 裡的工作階段，直接轉到 Visual Studio Code 繼續做。這項功能要解決的是開發流程中的斷點：AI 代理程式完成大部分程式碼變更後，開發者還是得做最後的程式碼審查、除錯與本地測試。開發者不必在留在對話應用程式裡與到編輯器重新開始之間二選一；原有的對話紀錄、程式碼變更內容和工作上下文都能完整保留，從 AI 輔助編碼接到人工精修，中間不必斷開。

前置準備與工作階段轉移

開始之前，開發者需要先安裝並登入 GitHub Copilot App，VS Code 也要安裝好，並連線到同一個 GitHub 帳號。此外，必須有一個包含程式碼變更的 Copilot App 工作階段，而且開發者要有該工作階段對應儲存庫的權限，才能修改與推送。教學假設開發者已熟悉 VS Code 的導覽、整合終端機操作，以及 Git 分支與拉取請求（Pull Request）的基本流程。

首先，在 Copilot App 中開啟想繼續的工作階段。交出控制權之前，建議先看過任務內容與 Copilot 已完成的部分。工作階段裡不只有修改過的檔案，還記錄了任務目標、計畫，以及產生這些變更的對話歷史。這些上下文對理解 AI 的實作邏輯很重要，而且不用手動摘要，也不用把歷史記錄複製到新的聊天室，就能直接轉移。

接著，在工作階段中選擇「在 VS Code 中開啟」。如果系統偵測到多個支援的編輯器或安裝版本，開發者要選定想用的 VS Code 實例。VS Code 會開啟與該工作階段關聯的工作樹（worktree），並在 Copilot 側邊欄顯示現有的工作階段。這樣會連接三樣東西：保留原始任務、計畫與對話的上下文、可逐行檢視的程式碼差異（diff），以及與工作階段相同的隔離工作樹。也就是說，開發者是在延續現有的工作階段，而不是在編輯器視窗裡重建一次。

程式碼審查與本地測試

進入 VS Code 後，開發者可以從「原始碼控制」檢視（Source Control view）檢查程式碼差異，逐行審查檔案。審查時應當作處理其他建議變更一樣：確認程式碼是否解決了所提出的問題、是否遵循儲存庫的慣例、是否妥善處理錯誤狀態與邊緣案例，測試是否涵蓋變更後的行為，以及有沒有改到無關的檔案。如果對實作細節有疑問，可以直接在側邊欄繼續向 Copilot 提問，例如問某個函數為什麼這樣改、可能有什麼影響。由於工作階段與工作樹保持連接，開發者不必重新描述任務，就能要求 AI 繼續修改。

有些細節需要手動調整，例如修改標籤文字、變數命名、樣式，或補測試案例，開發者可以直接在 VS Code 裡編輯檔案。這些手動變更會直接疊在 AI 的成果上，不必複製檔案，也不必手動重建分支。編輯完成後，可以用 VS Code 的整合終端機跑專案的驗證流程。具體指令取決於儲存庫設定，例如網頁應用程式可能有特定的測試指令。開發者應把 AI 產生的變更當成人工寫的程式碼來對待：執行相關測試、檢查失敗原因，並自行驗證行為。如果開發伺服器提供 localhost URL，在 VS Code 設定支援的情況下，可以用 VS Code 的整合瀏覽器直接在編輯器內測試，並確認介面變更在不同視窗大小與各種狀態下的表現。

提交變更與持續互動

開發過程中，互動方式可以自己選：變更需要全域分析或重複編輯時，就提示 Copilot；明確知道要改什麼時，就直接編輯；測試與修飾階段也可以兩種方式交替使用。例如手動調整介面後，可以要求 Copilot 為更新後的標籤新增測試並執行，同時確保不修改無關元件。因為仍在原本的工作階段中，Copilot 知道「更新後的標籤」指的是什麼。

實作準備好之後，開發者應再看一次最終的程式碼差異，然後透過「原始碼控制」檢視或整合終端機提交並推送變更，指令包括 `git status`、`git add`、`git commit -m "Refine session changes"` 和 `git push`。由於 VS Code 開啟的是與工作階段關聯的工作樹與分支，推送分支就會自動更新追蹤這項工作的拉取請求。開發者不必把完成的檔案複製到其他簽出位置，也不必手動把工作和拉取請求重新連起來。

這套工作流程的分工很清楚：Copilot 負責較大或重複性的實作任務，開發者則在編輯器裡做詳細審查、針對性修改、本地測試與最後修飾。工作階段、程式碼差異與工作樹會跟著開發者移動：先在 Copilot App 中指導工作，再切換到 VS Code 手動控制，最後透過同一個拉取請求流程推送完成的結果，讓開發過程保持連續。