部落格最新文章
分享技術與日常生活
DeepSeek-V4.1-Flash-1017 模型介紹：願望驅動編程、基準提升與 Search/Fetch API
前言DeepSeek 在 2026 年 10 月 17 日推出 DeepSeek-V4.1-Flash-1017，是 9 月 V4.1 Flash 的更新版。這次發布的主題是「Wish-Driven Programming（願望驅動編程）」：官方說法是把一個完整專案交給模型，由它自己規劃、產生、檢查再修正到可交付的成果。官方釋出的示範涵蓋 3D 建模、網頁遊戲與 Godot 引擎重製，訴求是「講出願望，模型完成開發」。官方發布說明 同一天 DeepSeek 也開放自研的 Search 與 Fetch API，讓 Agent 能自行搜尋網頁並讀取正文。這篇整理截至 2026 年 10 月 17 日 的官方資訊，包含這次改了什麼、基準數據怎麼看、API 與收費的變化，以及導入時要留意的地方。
Laravel 轉 C# 的概念對照：Repository、Middleware、DI 與 EF Core 實戰指南
前言在 Laravel 專案裡，如果一百個後台列表都有相似的篩選、排序與分頁，我們可能會建立一個共用 Repository，讓大家從同一個入口取資料。轉到 C# 後，卻常看到另一種建議：直接使用 EF Core，把查詢條件抽成 IQueryable<T> 擴充方法。兩邊都在解決重複程式碼，差異到底在哪裡？ 類似的疑問也會出現在 Middleware、Service Provider、Model、Event 與 Validation。熟悉 Laravel 的經驗很有用，但遷移時需要重新確認三件事：這個元件負責什麼、活多久，以及在哪個時機真正執行工作。 這篇以 ASP.NET Core 與 EF Core 為核心，整理這些概念的對應與實務取捨。
C# 架構實戰比較：同一個訂單 API，三層、DDD 與垂直切片怎麼選？
前言假設今天要用 C# 寫一套訂單後端，包含建立訂單、查詢、付款狀態更新與取消訂單。採用三層架構，可以從 Controller → Service → Repository 開始；採用 DDD，可能會出現 Application、Domain、Infrastructure；採用垂直切片，又會變成 Features/Orders/Cancel。光看目錄，很難判斷這些選擇在實際開發上差在哪裡。 這篇固定使用同一套 ASP.NET Core API、EF Core 與 PostgreSQL，以「取消訂單」比較三種寫法，再把需求改成「多個入口共用規則」「與付款同時發生」「取消後要發送通知」，觀察程式碼與責任如何變動。比較集中在專案內部的設計、開發與維護成本。
