Ray Liu's Blog

前言在 Laravel 專案裡，如果一百個後台列表都有相似的篩選、排序與分頁，我們可能會建立一個共用 Repository，讓大家從同一個入口取資料。轉到 C# 後，卻常看到另一種建議：直接使用 EF Core，把查詢條件抽成 IQueryable<T> 擴充方法。兩邊都在解決重複程式碼，差異到底在哪裡？ 類似的疑問也會出現在 Middleware、Service Provider、Model、Event 與 Validation。熟悉 Laravel 的經驗很有用，但遷移時需要重新確認三件事：這個元件負責什麼、活多久，以及在哪個時機真正執行工作。 這篇以 ASP.NET Core 與 EF Core 為核心，整理這些概念的對應與實務取捨。 本文依 2026-10-16 查閱的 Laravel 13.x、ASP.NET Core 10 與 EF Core 官方文件整理。C# 程式碼是聚焦概念的片段，省略完整型別、DI 註冊與錯誤回應整合，未建立或執行完整範例專案；版本特有行為會另外註明。 一、先用職責對照，避免只翻譯名稱有些概念十分接近，有些則需要拆成幾個元件...

前言假設今天要用 C# 寫一套訂單後端，包含建立訂單、查詢、付款狀態更新與取消訂單。採用三層架構，可以從 Controller → Service → Repository 開始；採用 DDD，可能會出現 Application、Domain、Infrastructure；採用垂直切片，又會變成 Features/Orders/Cancel。光看目錄，很難判斷這些選擇在實際開發上差在哪裡。 這篇固定使用同一套 ASP.NET Core API、EF Core 與 PostgreSQL，以「取消訂單」比較三種寫法，再把需求改成「多個入口共用規則」「與付款同時發生」「取消後要發送通知」，觀察程式碼與責任如何變動。比較集中在專案內部的設計、開發與維護成本。 本文的「垂直架構」指 Vertical Slice Architecture，垂直切片架構。程式碼為說明責任配置的核心片段，省略 DI、完整型別、EF 對應與例外轉譯，沒有建立或執行三套可重現的 C# 範例專案；文中的選型是依情境提出的工程判斷。 一、先釐清：這三個名稱關注的事情不同三層、DDD 與垂直切片可以放在一起討論，...

前言「把一部分查詢搬去 MongoDB，真的會比較快嗎？」「Cassandra、ScyllaDB 為什麼能存那麼多聊天訊息？」「NoSQL 是不是為了效能，接受寫入成功後資料還會消失？」這幾個問題其實連在一起：資料庫用什麼方式組織資料，以及它回覆成功時，到底承諾了什麼。 這篇從實際選型出發，先整理各類資料庫擅長的工作，再深入 MongoDB、Cassandra、ScyllaDB 與 Discord 的遷移案例，最後回到資料遺失、讀寫一致性和 CQRS（命令與查詢職責分離）讀模型。重點是找出哪個工作負載值得換工具，以及換了之後要承擔哪些責任。 先分清楚：資料模型、交易保證與擴展方式NoSQL 是一個範圍很廣的分類，包含文件、鍵值、寬列、圖等不同模型。**ACID 描述交易的原子性、一致性、隔離性與持久性，和是否使用 SQL 是不同維度。**例如 MongoDB 支援單文件原子操作，也支援跨文件與分片叢集的交易，不能直接把它歸類成「沒有交易保證」。MongoDB 原子性與交易 同樣地，「有多台機器」也可能代表不同事情：有些副本是保存相同資料、分擔讀取；有些分片則各自保存不同資料、...

前言假設要做同一套會員與訂單 API：有路由、驗證、ORM、資料庫連線、Redis 快取與 JSON 回應，分別用 Go、C#、Java、Node.js、PHP 實作。在功能一樣、部署成容器的前提下，哪一種比較省記憶體？哪一種容易在高流量下卡住？正式環境又要多照顧哪些地方？ 我的選型起點是：**重視精簡常駐服務，先評估 Go；重視複雜業務與持續吞吐，評估 C#、Java；以 TypeScript 整合服務，評估 Node.js；快速交付商業 CRUD，評估 Laravel，並把 FPM 與 Octane 分開看。**接下來把這些判斷放進同一個專案比較，說明背後的 CPU、記憶體與執行模型差異。 比較基準：同樣功能、相同資源與相同達標條件本文比較的是 Linux 容器中的後端 API。JavaScript／TypeScript 都以 Node.js 執行後端來看；C# 使用現代 ASP.NET Core。PHP 則分成傳統 PHP-FPM 與 Laravel Octane，因為兩者的請求生命週期不同。 先定義一套共同的微服務規格，避免拿精簡 JSON endpoint 和完整訂...

前言Claude Code 不只是能讀取程式碼、呼叫終端機的 AI 工具。把專案規範、依路徑載入的規則、可重複執行的 Skills，以及環境變數與 Hooks 設定好之後，它才能在不同專案裡穩定使用正確的建置方式、編輯習慣和工具權限。 這篇整理 Claude Code 的幾種設定方式，並釐清一個容易搞混的問題：**.claude/rules/ 裡的 Rule 是提示 Claude 的 Markdown 指令，不能直接設定 Shell 環境變數。**本文依 Anthropic 官方文件截至 2026 年 10 月 14 日 的內容撰寫；Claude Code 仍在持續更新，實際可用欄位請以官方文件及本機版本為準。 封面為 AI 生成的概念插畫，呈現專案指令、路徑規則、工作流程與執行環境之間的關係。 先建立設定的心智模型Claude Code 有多種可調整的層次。它們看起來都像「設定」，實際上作用不同：有的提供上下文，有的改變程式的執行環境，有的在特定事件發生時執行程式。 機制 主要用途 載入或執行方式 CLAUDE.md 專案架構、慣例、常用命令等持續適用的背景 進...

前言AI 寫的文字有辦法被辨識嗎？OpenAI 在 2026 年 10 月 5 日公布文字浮水印技術 textGrain：它不會在句子裡插入看得見的標記，而是在生成時讓選字帶有統計訊號，再由偵測器判斷文字是否含有這種訊號。OpenAI 公告 這項消息和歐盟《AI Act》的生成內容透明度規範有關，但「偵測到浮水印」不能直接證明誰寫了文章，也不能證明整篇都由 AI 產生。本文以 2026 年 10 月 6 日為準，說明 textGrain 的基本原理、OpenAI 公布的測試結果，以及實際使用時需要保留的判斷空間。 封面為 AI 生成的概念插畫，用紙帶與隱約出現的規律符號表現統計浮水印；不是 OpenAI 產品畫面，也不是 textGrain 的演算法圖。 文字浮水印和一般 AI 偵測器有什麼不同？一般 AI 文字偵測器通常會根據輸出文字的特徵，估算內容由模型生成的可能性。textGrain 則在生成文字時，把訊號放進選字的統計關係中，之後再由配套的偵測器尋找訊號。 這有點像在紙張中混入肉眼看不見的纖維。一般偵測器只能從文章外觀猜測來源；浮水印則需要生成端先嵌入訊號，偵測...

前言Google 在 2026 年 9 月 30 日公布新一代模型 Gemini 4 Argon。這次發布的重點不是一般聊天問答，而是讓模型持續處理複雜、耗時的工作：從大型程式碼修改，到金融與法律研究，再到漏洞分析與修補。Google 官方公告 不過，看到「Gemini 4 發布」不代表現在就能打開 Gemini App 或呼叫公開 API。Gemini 4 Argon 目前先透過 Fairwind 計畫提供給受信任的資安防禦者，Google 表示會在持續測試防護措施後，再逐步開放給開發者、企業與消費者。本文以 2026 年 10 月 1 日為準，整理目前已公開的內容與仍待確認的部分。 封面為 AI 生成的概念插畫，用路徑與修補結構表現多步驟推理；不是 Gemini 4 的產品截圖。 Gemini 4 Argon 是什麼？Gemini 4 Argon 是 Google 新公布的前沿模型（frontier model），定位在需要多步推理、持續執行和跨資料理解的工作。Google 特別提到真實軟體工程、企業知識工作（例如法律與金融）以及資安防禦。這些任務的共同點是：模型得...

前言OpenAI DevDay 2026 在 9 月 29 日於舊金山 Fort Mason 舉行。這次不是只發表一個新模型：OpenAI 官方回顧列出 20 多項更新，範圍從 GPT-6.1 Sol、Codex 與 Agents API，一路延伸到 ChatGPT 的長期 Agent、團隊協作、外掛和企業採購。 把這些消息放在一起看，主軸是讓 AI 從「等你下指令的工具」往「能持續承接工作、透過工具採取行動，並與團隊共享上下文」移動。本文依官方 DevDay 回顧逐項整理，並標示截至 2026 年 9 月 30 日 的推出、預覽與即將推出狀態。 DevDay 2026 的活動與產品主線DevDay 的實體活動在 Fort Mason 舉行，當地時間上午 10 點由 Sam Altman 主持開場演講，並安排技術議程、實作展示與工作坊；Keynote 也提供線上直播。官方 DevDay 頁面表示，其他場次的錄影會在活動後上線。OpenAI 另規劃在 Bengaluru、Tokyo、Seoul、Berlin、Paris、London、São Paulo 和 Mexico Cit...

前言Anthropic 在 2026 年 9 月 28 日發表 Claude Sonnet 5.5，主打把模型能力、速度與每項工作的成本一起往前推。官方表示，它比 Sonnet 5 快 30% 以上，多數工作成本最多降低 30%；應用重心則放在日常程式開發、Agent 任務，以及文件、簡報和試算表等知識工作。 這篇整理截至 2026 年 9 月 29 日 的官方資訊，包含模型定位、基準測試、價格與導入時要留意的地方。基準分數可以幫助理解改進方向，但不能直接當成每個團隊的實際成效保證。 Claude Sonnet 5.5 的定位Sonnet 5.5 是 Claude 5.5 家族的第二款模型，接在 Opus 5.5 之後。Anthropic 將它定位為處理範圍明確、日常會反覆遇到的工作：修正程式錯誤、理解程式碼庫、產出文件與簡報，或在工具協助下完成一段工作流程。 模型 官方定位 適合優先評估的情境 Claude Sonnet 5.5 速度快、能力均衡的日常工作模型 程式修改、文件產出、常見 Agent 工作流程 Claude Opus 5.5 面向需要持續判斷的...

2026 年 9 月下旬的前沿 AI 戰場，只能用「神仙打架、全面開戰」來形容。就在 OpenAI 於 9 月 22 日宣布推出價格大砍 50% 的中堅模型 GPT-6 Sol 與極速模型 GPT-6 Luna 之際，Anthropic 緊接著在同一天投下重磅炸彈——正式推出新一代 Claude 5.5 家族的開路旗艦：Claude Opus 5.5！ Anthropic 官方宣稱，Opus 5.5 在絕大多數核心任務上已經達到、甚至超越了月初剛發布的長思考代理模型 Claude Fable 5.1；更關鍵的是，其整體運作成本比前代 Opus 5 降低了約 40%，輸出速度提速超過 30%。這場幾乎在同一天爆發的模型對決，宣告了 2026 下半年「高效能 × 低成本」的代理人（Agentic）競賽正式進入白熱化階段。 本文將為大家帶來 Claude Opus 5.5 的一手消息，並將其與 Anthropic 體系的 Opus 5、Fable 5.1，以及 OpenAI 旗下的 GPT-6 Sol、GPT-6 Luna 與極致旗艦 GPT-6 Astra，進行一次跨陣營的規格、...