Daily Digest

每日新聞摘要

2026年03月04日

今日總結

內容會跟隨語言切換。

📝 今日焦點:說明 Spring AI 1.1 的遞迴顧問如何在顧問鏈下游重試 LLM 呼叫(含 ToolCallAdvisor 與 StructuredOutputValidationAdvisor 的用途),示範自訂 QualityCheckAdvisor 與以 chain.copy(this).nextCall() 重試的模式;此設計提升輸出可靠度,但需明確重試上限以避免無窮迴圈與非預期成本。 📝 今日焦點:簡短介紹 Trail for Android 作為自我架設的連結日誌原生用戶端,指出其定位與用途,並引導讀者至完整 Medium 文章以取得實作細節與使用情境。 🔧 效能最佳化:討論遞迴顧問與工具呼叫的取捨 — 重試能提升結果品質但增加 API 成本、延遲與 token 使用,且需在非串流模式下運作以避免迴圈;Media3Watch 透過 ABR 遙測與離線韌性設計來觀察與優化自適應串流行為;Jetpack Compose 的 lifecycle-aware 收集可避免在非活躍 UI 狀態下浪費資源,三者均強調觀測與上限策略以控管成本與效能。 🏗 架構設計:Media3Watch 的工程優先順序聚焦離線韌性、偵錯覆層與打包發佈(Maven Central),目的是提高穩定性與採用率;同時,文章以 Trunk-Based Development 主張頻繁合併與短期變更(配合功能開關與 CI),以降低整合風險並加速持續交付,兩者分別處理系統可靠度與團隊協作流程。 ✅ 測試與品質:示範如何用 mock ChatModel 驗證遞迴顧問的重試行為並確認重試次數上限,強調必須在測試中覆蓋重試與失敗情境;此外比較 collectAsState 與 collectAsStateWithLifecycle,建議在需尊重元件生命週期時採用後者以避免非必要更新與資源浪費,提升 UI 穩定性與可測性。 🚀 語言演進:Android 17 的聯絡人選取器改變應用存取通訊錄的模式,允許使用者僅授予單一聯絡項目(如單一電話號碼),大幅降低隱私暴露與權限摩擦,對偏好最小資料存取與提升使用者信任的應用具有直接正面影響。

01

A Guide to Spring AI Recursive Advisors

Baeldung 作者:Ralf Ueberfuhr 發布:03-04 08:23

Spring AI 遞迴顧問指南

遞迴顧問可以多次迴圈執行下游顧問鏈,重複呼叫 LLM 直到滿足特定條件。

重點摘要

遞迴顧問使下游顧問與 LLM 呼叫可重複執行以實現重試與迭代
內建 ToolCallAdvisor(工具呼叫回圈)與 StructuredOutputValidationAdvisor(結構化輸出驗證)
務必設定終止條件,僅支援非串流模式,且會增加成本與延遲

本教程說明 Spring AI 1.1 的遞迴顧問概念:它可在顧問鏈下游反覆執行,對 LLM 進行多次呼叫以達成條件。內建兩種實作:ToolCallAdvisor(將工具呼叫回圈移入顧問鏈,使其他顧問可見每次工具呼叫)與 StructuredOutputValidationAdvisor(根據 Java record 派生的 schema 驗證 LLM 的 JSON 輸出,失敗時重試)。範例展示如何建立自訂 QualityCheckAdvisor,透過 augment prompt 並以 chain.copy(this).nextCall() 重新執行下游鏈以重試;並說明用 mock ChatModel 做測試以驗證重試次數。文章也討論排序、成本、延遲與 token 使用等取捨,強調必須設定重試上限以避免無窮迴圈。

02

From Alpha to Almost-Production: Building Media3Watch Part 2

Medium Kotlin 作者:Oğuzhan Ekşi 發布:03-04 07:38

從 Alpha 到準生產:建置 Media3Watch(第二部分)

透過完成離線韌性、ABR 遙測、偵錯覆層與在 Maven Central 發表等項目,清除路線圖上的待辦事項。

重點摘要

實作離線韌性以在離線或網路不穩時維持功能
加入 ABR 遙測以觀察自適應碼率行為
建立偵錯覆層並準備在 Maven Central 發布套件

本文第二部分描述將 Media3Watch 從 alpha 推向接近生產的過程,作者透過完成路線圖上的幾項任務來推進:實作離線韌性、加入 ABR 遙測、建立偵錯覆層,以及準備在 Maven Central 發布套件。文章說明每項工作的目的──在無網路時維持播放、觀察自適應碼率行為、提供執行時偵錯工具,並透過 Maven 簡化套件發佈與採用,同時概述工程優先順序、測試與遙測收集策略,以及包裝與發佈上的實務考量,幫助專案朝穩定與更廣泛採用邁進。

03

Why Every Dev Should Merge Daily (And Stop Hoarding Features)️

Medium Kotlin 作者:RAFA 發布:03-04 09:11

為何每位開發者都應每天合併(別再囤積功能)

每天合併並採用 Trunk-Based Development,可避免長期分支與功能囤積。

重點摘要

主張每天合併以避免長期存在的分支
反對在私人分支中囤積未完成功能
介紹以主幹為中心的 Trunk-Based Development 工作流

文章主張開發者應該將變更每天合併到主幹,而不是累積成長期存在的功能分支。作者指出,將未完成的功能隔離在私人分支會造成整合延遲、回饋不足與更多衝突。作為解方,文中介紹 Trunk-Based Development:以單一共用主幹為中心、頻繁整合與短期變更(常搭配功能開關或小量增量提交)。文章也說明採用此方法需要的文化與流程調整,例如持續整合、頻繁審查與可測試的小步提交。整體目的在說服開發者與團隊透過每天合併與主幹開發,提升協作效率、降低整合風險並加速更安全的持續交付。

04

Trail for Android: A Native Client for Your Self-Hosted Link Journal

Medium Kotlin 作者:Jan Rabe 發布:03-04 12:40

Trail for Android:為自我架設的連結日誌打造的原生用戶端

我喜歡分享我發現的事物。

重點摘要

介紹 Trail for Android,作為自我架設連結日誌的原生用戶端
作者 Jan Rabe 表示他習慣分享有價值的發現
文章片段短促,並引導讀者在 Medium 閱讀完整內容

本文片段介紹 Trail for Android,一款定位為自我架設連結日誌(link journal)的原生 Android 用戶端。作者 Jan Rabe 以自己喜歡分享發現為開場,舉例包括切中要點的部落格文章、優雅解決問題的專案以及改變視角的演講等,並將 Trail 放在這種蒐集與分享連結的實務脈絡中。本文段落簡短,主要功能是引介並指向 Medium 上的完整文章,讓有興趣的讀者取得實作細節、功能說明與使用說明。大意強調使用者可在自我架設的環境中蒐集、整理並分享連結,並以原生行動用戶端提升行動端的捕捉與檢視體驗。

05

collectAsState vs collectAsStateWithLifecycle in Jetpack Compose

Medium Kotlin 作者:Nirali Pandya 發布:03-04 03:10

Jetpack Compose 中的 collectAsState 與 collectAsStateWithLifecycle 比較

在使用 Jetpack Compose 開發 Android 應用時,常在 ViewModel 中使用 Flow 或 StateFlow。

重點摘要

在 ViewModel 中暴露 Flow 或 StateFlow
資料流會隨時間發出,需要在 Compose 中收集
比較 collectAsState 與具生命週期感知的 collectAsStateWithLifecycle

本文說明在 Jetpack Compose 開發中,常於 ViewModel 使用 Flow 或 StateFlow 來持續發出資料,並比較 collectAsState 與 collectAsStateWithLifecycle 兩種在 Compose 中將 flow 轉為 State 的做法。文章說明生命週期感知在收集資料流時的重要性,指出何種情境適合直接使用 collectAsState、何時應採用 collectAsStateWithLifecycle 以避免在非活躍 UI 狀態下處理更新或浪費資源,並提供實務上的使用建議,協助開發者依據元件生命週期正確整合 ViewModel 的資料流。

06

Revolutionizing Privacy: A Deep Dive into the Android 17 Contact Picker

Medium Kotlin 作者:Pankaj Rai 發布:03-04 05:42

革命化隱私:深入探討 Android 17 的聯絡人選擇器

多年來,Android 的「聯絡人」權限一直是開發者與使用者之間的摩擦點。

重點摘要

回應長期存在的聯絡人權限摩擦
允許挑選單一電話號碼而非授予整本通訊錄權限
降低隱私暴露並簡化開發者常見需求的實作

Android 17 的聯絡人選擇器重新定義應用存取通訊錄的方式,回應多年來「聯絡人」權限對開發者與使用者造成的摩擦。新機制允許使用者直接挑選個別聯絡項目(例如單一電話號碼),應用程式僅能取得被選取的資料,無需全面授權整本通訊錄。這可降低隱私暴露、減少權限提示並簡化針對撥號或傳訊等常見需求的實作。文章探討為何聯絡人權限問題嚴重、選擇器如何緩解這些問題,以及這項設計轉變對於開發重視隱私應用的意義。透過限制資料存取,Android 17 希望在維持功能性的同時提升使用者信任。