.NET Walker

在開發 LINE Bot 的 AI Agent 或客服機器人時，最重要的功能之一就是 記憶 。 使用者永遠會預期機器人應該要能「記得上一句話」，並能依照上下文繼續對話。 在 Semantic Kernel 中，提供了 ChatHistory 物件來維護對話脈絡。這個物件會記錄 system / user / assistant 的訊息序列，當傳給大語言模型 (LLM) 時，就能讓模型在上下文中產生更自然的回覆。 但是，有一個問題： LINE Bot 的 Webhook API 是 Stateless 的 ，這意味著，每一次訊息事件進來，Controller 都是新的，不會自動幫你保存之前的 ChatHistory 。 因此，如果我們要讓 Semantic Kernel 記住對話，就需要額外設計一個「記憶儲存機制」。 短期記憶的解決方案：MemoryCache 方法有很多，但如果你的應用場景是： AI Agent / QA 客服 一次對話通常會在 半小時內結束 這時候就不需要複雜的資料庫，只要使用 .NET 內建的 MemoryCache 就能搞定。 MemoryCache 的特點 存放在伺服器記憶體中 可以設定 滑動到期時間 (SlidingExpiration) → 長時間沒互動就清掉 可以設定 絕對到期時間 (AbsoluteExpiration) → 即使一直互動，最多存活多久(避免高費用或token爆掉) 效能快。但也因為是存放在伺服器端記憶體中，應用程式重啟或多台伺服器作HA架構時，資料會消失，重新佈署應用程式時，也會消失。 還算是適合「短期記憶」的應用場景。 專案架構 底下示範如何在 LINE Bot WebAPI 專案中，整合該機制，我們建立了三隻程式： Controllers/LineBotChatGPTWebHookController.cs （處理 LINE Webhook） Controllers/ChatCompletion.cs （使用Semantic Kernel 生成 AI 對話） Controllers/ChatHistoryMemoryStore.cs （短期對談記憶保存） 完整程式碼我放在: https://github.com/isdaviddo...

程式碼的世界裡，有一個古老的爭論： 大括號 { 到底該放在同一行，還是獨立成一行？ 這不只是排版問題，有時甚至會演變成團隊會議上的「宗教戰爭」。而我自己也有喜歡的 indent style ，如果看到團隊中其他人的寫法和我不同，雖不至於惱怒，但總覺得有些彆扭。有一種衝動很想把它全部改成自己習慣的方式。 你大概可以想像，當有一天，我發現 VS Code 升級到新版之後，排版和對齊方式竟然變成和我喜歡的不同，那時候我有多麼的震驚，一整天都想要把它給改回來。 怎麼做? 今天我們就來談談，如何在 VS Code 裡改設定，讓 { 的排版聽話。 兩種常見風格 先來看看範例： 1. K&R （大括號跟在同一行） public class HelloWorld { public void SayHello ( ) { if ( true ) { Console . WriteLine ( "Hello, world!" ) ; } } } 2. Allman Style（大括號獨立一行） public class HelloWorld { public void SayHello ( ) { if ( true ) { Console . WriteLine ( "Hello, world!" ) ; } } } 先問問，你喜歡哪一種? 各自的優缺點 同一行風格 (K&R) ✔ 節省垂直空間，檔案比較短。 ✔ 很多 C# 官方範例和文件都是這種格式。 ✘ 有人覺得程式「擠在一起」，閱讀時容易忽略最末端的 { 。 獨立一行風格 (Allman) ✔ 大括號醒目，結構一眼就能看出來。 ✔ 不容易漏掉對應的 { 與 } 。 ✘ 程式會「莫名變長」，多佔好幾行。 👉 簡單說：前者像極簡主義，後者像穿寬鬆衣服，空間感十足。 你是哪一派呢？ 在 VS Code 裡如何調整？ 方法一： .editorconfig （推薦） 在專案或解決方案根目錄新增 .editorconfig 檔案： root = true [*...

前陣子，網路上出現一支很轟動的受訪影片， 原因不只是它的長度驚人👉整整六小時： 更重要的是，受訪者是 DHH。 如果你不熟悉他是誰，DHH 全名是 David Heinemeier Hansson，他是 Basecamp 的創辦人，更是 Ruby on Rails 框架的建立者。在開發者的江湖裡，他是那種推一句話就可能引發社群爭論、寫一篇 blog 就可能改變許多開發者的那種人。 訪談中，他談到一個很多人都有那麼點感覺的主題： AI 與 Vibe Coding 對開發者帶來的影響。 他坦言，自從頻繁使用 Auto Complete 與 AI code generation 之後，開始感受到一種「技能退化」的跡象。(有鑑於他的開發能力與背景，我相信他說的，遠多過於其他那些早已不寫 Code 的業界大佬) 一些原本熟練的 API 名稱，突然要多想一下； 思考邏輯的節奏被打斷，肌肉記憶也逐漸消失。 你知道我個人對 AI 輔助開發一直以來的看法， 在絕大部分的情況下，我支持使用 AI 輔助開發遠高於其他人。 為何是「在絕大部分的情況下」呢？ 因為，身為一位稍有年資的開發者，我依稀覺得有某個地方怪怪的，但又一直說不上來是哪裡。 直到這次聽到 DHH 的分享，他是第一個明確說出我一直講不出來的那種感受的人，深思後我不得不同意他的觀點。 大量使用 AI輔助開發，特別是最近很紅的 CLI 那種，確實有可能失去開發者特有的 「肌肉記憶」，不只是敲鍵盤的準確度而已，而是某種鍵盤跟大腦之間獨特的聯繫。 如今，大量使用 AI 輔助開發的人， 大多都認為未來開發者的角色將逐漸改變。 從一個「敲打鍵盤的人」，變成一個「溝通者」或「監工者」。 與 AI 溝通、審視 AI 產出、並且進行判斷與修正。 但這樣的轉變，是否也像極了過去許多技術人員，逐漸離開技術轉型成主管的過程？ 看似升級，實則在過程中逐漸失去對技術本身的感知與掌握。 當我們不再自己動手，久而久之，是否也會失去「能動手」的能力？ DHH 說，那些「自己一行行鑿刻程式碼」的過程，恰好是開發工作樂趣的來源。 當我們在鍵盤上敲下每一個詞彙時，大腦同時也在構建一種獨特的神經迴路 – 那正是開發者創造力與思考能力的來源。 他並不反對 Vibe Coding，只是用一個開發人員的角度給出了提醒...

最近有個發生在我們專案上的真實案例。 一位初階開發人員用 AI 一口氣生出 前端註冊表單 以及 後端驗證與寫入資料庫 的程式碼。建置沒錯、可以運行、AI 自我檢查後也說了聲沒問題，但是一跑， 前端的資料就是進不到後端模型 ，驗證當然也就永遠失敗。 這位 Junior Developer 卡在這邊三小時(生成這段程式碼的時間其實只有5分鐘)，直到下班前，一票老傢伙看不下去，在旁邊盯著把前後端程式碼一一對起來後才發現，問題居然只需要改一個字母而已。 現場重現：前端 AJAX 送這個 劇情其實很簡單，前端把使用者輸入後的資料，包裹成類似底下這樣的 JSON，透過 AJAX 丟到後端 Controller： { "UserName" : "Rick" , "Email" : "rick@example.com" , "Password" : "P@ssw0rd!" , "PhoneNumber" : "0987123456" } 產出上面的這段 JSON 的程式碼是 AI 寫的。 而接著 ASP.NET Core 的 Controller 大概長底下這樣： [ ApiController ] [ Route ( "api/[controller]" ) ] public class AuthController : ControllerBase { [ HttpPost ( "register" ) ] public IActionResult Register ( [ FromBody ] RegisterRequest input ) { // input 的屬性全是 null -> 驗證失敗 if ( input is null || string . IsNullOrWhiteSpace ( input . username ) ) return BadRequest ( "payload invalid." ) ; /...

近年來「AI Agent」的開發已經非常普遍，不管是做客服機器人、知識檢索，還是線上客服小幫手，大家常用的API介面幾乎都是 OpenAI 的 Chat Completions API 。 在大多數情境下，我們會用 非串流（non-streaming） 的方式呼叫，也就是送出一個請求，等伺服器思考完再一次回傳完整的回答。這樣的模式在 LINE、Teams、Slack 這類即時通訊平台的 Chat Bot UI 中沒什麼問題，因為使用者本來就習慣機器人一次回覆一整段文字。 但其實還有一種像是ChatGPT 官網那樣的輸出方式。 漸進式輸出的好處 但如果你用過 ChatGPT 官方網站，就會發現它的回覆方式完全不同：文字會像打字機一樣一個字一個字冒出來。這種「漸進式輸出」的體驗有幾個好處： 回應更即時 使用者不需要等模型完整算完才能看到內容，能先讀到前幾個字，就有「系統已經在思考」的感覺。 降低等待焦慮 在 UX 上，空白畫面最容易讓人懷疑「是不是壞掉了」。逐字輸出則能持續回饋，讓人安心。 模擬自然對話 人類聊天的過程就是一邊想一邊講，這種輸出方式更貼近自然互動。 更有戲劇感 對 Demo、教學、產品展示特別有用，可以讓使用者感覺「AI 正在思考」。 因此，雖然很多 Chat Bot 不一定需要這樣的 UI，但如果你的產品本身能夠提供這種 漸進式對話 ，以「Streaming 方式回覆」可以讓用戶體驗好很多。 Streaming 是怎麼實作的？ 那麼，ChatGPT 網站的打字機效果是怎麼做的？ 關鍵就在於 OpenAI 提供的 stream: true 參數。 當你在呼叫 /v1/chat/completions API 時，如果設定 stream: true (底下第二行)，伺服器就不會一次把整個 JSON 給你，而是會用 Server-Sent Events (SSE) 協議，持續推送「事件」。 { "model": "gpt-4o-mini", "stream": true, "messages": [ { "role": "system", "co...

『Vibe Coding 是本年度最糟糕的主意。』Continuous Delivery 一書的作者 David Farley 這麼說。 毫無疑問的，AI 可以加快開發速度，但同樣毫無疑問的，Vibe Coding 可能會讓開發人員減少對程式碼的『思考』。👈而這件事情長期來看是危險的。 如果你有開始用 Vibe Coding 做實際專案的開發，特別是中大規模的重構或功能實作，應該多少都會有類似的體會。 讓我自己最訝異的，是現在我花最多的時間竟然不是寫程式，而是在「等待」AI 回應我下的提示詞。 這個等待，短則一兩分鐘，有時甚至要等個五分鐘以上。 在這段等待時間裡，我偶爾會做一些與專案有關的事，但老實說，更多時候是作些雜事，像是回個 Email、傳訊息，甚至看看 YouTube。 等回過神來，思路早已被打斷，在多工之間切換，原本熟悉的「心流」也一點一點消失了。 儘管開發的總體效率看起來是變快的，但我對自己產生的這份程式碼，卻有種「不是我寫的」的陌生感。 儘管每一行都是照著我的提示詞產出，測試也通過了，但我心裡對它總有種說不出的距離。 一開始，我還會很努力地逐行確認，逐句檢查邏輯。 但當 AI 產出的品質愈來愈穩定，我發現自己開始得「靠意志力」才能完整地看過每一段程式。 一旦哪天趕進度、趕時程、測試又剛好都通過，我們就很容易放過它了。「AI這樣改…應該是OK的吧？」這句話愈來愈常出現在心中。 可以想像，當專案進入壓力期，那種「認真檢查 AI 程式碼」的機率只會雪崩式下滑。 從專案管理的角度來看，這樣好像也沒什麼問題：時程更短，效率更高，品質甚至可能更穩定。PM 滿意、客戶開心，聽起來一切都挺不錯的。 但 David Farley 給了我一絲提醒，動手實作對開發者的價值，不只是產生程式碼，而是「透過實作的過程訓練思考與設計」讓開發人員持續累積洞察與能力。 對外行人來說，軟體開發是一種生產技術；但對開發者自己而言，寫程式本身就是一種認知活動，一種將抽象邏輯具象化的過程，是設計、分析、解構與重組問題的訓練。 而 Vibe Coding 讓我們把這些練習機會，一次又一次的交給了 AI。 我們依舊能交付成果，但卻少了過去那些累積經驗的軌跡。 如果寫程式除了交付價值，還包含學習價值，那這部分現在正慢慢被 AI 侵蝕。 以前，從一個 juni...

前情提要 為何大家現在都喜歡採用 SSO? 我最近手上很多案子，都建議客戶不要自己實作帳號密碼登入，而是直接採用SSO登入。 因為，現今資安與用戶體驗的雙重考量，很多專案開發時，都會選擇整合 Google、Microsoft、LINE 這類大廠的 SSO（Single Sign-On，單一登入）機制，來取代自己儲存帳號密碼，如此可以降低很多資安風險，在面對資安稽核的時候，也省了一些什麼資料庫帳號密碼加密、金鑰保存的一堆麻煩。 而採用SSO對用戶也有一個好處，就是用戶不再需要記得很多組密碼，可以輕易實現 「一個帳號，多處通行」 。用戶在某個服務登入一次，其他整合同一身份平台的 網站/應用程式 就能直接使用，不必每次重新輸入帳密。對用戶來說方便，對開發者來說省事，對資安來說統一控管理論上也比較更安全。 但，不是每個 SSO 都能「好好登出」 某次，被客戶問到了一個問題。 客戶的用戶，使用瀏覽器登入我們的系統，但該瀏覽器會記得用戶的SSO session，因此當用戶關閉瀏覽器後，重新開啟瀏覽器登入系統時，看似需要登入，但發現即便導引到了SSO的登入畫面，卻無須輸入帳密，隨即可以登入!? 其實，SSO單一登入機制 by design 就是這樣設計的，這本來就是SSO的便利性和好處。然而，客戶卻有個疑問，如何強制讓用戶一定要用戶重新輸入帳密呢? 事實上，還真的不是每個 SSO 都能「登出」 雖然許多人都有用過 SSO，但可能很多人不知道： 不是每一個 SSO 都有支援「全域登出」的 API 或 URL 。 事實上，很多整合 SSO 的「登出」功能，本質上只是 在下一次登入時強迫重新驗證 ，並不是真的清空 IdP（身份提供者）的全域 Session。 更有趣的是： 這個所謂的「重新驗證」也不一定會要求用戶重新輸入密碼 。 有的 SSO 可以透過特定的參數在登入時直接強迫用戶輸入帳密（無視現有 Session），有的則只能「盡力要求」。最後要不要真的打密碼，還得看 SSO Provider 如何實作安全政策(例如MFA、零信任)。 就拿我在專案中最常使用的 MS, Google, LINE 三種 SSO Provider 來說，對於「登出」與「重新登入」的實作方式都不同。 Microsoft — 最直白的強制重登 https://login.m...

最近爬蟲事件很熱鬧，許多網站針對防止爬蟲程式竊取資料都有著不同的做法。日前，在一個聚餐中，有位同學提到了一個她們自己公司最近的需求。 該公司所開發的網站，需要將大量的媒體內容(影片、圖片、或是文件)，分享給不特定的用戶，上網觀看這些內容的用戶不需要登入，就可以以匿名方式檢視這些媒體內容。 然而，該網站又不希望，用戶(其實主要擔心的不是用戶，是爬蟲)能夠輕易地獲取媒體的網址，就將其分享給其他人，甚至輕易複製出一個完全一模一樣的網站。 簡單的說就是，網站想分享資訊，卻不希望用戶可以再次把這資訊分享給其他人，問大家有沒有好方法。 問到我，當然推一下 Azure 的 Blob儲存體。 近代的雲端儲存機制，其實都有提供類似的功能，可以讓媒體(mp4, jepg, pdf, … etc.)的檢視網址，變成僅供一次性的使用，而且可以針對特定IP或特定時間進行鎖定。 也就是說，當用戶進到某個網頁觀看上面的影片、圖片、閱讀PDF文件的時候，倘若將該媒體的網址複製下來，然後傳給其他第三人，這個第三人是無法用該網址觀看媒體資料的，因為IP不同，觀看的時間也不同。 這個功能稱為 SAS( Shared Access Signature ) : 在 Azure Storage 儲存體的 Blob 上，你可以針對一個受保護的檔案，設定其 SAS( Shared Access Signature )，這意味著如果用戶拿到這個檔案的 url，也無法開啟，一定要有一個合法的簽章，類似底下這樣: https://teststo202508.blob.core.windows.net/testcontainer/sashimi.jpg?sp=r&st=2025-08-02T07:10:29Z&se=2025-08-02T15:25:29Z&spr=https&sv=2024-11-04&sr=b&sig=ch7GZYS8rJii%2B45GJb4kKWj4valFW84E3Btgppc51aE%3D 如果用戶只拿該檔案的原始URL： https://teststo202508.blob.core.windows.net/testcontainer/sashimi.jpg 肯定是不能讀取的，會出現底下錯誤： 你可以針對該檔案，...

之前我發了一篇文章，標題是「原來使用 .NET 寫一個 MCP Server 如此簡單」。結果有不少朋友留言敲碗，說：「只有 Server，沒有 Client，這怎麼行？」 呃…我只能說，這個要求顯然 很有道理 。🙄 所以今天趁上課的空檔，補一篇文，來介紹如何撰寫 MCP Client ，把整個架構補齊。 你會發現，其實，開發 MCP Client 也非常簡單耶。 MCP 架構的本質 不過，在開始之前，有一個觀念需要釐清：無論是 MCP Server 或 MCP Client，其實都與 LLM（大型語言模型）沒有 直接關聯 ，這和很多人理解的不同。 MCP 架構的本質，只是為了讓 AI Agent（或 Chat Bot）更容易知道怎麼呼叫外部的服務提供者(就叫做MCP Server)，並且能方便地列舉出這些服務所提供的功能(就叫做MCP Server Tool)，以及清楚了解每個功能呼叫時所需的參數。某種程度上，它的角色有點類似早期 Web Service 時代的 WSDL/SOAP ，或是現代 REST API 架構中的 Swagger/OpenAPI 👉👉 都是用來提供一種 標準化的服務描述與呼叫方式 ，使服務整合變得更一致、更具可預測性。 至於， 什麼時候該呼叫哪一個功能 、呼叫時所要填入的具體參數 值 是什麼，這些判斷與決策的工作，才是由 AI(LLM) 來處理的。而真正去執行這些呼叫動作的，則是 AI Agent(或者稱之為，MCP Host)。 簡單的說就是，對談機器人(或AI Agent)可以藉由 LLM 來呼叫遠端的服務，而 MCP 架構則讓對談機器人可以得知有哪些服務可供呼叫，並且在呼叫時應該要傳入哪些參數。 因此，要開發一個能夠呼叫 MCP Server 服務的 Client 端，自然也需要建立一個具備決策與執行能力的 AI Agent。 這部分，我們待會會採用 Semantic Kernel 作為實作的基礎框架。 之前我們 早已介紹過 Semantic Kernel ，它不僅可以介接各種 大語言模型（像是 OpenAI 或 Azure OpenAI），還能彈性地設計與掛上各種 skills 與 plugins ，非常適合用來打造具備「對談 → 意圖理解 → 功能選擇 → 發出呼叫」這一整套流程的AI Agen...

MCP 的重要性與意義 MCP 的重要性在於它建立了一個標準化的架構，讓開發者能夠快速建構出給 AI Agent 呼叫的各種功能。 舉例來說，假設我們希望實現一個 可以透過自然語言對談的請假功能 ，傳統上我們必須建立一個前端 Chat Bot 作為 UI、還得撰寫後端 API、資料驗證邏輯、資料庫存取介面…等，另外還要設計 Chat Bot 的對話邏輯，才能把請假功能整合到Chat Bot的對談訊息中。 但在 MCP 的架構下，這樣的流程可以大幅簡化。 開發者只需要實作幾個「請假功能」的介面（Tool Interface），接著定義好運行這個功能需要輸入哪些參數（例如請假人、開始時間、代理人、事由…etc.），並透過 JSON 來描述這些參數的格式與驗證邏輯。接著，AI Agent 便可以在對話過程中，自動根據對談前後文理解使用者意圖，挑選出適合的Tool來運行，主動發出呼叫的請求。如此一來，大幅簡化了AI Agent開發的難度。(本質上就是 Function Calling 的概念) 而 .net 又把這個難度降低到人人可以開發的程度，底下是一個使用 .net 開發的 請假功能 MCP Server，並且使用 GitHub Copilot來呼叫的例子： 其實我之前用 Semantic Kernel做個類似的範例，只是如今 .net 讓它變得更簡單，而且輕易地可以透過MCP架構讓不同的 MCP Client端呼叫使用。 如何用 .NET 撰寫 MCP Server 要使用 .NET 撰寫 MCP Server 非常簡單，受益於 Microsoft.Extensions.Hosting 和 ModelContextProtocol 套件，我們可以在幾分鐘內輕鬆地實作 MCP Tool 和 MCP Server 。 以下是MCP Server的完整程式碼： using Microsoft . Extensions . DependencyInjection ; using Microsoft . Extensions . Hosting ; using Microsoft . Extensions . Logging ; using ModelContextProtocol . Server ; using System ...

來看看這張圖發生了什麼事情? 沒錯，我們正在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-...

隨著 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 所產生的技術債，根本無法長存於系統當中。甚至開發者還能透過每日的掃描...