.NET Walker

我跟你說，我夢想著實現這個功能很久了✌ 我一直希望能夠在 CI/CD Pipeline 中加入 LLM 的力量。 我一直想透過 CLI 讓 LLM 在 Pipeline 中自動處理重複性任務。例如，在晚上讓 AI 自動幫我找 bugs、自動做 Code Review、甚至自動撰寫說明文件或一部分程式碼… 然後，我夢寐以求的 “兩班制全天候24h開發團隊” 就可以實現了!!! 白天，由 Developer 搭配 AI 進行開發。 晚上，由 AI 自己去做比較不需要人監督或無傷大雅的工作，像是寫文件，找 bugs 之類的。 然後隔天早上工程師上班之後，就可以繼續接手 AI 昨晚產出的成果，接著進行開發。 嘿嘿，這樣是不是太完美了? 想想都覺得興奮。 緣起 在現代軟體開發中，效率與自動化是不可或缺的要素。 GitHub Copilot CLI 的出現，為我們提供了一個強大的工具，能夠在開發過程中自動生成程式碼、撰寫技術文件，甚至協助除錯。 假設我能將這項工具整合到 Azure DevOps 的 Pipeline 中，自動在晚上運行，就可以實現我之前說的 全天候的開發流程 。(以前是把程式碼發包給印度的工程師，現在 AI 就是我的夜班工程師!!!) 嘗試在 Azure DevOps Pipeline 中使用 GitHub Copilot CLI 想要將 GitHub Copilot CLI 整合到 Azure DevOps Pipeline 中，有幾個關鍵步驟。 首先，你要能夠在 Build Agent 上安裝 GitHub Copilot CLI。要這麼做不難，只需透過底下這個 bash script 指令就可以完成安裝 。 npm install -g @github/copilot 只是，你得先確定 Node.js 已經安裝在你的 Agent 上，且是最新版本。 因此，我們會在 pipeline 中，先用一個 step 來安裝 Node.js。 steps : - task : NodeTool@0 displayName : 'Use Node 22.x' inputs : versionSpec : 22.x 接著，我們就可以安裝 GitHub Copilot CLI 了...

這支影片展示了如何透過 Azure DevOps (ADO) 的 Model Context Protocol (MCP) 整合 Chrome DevTools MCP ，實現端到端（E2E）的自動化 UI 測試流程。 影片中展示了如何讓測試腳本的運行不再倚賴人工，開發者只需要在 GitHub Copilot 中下達提示指令，MCP 代理便能自動呼叫瀏覽器、執行互動測試、檢查運行結果並回報測試通過或失敗，還能順手撰寫完整的測試報告。 整個流程結合了 AI Agent + Chrome DevTools + Azure DevOps Test Case 的強大能力，實現真正的「零人工自動化測試」： 由 PM/SA/PO 負責描述測試路徑 （例如登入流程、輸入數據、按鈕執行…etc.） 由 Chrome DevTools MCP 負責具體執行並檢查測試結果 由 GitHub Copilot 負責記錄與撰寫測試結果 這樣的整合大幅提升測試效率與速度。 未來，或許每位工程師都能「像喝咖啡一樣輕鬆地跑完自動化測試」。 看完之後，來 FB 留言分享一下你的感想～ https://www.facebook.com/DotNetWalker/posts/pfbid02qnBruy8mJLnoCswoXnNRQvAqoyAhnXMEA9dqcun3M3rSMx1rv3NovvAZWmJBFqwBl 我很好奇大家的看法。

日前參加 DevDays 2025 大會，和幾位 MVP 講師在台上 live 接受學員們的提問。問題五花八門，既有技術細節，也有宏觀趨勢。會後又和社群朋友閒聊，回到家，還收到幾則來自學員與老友的 LINE 訊息。 和大夥閒聊和互動的過程中讓我更感受到，似乎還是有不少開發人員對 Vibe Coding 以及最近這陣子以來，AI所帶來的改變感到焦慮~ 技術變化如此快速，我們究竟該緊跟不放，還是先按兵不動？ 到底該持續follow，還是讓子彈飛一會兒? 不只是個人，企業也急於導入 AI，卻總是找不到真正有意義的場景與能發揮價值施力點。 大家隱約知道 AI 開始改變了許多事情，但心中又有一絲不安：自己該怎麼辦？該如何面對？ 在一個半小時的時間裡，我還真無法給一個面面俱到的答案。 最後主持人請我做個總結，但其實我心裡想講的是，在資訊產業當中，面對變革早已不是一天兩天的事情了。2022 年底 ChatGPT 初現時，我滿懷興奮與期待；到了 2023 年中，焦慮與疑惑席捲而來；2024 年底，我逐漸找回自己的節奏，直到今天。 回想自己整個歷程， DevDays 2025 大會的最後，我分享給大家我自己面對 AI 時的三個心態與轉折… 接觸：直球對決 直到今天，仍有不少人對 AI 避之唯恐不及，甚至認為它只是一場即將破滅的泡沫。這樣的想法很可以理解，當市場上各種 AI 課程、話題氾濫，它走向泡沫並不令人意外。但請注意，那是對投資人而言。而我們來說，則大大不同。還記得2001年 .com 泡沫化之後發生的事情嗎？真正的改變，那時才剛剛開始。 AI帶來的影響已無庸置疑，這個階段，你的各種的接觸都是好事(是的，包含可能帶來風險的 Vibe Coding )，各種嘗試都是加分，不要躲避，去面對這個改變，直球對決，這是第一件事情，也是最重要的一件。 體驗：唯有親身嘗試，才會生出洞見 接著是體驗，我是指你自己親身的體驗。不只是去聽聽課，或只是上網玩玩圖片生成、與ChatGPT聊聊天而已。 昨天提到，光是 Vibe Coding 這個詞，十個人就能說出十一種不同的解釋。我自己在 2022 到 2025 年間，就歷經至少四種不同型態的 AI 輔助開發，而 Vibe Coding 這個詞到了2025年初才開始出現。其實每種方式在碰到不同的情境時（專案大小、團隊...

昨天 “恰巧” 碰上了洗版全台的 vibe coding 事件，所以很多人以為我說 Responsible Vibe Coding 是玩笑話 ​ 不~我是認真的。 你拿 Responsible Vibe Coding 這個字去網路上搜尋，就會發現，早已經有太多人在討論 Vibe Coding 帶來的風險以及如何因應。 特別是對於原本不在軟體開發領域的開發新手而言，有許多需要注意的事情，甚至已經有人針對 Responsible Vibe Coding 列出了 guidelines… LLM確實讓進入軟體開發的門檻大幅下降，甚至有人用了 democracy 這個詞來形容(意味著過去被少數人壟斷的專有能力，如今已釋放給所有人…)，但這也是 吳恩達(Andrew Ng) 不喜歡 vibe coding 這個詞彙的原因 讓人誤以為軟體開發從此就變得人人可做了。 然而其實不是的。 因為，專業 與 非專業 的差異，其實不只是能力，而是 『態度』。 專業不只是因為能力比較強，或是比較有經驗，也是因為願意去做那些流程中看似無聊和瑣碎的雜事，以至於我們的成品可以在安全性和品質上得到保障。 寫程式，或許變得容易了(反正都是AI寫嘛)，但寫出高品質的好程式，則依舊是專業人士才能作到的事情。 新手面對 Vibe Coding 到底該注意些什麼，如何才能兼顧品質、安全、和效率? 我把相關資訊，放在底下: https://vibe-coding-manifesto.com/ https://medium.com/@harsz89/from-heads-down-to-hands-off-a-journey-into-responsible-vibe-coding-3d81a1c5634c https://www.businessinsider.com/andrew-ng-vibe-coding-unfortunate-term-exhausting-job-2025-6 針對 vibe-coding-manifesto 這份給開發人員的 Responsible Vibe Coding 建議，整理如下: Rules for AI-Assisted PR Submissions（AI 輔助的 PR 提交規則） 這一部分主要在講：如果你用 AI 幫忙產生程式碼，當...

在最近的某個專案當中，客戶希望在 LINE 官方帳號的互動中，使用 Imagemap 訊息格式。 Imagemap 可以讓使用者點擊圖片上的不同區塊，以便於觸發不同的行為，例如導向不同的網頁、回傳不同的文字訊息，非常適合設計互動式選單或導覽。 例如，假設你用底下這張圖當作Imagemap： 則可以設定成，如果用戶點選左邊，則會出現 鶯歌 的簡介，點右邊，則會出現八德的簡介。 我的 team member 馬上動手實作，照著文件寫下程式碼，其中一則 Imagemap 訊息的json代碼類似底下這樣： { "type" : "imagemap" , "baseUrl" : "https://example.com/images/sample.png" , "altText" : "選單" , "baseSize" : { "width" : 1040 , "height" : 1040 } , "actions" : [ { "type" : "uri" , "linkUri" : "https://example.com/page1" , "area" : { "x" : 0 , "y" : 0 , "width" : 520 , "height" : 520 } } ] } 但是，不管怎麼設定，圖片就是顯示不出來。總是出現類似底下這樣的錯誤訊息： debug 了好一陣子，毫無頭緒。 同仁跑來問我時，我看了一眼，突然想起以前也踩過這個坑。 其實， baseUrl 並不是一張圖片的 URL ！ 此參數之所以叫做「baseUrl」，是因為它代表的是 圖片的基底路徑 。(而非圖片的路徑) LINE Imagemap 為了要在不同裝置（例如手機解析度不同）都能有合適的圖...

在開發 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." ) ; /...