TechSummary 2025-09-03

🤖 撰寫 Copilot 自訂指令的 5 個技巧

Source: https://github.blog/ai-and-ml/github-copilot/5-tips-for-writing-better-custom-instructions-for-copilot/

• Copilot 指令文件 (copilot-instructions.md) 至關重要，它能為 Copilot 提供專案的必要上下文，如同新人入職時的背景知識，有助於避免混淆和錯誤。
• 專案概覽： 指令文件應以專案的「電梯簡報」開頭，簡潔描述應用程式的目標、受眾和主要功能。

  # Contoso Companions
  
  This is a website to support pet adoption agencies. Agencies are onboarded into the application, where they can manage their locations, available pets, and publicize events. Potential adoptors can search for pets available in their area, discover agencies, and submit adoption applications.

• 技術棧識別： 明確列出專案使用的後端、前端技術、API 和測試套件，並可簡要說明其用途，幫助 Copilot 理解開發環境。

  ## Tech stack in use
  
  ### Backend
  
  - Flask is used for the API
  - Data is stored in Postgres, with SQLAlchemy as the ORM
    - There are separate database for dev, staging and prod
    - For end to end testing, a new database is created and populated,
      then removed after tests are complete
  
  ### Frontend
  
  - Astro manages the core site and routing
  - Svelte is used for interactivity
  - TypeScript is used for all front-end code
  
  ### Testing
  
  - Unittest for Python
  - Vitest for TypeScript
  - Playwright for e2e tests

• 編碼規範： 詳述專案的編碼風格、標準和測試要求，例如型別提示、分號使用、單元測試和端對端測試的規定等，這部分可獨立成區塊。

  ## Project and code guidelines
  
  - Always use type hints in any language which supports them
  - JavaScript/TypeScript should use semicolons
  - Unit tests are required, and are required to pass before PR
    - Unit tests should focus on core functionality
  - End-to-end tests are required
    - End-to-end tests should focus on core functionality
    - End-to-end tests should validate accessibility
  - Always follow good security practices
  - Follow RESTful API design principles
  - Use scripts to perform actions when available

• 專案結構說明： 描述專案的文件夾結構及其內容，可幫助 Copilot 快速定位並理解各部分功能。

  ## Project structure
  
  - server/ : Flask backend code
    - models/ : SQLAlchemy ORM models
    - routes/ : API endpoints organized by resource
    - tests/ : Unit tests for the API
    - utils/ : Utility functions and helpers, including database calls
  - client/ : Astro/Svelte frontend code
    - src/components/ : Reusable Svelte components
    - src/layouts/ : Astro layout templates
    - src/pages/ : Astro pages and routes
    - src/styles/ : CSS stylesheets
  - scripts/ : Development, deployment and testing scripts
  - docs/ : Project documentation to be kept in sync at all times

• 指向可用資源： 列出專案中可用的腳本或工具，如開發、部署和測試腳本，或特定的 MCP 伺服器，以提高 Copilot 的準確性和速度。

  ## Resources
  
  - scripts folder
    - start-app.sh : Installs all libraries and starts the app
    - setup-env.sh : Installs all libraries
    - test-project.sh : Installs all libraries, runs unit and e2e tests
  - MCP servers
    - Playwright: Used for generating Playwright tests or interacting with site
    - GitHub: Used to interact with repository and backlog

• Copilot 輔助生成指令文件： Copilot 自身也能協助創建 copilot-instructions.md 文件，提供標準化的提示範本，幫助開發者釐清專案目標。

  Your task is to "onboard" this repository to a coding agent by adding a .github/copilot-instructions.md file. It should contain information describing how the agent, seeing the repo for the first time, can work most efficiently.
  ...
  ## Guidance
  
  Ensure you include the following:
  
  - A summary of what the app does.
  - The tech stack in use
  - Coding guidelines
  - Project structure
  - Existing tools and resources

• 強調指令文件無需完美，但有總比沒有好，且應隨著專案演進而更新。

💡 您對 MCP 的理解有誤：3 大迷思

Source: https://www.docker.com/blog/mcp-misconceptions-tools-agents-not-api/

• 誤解一：「MCP 只是另一個 API」。 MCP (Model Context Protocol) 是一個為 LLM 工具使用、意圖調解和上下文交換設計的模型導向協議，旨在讓非確定性代理能安全有效地使用底層 API，而非取代傳統 RPC。
  • MCP 提供具有意圖和功能的工具介面、超越請求/響應的上下文介面，以及非確定性規劃與確定性執行之間的可靠銜接點。
  • 設計模式建議：在 MCP 工具定義中包裹穩定業務 API，表達前置條件、成功標準和模型可推論的功能；將工具執行視為確定性且冪等，並驗證模型規劃衍生的輸入。
• 誤解二：「工具就是代理 (Agents)」。 工具只負責執行特定任務，而代理則具備目標追蹤、重新規劃、錯誤恢復和評估功能，並會循環執行直到目標達成。
  • 代理具備代理性、評估能力以及記憶和上下文管理。
  • 設計模式建議：將代理控制迴圈置於工具之外，負責決定下一步運行哪個工具；給予代理可量化的成功指標；在信心不足或存在歧義時，透過 MCP 提示向用戶尋求澄清。
• 誤解三：「MCP 僅限於工具」。 MCP 除了工具定義外，還包含資源 (Resources)、提示 (Prompts) 和引導 (Elicitations)，這些都是上下文豐富工作的一等公民。
  • 忽略其他部分將錯失結構化的知識庫（資源）、可重複使用且版本化的指令集（提示），以及在用戶輸入可解決歧義時的人工回饋機制（引導）。
  • 設計模式建議：將知識庫、文件等映射為具權限和生命週期的 MCP 資源；將提示視為程式碼，進行版本控制、測試和回滾；定義何時觸發用戶輸入以及如何恢復流程。
• 整合： MCP 作為非確定性（模型規劃、工具選擇）與確定性（工具執行、驗證）層之間的橋樑，透過工具、資源、提示和引導，連接智慧行為與可靠系統，確保 AI 系統的可觀察性和治理。

🔒 JetBrains IDEs 和 Qodana 中增強的弱點 API 檢測

Source: https://blog.jetbrains.com/idea/2025/09/enhanced-vulnerable-api-detection-in-jetbrains-ides-and-qodana/

• JetBrains IDEs (如 IntelliJ IDEA) 和 Qodana 已強化其弱點 API 檢測功能，透過與 Mend.io 的合作，提供關於開源函式庫中易受攻擊方法的數據。
• 弱點 API 功能： Package Checker 插件利用 Mend.io 的數據，並透過分析呼叫圖 (call graphs) 來豐富數據，識別並高亮顯示程式碼中使用的弱點方法。
• 支援語言： 該功能支援 Java、Kotlin、C# (在 Rider 和 ReSharper 中)、JavaScript、TypeScript 和 Python 等多種語言。
• 啟用方式： 在 IDE 設定 (macOS: ⌘, / Windows/Linux: Ctrl+Alt+S) 中，導航至 Editor | Inspections，搜尋「Vulnerable API」並選擇要啟用的檢測項目。
• 使用方式：
  • 高亮顯示的弱點程式碼會顯示詳細的漏洞資訊。透過上下文動作 (macOS: ⌥⏎ / Windows/Linux: Alt+Enter) 可導航至宣告依賴的文件，並提供更新至不受影響版本的選項。
  • 專用的「Vulnerable Dependencies」視窗提供專案的整體漏洞狀態和每個檢測到的弱點依賴項的詳細資訊。
• CI/CD 整合： 弱點 API 和弱點依賴項功能也適用於 Qodana，可無縫整合到 CI/CD 或安全評估流程中，提升自動化安全檢測能力。

🐳 Kubernetes v1.34: Service Account Token 用於映像拉取晉升為 Beta 版

Source: https://kubernetes.io/blog/2025/09/03/kubernetes-v1-34-sa-tokens-image-pulls-beta/

• 背景： Kubernetes v1.34 將服務帳戶令牌集成用於 Kubelet 憑證提供者 (Credential Providers) 的功能升級至 Beta 版，旨在減少對長效憑證的依賴，提供更安全、更短暫的映像拉取憑證。
• Beta 版新特性：
  • cacheType 欄位為必填： 在憑證提供者配置中，cacheType 欄位現在為必填，用於指定兩種緩存策略：
    • Token: 憑證生命週期與令牌綁定，適用於憑證生命週期與令牌相同的情況。
    • ServiceAccount: 憑證在相同服務帳戶的所有 Pod 中有效，可跨 Pod 復用。

    tokenAttributes:
      serviceAccountTokenAudience: "my-registry-audience"
      cacheType: "ServiceAccount" # Required field in beta
      requireServiceAccount: true

  • 隔離的映像拉取憑證： Beta 版提供了更強大的安全性隔離。系統會追蹤拉取映像時使用的 ServiceAccount 身份 (namespace, name, UID)，確保 Pod 只能存取由其授權的 ServiceAccount 拉取的映像。
• 運作方式：
  • 配置： 憑證提供者透過配置 tokenAttributes 欄位來啟用服務帳戶令牌。

    apiVersion: kubelet.config.k8s.io/v1
    kind: CredentialProviderConfig
    providers:
    - name: my-credential-provider
      matchImages:
      - "*.myregistry.io/*"
      defaultCacheDuration: "10m"
      apiVersion: credentialprovider.kubelet.k8s.io/v1
      tokenAttributes:
        serviceAccountTokenAudience: "my-registry-audience"
        cacheType: "ServiceAccount" # New in beta
        requireServiceAccount: true
        requiredServiceAccountAnnotationKeys:
        - "myregistry.io/identity-id"
        optionalServiceAccountAnnotationKeys:
        - "myregistry.io/optional-annotation"

  • 映像拉取流程： Kubelet 協調憑證提供者和容器執行時，根據 cacheType 策略緩存憑證，並記錄 ServiceAccount 座標進行後續授權檢查。
  • 受眾限制 (Audience restriction)： 透過 RBAC (Role-Based Access Control) 配置，確保 Kubelet 只能為授權的受眾請求服務帳戶令牌，進一步增強安全性。

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: kubelet-credential-provider-audiences
    rules:
    - verbs: ["request-serviceaccounts-token-audience"]
      apiGroups: [""]
      resources: ["my-registry-audience"]
      resourceNames: ["registry-access-sa"] # Optional: specific SA

• 遷移與使用： 需要 Kubernetes v1.34 或更高版本，並啟用 KubeletServiceAccountTokenForCredentialProviders=true 特性閘道（默認啟用）。現有 Alpha 版使用者需更新其憑證提供者配置，加入 cacheType 欄位並審查緩存策略。

📊 使用 Google Cloud Platform 和 Apache Airflow 開發全國性即時遙測分析平台

Source: https://dzone.com/articles/real-time-telemetry-gcp-airflow

• 專案目標： 在 TELUS 內部，開發一個能夠即時分析加拿大境內超過 100,000 個機上盒 (STB) 數據的遙測分析平台。
• 核心目的： 透過即時數據分析，協助團隊更快做出營運決策，並提升數百萬客戶的體驗。
• 面臨的挑戰： 舊有的數據基礎設施主要依賴於批次處理和孤立的數據管線，無法支援即時診斷，導致數據難以即時傳遞到需要它的團隊，形成營運上的盲點。
• 解決方案： 採用現代化方法，利用 Google Cloud Platform (GCP) 的彈性與可擴展性、Apache Airflow 的工作流編排能力，以及基礎設施即程式碼 (IaC) 工具來克服現有障礙，建立一個面向未來的解決方案。

💻 在生成式 AI 時代評估語言設計：DSLs 與函式庫的比較

Source: https://dzone.com/articles/gpl-vs-dsl-ai-evolution

• 在生成式 AI (GenAI) 時代，程式語言設計中，領域特定語言 (DSLs) 與函式庫 (Libraries) 之間的傳統權衡正在發生變化。
• 傳統範式：
  • 通用程式語言 (GPLs) 具備高度多功能性，並透過豐富的函式庫支援跨多個領域的開發。然而，這種靈活性可能導致需要編寫更多程式碼，且在實現專業解決方案時，需要深厚的領域知識。
  • 領域特定語言 (DSLs)，如 SQL、CSS 或 XAML，專為特定領域設計和優化，提供更高的表達性和簡潔性，但通常在靈活性方面有所限制，並且學習曲線可能不同。
• AI 演進的影響： 隨著 AI 技術的發展，程式碼的編寫方式以及對生產力、可維護性和創新性的定義正在轉變。這使得 DSLs 與函式庫之間的界線變得模糊，並促使業界重新評估它們在表達性、整合複雜性和學習曲線等方面的優勢和挑戰。

🔍 可觀察性的盲點：追蹤 Kafka 管線中的消息丟失

Source: https://dzone.com/articles/observability-tracing-message-drops-kafka-pipelines

• 在分散式系統中，尤其是在高擴展性的消息平台（如 WhatsApp Business 或 IoT 命令鏈）中，事件無聲無息地丟失並非簡單的錯誤，而是架構上的盲點。
• 根本原因： 遙測失敗或消息丟失常常被誤認為應用程式錯誤，但其深層次原因在於事件流中的可觀察性差距。
• 解決方案： 本文探討了後端工程師和 DevOps 團隊如何使用一系列工具來偵測、除錯和預防基於 Kafka 的串流管線中的消息丟失。
• 關鍵工具： 包括 OpenTelemetry 用於分散式追蹤、Fluent Bit 用於日誌聚合、Jaeger 用於追蹤可視化，以及 Dead-Letter Queues (DLQs) 用於處理無法投遞的消息。
• 目標是確保在高併發事件系統中，每個事件都是可追溯和負責任的，從而避免「不可見的」消息丟失問題。

⚙️ 簡單高效的 Spring/Kafka 數據流

Source: https://dzone.com/articles/simple-efficient-springkafka-datastreams

• 文章探討了如何利用 Spring Cloud Data Flow 構建高效能的 Spring/Kafka 數據流，這是一個用於管理串流和批次作業的應用程式。
• 核心架構： 數據流由獨立的資料來源 (data source) 和資料匯 (data sink) 應用程式組成，兩者透過 Kafka 發送的事件實現鬆耦合。這種分離設計提高了系統的靈活性和可維護性。
• 典型應用範例：
  • 串流一： 以 Debezium 作為資料來源，將資料庫的異動資料 (database deltas) 透過 Kafka 發送。資料匯接收事件後，將其轉換為 SOAP 請求並發送給下游應用程式。
  • 串流二： 從應用程式接收 SOAP 請求，將其作為事件發送到 Kafka。隨後，資料匯接收該事件並在資料庫中建立相應的條目。
• 透過 Kafka 作為中間件，這些數據流能夠高效地處理數據傳輸和轉換，支援異步通信模式。

⚡ 理解零拷貝 (Zero-Copy)

Source: https://dzone.com/articles/understanding-zero-copy

• 背景： 在高效能運算和網路應用領域，有效處理數據至關重要。傳統的輸入/輸出 (I/O) 操作通常涉及冗餘的數據複製，這會產生效能瓶頸，限制吞吐量並增加延遲。
• 零拷貝定義： 零拷貝是一種強大的最佳化技術，旨在最小化或消除這些不必要的數據移動，從而顯著提升系統效能。
• 傳統 I/O 路徑的缺點： 想像一個常見場景：應用程式需要從磁碟讀取文件並透過網路傳輸。在傳統 I/O 模型中，這個看似直接的操作會涉及一系列數據複製：
  1. 數據從磁碟複製到作業系統核心緩衝區。
  2. 數據從核心緩衝區複製到應用程式緩衝區。
  3. 數據從應用程式緩衝區複製回核心的 Socket 緩衝區。
  4. 數據從 Socket 緩衝區複製到網路介面卡 (NIC)。
• 這些重複的記憶體複製操作消耗寶貴的 CPU 週期和記憶體頻寬，並增加上下文切換的開銷。零拷貝技術旨在直接在核心空間內傳輸數據，或直接從硬體傳輸到網路，避免多餘的緩衝區複製。

🔗 理解 Apache Spark 連接類型

Source: https://dzone.com/articles/spark-join-types-explained

• 文章探討了 Apache Spark 中資料框 (DataFrame) 或表格連接 (join) 操作的三種主要類型，這是 Spark 數據轉換中最常用的操作之一。
• 連接操作： 在 Apache Spark 中，開發人員可以使用連接操作根據特定（可排序）的鍵來合併兩個或多個數據框。
• 內部機制： 儘管連接操作的語法通常很直接，但其內部的運作機制往往被遮蔽。Apache Spark 內部 API 提供了多種用於連接的演算法，並會自動選擇其中一個。
• 效能考量： 如果開發人員不了解這些核心演算法或 Spark 的選擇機制，一個基本的連接操作可能會變得非常昂貴。因此，理解不同連接類型及其背後的演算法對於編寫高效能的 Spark 應用至關重要。

🛡️ 容器安全要點：從映像到運行時保護

Source: https://dzone.com/articles/container-security-essentials

• 核心目標： 容器安全旨在確保所運行的映像具有極低的漏洞和惡意軟體。儘管實現零漏洞在現實世界中幾乎不可能，但至少需要處理關鍵到中等程度的漏洞，以避免潛在的妥協。
• 多層次防禦： 容器安全可比喻為剝洋蔥，每一層都增加了對潛在威脅的抵禦能力。這意味著需要從多個角度和階段來考慮安全性。
• 涵蓋範圍： 文章將深入探討從容器映像的創建和管理，到運行時環境的保護，可以採取哪些關鍵步驟來提升整個容器基礎設施的整體安全性。
• 這包括但不限於映像掃描、依賴項分析、最小化映像大小、運行時策略執行和網路隔離等措施。

🔑 Ampere® 上的加密函式庫

Source: https://dzone.com/articles/cryptography-libraries-on-ampere

• 背景： 密碼學是透過數學技術保護通訊和數據的科學，其核心目標是確保數據的機密性、完整性和真實性。
• 廣泛應用： 密碼學技術在現代數位世界中無處不在，廣泛應用於網頁服務、負載平衡代理、資料庫加密、安全通訊協議（如 HTTPS）等多個領域。
• 密碼學分類： 密碼學通常可以分為三類（儘管原文未具體展開，但通常包括對稱加密、非對稱加密和雜湊函數）。
• 文章將探討在 Ampere® 架構（通常指基於 ARM 的伺服器處理器）上，加密函式庫的效能和應用。這可能涉及到針對 ARM 架構的特定優化，以及如何利用其特性來提升加密解密操作的效率。

🔐 為什麼零信任不是產品，而是您在 2025 年不可忽視的戰略

Source: https://dzone.com/articles/zero-trust-2025-guide

• 核心觀念： 「零信任」(Zero Trust) 並非一個可購買的產品或解決方案，而是一種必須遵循的思維模式、綜合策略和持續承諾。
• 普遍誤解： 儘管「零信任」在 2025 年已成為一個無處不在的術語，頻繁出現在產品包裝、研討會和銷售演示中，但其基本理念仍被嚴重誤解。
• 重要性： 鑑於不斷擴大的攻擊面、異質性工作環境和日益複雜的威脅行為者，將零信任視為一個簡單的「勾選項目」或單一產品，不僅效率低下，而且會帶來極高的安全風險。
• 組織必須將零信任作為一種貫穿整個基礎設施和營運流程的全面策略來實施，強調「永不信任，始終驗證」的原則，以應對不斷變化的網路安全挑戰。

🗄️ 文件系統與資料庫：一個完整的循環

Source: https://dzone.com/articles/file-systems-and-database-full-circle

• 文件系統的起源與挑戰： 在資料庫管理系統 (DBMS) 發明之前，檔案系統是最初的數據儲存方式。1970 年代，組織手動將數據儲存在多個伺服器上的文件中（如平面文件），導致資料冗餘、一致性、共享、安全和檢索等問題。
• DBMS 的興起： 隨著 DBMS 的發明，資料交易開始符合 ACID 特性（原子性、一致性、隔離性、持久性），從而提供了資料一致性、完整性、恢復能力和併發控制。現代 DBMS 還提供了災難恢復、備份與恢復、數據搜尋、數據加密和安全性等高級功能。
• 檔案儲存的迴歸： 儘管 DBMS 取得了顯著進步，但由於大數據、雲端技術、物聯網、社群媒體以及不斷演進的數據格式（如非結構化和半結構化數據）的發展，檔案儲存再次成為一個熱門話題，形成了一個「完整的循環」。新的技術如數據湖和對象儲存將文件儲存帶到了新的高度，彌補了傳統 DBMS 在某些場景下的不足。

🧠 邁向可解釋 AI (第六部分)：連接理論與實踐 — LIME 揭示了什麼，又遺漏了什麼

Source: https://dzone.com/articles/explainable-ai-what-lime-shows

• 系列回顧： 本系列旨在探索 AI 可解釋性 (Explainable AI, XAI) 如何建立信任、確保問責制並符合實際需求，從基礎原則到實際應用案例。
• 前一部分： 在第五部分中，文章實作介紹了 LIME (Local Interpretable Model-agnostic Explanations) 的應用，透過逐步解釋來偵測肺炎。
• 本文核心： 第六部分著重於連接理論與實踐，深入探討 LIME 這種模型不可知 (Model-agnostic) 的可解釋 AI 技術所能揭示的資訊，以及它在解釋 AI 模型決策過程中可能遺漏或未能完全解釋的部分。
• 目標是理解 LIME 的優勢與局限性，例如它如何透過局部線性模型來解釋單個預測，同時也探討其在複雜特徵交互或全局解釋方面的不足，從而更全面地評估 AI 模型的決策過程。