TechSummary 2025-09-04
· 閱讀時間約 13 分鐘
💡 使用 MCP 引導機制打造更智能的互動：從繁瑣的工具呼叫到流暢的使用者體驗
- 本文探討了如何透過 MCP (Multi-Modal Chat Protocol) 中的引導 (elicitation) 機制，改進 AI 應用（如 GitHub Copilot）與使用者的互動體驗，使其更加自然和無縫。引導機制讓 AI 在缺少必要資訊時能主動暫停並提問，而非僅依賴預設值。
- 範例應用: 在建立回合制遊戲（如井字遊戲、剪刀石頭布）時，若使用者未提供難度、玩家名稱或先手順序等資訊，AI 會透過引導機制提問，而不是直接使用預設值。
- 實作挑戰與解決方案:
- 工具命名混淆: 過去因工具名稱相似（如
create-tic-tac-toe-game與create-tic-tac-toe-game-interactive），導致 AI 選錯工具。解決方案是合併工具並使用清晰、獨特的名稱（例如：將八個工具縮減為create-game、play-game、analyze-game、wait-for-player-move）。 - 處理部分資訊: 直播時發現引導機制會重複詢問所有偏好，即使部分資訊已提供。修復方式是在工具被呼叫後檢查已提供的資訊，只引導詢問缺失的部分。
- 工具命名混淆: 過去因工具名稱相似（如
- 內部工作原理: MCP 伺服器在呼叫
create_game工具時，會檢查所需參數、將選用參數傳遞給獨立方法、若資訊缺失則啟動引導機制、呈現基於 schema 的提示、收集回應，最終執行createGame方法。 - 重要學習: 使用者體驗、工具命名清晰度和迭代開發對於建立更優質的 AI 工具至關重要。
🧠 混合式 AI 已來臨，並在 Docker 中運行
Source: https://www.docker.com/blog/hybrid-ai-and-how-it-runs-in-docker/
- 核心概念: 混合式 AI (Hybrid AI) 結合了強大的雲端模型（監督者，Supervisor）與高效的本地模型（小兵，Minions），在效能、成本和隱私之間取得平衡，解決了 GenAI 應用在處理大型文件或複雜工作流程時，品質與成本之間的權衡問題。
- Minions 協議: 遠端模型（Supervisor）不直接處理所有數據，而是生成 可執行程式碼來分解任務；本地模型（Minions）在 Docker 容器中執行這些平行子任務；遠端模型最終聚合結果。
- Docker 化實作範例:
- 使用
docker compose up啟動 Minions 應用伺服器。 - 遠端模型接收請求，生成協調程式碼。
- 協調程式碼在 Docker 容器內的 Minions 應用伺服器中執行，提供沙盒隔離。
- 本地模型平行處理子任務（如分析文件塊、摘要、分類）。
- 結果返回給遠端模型進行彙總。
- 使用
- 優勢:
- 成本降低: 本地模型處理大部分 tokens，顯著減少雲端模型使用量（MinionS 協議可降低 5.7 倍成本，同時保持 97.9% 效能）。
- 可擴展性: 將大型任務分解為小型任務，可在本地模型間水平擴展。
- 安全性: 應用伺服器在 Docker 容器中運行，提供沙盒隔離，確保動態協調的安全性。
- 開發者簡便性: Docker Compose 將所有配置整合到單一檔案，無需複雜環境設定。
- Docker Compose 配置範例:
此配置可啟動一個運行 Llama 3.2 模型並擁有 10k 上下文視窗的本地 worker。
models:
worker:
model: ai/llama3.2
context_size: 10000 - 權衡: 儘管顯著降低雲端成本，但由於任務拆分、本地處理和聚合，回應時間可能會較慢（約 10 倍）。
🔍 靜態程式碼分析提升開發者體驗的五種方式
Source: https://blog.jetbrains.com/qodana/2025/09/improve-developer-experience/
- 靜態程式碼分析 (Static Code Analysis) 是一種強大的工具，無需運行程式碼即可檢查潛在問題，從而減少開發人員的摩擦，使他們能更專注於解決問題。
- 提升開發者體驗的五種方式:
- 更快的反饋循環: 直接整合到開發環境或 CI/CD 管線中，提供即時的錯誤、風格違規和安全漏洞洞察，讓開發者在編碼時就能即時修復問題。
- 降低認知負荷: 作為安全網，自動捕捉程式碼標準違規、不安全結構，並提醒最佳實踐，減少記憶所有規範的心理負擔。
- 改進程式碼品質和一致性: 強制專案的編碼標準，確保一致性和可讀性；檢測常見錯誤模式，如空指針解引用、未初始化變數。
- 整個生命週期的時間節省: 在開發早期階段捕獲問題，大幅降低發布後修復缺陷的成本；透過預過濾瑣碎問題，讓程式碼審查更專注於架構和邏輯。例如，Qodana 提供的快速修復功能能節省大量時間。
- 與現代開發者體驗工具整合: 與 CI/CD 管線整合，建立自動化的品質門禁；與 IDE 整合，提供即時回饋；甚至可將發現結果與合規標準對齊。
- 結論: 靜態程式碼分析不僅是錯誤捕獲工具，更是改善開發者體驗、提高生產力和交付更高品質軟體的關鍵。
🛠️ ReSharper 與 Rider 2025.2.1 更新與修正已發布！
Source: https://blog.jetbrains.com/dotnet/2025/09/04/resharper-and-rider-2025-2-1-is-out/
- JetBrains 發布了 ReSharper 和 Rider 2025.2 的首個錯誤修復更新，帶來了重要的修正和品質改進，以及針對性的效能優化。
- ReSharper 2025.2.1 關鍵更新:
- Unity 支援 整合至命令列工具 (CLT): ReSharper 的 Unity 專屬檢查和清理規則現在可以在
inspectcode和cleanupcode等命令列工具中運行，確保 IDE 和 CI/CD 管線之間的一致性。 - 重要修正:
- ReSharper C++ 在獨立安裝時可在 Out-of-Process (OOP) 模式下運行。
- C++ 單元測試可在 OOP 模式下執行。
- Search Everywhere 對話框即使在解決方案未完全載入的情況下也能在 OOP 模式中獲得焦點。
- 恢復了 OOP 模式下 IDE 快捷鍵的正確行為。
- 修復了 Visual Studio 觸發 ReSharper 動作或開啟擴充功能選單後可能凍結的問題。
- 恢復了異步上下文中程式碼自動完成的正確行為。
- Unity 支援 整合至命令列工具 (CLT): ReSharper 的 Unity 專屬檢查和清理規則現在可以在
- Rider 2025.2.1 關鍵更新:
- 單元測試: 單元測試探查器不再顯示重複條目，包括 xUnit 專案。
- 偵錯: 使用嵌入式偵錯符號時，Edit & Continue 功能恢復正常；修復了偵錯器在異常處停止但不允許恢復執行的問題。
- AI 助手: 修復了 AI 助手在 C# 專案中可能生成 C++ 程式碼片段的問題。
- 其他修正: Encapsulate Field 重構快捷鍵恢復；GDScript 檔案正確識別；環境變數中的分號值處理問題；Frame Viewer 相關修復；Create Branch 操作的可用性恢復；Windows 上 Dynamic Program Analysis (DPA) 快照檔案未清理的問題；macOS 上 Monitoring 工具視窗的 CPU 使用率優化。
- 下載方式: 可透過 JetBrains 網站或 Toolbox App 下載最新版本。
🗓️ JetBrains JavaScript Day 2025 開放報名
Source: https://blog.jetbrains.com/webstorm/2025/09/jetbrains-javascript-day-2025-registration-is-now-open/
- JetBrains 宣布第五屆年度 JavaScript Day 免費線上活動已開放報名。
- 活動資訊:
- 日期: 2025 年 10 月 2 日
- 時間: 美東時間上午 9:00 / 中歐夏令時間下午 3:00
- 地點: 線上舉行
- 費用: 免費
- 活動內容: 將匯集 JavaScript 領域具啟發性的講者，分享他們的故事、想法和經驗教訓，提供實用的見解，幫助參與者在快速發展的 JavaScript 生態系統中保持領先。
- 部分講者與主題包括:
- Craig Spence: Quantumania.js
- Alexander Lichter: Faster Builds and Fewer Headaches with Modern JavaScript Tooling
- Victor Savkin: Beyond Build Orchestration: What It Takes to Build Modern JavaScript Monorepos
- Kent C. Dodds: The New User Interaction Model
- Ryan Carniato: Beyond Signals
- Jan-Niklas Wortmann: JetBrains Doesn’t Want Me To Give This Talk
- Lydia Hallie: Bun: The Fast JavaScript Runtime
- Jessica Janiuk: Tough Decisions: the complexities of maintaining a popular open source project
✨ Kotlin 2.2 改善註解處理：減少樣板程式碼，減少意外
- Kotlin 2.2 針對註解處理進行了改進，解決了與 Spring 或 JPA 等框架協作時，註解行為可能不如預期的問題，減少了樣板程式碼並帶來更可預測的行為。
- 過去問題: 在 Kotlin 2.2 之前，諸如
@NotBlank或@Email等註解若應用於建構函式參數，預設只會應用到參數本身 (@param)。這意味著屬性驗證只在物件首次創建時發生，而不會在後續屬性更新時觸發。public class Order {
@Id @GeneratedValue private final long id;
@NotNull private String name;
@NotNull private String email;
public Order(long id, @NotBlank @NotNull String name, @Email @NotNull String email) { /* ... */ }
} - 舊的解決方案: 必須明確指定 use-site target，如使用
@field:來確保註解應用於底層欄位或屬性，這增加了程式碼的冗餘。@Entity
class Order(
@field:Id @GeneratedValue val id: Long,
@field:NotNull var name: String,
@field:Email var email: String
) - Kotlin 2.2 的新預設行為:
- 自 Kotlin 2.2 起，沒有明確指定 use-site target 的註解將同時應用於建構函式參數和屬性/欄位，與大多數框架的預期行為保持一致。
- 原始的簡潔程式碼現在能如預期般工作，無需額外的
@field:語法。
@Entity
class Order(
@Id @GeneratedValue val id: Long,
@NotBlank var name: String,
@Email var email: String
) - 如何啟用新行為:
- 需要 Kotlin 2.2。預設情況下，編譯器會針對行為可能改變的程式碼發出警告。
- 在
build.gradle.kts中添加以下編譯器選項以完全啟用新行為：kotlin {
compilerOptions {
freeCompilerArgs.add("-Xannotation-default-target=param-property")
}
} - 若想保留舊行為或過渡模式，可使用
-Xannotation-defaulting=first-only或-Xannotation-defaulting=first-only-warn。
- 重要性: 此改變使註解行為更具可預測性，減少樣板程式碼，並消除了 Spring 和 JPA 開發人員多年來面臨的一類潛在錯誤，提升了 Kotlin 與主流框架的整合體驗。
🤝 如何利用 AI 增強 Scrum 儀式
Source: https://dzone.com/articles/ai-enhance-scrum-ceremonies
- Scrum 作為主流的敏捷開發方法，其核心儀式包括衝刺規劃、每日站會、衝刺審查和衝刺回顧，旨在促進協作、對齊和交付。
- Gartner 的報告指出，87% 執行敏捷開發的組織採用 Scrum。
- 人工智慧 (AI) 透過應用進階分析和基於邏輯的技術（包括機器學習），可以解釋事件、支持和自動化決策並採取行動，從而增強這些 Scrum 儀式，提升其效率和洞察力。
🔒 在 LLM 應用中保護 PII：資料匿名化的完整指南
Source: https://dzone.com/articles/llm-pii-anonymization-guide
- 組織渴望利用大型語言模型 (LLM) 解決業務問題，但對於將敏感資料（特別是個人身份資訊 PII）傳輸到第三方託管模型存在顧慮。
- 本文探討了一種強大的緩解技術：資料匿名化 (anonymization) 與去匿名化 (de-anonymization)，以在保護敏感資料的同時，有效利用企業環境中的 LLM。
🔗 供應鏈攻擊時代的 CI/CD：如何保護每個提交
Source: https://dzone.com/articles/ci-cd-pipeline-security-supply-chain
- 數位基礎設施的脆弱性日益顯現，一次受損的依賴、惡意提交或被忽視的漏洞都可能導致整個系統崩潰。例如，2024 年 3 月發現的 XZ Utils 後門事件，凸顯了精心策劃的供應鏈攻擊對開源開發基礎的威脅。
- 本文強調在 CI/CD (持續整合/持續交付) 管道中保護每一個提交的重要性，呼籲業界應將供應鏈安全視為必須解決的關鍵問題，以應對日益複雜的網路攻擊。
🤔 建立 AI 代理前需問的 5 個關鍵問題
Source: https://dzone.com/articles/agentic-ai-questions-adoption
- 代理式 AI (Agentic AI) 正在改變遊戲規則，但公司在急於建構或部署 AI 代理之前，必須提出一些關鍵問題。
- 並非所有問題都需要 AI 代理來解決，如果沒有正確的基礎，尤其是在資料方面，代理式 AI 可能會迅速變成一個昂貴且高風險的錯誤。
- 本文旨在引導組織在自動化代理式 AI 之前進行深思熟慮的規劃，避免資源浪費和錯失機會。
💰 手動 K8s 成本優化的無止境循環耗費組 織巨大成本
Source: https://dzone.com/articles/the-endless-cycle-of-manual-k8s-cost-optimization
- Kubernetes (K8s) 的開發人員和 DevOps 團隊通常將重心放在效能上，而對成本方面關注較少。當工作負載運行順暢並符合服務級別協議 (SLA) 時，預算考量往往退居次位，直到外部壓力（通常來自財務團隊）要求進行優化。
- 然而，忽略成本直到財務介入的現實，會導致效率低下和資源浪費，最終耗費大量時間和精力於成本優化，這些時間本可以用於其他戰略性計畫。這強調了需要更主動、系統化的 K8s 成本管理方法。
🚀 將 AI 帶出孤島——為何團隊經驗超越開發者工具
Source: https://dzone.com/articles/rethinking-ai-team-productivity
- 許多 AI 實作僅專注於單一步驟的局部優化，而忽略了團隊協作的整體情境。本文認為，在設計產品時，最佳方法是重新構想問題，而非僅做漸進式改進。
- 質疑為何 在 AI 作為近年來最大的技術創新時，許多產品卻仍專注於單獨改進每個步驟，而不是從團隊協作的角度來完成工作。
- 提倡將 AI 應用從孤立的個人工具提升到促進團隊生產力和整體體驗的層面，強調團隊經驗在充分發揮 AI 潛力方面的重要性。