26 篇文章 含有標籤「Security」

🚀 使用 GitHub Copilot 代理模式現代化 Java 專案的逐步指南​

Source: https://github.blog/ai-and-ml/github-copilot/a-step-by-step-guide-to-modernizing-java-projects-with-github-copilot-agent-mode/

• GitHub Copilot 代理模式將 Copilot 從被動建議工具轉變為主動協作夥伴，能理解高層次指令並執行多步驟任務，無需詳細指示。
• 搭配 GitHub Copilot 應用現代化 VS Code 擴充功能，此工具組提供互動式、逐步指引，幫助開發者更快、更少錯誤地升級和遷移 Java 專案。
• 現代化流程包括：分析專案、生成升級計畫、自動應用變更、修復建構問題、驗證測試、檢測並修復 CVEs，並提供完整的摘要報告。
• 範例指令與程式碼片段：
  • 啟動代理會話後，輸入：

    Using Java upgrade tools,upgrade this project to Java 21. Analyze deprecated APIs, update Gradle dependencies, and propose a safe, testable migration plan.
    

  • 程式碼升級前後對比：

    // Before (deprecated constructor)
    View view = this.resolver.resolveViewName("intro", new Locale("EN"));
    
    // After Java 21 upgrade
    View view = this.resolver.resolveViewName("intro", Locale.of("EN"));
    

• 此外，它還支援將應用程式遷移到 Azure，進行雲端就緒評估，並將認證從地端遷移到 Microsoft Entra ID。
• 自動化 CVE 掃描是其關鍵安全功能，可智慧地提出安全版本替換或推薦替代函式庫，以維持安全合規。

如何使用 Cerebras 和 Docker Compose 建構安全的 AI 編程代理 🔐​

Source: https://www.docker.com/blog/cerebras-docker-compose-secure-ai-coding-agents/

• 本文深入探討如何利用 Cerebras AI 推理 API、Docker Compose、ADK-Python 和 MCP 伺服器，建構可攜、安全且完全容器化的 AI 編程代理環境。
• 入門設定：首先透過 git clone 取得範例程式碼，並設定 CEREBRAS_API_KEY 於 .env 檔案中，然後執行 docker compose up 啟動系統，代理介面可在 localhost:8000 存取。

  git clone https://github.com/dockersamples/docker-cerebras-demo && cd docker-cerebras-demo
  cp .env-sample .env
  # 編輯 .env 檔案，加入您的 Cerebras API 金鑰
  docker compose up
  

• 架構解析：代理系統由三個核心元件組成：代理迴圈（基於 ADK-Python）、MCP 工具（透過 Docker MCP Gateway 提供，如 context7 和 node-sandbox）以及 AI 模型（可選擇本地 Qwen 模型或 Cerebras API 驅動的高性能 Cerebras 代理）。
• 建構自訂沙箱作為 MCP 伺服器：文中展示如何建構一個安全的程式碼執行沙箱。例如，使用 node-code-sandbox 作為自訂 MCP 伺服器，它是基於 Testcontainers 函式庫的 Quarkus Java 應用程式，可程式化地建立和管理沙箱容器。
• 沙箱安全性：在沙箱容器中禁用網路 (.withNetworkMode("none")) 是關鍵安全措施，防止代理程式碼外洩資料。例如：

  GenericContainer sandboxContainer = new GenericContainer<>("mcr.microsoft.com/devcontainers/javascript-node:20")
                  .withNetworkMode("none") // disable network!!
                  .withWorkingDirectory("/workspace")
                  .withCommand("sleep", "infinity");
  sandboxContainer.start();
  

  可在沙箱內執行命令或寫入檔案：

  // 在沙箱內執行命令
  sandbox.execInContainer(command);
  
  // 將檔案寫入沙箱
  sandbox.copyFileToContainer(Transferable.of(contents.getBytes()), filename);
  

• 整合沙箱至 MCP Gateway：將自訂伺服器打包成 Docker 映像後，透過 mcp-gateway-catalog.yaml 檔案整合至 MCP Gateway，並在 docker-compose.yml 中啟用。此設定確保沙箱容器在代理請求時被啟動，並在 Compose 停止時由 Testcontainers 自動清理。

      longLived: true
      image: olegselajev241/node-sandbox@sha256:44437d5b61b6f324d3bb10c222ac43df9a5b52df9b66d97a89f6e0f8d8899f67
  

• 容器化沙箱的安全性優勢：容器提供清晰的安全邊界，禁用網路可有效防止資料外洩，同時允許其他工具（如 context7）正常存取網路。

🚀 GitHub MCP 註冊中心：加速發現 MCP 伺服器​

Source: https://github.blog/ai-and-ml/github-copilot/meet-the-github-mcp-registry-the-fastest-way-to-discover-mcp-servers/

• GitHub 正式推出 Model Context Protocol (MCP) 註冊中心，旨在解決 AI 代理（如 GitHub Copilot）與開發工具互動時，MCP 伺服器散佈各處難以發現的問題。
• MCP 註冊中心作為集中平台，簡化了 MCP 伺服器的探索、瀏覽和使用，促進更開放、互通的 AI 生態系統。
• 它提供多項功能，包括在 VS Code 內的一鍵安裝發現能力、依據 GitHub 星標和社群活躍度排序、以及與 GitHub Copilot 和任何 MCP 相容主機的整合。
• 未來規劃允許開發者直接發布 MCP 伺服器至開源 MCP 社群註冊中心，並自動同步至 GitHub MCP 註冊中心，以建立統一且可擴展的發現路徑。

GitHub SSH 存取引入後量子安全 🔒​

Source: https://github.blog/engineering/platform-security/post-quantum-security-for-ssh-access-on-github/

• GitHub 將為其 SSH 端點新增一個後量子安全 SSH 金鑰交換演算法：sntrup761x25519-sha512（或 sntrup761x25519-sha512@openssh.com）。
• 此變更僅影響 SSH 存取，對 HTTPS 存取無影響，也不影響位於美國地區的 GitHub Enterprise Cloud 資料駐留。
• 目的是防範未來量子電腦可能進行的「先儲存，後解密」攻擊，確保資料的長期安全。
• 採用混合式方法，結合了 Streamlined NTRU Prime（一種新的後量子安全演算法）與經典的 Elliptic Curve Diffie-Hellman（使用 X25519 曲線），確保安全性不低於經典演算法。
• 此演算法將於 2025 年 9 月 17 日起在 GitHub.com 和非美國地區的 GitHub Enterprise Cloud 上啟用，並將包含在 GitHub Enterprise Server 3.19 中。
• 大多數現代 SSH 客戶端（例如 OpenSSH 9.0 或更新版本）將自動選擇新演算法，無需手動配置；舊版客戶端將回退到舊演算法。
• 您可以透過執行 ssh -Q kex 來檢查 SSH 客戶端是否支援此演算法，並使用 ssh -v git@github.com exit 2>&1 | grep 'kex: algorithm:' 來查看連接 GitHub 時所使用的金鑰交換演算法。

🛠️ 以開源和 AI 構建個人應用程式​

Source: https://github.blog/open-source/maintainers/building-personal-apps-with-open-source-and-ai/

• 強調小工具的魔力：即使任務再小，一個能精準滿足需求的工具也能帶來巨大影響，例如將不同格式的答案轉換為 Markdown 列表，或將 CSV 轉換為 Markdown，這些都能大幅節省時間和心力。
• 開源作為實驗場：GitHub 等開源平台是尋找、修改和分享個人工具的絕佳場所。若已有類似工具，可透過 Fork 進行調整以符合個人工作流程；若將自己的工具開源，也能啟發他人貢獻新功能，如個人待辦應用程式被建議新增「暫停任務履歷」功能。
• AI 作為倍增器：AI 技術如 GitHub Copilot 大幅加速個人軟體開發。過去需耗時處理的框架、錯誤，現在 AI 能協助專案建構、故障排除，甚至解釋複雜程式碼，降低了開發門檻。
• 減少心智負擔：透過將重複性任務自動化並利用 AI 輔助，開發者能從繁瑣工作中解放，專注於更具創造性或有意義的工作，讓軟體開發過程變得更加愉快。
• 分享與成長：當工具開源並有其他人使用時，安全性與可維護性變得重要。社群的參與能協助發現問題、提出改進，甚至帶領專案走向新方向，透過協作共同成長。

🚀 GitHub Universe 2025 指南：日程表剛剛發布！​

Source: https://github.blog/news-insights/company-news/your-guide-to-github-universe-2025-the-schedule-just-launched/

• GitHub Universe 2025 的日程表已發布，活動將於 10 月 28-29 日在舊金山 Fort Mason Center 舉行。
• 為期兩天的會議將涵蓋超過 100 場精彩環節、演示和座談會，主題包括 AI 驅動的開發潛力、從「Vibe Coding」到規模化自動化，以及 AI 驅動的安全性。
• 早鳥票優惠已延長至 9 月 17 日，提供 400 美元的折扣，並可與團體折扣（3+ 張票 25% 折扣，8+ 張票 35% 折扣）疊加使用。
• 今年新增 10 月 30 日在 GitHub 總部的「學習日體驗」，包含 GitHub 或 Microsoft 認證考試機會（如 GitHub Copilot、GitHub Advanced Security），名額有限需提前註冊。
• 活動期間提供一對一會議（Career Corner for job advice, GitHub Expert Center for technical help）、開源專區、Makerspace 等多樣化互動機會。
• 針對學生提供虛擬微指導會議，幫助學生進行履歷反饋、職涯建議和技能發展。

🔗 如何使用 GitHub 與 JFrog 整合實現從提交到生產的安全可追溯建構​

Source: https://github.blog/enterprise-software/devsecops/how-to-use-the-github-and-jfrog-integration-for-secure-traceable-builds-from-commit-to-production/

• GitHub 與 JFrog 推出新的整合，旨在建立安全、可追溯的軟體供應鏈，將原始程式碼與經認證的二進位檔案連結。
• 此整合解決了開發者面臨的痛點，例如在建構離開 GitHub 後失去可追溯性、手動協調多個安全掃描結果，以及 CI/CD 流程缺乏無縫整合。
• 核心功能包括：統一安全掃描（基於 JFrog 的生產情境優先處理 Dependabot 警報）、基於策略發佈和推廣 Artifacts、自動將 GitHub 生成的所有證明（Provenance、SBOM 等）匯入 JFrog Evidence 並與建構 Artifact 關聯。
• 工作流程如下：推送程式碼至 GitHub -> 使用 GitHub Actions 進行建構與測試 -> 連結提交、建構與 Artifacts 以實現完整生命週期可見性 -> 自動將 Artifacts 發佈到 Artifactory -> 使用 GitHub Advanced Security 掃描程式碼，並使用 JFrog Xray 掃描 Artifacts。
• 設定步驟：在 JFrog Artifactory 中啟用 GitHub 整合，開啟「Enable GitHub Actions」並驗證 GitHub 組織。
• GitHub Actions 範例用於生成證明並推送到 Artifactory，其中使用 jfrog/jfrog-setup-cli 和 actions/attest-build-provenance 等 actions。

  name: Build, Test & Attest
  
  on:
    push:
      branches:
        - main
  
  env:
    OIDC_PROVIDER_NAME: [...]
    JF_URL: ${{ vars.JF_URL }}
    JF_REGISTRY: ${{ vars.JF_REGISTRY }}
    JF_DOCKER_REPO: [...]
    IMAGE_NAME: [...]
    BUILD_NAME: [...]
  
  jobs:
    build-test-deploy:
      runs-on: ubuntu-latest
      permissions:
          contents: read
          packages: write
          attestations: write  # Required for attestation
          id-token: write      # Added for OIDC token access
  
      steps:
      - name: Checkout code
        uses: actions/checkout@v5
  
      - name: Install JFrog CLI
        id: setup-jfrog-cli
        uses: jfrog/setup-jfrog-cli@v4.5.13
        env:
          JF_URL: ${{ env.JF_URL }}
        with:
          version: 2.78.8
          oidc-provider-name: ${{ env.OIDC_PROVIDER_NAME }}
  
      - name: Docker login
        uses: docker/login-action@v3
        with:
          registry: ${{ env.JF_REGISTRY }}
          username: ${{ steps.setup-jfrog-cli.outputs.oidc-user }}
          password: ${{ steps.setup-jfrog-cli.outputs.oidc-token }}
  
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3
  
      - name: Build and push Docker image
        id: build-and-push
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: ${{ env.JF_REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.run_number }}
          build-args: ${{ env.BUILD_ARGS }}
  
      - name: Attest docker image
        uses: actions/attest-build-provenance@v2
        with:
          subject-name: oci://${{ env.JF_REGISTRY }}/${{ env.IMAGE_NAME }}
          subject-digest: ${{ steps.build-and-push.outputs.digest }}
  

• 最佳實踐建議使用 OIDC 避免長時間憑證、自動化 Artifactory 中的推廣流程、早期設定安全閘門以阻止未經證明或存在漏洞的建構進入生產，並利用 JFrog Evidence 中的 Provenance 證明實現即時追溯。

🚀 如何使用 Playwright MCP 和 GitHub Copilot 偵錯 Web 應用程式​

Source: https://github.blog/ai-and-ml/github-copilot/how-to-debug-a-web-app-with-playwright-mcp-and-github-copilot/

• Playwright Model Context Protocol (MCP) server 結合 GitHub Copilot 可自動化 Web 應用程式的錯誤重現、驗證與修復過程，解決許多專案缺乏完善測試的痛點。
• Playwright 是一個用於 Web 應用程式的端到端測試框架，而 MCP 則是由 Anthropic 開發的開放協議，旨在將工具暴露給 AI 代理。Playwright MCP Server 允許 Copilot 建立並執行這些自動化腳本。
• 在 VS Code 中配置 Playwright MCP server 需在 .vscode/mcp.json 中添加以下配置，使其可供所有專案使用：

  {
    "servers": {
      "playwright": {
        "command": "npx",
        "args": [
          "@playwright/mcp@latest"
        ]
      }
    }
  }
  

• GitHub Copilot agent mode 能夠根據錯誤報告的重現步驟，利用 Playwright MCP server 自動執行測試、確認問題、追蹤並解決錯誤，甚至在提出修復方案後，返回 Playwright 驗證其有效性。
• 透過 Playwright，Copilot 能「看到」其更改對網站的影響，這對於處理更複雜的錯誤尤其寶貴，顯著提升了偵錯效率。

💡 使用 MCP 引導機制打造更智能的互動：從繁瑣的工具呼叫到流暢的使用者體驗​

Source: https://github.blog/ai-and-ml/github-copilot/building-smarter-interactions-with-mcp-elicitation-from-clunky-tool-calls-to-seamless-user-experiences/

• 本文探討了如何透過 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 配置範例:

  models:
    worker:
      model: ai/llama3.2
      context_size: 10000
  

  此配置可啟動一個運行 Llama 3.2 模型並擁有 10k 上下文視窗的本地 worker。
• 權衡: 儘管顯著降低雲端成本，但由於任務拆分、本地處理和聚合，回應時間可能會較慢（約 10 倍）。

🔍 靜態程式碼分析提升開發者體驗的五種方式​

Source: https://blog.jetbrains.com/qodana/2025/09/improve-developer-experience/

• 靜態程式碼分析 (Static Code Analysis) 是一種強大的工具，無需運行程式碼即可檢查潛在問題，從而減少開發人員的摩擦，使他們能更專注於解決問題。
• 提升開發者體驗的五種方式:
  1. 更快的反饋循環: 直接整合到開發環境或 CI/CD 管線中，提供即時的錯誤、風格違規和安全漏洞洞察，讓開發者在編碼時就能即時修復問題。
  2. 降低認知負荷: 作為安全網，自動捕捉程式碼標準違規、不安全結構，並提醒最佳實踐，減少記憶所有規範的心理負擔。
  3. 改進程式碼品質和一致性: 強制專案的編碼標準，確保一致性和可讀性；檢測常見錯誤模式，如空指針解引用、未初始化變數。
  4. 整個生命週期的時間節省: 在開發早期階段捕獲問題，大幅降低發布後修復缺陷的成本；透過預過濾瑣碎問題，讓程式碼審查更專注於架構和邏輯。例如，Qodana 提供的快速修復功能能節省大量時間。
  5. 與現代開發者體驗工具整合: 與 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 動作或開啟擴充功能選單後可能凍結的問題。
    • 恢復了異步上下文中程式碼自動完成的正確行為。
• 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 改善註解處理：減少樣板程式碼，減少意外​

Source: https://blog.jetbrains.com/idea/2025/09/improved-annotation-handling-in-kotlin-2-2-less-boilerplate-fewer-surprises/

• 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 潛力方面的重要性。

🚀 AI 驅動的規範式開發：GitHub 開源工具包 Spec Kit 入門​

Source: https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/

• 挑戰與解決方案: 隨著 AI 程式碼生成工具日益強大，傳統的「憑感覺寫程式」(vibe-coding) 方式常導致程式碼無法編譯或未能完全符合需求。GitHub 提出「規範式開發」(Spec-driven development)，將規範視為活生生的可執行文件，作為工具與 AI 代理生成、測試、驗證程式碼的單一事實來源。
• Spec Kit 工具包: GitHub 開源工具包 Spec Kit 旨在將規範式開發引入 AI 程式碼生成工作流程，支援 GitHub Copilot、Claude Code 和 Gemini CLI 等工具。
• 四階段開發流程:
  1. Specify (規範): 提供高層次的「是什麼」和「為什麼」，AI 生成詳細的用戶旅程和預期成果規範。
  2. Plan (規劃): 提供技術棧、架構和限制，AI 生成全面的技術實作計劃。
  3. Tasks (任務): AI 將規範與計劃分解為可單獨實作與測試的小型任務。例如，從「建置認證」變成「創建驗證電子郵件格式的用戶註冊端點」。
  4. Implement (實作): AI 根據任務逐一生成程式碼，開發者審查針對特定問題的精確變更。
• 核心優勢:
  • 意圖即真理: 從「程式碼是真理來源」轉變為「意圖是真理來源」，使規範可執行並自動轉化為工作程式碼。
  • 減少猜測: 明確的規範、技術計劃和任務提供 AI 更高清晰度，提高其效率。
  • 適用場景: 適用於從零開始的新專案 (Greenfield)、現有系統的功能擴展 (Feature work) 及遺留系統現代化 (Legacy modernization)。
  • 大規模應用: 組織的安全政策、合規規則、設計系統限制等要求可直接整合到規範和計劃中，供 AI 使用。
• Spec Kit 使用範例 (CLI):
  • 初始化專案：

    uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>
    

  • 生成規範：

    /specify "Build a new e-commerce product catalog with search functionality."
    

  • 生成技術計劃：

    /plan "Use Python, FastAPI, PostgreSQL, and integrate with Stripe for payments."
    

  • 分解任務並實作：

    /tasks