.NET Walker

昨天 “恰巧” 碰上了洗版全台的 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，只是用一個開發人員的角度給出了提醒...