摘要： GitHub 於 2026 年 9 月 10 日說明 Copilot app 的 diff、終端機與瀏覽器面板，可在同一應用內審核 agent 變更、執行專案並檢查 UI。建議的檢查順序是什麼變了、能否執行、行為是否符合預期；文章也提醒面板解決的是檢視位置，不代表審核品質自動提升。
一項由 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
確認完成後，接受變更與建立 pull request 都能直接在 Copilot app 內進行。整條流程——看 diff、在終端機啟動專案、在瀏覽器檢查、來回迭代——全部集中在同一個地方，既不必切換分頁或應用程式，也不會因為跳出去而弄丟原本的判斷脈絡。
有一個容易被忽略的取捨：把工具收進同一個介面，降低的是切換成本，但審核品質不會因此自動提升。diff 面板只呈現差異，是否理解差異依舊取決於你；終端機面板只負責執行，指令對不對仍要自己判斷。面板解決的是「在哪裡看」，不是「看不看得懂」。
如果你正在導入 agent 協助開發，這種把驗證步驟內建到工作介面的做法，和結構化資料擷取工具該先看層級再看可驗證性的邏輯相近：工具再順手，最後仍要有人能驗證產出。實務上的下一步很簡單——下次 agent 交出改動時，別急著按接受，先依序走完 diff、執行、瀏覽器這三關。