GitHub Copilot Sentry Canvas 怎麼修線上崩潰？2026 教學

Agent 依照堆疊產生了補丁，卻無法在對應發布版本重現崩潰：這種情況下，最快解法不是立即合併，而是先把 GitHub Copilot Sentry Canvas 限定在只讀調查，再用隔離工作區、CI、真實運行環境和人工審批完成修復閉環。適用於希望縮短定位時間、但不能放寬生產變更門檻的團隊。

最後更新：2026 年 9 月 19 日；資料核實自 GitHub 於 2026 年 9 月 18 日的 Copilot 更新、Copilot app 官方文件、Canvas 擴充功能文件及 Agent session 文件。

先把「分析更快」與「問題已解決」分開

GitHub Copilot Sentry Canvas 的價值，是把錯誤上下文、程式碼調查、驗證工作和修復任務放到同一個工作面。GitHub 在 2026 年 9 月 18 日 的更新中確認，Copilot app 新增 Sentry Canvas，可查看錯誤、堆疊及相關上下文，並協助調查、驗證修復和準備 Pull Request。GitHub 更新說明

但你不能把它當成自動發布系統。Canvas 不會替你證明根因，也不會因為 PR 已建立、測試變綠或錯誤不再出現，就取得生產發布資格。生產日誌、程式碼倉庫、CI 和發布系統仍要各自保留權威紀錄。

這篇適合三類讀者：

• 維護線上 Web、後端或桌面應用，希望縮短崩潰定位時間的開發團隊。
• 負責 Copilot 權限、程式碼倉庫和故障資料連線的平台工程師。
• 需要在 Xcode 或真實 macOS 環境重現崩潰的 iOS、macOS 與 Mac 應用團隊。

試點前：先保存原有事故處理基線

不要從仍在擴大的生產事故開始第一次聯調。先挑一個已解決、可以安全重放的 Sentry 事件，並保存目前流程的證據：

1. 告警何時進入團隊的事故流程。
2. 誰完成初步定位，使用了哪些日誌、堆疊和版本資料。
3. 修復分支如何建立，做過哪些測試。
4. 哪個 reviewer 批准合併，發布後如何確認結果。
5. 原流程中等待、返工和環境占用發生在哪些位置。

這裡的目的不是先證明 Copilot 更快，而是避免用主觀印象比較。你要把「定位完成」定義成有受影響版本、可重現條件和證據鏈的狀態，而不是一段看似合理的模型解釋。

試點樣本應同時保留 Sentry 事件識別、發布版本、提交雜湊、環境標籤、原始堆疊和最後修復提交。若這些資料在原流程已經互相對不上，先修正事故記錄，再接入 Canvas。

第一階段：從 Copilot app 建立最小權限連線

從 GitHub Copilot app 的 Customize 區域確認 Sentry Canvas 是否對你的帳號和組織可見；安裝入口以 Copilot app 自訂官方文件 為準，不要依照截圖或社群貼文自行猜測按鈕位置。

首輪連線只處理「看」：

• 允許查看錯誤、堆疊和必要的相關上下文。
• 暫不把程式碼寫入、外部命令執行和網路存取視為預設權限。
• 保存帳號、倉庫、專案與權限範圍的截圖或管理記錄。
• 記錄誰批准連線、試點使用哪個事件，以及何時撤銷。

Canvas 擴充功能的機制與可用能力，應以官方 Canvas 擴充功能文件為準。文件沒有說明的資格、授權範圍、資料同步方式或功能狀態，不應由你從「看得到」推論成「可以改得到」。

若連線關係無法解釋，例如不清楚哪個帳號取得哪個專案的資料，立即停止試點。這不是延遲部署，而是避免把事故資料、私人程式碼和未批准的執行能力混在同一個工作面。

第二階段：把首次調查寫成可重現任務

連線完成後，讓 Copilot 根據 Sentry 事件整理三類內容：

• 可能受影響的程式碼範圍。
• 原始崩潰的復現假設。
• 還缺少哪些版本、環境或輸入證據。

你要把這些內容標記為「模型分析」，不要寫成「根因已確認」。接著逐項核對：

• 發生錯誤的發布版本，是否與目前檢出的提交一致。
• 發布批次、環境標籤和原始堆疊，是否指向同一制品。
• 符號檔或診斷記錄，是否能讓行號和函式名稱可信。
• 測試資料是否真的觸發原始路徑，而不是只通過一條相似流程。

Apple 對崩潰報告與診斷日誌的取得方式有自己的記錄要求；涉及 iOS 或 macOS 時，應同時保存Apple 官方崩潰報告文件所涉及的原始資料，而不是只保留 Canvas 摘要。

一個常見的失敗案例

某團隊讓 Agent 依照堆疊改動錯誤處理流程，PR 很快建立，靜態檢查也沒有報錯；但團隊拿不到與線上相同的發布制品，無法重現原始崩潰。此時「補丁已產生」只代表程式碼工作已開始，不代表修復成立。

正確下一步是把任務標記為待調查，補齊版本、制品和輸入條件。若受控環境仍無法重現，就先停止要求 Agent 生成更多補丁，否則每一輪猜測都會增加返工和審查負擔。

第三階段：把程式碼修改移入隔離工作區

當事件、版本和復現假設可以對上，才進入修改階段。修復必須在獨立分支、Git worktree 或受控執行環境中完成，不能讓事故對話直接驅動主工作區。

你需要保存四類記錄：

1. Agent 修改了哪些檔案，以及每個檔案的理由。
2. 執行過哪些命令，命令是否改變依賴或產制品。
3. 依賴、建置設定和環境變數有沒有變化。
4. 哪些測試通過、哪些測試未執行，以及未執行原因。

GitHub 的 Agent session 文件可用來理解工作階段與產物管理方式，但不要只依賴聊天摘要交接。人工接管時，工程師應能從工作區、提交、命令紀錄和測試結果重建 Agent 做過的事。

涉及 iOS、macOS、桌面應用或平台相依套件時，把修復分支放到具備對應工具鏈的隔離雲端 Mac。這一步不是為了讓 Agent「看起來像在 Mac 上工作」，而是要在實際 macOS、Xcode、簽署設定和依賴條件下驗證。若你正在整理遠端執行環境，可先參考 kvmsync 的遠端環境說明，再按你的專案政策限制存取範圍。

第四階段：用兩層驗證決定能否提交 PR

第一層是確定性檢查：

• 單元測試覆蓋原始錯誤條件。
• 回歸測試確認正常流程沒有被改壞。
• 靜態分析、格式檢查和依賴檢查完成。
• 建置輸出與預期目標一致。

第二層是接近線上的真實環境驗證。你要使用與事故版本相符的執行環境，重跑原始崩潰路徑；Mac 應用和 Apple 平台專案還要完成真實 Xcode 建置、測試及制品檢查。單靠 Copilot 建立的 PR、測試變綠或錯誤暫時消失，都不足以證明根因已解決。

PR 應保留人工 reviewer、分支保護和既有合併門禁。GitHub 對受保護分支的官方說明可作為門禁設定的參考；Agent 的風險與人工控制邊界，則應一併核對官方 Agents 負責任使用指南。

何時必須停止或回退

出現以下任一情況，就不要把任務推進到自動化修改：

• Sentry 事件與當前制品或發布版本對不上。
• Agent 把無關檔案納入修復，卻不能說明理由。
• 復現只在模型描述中成立，受控環境無法重演。
• 測試通過，但沒有測到原始崩潰路徑。
• 權限從只讀變成可寫入，卻沒有新的批准記錄。
• 你無法從事件、會話、提交、CI 到運行結果建立連續證據。

回退不等於放棄工具。你可以把 Canvas 留在只讀分析模式，待版本、權限或環境問題修正後再重試。

第五階段：首週用證據決定擴大、限量或退回只讀

試點完成後，不要用生成程式碼量衡量效果。應比較原流程與新流程的：

• 從告警到初步定位的等待時間。
• 復現成功率與無法復現的比例。
• Agent 產生的無效修改輪次。
• 人工返工、審查和環境占用。
• 事件、Copilot 會話、程式碼提交及發布記錄是否一致。

這些指標要放回同一事故類型和相近複雜度中比較，否則容易把簡單事件的改善誤認為工具能力。第一週只要出現權限漂移、事件誤關聯或真實環境不可重現，就回到只讀分析；只有代表性事故穩定通過復現與回歸，才擴展到更多倉庫。

用這張表決定下一步

完成只讀試點後，你可以再閱讀 kvmsync 的 AI 開發文章，把隔離工作區、Agent 交接和雲端 Mac 驗證納入同一套團隊流程。若要評估臨時測試環境的租用方式，可查看 kvmsync 的方案頁，但先以專案工具鏈、資料隔離和回收流程是否符合要求為準。

常見問題

GitHub Copilot 怎樣讀取 Sentry 崩潰報告並協助定位？

先由 Sentry Canvas 提供錯誤、堆疊與相關上下文，再讓 Copilot 整理受影響程式碼範圍、復現假設及待補證據。你仍要核對版本、發布批次、環境標籤和原始堆疊；模型提出的根因只是調查線索，不是已證實的結論。

Sentry Canvas 可以直接改程式碼並建立 Pull Request 嗎？

官方資料顯示，它可協助調查、驗證修復及準備 Pull Request，但這不代表具備自動部署或生產發布授權。程式碼寫入、外部命令、網路存取及合併仍須按你的組織政策另行授權，並保留 CI、人工 reviewer 和分支保護。

在 Copilot 修復線上錯誤前，團隊應先開放哪些權限？

第一輪只開放查看錯誤、堆疊和必要上下文的最低權限，並記錄帳號、倉庫、專案及權限範圍。若無法說明資料如何流動，或發現寫入、命令執行和網路存取被一併開啟，應停止試點，回到只讀分析。

iOS 崩潰要怎樣放到遠端 Mac 環境重現？

先鎖定與線上版本相符的提交、依賴、符號檔和建置設定，再把修復分支放入隔離的雲端 Mac。於真實 macOS 與 Xcode 工具鏈中重跑原始路徑，保存建置、測試、制品和命令紀錄；只在聊天視窗中重現並不足以驗收。

Sentry 產生的修復建議還需要人工審核嗎？

需要。人工 reviewer 要比對原始事件、補丁範圍、回歸測試和實際運行結果，確認沒有把錯誤隱藏、改動無關流程或只修正測試。PR 建立、測試變綠或錯誤暫時消失，都不能單獨證明根因已解決。

如果你目前的流程是直接把生產倉庫交給 Agent，常見缺點是權限邊界難以追蹤、崩潰版本未必能在同一環境重現，而且人工審查容易被「PR 已建立」的表象取代。相較之下，租用 kvmsync 的雲端 Mac 作為可回收的隔離驗證環境，能讓你在保留原有 CI、分支保護和人工批准的前提下，針對 Apple 平台工具鏈完成真實建置與復現；它不適合長期固定重負載或必須直接連接實體設備的工作，但很適合先完成一次受控的修復驗證，再決定是否擴大部署。