.NET Walker

最近有個發生在我們專案上的真實案例。 一位初階開發人員用 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 肯定是不能讀取的，會出現底下錯誤： 你可以針對該檔案，...