當 agent 改完一段程式碼，你真正要回答的其實只有三件事：改了什麼、跑不跑得起來、功能對不對。過去這三件事分散在編輯器、終端機視窗和瀏覽器三個地方，來回切換本身就是一種成本。GitHub 在 2026 年 9 月 10 日發布的入門說明指出，現在這三個動作可以在 GitHub Copilot app 內完成，不必離開應用程式。
三個面板各自負責一個問題
diff 面板處理「改了什麼」。它把新增、刪除與修改的行標示出來，新增以綠色、刪除以紅色呈現。看到差異之後，你可以接受變更、留下註解，或請 Copilot 再調整。GitHub 的說法是使用者保有最終決定權。
終端機面板處理「跑不跑得起來」。指令直接在 session 內執行，GitHub 特別提到多數情況只是跑專案自己的指令並讀結果，不需要把它當成什麼高門檻工具。除了手動執行，也可以設定成 script，透過 Run 按鈕觸發。文中以網站專案為例：加入開啟 client 資料夾並執行 npm run dev 的 dev server script，按 Run 啟動伺服器。終端機可以同時開多個視窗切換。
瀏覽器面板處理「功能對不對」。只要改動涉及使用者介面，就能在面板內開啟並實際操作新功能。想繼續調整時，Pick & Polish 工具可以選取頁面元素，再交給 agent 修改；改完重跑 dev server script 就能看到結果。
為什麼「同一個視窗」比想像中重要
這三個面板的價值不在於功能本身有多新，而在於它們把審核變成一個連續動作。當 diff、執行結果與畫面並排存在，你可以在同一個脈絡裡判斷 agent 的產出，而不是先記住某個差異、切到終端機、再切到瀏覽器確認。GitHub 的描述是：review、run、preview 並排，讓 agent 做出的改動「感覺安全而不是可怕」，因為你能證明即將合併的東西真的會動。
對剛開始用 coding agent 的人來說，這其實是一份可操作的檢查清單。GitHub 建議在按下接受之前固定問三個問題：什麼變了？它跑得起來嗎？它真的有用嗎？這三個問題的順序也合理——先看差異，再驗證執行，最後確認行為符合預期。
從審核到開 PR 的收尾
確認完成後，可以直接在 Copilot app 內接受變更並建立 pull request。整條流程——看 diff、在終端機啟動專案、在瀏覽器檢查、來回迭代——都在同一個地方完成，不用切換分頁或應用程式，也不會因為跳出去而失去原本的判斷脈絡。
這裡有一個容易被忽略的取捨：把工具收進同一個介面，降低的是切換成本，但不會自動提升審核品質。diff 面板只呈現差異，是否理解差異仍然取決於你；終端機面板只負責執行，指令對不對仍要自己判斷。面板解決的是「在哪裡看」，不是「看不看得懂」。
如果你正在導入 agent 協助開發，這種把驗證步驟內建到工作介面的做法，和結構化資料擷取工具該先看層級再看可驗證性的邏輯相近：工具再順手，最後仍要有人能驗證產出。實務上的下一步很簡單——下次 agent 交出改動時，別急著按接受，先依序走完 diff、執行、瀏覽器這三關。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。