.NET Walker

對多數開發人員而言，GitHub 不僅是一個儲存程式碼的地方，更是一整套開發流程的中樞。從原始碼管理、Issue 討論、Pull Request 協作，到 CI/CD 整合，GitHub 提供了豐富的功能，支援現代軟體開發的各個階段。 這使得 GitHub 一推出 GitHub Models ，立即讓人眼睛一亮。這項功能對開發人員來說，堪稱是一大福音。它提供了多種 LLM（大型語言模型）的介接能力，並且開放免費使用，讓開發者在無需註冊 OpenAI、Azure 或其他雲端服務帳號的情況下，就能快速體驗 LLM 在程式設計與AI Agent 開發的應用潛力。 對於尚在試驗階段，或使用頻率不高的個人或小型團隊來說，這不僅省下了搭建本地模型環境的複雜度與資源消耗，也大幅降低了學習與導入門檻，真正做到「人人都能用 AI 來寫程式」。 如何使用 要使用 GitHub Models 相當簡單，你只需要有 GitHub 帳號(不管是否有付費均可)，即可從底下網址進入 Models : https://github.com/marketplace/models 進入後，先在左上角選擇你想使用的 Model : 你會發現選擇琳瑯滿目，從 OpenAI 系列，到微軟的 Phi-3、DeepSeek、Llama 任君選用。 選擇好之後，你可以在測試區，輸入對談文字測試看看，會看到大語言模型的回應文字： 你還可以按下Compare： 去比較兩款不同的大語言模型，在回應上是否有所不同： 如果要調整 System Prompt、Max Tokens、Temperature 等長用參數，可以在右上方找到。 選擇好你想用的模型之後，如果想要著手開發，可以切換到 Code，這邊可以讓你選擇不同的開發技術，網頁上會依照你的選擇，出現相對應的程式碼範例： 注意，這邊的 API Endpoint 和官方模型有所不同，是唯一你在使用 GitHub Models 時需要調整的地方。 申請 Token 在呼叫該 API時，一樣會需要一個 token。 你可以在底下位置申請： https://github.com/settings/personal-access-tokens/new 進入後找到 Permissions，展開後選擇 Models，將其設為Read-...

最近看到網路上不少人 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 ...