當麻許不寫程式

上一篇介紹了 Exa Search API，讓 AI Agent 可以直接搜尋網路，不需要再透過 Playwright 開啟瀏覽器，也不用自己解析 Google 的搜尋結果

不過搜尋只解決了一半的問題..

最近在開發 Web Agent，一直想弄個免費的 Web Search 備援

原本第一個想到 Google Search API，結果查了一下官方文件，Google 的 Custom Search JSON API 已經停止接受新用戶，既有用戶也得在 2027 年 1 月 1 日前完成遷移

以前好歹還有每天 100 次免費搜尋，現在連申請的機會都沒了 :'(

如果你有在寫 AI Agent，你就知道搜尋(Web Search)是一件麻煩的事情

如果要用 Google，你別傻了，它們是最麻煩的，光是 API 申請、設定跟計費就夠煩了，當然你可以用 Playwright 直接開瀏覽器搜尋
但是就很消耗資源，你知道的...

我之前也試過用 C# HttpClient 直接抓 DuckDuckGo，原本以為只要解析搜尋結果的 HTML 就搞定了
結果連續三次 HTTP 403，連搜尋都還沒開始就被擋下來了 XD

上一篇測了 Cloudflare Workers AI 的 FLUX.1 Schnell

這次換另外一顆：

@cf/black-forest-labs/flux-2-klein-4b

這顆我覺得比 Schnell 更適合真的拿來做 Blog 圖片

原因很簡單，它可以直接設定圖片的寬高，也支援 seed , width , height ，所以如果我要 16:9，不用自己再裁圖

直接指定 1280 x 720 就可以

最近我一直在找可以直接用 API 產圖，而且成本不要太誇張的服務

最後又回頭看了一下 Cloudflare Workers AI

Cloudflare 其實不只有文字模型，它也有提供圖片生成模型，其中一個就是

@cf/black-forest-labs/flux-1-schnell

上一篇已經讓 .NET 10 ASP.NET Core 支援 MCP，OpenCode 也可以直接呼叫 UpdateHoroscope 去修改網站上的雙子座運勢

不過上一篇是直接連 http://localhost:5100/mcp

本機測試當然沒差，但如果真的放到 Server 上，這樣我自己是不太敢用 ...

最近在測 MCP，一開始看很多範例都是 Echo、GetWeather，Code 可以跑，但是我自己還是覺得有點難看出實際可以拿來幹嘛

所以這次換一個簡單一點的案例，讓你直接體驗 MCP 對於製作網站可以幹嘛

最近在看 API Client 驗證這一塊

一般除了 Token 之外，可能還會再加 DeviceId、Fingerprint 之類的資訊，用來判斷是不是原本那台 Client

但這些東西本質上還是 Client 傳一個值給 Server

如果真的想確認 Client 還是不是原本那個，就可以再多一層 Key Proof

寫 C# 久了之後，會發現效能改善不一定都要做到很複雜
很多時候不是要換架構，也不是一定要上什麼很進階的技巧， 反而只是一些平常寫 Code 時的小習慣

例如少查一次 Dictionary、少產生一個 String、少配置一個 Array，單看一次幾乎沒有差
但如果這段程式每天跑幾十萬、幾百萬次，這些小地方累積起來其實就有差了..

前一篇測試了 Scriban，主要目的就是希望在 .NET 10 裡面
可以讓前端頁面在執行期直接修改，不用每次都重新 Build、Publish、Deploy..

前一篇測試了 RazorEngineCore，主要目的就是希望在 .NET 10 裡面
可以做到像以前 ASPX 一樣，前端頁面可以直接修改，不用每次都重新 Build、Publish、Deploy..

最近朋友問我可不可以不透過 Visual Studio or Visual Code 呼叫 Github Copilot 

感覺起來他就是要幹大事，其實問一下 AI 就知道可以不過我還是測試一下

畢竟可以讓程式自己寫程式，一直都是工程師的浪漫?

很多人一開始看 async/await，都會先把它當成語法糖。

我自己一開始也是這樣想

就覺得不就是把同步改成 await，讓 thread 不要卡住，看起來也比較現代一點，而且你現在用 copilot 應該也是 tab tab 就出來了

但真的在 API、網站服務，或是有點流量的系統裡用久之後，才會慢慢發現

async 不是只有能不能跑而已，它其實還會影響 效能、記憶體使用量，還有整體穩定度

有些 async code 表面上完全沒問題

但如果剛好寫在系統很常被呼叫的地方，它就可能一直默默建立 Task

平常流量小的時候不太有感，等到 request 一多，GC 開始變忙，延遲就會慢慢浮出來

一開始看到 record，其實完全抓不到重點

看起來跟 class 很像，而 class 又早就被拿來跟 struct 比過無數次

現在再多一個 record，第一反應只覺得，是不是又一個學了也不一定會用到的語法糖..

最近在整理一段舊系統的商業邏輯時，發現錯誤處理幾乎清一色都是  try/catch + throw

現在其實已經是  21 世紀了，很多時候有更好的方法可以處理 try catch 跟以前學習的方式有點不同

這篇單純記錄我實際套用 Result Pattern 後的想法與最小可行寫法筆記一下..

最近看到一個小眾的套件有點意思，就測試了一下 叫做 Facet.Net ，這套件有一些方便的地方

但是也有一些限制，這邊就簡單介紹一下，我覺得在製作一些 API  的時候會是有用且方便的..

聊一下關於好用的 LINQ 很多時候我們從資料庫撈出資料來，並且透過 API 往外吐，這是後我們都會把肥大的資料

拿掉一些或是組合一些欄位，之後再往外面吐，當然這沒什麼問題但...

最近遇到一個老專案，他之前設計都讓客戶自由輸入生日，不過幸好 placeholder 提示

至少他的客戶是乖乖輸入 國曆xx年xx月xx日，或是農曆xx年xx月xx日，但是他現在跟我說要算

天干地支跟五行...WT...

最近都再釐清一些觀念跟償還技術債，其實只要常常遇到程式要大量改寫成非同步化常常對專案都是

毀滅性的更改，也就是大量翻修，這裡面有一個很常被忽略的東西，處理的好才能夠把非同步化達到最大價值

很多人聽過 MessagePack，但真正用在 Web API 上的機會其實不多，尤其是完整從 Client 到 Server 都走 binary 傳輸的情境

這篇文章用 .NET 10 示範一個最小可行的案例，實作一個只接受 MessagePack 的 Web API，並搭配一個 Client 呼叫範例

讓整個傳輸流程從頭到尾都清楚可以快速複製貼上了解