博客 / 列表

blossom - AI 的“性格旋鈕”——什麼是大模型的温度？

你有沒有發現：有時候 AI 像個嚴謹的老教授，回答滴水不漏；有時候它又像個天馬行空的藝術家，能編出一堆意想不到的情節？ 這背後往往藏着一個關鍵參數：温度（Temperature）。 別擔心，調高温度並不會讓電腦“發燙”，也不是讓 AI 發燒。這裏的温度，更像一個控制 AI “有多敢冒險”的性格旋鈕： 温度低 → 更穩、更像標準答案 温度高 → 更發散、更有創意，但也更容易跑偏 一、為什麼

後端

blossom - 拒絕慢查詢！像逛超市一樣看懂數據庫索引

點擊網頁上的“搜索”按鈕，加載圈轉了數秒才出現結果，這種體驗對於用户來説並不友好。查看後台日誌時，往往會發現這是由慢查詢 SQL 引起的。 很多時候，慢查詢的根源在於沒有建立索引（Index），導致數據庫被迫進行“全表掃描”。 到底什麼是索引？為什麼增加索引能顯著提升速度？它又帶來了什麼代價？本文將摒棄枯燥的計算機教材定義，通過“逛超市”的直觀案例，深入淺出地解析數據庫索引原理。 一、 為什麼查

後端

blossom - Google MusicFX 上手指南：零基礎也能當 AI DJ？

對於許多視頻創作者或音樂愛好者來説，製作一段獨一無二的 BGM 往往門檻極高。專業音樂軟件（DAW）複雜的音軌和參數界面常令人望而卻步。隨着 AI 技術的進步，Google Labs 推出的 MusicFX 系列工具正在改變這一現狀。 通過 MusicFX DJ 模式，用户無需識譜，無需昂貴的硬件設備，僅需簡單的交互，即可體驗實時控制音樂流動的樂趣。本文將深度解析 MusicFX DJ 的操作流程

後端

blossom - 再見手寫 CSS！用 Google Stitch + AI Studio 實現“所見即代碼”的開發流

對於全棧開發者而言，常面臨這樣一個挑戰： 後端的架構設計可能完美無瑕，數據庫範式標準優雅，接口響應速度極快——但將這些展示在網頁上時，卻往往陷入困境。面對 CSS 的 flex 佈局、複雜的居中對齊、以及多端適配的響應式設計，開發者往往希望有一個懂審美的智能助手能自動完成這層“皮囊”的構建。 隨着 Google Labs 推出實驗性工具 Stitch，配合 Google AI Studio，UI

後端

blossom - Google Labs 新品實測：Mixboard、Flow 和 Learn Your Way 上手體驗

AI 的發展速度令人目不暇接。如果説 2023 年是“對話框（Chatbot）”的元年，那麼 2025 年似乎正在成為“工作流（Workflow）”的一年。 Google Labs 近期放出的三個生成式 AI 實驗項目——Mixboard、Flow 和 Learn Your Way，展現了這一趨勢。這三款工具分別針對視覺創意、視頻敍事和深度學習場景，設計了完全不同的交互形態。它們不再是單純的“生成

後端

blossom - Google Opal 初體驗：0 代碼手搓一個 YouTube 視頻轉中文博客 APP

在 AI 應用構建領域，Google Labs 推出的 Opal 正以其獨特的“生態整合”和“Text-to-App”能力引起廣泛關注。與傳統的低代碼平台不同，Opal 允許用户通過自然語言描述需求，直接生成完整的 AI 工作流。 本文將通過一個實際案例——“自動將 YouTube 視頻轉換為中文博客文章”，拆解 Opal 的自動化構建能力與工作流邏輯。 什麼是 Google Opal？ Goog

後端

blossom - 告別輪詢延遲：基於 SSE + Redis Pub/Sub 構建絲滑的客服聊天系統

在即時通訊（IM）領域，用户體驗的“生死線”往往只有幾秒鐘。 想象這樣一個場景：用户滿懷焦急地發了一句“在嗎？我要退款”，然後盯着屏幕等待。如果你的系統還在用每 5 秒一次的輪詢（Polling），那麼用户可能要等好幾秒才能看到客服回覆的“您好”。這幾秒的空白，足以消磨掉用户的耐心。 傳統的解決方案往往走向兩個極端：要麼是輪詢（資源浪費且有延遲），要麼是全套的 WebSocket（協議重、心跳管理

後端

blossom - 擊穿防線：從“12·22”風控事件看下一代直播安全架構的進化

摘要： 2025年12月22日深夜，一場針對短視頻與直播平台的“飽和式攻擊”給我們敲響了警鐘。數萬個沉睡賬號被瞬間喚醒，海量違規內容利用推薦算法的冷啓動機制進行流量劫持，導致審核系統在瞬時高併發下發生擁塞。 拋開輿論與商業層面的喧囂，作為技術與架構從業者，我們需要冷靜透視這場不對稱戰爭的本質。這不僅是一次內容安全事故，更是一次對傳統“堆人肉、堆算力”防禦模式的降維打擊。本文將從源頭防禦

後端

blossom - AI 時代的攻防暗戰：從“誘導刪庫”到“錢包耗盡”，必須警惕的 10 大風險

引言：繁榮背後的陰影與毀滅性打擊 從自動駕駛汽車穿梭於城市街頭，到智能客服接管 24 小時業務，人工智能已滲透至現代社會的毛細血管。然而，在 AI 技術高歌猛進的表象下，一場針對數字基礎設施的隱秘戰爭正在升級。 剛剛過去的“12·22 快手攻擊事件”便是這場暗戰中一次慘痛的註腳。事後覆盤顯示，這並非一場簡單的流量騷擾，而是一次在極短時間內將平台打得措手不及的“閃電戰”： 從試探到崩盤：短短數小時的

後端

blossom - 詳解 Redis Write-Behind 模式：如何用 Redis 給數據庫做“擋板”

1. 引言：數據庫的“至暗時刻” 在互聯網高併發場景下，經常會出現流量突發的狀況。例如短視頻 App 遭遇熱點事件，幾百萬用户瞬間涌入，產生海量的點贊與評論互動。 此時，後端監控系統往往會發出警報： 數據庫 CPU 飆升至 100%。 磁盤 I/O 被打滿，寫入延遲從幾毫秒惡化至數秒。 連接池耗盡，新的請求因無法獲取連接而報錯。 這種現象的根本原因在於：在傳統架構中，每一次前端的“點贊”

後端

blossom - 客服工作台設計（二）：別讓客服“裸奔”，打造超強上下文輔助面板

在上一篇文章中，探討了如何通過“雙梯隊排序 + 錨點時間”重構客服工作台的左側會話列表，從而讓客服不再需要雜亂的列表中“找單子”，實現了高效的流轉。 然而，當高效的列表引流引擎將一個全新的客户會話推送到客服面前時，新的挑戰隨之出現：客服往往對屏幕對面的這個人一無所知。不知道客户的身份，不知道之前的交互歷史，也不確定該採用何種應對策略。 這種狀態，如同將一名戰士空投至戰場卻未提供地圖與情報，通常被稱

後端

blossom - 如何設計高效的客服工作台會話列表？拒絕照搬通用 IM 模式

在構建客服系統（Agent Workbench）時，市面上常見的即時通訊（IM）軟件往往成為首選的參考對象。畢竟，即時通訊是大眾最熟悉的溝通形態。 於是，很多客服系統的會話列表設計呈現出這樣的形態：所有會話按“最後一條消息時間”倒序排列；有新消息來，會話瞬間跳到頂部；紅點消掉代表“已讀”。 但在實際運營中，這種照搬“通用 IM 模式”的做法，往往無法滿足高強度的服務需求，甚至成為效率提升的瓶頸。本

後端

blossom - Rust 模塊化單體架構：告別全局 Migrations，實現真正的模塊自治

在 Rust 後端開發領域，Workspace Modular Monolith（基於工作空間的模塊化單體） 架構正日益流行。這種架構模式巧妙地平衡了開發效率與部署成本：在開發階段，它提供了類似微服務的物理隔離（crates 分離）；而在部署階段，它保留了單體應用的簡單性（單一二進制文件）。 然而，在模塊化的高牆之下，往往隱藏着一個難以忽視的架構短板——數據庫遷移（Database Migrati

後端

blossom - 權限系統設計：功能權限與數據權限的解耦之道

在後端系統的設計中，權限（Authorization）永遠是一個核心命題。 在項目初期，為了追求開發速度，往往容易憑直覺採用一種極其簡單的設計方案。然而，正是這個起初看起來“最快”的方案，往往會成為後期維護中最大的噩夢。 本文將從一個典型的“設計反模式”開始，探討如何構建一個成熟的後端權限防禦體系。 一、 起手式的陷阱：User 表裏的 permissions 字段 在項目剛啓動，用户量較少時，很

後端

blossom - 從“字段拆分”到“架構分層”：IM 系統消息狀態更新的演進之路

摘要：在 IM 系統開發中，發送圖片或視頻是一個涉及長耗時 I/O 的過程，系統需要頻繁更新消息的流轉狀態（Pending -\ Uploading -\ Sent）。許多開發者為了追求 Schema 的簡潔性，傾向於將這些狀態字段放入 JSON Payload 中。本文將從數據庫底層原理（MVCC、Row Copy、TOAST）出發，剖析這種設計為何是性能的“隱形殺手”，並展示如何通過架構演進實

後端

blossom - 會話更新的防抖進化 —— 填補“亂序”與“丟數據”的深坑

摘要：在上一篇文章中，我們設計了一個基於 Actor 模式的“寫緩衝（Write-Behind）”防抖系統，看似美好，但是還是有消息亂序與數據丟失的隱患。本文將詳細記錄 V2 版本的重構思路：通過引入 阻塞背壓 (Blocking Backpressure)、延遲確認 (Deferred ACK) 和 事件循環 (Event Loop)，構建一個更加健壯、嚴謹的防抖系統。 1. 背景與挑戰：從“

後端

blossom - 拒絕寫放大：基於 Actor 模式與背壓機制的無鎖寫緩衝設計

1. 引言：高併發下的防抖挑戰 在構建即時通訊（IM）或物聯網（IoT）系統時，核心挑戰往往不在於消息的接收吞吐量，而在於如何高效處理隨之而來的海量狀態更新。 業務場景中常見的一環是：每當收到一條新消息，都需要更新對應會話（Session）的 last_active_time（最後活躍時間）和 digest（最新消息摘要）。如果在高併發場景下，每一條消息都直接觸發一次數據庫 UPDATE 操作，將

後端

blossom - 如何高效且優雅地批量處理會話更新？

1. 痛點：被“寫放大”拖垮的數據庫 在對接企業微信、3-chat 等第三方 IM 系統時，核心挑戰往往不在於消息的接收，而在於如何高效地處理隨之而來的海量狀態更新。 業務場景中常見的一環是：每當收到一條新消息，都需要更新對應會話（Session）的 last_active_time（最後活躍時間）和 digest（最新消息摘要）。 這裏存在一個隱蔽的性能殺手： 在羣聊活躍或消息洪峯場景下，

後端

blossom - 拒絕 “LGTM”：如何構建 AI 首席架構師進行防禦性 Code Review

在現代軟件開發流程中，Code Review（代碼審查）往往面臨兩難境地：要麼因為趕進度變成了形式主義的 “LGTM” (Looks Good To Me)，要麼 Reviewer 在疲勞中忽略了隱蔽的事務失效、併發安全或前端的響應式丟失等深層問題。 特別是在引入 AI 輔助編程工具（如 Spec Kit）後，雖然代碼生成的效率大幅提升，但代碼的邏輯健壯性依然需要嚴格把關。在執行 git comm

後端

blossom - 拒絕 if-else：利用 Jackson 多態註解 (@JsonTypeInfo) 重構複雜的 IM 消息處理邏輯

引言：被“上帝類”支配的恐懼 在後端開發中，對接第三方 IM 系統（如微信、企業微信、或 RPA 機器人）的回調接口往往是一場噩夢。 通常，上游為了省事，會丟給你一個聚合的 JSON。不管消息是文本、圖片、還是系統通知，數據都塞在一個通用的 payload 對象裏，全靠外層的 messageType 來區分。 為了接收這個 JSON，我們往往會被迫寫出一個 "上帝類" (God Class)： /

後端

blossom - 拒絕 Token 焦慮：我在 Spec Kit 開發中總結的 3 個“摳門

引言：AI 很好用，但 Token 真的很貴 在 AI 輔助編程（如 Spec Kit）日益普及的今天，我們往往會陷入一種兩難：既想讓 AI 幫我們幹完所有髒活累活，又看着後台飛速消耗的 Token 感到肉疼。 尤其是在處理複雜需求時，隨着對話輪數的增加，上下文（Context Window）會變得極長。這不僅意味着 Token 消耗呈指數級增長，更糟糕的是，上下文越長，AI 的“注意力”越分散，

後端

blossom - Spec Kit 踩坑實錄：為什麼我嚴格走了7步，AI 生成的代碼還是沒法用？

引言：完美的流程，崩塌的結果 最近我在使用 Spec Kit 做需求開發。這套工具宣稱通過標準化的 7 個步驟——Specify（定義）、Clarify（澄清）、Plan（計劃）、Tasks（任務）、Analyze（分析）、Checklist（檢查）、Implement（實現）——來生成高質量代碼。 我的初衷是美好的：輸入需求，喝杯咖啡，輸出代碼。 但現實給了我一記響亮的耳光。當我滿懷期待地跑到第

後端

blossom - Spring Boot 三層架構解密：從 Controller 到 Repository 的數據之旅

在構建 Spring Boot 應用時，初學者最容易犯的錯誤就是把所有的邏輯——參數接收、業務判斷、SQL 查詢——都塞進一個類裏。這種“麪條式代碼”不僅難以維護，而且充滿安全隱患。 為了解決這個問題，現代後端開發普遍採用 三層架構 (Three-Tier Architecture)。這種架構的核心思想是**“各司其職”**。 今天，我們就來拆解 Controller、Service、Reposi

後端

blossom - Spec Kit 實戰：如何編寫 Constitution 中的“技術棧” (Tech Stack)

在 Spec Kit 的方法論中，Constitution（憲法） 扮演着至關重要的角色。它是所有 AI Agent（如 Specify Agent）必須遵守的最高法律。 而在憲法中，技術棧（Tech Stack） 部分不僅僅是一份“我們用了什麼庫”的清單，它是指導 AI 如何寫代碼、如何架構項目、如何複用組件的 “技術立法”。 如果説 Spec 是在告訴 AI “做什麼”（業務需求），那麼 Co

後端