.NET Walker

隨著 AI 應用在各種開發場景中愈來愈普及，微軟也持續優化 .NET 生態系對 AI 開發的支援。最新釋出的 .NET AI Chat Web App Template Preview 2 ，為開發者提供了一套更加完整且實用的範本，讓使用者可以快速建立支援 Retrieval-Augmented Generation（RAG）模式的聊天應用程式。 🛠️安裝 .NET AI Chat Template 要開始使用這個全新的 AI Chat 範本，只需要透過簡單幾個指令，就能在你的開發環境中安裝並啟用。 首先，請開啟 Terminal 命令列介面，執行以下指令來安裝最新版的範本套件： dotnet new install Microsoft.Extensions.AI.Templates 安裝完成後，你就可以直接使用 .NET CLI 建立新的 AI Chat 專案了。舉例來說，若要在當前目錄中建立一個新的 aichat 專案，只需執行： dotnet new aichatweb 執行後，使用 VS Code 開啟專案，只需要做一些簡單的設定： 在 appsettings.json 中，配置好 你的 GitHub Models Token( 這裡有介紹 )： "GitHubModels" : { "Token" : "github_pat_11AOOOOOOOOOOOOOOOMnB" } 並且在 wwwroot 的 Data 資料夾底下，放入你要進行檢索的 PDF 文件，確定一下你的環境有 .net 9 SDK，接著透過 dotnet run 就可以執行啦。 運行的結果如下： 在出現的畫面中，你可以直接對 PDF 文件進行詢問，系統會依照PDF文件中的內容進行回答，出現的準確度也還算不錯。 隨著 .NET AI Chat Template 的功能越來越完整，開發者現在可以更輕鬆地搭建基於自有資料的智慧聊天應用，不需要繁瑣的部署過程，也無需額外申請複雜的雲端服務。無論是個人實驗、專案原型，還是小型產品開發，都可以快速起步並持續擴展。如果你還沒試過，不妨趁著這次更新體驗看看，相信它會成為你未來 AI 開發流程中不可或缺的一環。 📚 延伸閱讀 .NET AI...

最近看到網路上不少人 vibe coding 與技術債之間的關係，甚至認為它將會等同於是「技術債製造機」。特別在 AI 越來越普及的今天，慢慢有一些開發者開始擔心：『 LLM 將會讓初階開發者更容易產出劣質程式碼，進而拖垮整體專案品質 』。 但這真的是事實嗎？ 我認為 未必 。 工具從來不是問題，關鍵是『人』 首先，我們得承認一件事： 會寫出技術債的開發者，用什麼工具都會寫出技術債。 早年，我們沒有 Google，只能查書或參考學長、前輩們 code 的寫；後來有了 Stack Overflow，我們學會了複製貼上；如今換成了 LLM，連搜尋都省了，直接叫 AI 生成就有範例可以參考。 這些方式起來可能都「有點草率」，甚至「有些不專業」，但我們也必須正視一個事實： 開發人員的成長曲線，本來就包含大量模仿與嘗試錯誤的過程。 很多今天能獨當一面的工程師，都是從這樣的方式走過來的。工具從來都不是問題，真正的問題 是你怎麼用它 。 會亂用工具的人，即使給他的是超強 IDE，他也能寫出災難；但會自主學習的人，哪怕用的是 AI，也能學得更快、做得更好。 技術債的真兇，不是 AI，是 落後流程 那照上面這樣的說法， AI 是不是依舊有可能會讓初階工程師更快產出「不嚴謹」的程式碼，進而在團隊中埋下大量的技術債呢？ 這個問題的假設前半段可能對，但後半段則離道甚遠。 AI 確實讓開發速度加快，但這就代表技術債會快速增加嗎？不一定。 因為真正能預防技術債的從來就不是「人」，而是「流程」。 一個成熟的軟體專案，理應早已建構有良好的 CI/CD Pipeline，並在其中配置自動化的程式碼品質檢查工具，例如 SonarQube、Checkmarx、ESLint 等，可以在自動化流程中，輕鬆地幫我們掃瞄出類似底下這樣的技術債或安全性報告，讓開發人員即時進行改善(參考 這裡 )： 甚至，現在我們還可以導入 GPT-4o、Claude 等 LLM，針對 Pull Request 的 Code Changes 自動執行語意層級的程式碼分析與品質建議。(參考我 這邊 的貼文) 也就是說， AI 能讓「開發變快」，同時也能讓「品質監控變更快」。 只要團隊有紀律地執行這些流程，vibe coding 所產生的技術債，根本無法長存於系統當中。甚至開發者還能透過每日的掃描...

過去我曾介紹過 在 Azure DevOps 中，使用 LLM 進行 code review 以及程式碼品質掃描(在 [here] & [here] )，得到許多回響，有不少朋友問，是否在 GitHub Repo 中也可以? 答案是…當然可以！ 透過 GitHub Actions，我們可以輕鬆整合 OpenAI API 或其他大型語言模型（LLM）服務，打造出自動化的程式碼審查流程。這不僅能協助團隊在每次 Pull Request（PR）時即時分析程式碼品質，還能提供風格建議、安全性提醒，揭露潛在的技術債，使得 AI code review 不再只是理想，而是落地實踐的 DevOps 一環。 要實現這個功能，我們只需要幾個關鍵步驟，即可在 GitHub 的 PR 流程中，部署一個基於 LLM 的程式碼品質掃描機制。 首先，建立一個 GitHub Action workflow，觸發時機設定為 pull_request 。接著，我們可以撰寫一個 yaml 腳本，在 PR 被觸發時，讀取變更的程式碼(commit changes)並送出給 LLM API（例如 OpenAI 的 GPT-4）。最後，將分析結果格式化為 comment，自動撰寫在 PR 回覆中，讓開發者即時收到建議。 我們先來看執行的效果。 底下 repo 中原本有一段程式碼，是計算BMI用的： public void OnPost ( ) { if ( Weight . HasValue && Height . HasValue && Height > 0 ) { Height = Height / 100 ; // Convert height from cm to m BMI = Weight / ( Height * Height ) ; } } 我在分支中將其修改如下，請注意，其中有很多明顯的bug和不當的寫法： public void OnPost ( ) { if ( Weight . HasValue && Height . HasValue && Height ...