.NET Walker

來看看這張圖發生了什麼事情? 沒錯，我們正在VS Code當中，使用 GitHub Copilot Agent Mode，透過自然語言的方式，查詢Azure DevOps中的工作項(WorkItems)。 其實，不僅僅可以查詢，也可以檢視細節、甚至新增、修改。範圍也不只有 WorkItems ，還包含 Pipeline 的觸發、PR的建立或PR Comment的新增…等，全部都可以透過自然語言來進行。 而這些，全都拜MCP所賜。 關於MCP 你大概聽說過 MCP，它是 Anthropic 提出的一套開放式標準協議（Model Context Protocol） ，旨在讓大型語言模型（LLMs）可以安全、模組化、可擴充地存取外部工具和資料來源。 簡單來說，你可以把 MCP 想像成 AI 世界中自然語言對談機器人對外的接口，像是我們寫程式的時候，可以透過 API 來串接外部系統， MCP 就是大語言模型對外「運行指令與資料交換」的標準協議 。 不同的是，傳統 API 是設計給 開發者 來用的，強調結構化資料、明確定義與嚴謹的格式；但 MCP 是設計 給大語言模型用 的，它理解自然語言、懂語意、會參考上下文。MCP 的設計讓模型能夠和用戶在以「對話的方式」溝通時，依照用戶的命令與外部系統互動，但底層其實還是透過 function calling 的概念與結構化的 JSON 交換資料，只是這一切都被封裝得更自然、更貼近人類使用者的自然語言。 如同上面你看到的，大語言模型透過 MCP，可以自動呼叫 Azure DevOps 系統的API，查詢資料、比對欄位、下指令修改狀態，整個流程就像是你請了一位懂 DevOps、又能聽懂人話的數位助理。 底下是新增一個 bug 單的例子： 這正是 MCP 的魔力： 讓大語言模型從資訊生成者，進化為任務執行者 。這背後不只是一個協議，而 是未來開發體驗的轉變 。未來開發者不再只寫程式，而是設計如何與 AI 協作；工作流程不再只是「使用工具」，而是「 與工具對話 」。 如何實現? 作法比想像的簡單超級多，由於最新版的 VS Code 和 GitHub Copilot 已經支援 MCP，所以你只需要確認你是在 Agent Mode(下圖一)，然後在專案工作區的 .vscode 資料夾中，置入一個 mcp.json 檔案...

圖片來自於孫運璿科技．人文紀念館 我一直很喜歡參觀古人的故居。 每次走進那種低調安靜的宅邸，最吸引我的，不是家具擺設，而是那些手寫的日記本。 像是在張學良故居看到他被幽禁時寫下的心情紀錄，或是在孫運璿的紀念館裡，看見他密密麻麻記錄每日行程與思考。那些筆跡，有時草率、有時端正，但都誠懇真實，像是他們用一種不對外的方式，試圖整理當天的得失與迷惘。 當時我就在想，這種「每天花一點時間檢視自己」的習慣，似乎是早些年來古人自我進化的方式? 有次，我們的系統在午間出現異常。 某個服務負載暴增，導致對外 API 幾乎停擺。 還好有同仁臨機應變，緊急調整參數、加上快取，才把系統救了回來。當天下午，大家在Teams 上一片感謝與稱讚：「反應太快了！」「厲害！」「幸好有你！」 然後，事情好像就這樣告一段落了。 但讓我印象很深的是——沒有人再回頭問：「為什麼會出問題？」 更沒有人提：「我們下次該怎麼避免這件事？」 這不是第一次，也不會是最後一次。 很多團隊都有個像是默契般的傾向： 只看事情怎麼解決，卻不去問事情為什麼會發生。 表面上看起來是一種積極正向的態度，但其實正是這種「避談錯誤」的文化，悄悄地讓我們錯失最寶貴的反省機會。 我一直很認同一句話：「寫出 bug、系統出錯、都沒關係，重點是團隊有沒有從中學到什麼?」每個迭代後的 Retrospective，才是團隊讓自己成長的機會。 很多古人有寫日記的習慣，不是為了記錄流水帳，而是每天逼自己回顧、和自己對話、幫自己成長。 曾國藩日課四條，日日記錄得失；朱熹、顧炎武、王陽明……這些歷史上的思想家，都透過日記整理自己的人生狀態和判斷標準。 這在今天看來，和我們寫技術筆記、開 retrospective會議，或是 incident postmortem，是如出一轍。 真正讓團隊變強的，不是「沒出錯」，而是「出了錯，敢講出來，能夠面對，願意修正。」 所以，當我們在 postmortem 或 retrospective 中回顧那些「差點出事但救回來」的案例時，可以多問一句：「這次為什麼會這樣？我們下一次可以怎麼避免？」retro，不是為了指責誰，而是為了讓我們不需要再依賴運氣。 這樣的文化，才會讓一個團隊真的進步； 這樣的思維，才會讓一個工程師真正成長。 參考 課程： 敏捷開發與Azure De...

最近在上課時，為了讓不想花錢申請 Azure 雲端服務的學員，也能夠實際體驗 CI/CD 的開發流程，我一直在尋找一個 免費、簡單 的網站部署的平台。希望用戶只要有 GitHub 帳號，就能將 repo 內的網站經由 GitHub Actions 自動佈署到雲端。 試過幾個方案之後，最後選擇了 Render.com 。它不但提供免費的靜態網站託管，還能輕鬆與 GitHub 整合，自動化部署流程幾乎沒什麼難度，非常適合教學與初學者練習使用。 什麼是 Render.com Render.com 是一個現代化的雲端平台，提供簡單、快速且免費的網站服務。​透過與 GitHub 的整合，開發者可以輕鬆地將靜態網站自動部署到 Render，並利用 GitHub Actions 進行持續整合與部署（CI/CD）。 Render 支援多種服務類型，包括： 靜態網站（Static Sites） ：​適用於 HTML、CSS、JavaScript 等前端資源，透過全球 CDN 提供快速、安全的內容傳遞。 Web 服務（Web Services） ：​支援 Node.js、Python、Ruby 等後端應用程式的部署。(但不支援 .net) 私有服務（Private Services） 、 背景工作（Background Workers） 、 排程任務（Cron Jobs） ：​適用於內部服務、非同步處理及定時任務。 如何從 GitHub 部署靜態網站到 Render Render 本身直接支援自動化佈署，你可用 GitHub 帳號申請Render.com ，並且直接建立一個靜態網站： 你可以在建立站台的時候，直接選擇要從哪一個 GitHub Repo 進行佈署: 在選擇好後，你可以配置該網站關聯的資料來源位置(選擇Repo中的資料夾): 設定完成之後，只需要一鍵就能佈署完成： 如果要變成自動化呢? 我們可以在 GitHub Repo 中設定 Action，來進行網站的自動化佈署。 由於Render.Com 提供一個自動化佈署的 WebHook(本質上就是一個API)，只要呼叫該API， Render.com 就可以自動從 GitHub repo 中取得最新的程式碼，並且佈署到伺服器端： 也因此，只要我們為其配置一個 GitHub Acti...

對多數開發人員而言，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-...