.NET Walker

發表文章

洞見

作者： DD - 9月 26, 2025

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

LINE Imagemap 陷阱：baseUrl 原來不是一張圖！

作者： DD - 9月 24, 2025

在最近的某個專案當中，客戶希望在 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中使用MemoryCache保存Semantic Kernel的對談記憶

作者： DD - 9月 15, 2025

在開發 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...

C# 格式化(formatter)在 VS Code 中的選擇

作者： DD - 9月 02, 2025

程式碼的世界裡，有一個古老的爭論：大括號 { 到底該放在同一行，還是獨立成一行？這不只是排版問題，有時甚至會演變成團隊會議上的「宗教戰爭」。而我自己也有喜歡的 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 [*...

開發者的肌肉記憶

作者： DD - 9月 02, 2025

前陣子，網路上出現一支很轟動的受訪影片，原因不只是它的長度驚人👉整整六小時：更重要的是，受訪者是 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，只是用一個開發人員的角度給出了提醒...

Junior Developers 在 Vibe Coding 時的問題與挑戰

作者： DD - 8月 31, 2025

最近有個發生在我們專案上的真實案例。一位初階開發人員用 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 開發者必學的 Streaming 漸進式輸出技巧

作者： DD - 8月 25, 2025

近年來「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 的起點，成為你學習的終點

作者： DD - 8月 24, 2025

『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 登出的那些事：Google、Microsoft、LINE 開發者必讀差異

作者： DD - 8月 17, 2025

前情提要為何大家現在都喜歡採用 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...

搜尋此網誌