對於開發 .NET 專案的工程師來說，最令人沮喪的時刻莫過於 CI 流程突然變紅，或是原本 8 秒能跑完的編譯，今天突然變成 40 秒，而你必須在成千上萬行的 MSBuild 輸出文字中尋找那唯一一行關鍵錯誤。
要徹底解決這些問題，最權威的證據就在二進位日誌檔 binlog 中。binlog 記錄了編譯過程中的每一個專案、目標（Target）、任務（Task）、屬性與診斷資訊。然而，傳統分析 binlog 需要開啟獨立的檢視器，且開發者必須對 MSBuild 的內部運作非常熟悉才能快速定位問題。
為了簡化這個過程，微軟推出了 MSBuild Binlog Analyzer for VS Code 擴充功能，將 AI 分析能力直接整合進編輯器中。
從偵探工作到對話式分析
這款工具的核心理念是將繁瑣的日誌挖掘工作交給 GitHub Copilot Chat。開發者不再需要手動滾動日誌尋找 NuGet 還原失敗的雜訊，而是可以直接詢問為什麼編譯失敗，或是哪些部分導致編譯變慢。
這種分析方式解決了幾個實務上的痛點。首先是根因分析，AI 能直接給出白話的錯誤原因，並允許開發者在 VS Code 中一鍵修復。其次是效能瓶頸定位，工具會自動對最慢的目標與任務進行排序，並標記出決定整體編譯時間的關鍵路徑（Critical Path），讓開發者知道優化哪裡才真正有效。
最後是增量編譯（Incremental Build）的驗證。開發者常懷疑為什麼某些專案明明沒改動卻被重新編譯，透過此工具可以明確得知哪些目標被觸發重建及其原因，而不需要憑感覺猜測。
技術底層：MCP 協定與 AI 的結合
這款擴充功能的強大之處在於它並非讓 AI 憑空猜測，而是透過 Model Context Protocol (MCP) 協定來運作。MCP 是一種允許 AI 模型安全地存取外部工具與數據的標準協議。
在底層，該擴充功能搭配了一個 .NET 全域工具伺服器 Microsoft.AITools.BinlogMcp。當開發者在聊天視窗中使用 @binlog 指令時，Copilot 會調用該伺服器提供的數十種分析工具來讀取實際的 binlog 數據。這種將 AI 與結構化數據結合的機制，確保了 AI 給出的答案是有據可依的，而非幻覺。
實務功能與工作流
在日常開發中，這套工具提供了多個維度的分析視圖。Binlog Explorer 提供側邊欄樹狀圖，讓開發者一眼看出專案結構、錯誤與警告分佈。而 Build Comparison 視圖則允許開發者將目前的編譯與基準線（Baseline）進行對比。
當編譯時間增加時，狀態列會直接顯示百分比增長。例如，如果 CoreCompile 階段增加了 14.7 秒，開發者可以將此回歸現象直接交給 @binlog 分析。AI 可能會分析出這是一個冷啟動（Cold-start）導致的首次編譯成本，而非程式碼本身的問題，這將分析從單純的數字提升到了具備上下文的解答。
此外，該工具還整合了 CI/CD 流程，可以直接從 Azure DevOps Pipelines 或 GitHub Actions 下載對應分支或 PR 的 binlog 進行分析，避免在瀏覽器與 IDE 之間頻繁切換。
總結與建議
對於 Junior 工程師來說，理解 MSBuild 的複雜生命週期需要時間。MSBuild Binlog Analyzer 將原本需要經驗累積才能完成的日誌分析，轉化為可對話的知識庫。它不僅縮短了修復錯誤的時間，更重要的是讓開發者能透過 AI 的解釋，學習如何分析編譯效能與診斷 MSBuild 的行為。
若要開始使用，需準備 VS Code 1.99 以上版本、GitHub Copilot 以及 .NET SDK，並從 Marketplace 安裝該擴充功能。
來源：devblogs.microsoft.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。