Visual Studio 2026 檔案簽入前的雙重保障

在 AI 協助寫程式已成日常的現在，我們常常會遇到「Copilot 幫我寫了什麼？」、「這段程式碼到底能不能用？」這類讓人不太安心的時刻。好在 Visual Studio 2026 在簽入前加入了兩道檢查機制，讓開發者能在 commit 前快速掌握 AI 產生的程式碼品質。本篇文章會示範這兩項功能如何運作，以及它們如何讓我們在大量依賴 AI 的開發流程中，仍然保有必要的掌控感與信心。

不可否認，即使我們不是使用以 AI 為主的編輯器，日常開發中還是有不少程式碼是完全由 AI（GitHub Copilot）產生的。這些程式碼到底需不需要開發者介入檢查？這件事我和 twMVC 的夥伴在每週四的固定聚會至少討論過兩次。

雙方都有不同觀點，而且各自站在不同角度看都能成立。雖然討論沒有結論，但身為開發者（尤其你還選擇繼續使用 Visual Studio 的話），多少還是會想知道：這次 AI 幫我寫的程式碼品質如何？到底改了什麼？會不會踩雷？

好在 Visual Studio 2026 在簽入前提供了兩道關卡，讓我們能在 commit 前稍微「介入」一下程式碼。

案例示範

假設我們有一段簡單程式，用來搜尋含指定 tag 的文章：

public async Task<IList<ArticleViewModel>> LookupDataAsync(string tagName)
{
    var query = dbContext.Articles.AsNoTracking();
    return query.Where(d => d.Tags.Contains(tagName))
        .Select(d => new ArticleViewModel
        {
            Id = d.Id,
            Title = d.Title,
            Body = d.Body.Substring(0, 100),
            CoverPhoto = d.CoverPhoto,
            CreateDate = d.CreateDate,
            Tags = d.Tags
        })
        .OrderByDescending(d => d.CreateDate)
        .ToList();
}

但如果我們技術能力不夠好，就可能寫成這樣：一開始就 ToList，導致整張表先載入記憶體，再做 Where，效能直接炸裂。

public async Task<IList<ArticleViewModel>> LookupDataAsync(string tagName)
{
    var query = await dbContext.Articles.ToListAsync();
    return query.Where(d => d.Tags.Contains(tagName))
        .Select(d => new ArticleViewModel
        {
            Id = d.Id,
            Title = d.Title,
            Body = d.Body.Substring(0, 100),
            CoverPhoto = d.CoverPhoto,
            CreateDate = d.CreateDate,
            Tags = d.Tags
        })
        .OrderByDescending(d => d.CreateDate)
        .ToList();
}

而且因為本來就技術不足，自己也檢查不出來，就準備要簽入了。

001

簽入前的檢查

在簽入前，你會發現下圖這個位置多了一個圖示：

002

點下去後，Visual Studio 2026 會請 Copilot 幫你分析程式碼是否有問題。分析完成後，如果有建議，就會出現 Copilot 評論註解 的連結。

003

點進去後，就能看到 Copilot 提供的建議。例如下圖第一個建議就是提醒我們：在篩選前就把所有文章載入記憶體是不好的，建議改用 IQueryable 讓篩選在資料庫端完成。

004

如果你想接受建議，把滑鼠移到該區塊就會出現 Copilot 圖示，點一下就能自動套用修正。如果不想採用，也可以點右上角的折疊圖示把建議收起來。

005

目前這部分的建議還沒有中文化，但現在 AI 這麼活躍，語言真的不是問題，所以還好啦 😅

產生 commit log

看完建議後就是要簽入程式碼了。人寫的 commit log 通常都非常精簡，精簡到幾乎沒什麼參考價值。因此我們可以讓 AI 幫忙產生詳細的 commit 註解，只要點下圖的圖示即可：

006

AI 產生的 commit log 就會像這樣，非常完整：

新增 BenchmarkSuite1 專案與文章查詢功能優化
新增 BenchmarkSuite1 專案並加入解決方案組態
HomeController Tags 方法增加條件判斷，調整 Check1/2/3 方法位置
ArticleService 新增 LookupDataAsync 以標籤查詢文章
優化 ArticleService 內 LINQ Select 物件初始化寫法

對我來說，現在 Copilot 代勞寫程式的情境越來越多，但到底這次改了什麼、做了什麼、會影響什麼？以前要看 Code 才知道，現在有這功能我都直接看 commit log，方便又快速。

客製化 Commit log 產生規則

如果你對 commit log 有特定格式要求，或公司規定要用 Conventional Commits，也可以讓 Copilot 依照你的規格產生。只要到：

選項 → GitHub → Copilot → 認可訊息自訂指示 輸入你的規則即可。

至於指示要怎麼打你可以問 AI 這裡提供我目前在用的

- 第一行為不超過 50 字元的單行摘要，開頭請加上類型前綴（例如 feat:, fix:, docs: 等），以簡潔描述此次變更。
- 第二行留空。
- 第三行起為完整描述，說明變更的動機、影響範圍與技術細節。
- 使用正式、技術性的語氣，避免口語或情緒性字眼。
- 使用台灣習慣的用語及名詞，避免使用中國用語與簡體中文。  
- 若有關聯的 issue 或 pull request，請在最後加上 Refs #編號 或 Fixes #編號。
類型前綴請依據以下分類選擇：
- feat: 新功能
- fix: 修 bug
- docs: 文件修改
- style: 格式調整（不影響程式邏輯）
- refactor: 重構（不新增功能、不修 bug）
- test: 測試相關
- chore: 雜項、建置、CI、工具設定

加上規格後再產生一次 commit log，就會變成我們喜歡的樣子：

feat: 增強文章查詢健壯性並新增標籤查詢功能
調整 ArticleService 內文章內容截斷邏輯，避免 Substring 例外，統一於多個查詢方法中實作。新增 LookupDataAsync 方法，支援依標籤名稱查詢文章。HomeController 調整 Tags 方法，於特定條件下設定 ViewBag.Tag 為 "All"，並將 Check1~3 方法移至類別底層。解決方案新增 BenchmarkSuite1 專案並更新組態設定。此變更提升系統穩定性並擴充查詢功能。

demoshop