TechSummary 2025-08-28

2025年8月29日 · 閱讀時間約 15 分鐘

AI Assistant

🤖 GitHub Models 如何幫助開源維護者專注於核心工作

Source: https://github.blog/open-source/maintainers/how-github-models-can-help-open-source-maintainers-focus-on-what-matters/

開源專案維護者常因重複性管理工作（如分類問題、處理重複項、要求重現步驟）而分心，GitHub Models 旨在利用 AI 自動化這些重複性工作。
透過 GitHub Models 結合 GitHub Actions，實現「持續 AI」(Continuous AI) 模式，提供自動化工作流程，例如自動問題去重、問題完整性檢查、垃圾郵件與低品質貢獻偵測、持續解決方案以及新貢獻者引導。

自動問題去重範例：

name: Detect duplicate issues
on:
  issues:
    types: [opened, reopened]
permissions:
  models: read
  issues: write
jobs:
  continuous-triage-dedup:
    if: ${{ github.event.issue.user.type != 'Bot' }}
    runs-on: ubuntu-latest
    steps:
      - uses: pelikhan/action-genai-issue-dedup@v0
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          # Optional tuning:
          # labels: "auto"          # compare within matching labels, or "bug,api"
          # count: "20"             # how many recent issues to check
          # since: "90d"            # look back window, supports d/w/m

問題完整性檢查範例：

name: Issue Completeness Check
on:
  issues:
    types: [opened]
permissions:
  issues: write
  models: read
jobs:
  check-completeness:
    runs-on: ubuntu-latest
    steps:
      - name: Check issue completeness
        uses: actions/ai-inference@v1
        id: ai
        with:
          prompt: |
            Analyze this GitHub issue for completeness. If missing reproduction steps, version info, or expected/actual behavior, respond with a friendly request for the missing info. If complete, say so.
            
            Title: ${{ github.event.issue.title }}
            Body: ${{ github.event.issue.body }}
          system-prompt: You are a helpful assistant that helps analyze GitHub issues for completeness.
          model: openai/gpt-4o-mini
          temperature: 0.2
      - name: Comment on issue
        if: steps.ai.outputs.response != ''
        uses: actions/github-script@v7
        with:
          script: |
            github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: ${{ github.event.issue.number }},
              body: `${{ steps.ai.outputs.response }}`
            })

建議維護者從一個工作流程開始，逐步擴展，並監控結果、根據專案語氣調整 AI 提示。

🔒 我們如何使用 Copilot 加速秘密保護工程

Source: https://github.blog/ai-and-ml/github-copilot/how-we-accelerated-secret-protection-engineering-with-copilot/

GitHub Secret Protection 旨在防止開發者不小心將敏感資訊提交到程式碼庫，提供推送保護、有效性檢查和 Copilot 秘密掃描等功能。
傳統上，為新的 token 類型添加驗證支持是重複性且耗時的框架驅動工作，團隊嘗試利用 AI 編碼代理 Copilot 來加速此流程，尤其在程式碼編寫和發布部分。
Copilot 善於程式碼變更，能根據詳細的 GitHub issue 提示自動生成 PR，將研究與規劃轉化為可執行程式碼。
結果顯示，在幾週內，透過 Copilot 引入了近 90 種新的 token 驗證類型，而此前數月僅引入 32 種，證明 Copilot 作為「倍增器」的潛力。
關鍵經驗：自動化能放大重複性工作流程的效益；將 Copilot 視為團隊成員，其生成程式碼需經過嚴謹審查和測試；高品質、詳細且包含範例的提示能提升 Copilot 輸出品質；適當設置可實現任務並行化。

🛡️ 設計即安全：Testcontainers、Docker Scout 和強化映像檔的左移方法

Source: https://www.docker.com/blog/a-shift-left-approach-with-docker/

本文探討「左移安全」(Shift-Left Security) 方法，如何在開發生命週期早期整合安全措施，以確保快速開發與高品質安全並存。

Testcontainers 實現左移測試：利用 Testcontainers 動態啟動資料庫和應用程式容器，在開發內部迴圈進行快速可靠的整合測試，甚至可以直接從 Dockerfile 啟動容器化應用。

beforeAll(async () => {
  const network = await new Network().start();
  // 1. Start Postgres
  db = await new PostgreSqlContainer("postgres:17.4").withNetwork(network).start();
  // 2.  Build movie catalog API container from the Dockerfile
  const container = await GenericContainer.fromDockerfile("../movie-catalog").withTarget("final").withBuildkit().build();
  // 3. Start movie catalog API container with environment variables for DB connection  
  app = await container.withNetwork(network).withExposedPorts(3000).start();
}, 120000);

Docker Scout 與強化型映像檔 (Docker Hardened Images, DHI)：使用 docker buildx --provenance=true --sbom=true 建構映像檔，為 Docker Scout 提供詳細安全分析。DHI 採用無發行版 (distroless) 理念，顯著減少攻擊面，提供近乎零可利用 CVE，並內建供應鏈安全。

切換至 Docker Hardened Images 僅需將 Dockerfile 中的基礎映像檔替換為 DHI 對應版本，可顯著減少映像檔大小和漏洞數量。

# Changed node:22 to dhi-node:22-dev
FROM demonstrationorg/dhi-node:22-dev AS base
WORKDIR /usr/local/app
COPY --chown=nonroot package.json package-lock.json ./
# ... (中間階段省略) ...
# Changed base to dhi-node:22
FROM demonstrationorg/dhi-node:22 AS final
WORKDIR /usr/local/app
COPY --from=prod-deps /usr/local/app/node_modules ./node_modules
COPY ./src ./src
EXPOSE 3000
CMD [ "node", "src/app.js" ]

整合外部安全工具：DHI 包含 SBOM 和 VEX 證明，可使用 docker scout vex get 匯出 VEX 數據，並與 Grype 或 Trivy 等掃描工具結合使用 --vex 旗標來抑制已知不可利用的 CVE。
```
trivy image demonstrationorg/movie-catalog-service-dhi:v1 --vex vex.json
```

🧠 利用規則掌握 Amazon Q Developer

Source: https://aws.amazon.com/blogs/devops/mastering-amazon-q-developer-with-rules/

開發團隊在使用 AI 助理時常面臨重複解釋編碼標準、工作流程偏好等挑戰。Amazon Q Developer Rules 允許將編碼標準和最佳實踐定義為規則庫，儲存在專案的 .amazonq/rules 資料夾中的 Markdown 文件中。
這些規則在開發者與 Amazon Q Developer 互動時會自動加載作為上下文，確保團隊成員獲得一致的 AI 指導，有效降低認知負荷、加速入職並保存團隊知識。

有效規則的推薦結構：包含「Rule Name」、「Purpose」、「Instructions」、「Priority」和「Error Handling」等區塊。

# Monitoring
## Purpose
This rule ensures that monitoring coverage is maintained when major features are added to the project.
## Instructions
- When implementing a major feature, ALWAYS check if MONITORING_PLAN.md needs updates.
- Major features include: new microservices, AI integrations, WebSocket endpoints.
- After updating MONITORING_PLAN.md, output "📊 Updated monitoring plan for: [feature]".
## Priority
High
## Error Handling
- If MONITORING_PLAN.md doesn't exist, create it with basic monitoring structure

規則透明化：透過在規則指令中添加唯一 ID，並創建一個「對話規則」來指示 Amazon Q Developer 在其回應中明確說明使用了哪些規則和 ID，提升透明度、有助於調試和學習。

# Conversation
## Purpose
This rule defines how Amazon Q Developer should behave in conversations, including how it should acknowledge other rules it's following.
## Instructions
- ALWAYS consider your rules before using a tool or responding. (ID: CHECK_RULES)
- When acting based on a rule, ALWAYS print "Rule used: `filename` (ID)" at the very beginning of your response. (ID: PRINT_RULES)
## Priority
Critical

實際案例展示了規則如何使 AI 助理在時間分析、前端組件開發和版本控制工作流程中提供更精確、一致且符合團隊標準的指導。

🌟 宣布推出 Awesome Copilot MCP Server

Source: https://devblogs.microsoft.com/blog/announcing-awesome-copilot-mcp-server/

為了解決 Awesome GitHub Copilot Customizations 儲存庫中大量自定義內容（聊天模式、指令、提示）難以發現和比較的問題，推出了 Awesome Copilot MCP Server。
MCP Server 允許用戶透過 GitHub Copilot Chat 搜尋這些自定義內容，並直接保存到其儲存庫中。

安裝先決條件：需安裝並運行 Docker Desktop。可直接透過 VS Code 按鈕安裝，或在 MCP 伺服器配置中添加以下 JSON 配置：

{
  "servers": {
    "awesome-copilot": {
      "type": "stdio",
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "ghcr.io/microsoft/mcp-dotnet-samples/awesome-copilot:latest"
      ]
    }
  }
}

使用 MCP Server：提供兩個工具 (#search_instructions, #load_instruction) 和一個提示 (/mcp.awesome-copilot.get_search_prompt)。在 GitHub Copilot Chat 中調用該提示，輸入關鍵字進行搜索，Copilot 將顯示一個結構化的表格，用戶可選擇要保存的自定義內容，MCP Server 會將其加載並保存到專案的.github/目錄中。

⚙️ IntelliJ IDEA 2025.1.5 發布！

Source: https://blog.jetbrains.com/idea/2025/08/intellij-idea-2025-1-5/

IntelliJ IDEA 發布了 2025.1.5 版本更新，用戶可透過 IDE 內部、Toolbox App 或 Ubuntu snaps 進行更新，也可從官網下載。
此版本主要包含以下更新：在 macOS 上連接第二個顯示器時，IDE 界面在 Google Meet 螢幕共享期間現在能流暢運行 (JBR-7582)。
UrlClassLoader.getFiles 現在返回預期的 java.nio.file.Path 實例，避免與其他路徑衝突 (IJPL-187780)。

🤖 Koog 0.4.0 發布：可觀測、可預測，並可部署於任何地方

Source: https://blog.jetbrains.com/ai/2025/08/koog-0-4-0-is-out-observable-predictable-and-deployable-anywhere-you-build/

Koog 0.4.0 版本聚焦於提升 AI 代理的可觀測性 (observable)、無縫部署能力和輸出可預測性，同時增加對新模型和平台的支持，包括 Langfuse 和 W&B Weave、Ktor 整合、原生結構化輸出、iOS 目標、GPT-5 和 DeepSeek 支持。

OpenTelemetry 支持 Langfuse 和 W&B Weave：提供完整的 OpenTelemetry 支持，可輕鬆安裝插件並連接到後端，查看嵌套的代理事件，以及每個請求的 token 和成本細分。

val agent = AIAgent(...) {
    install(OpenTelemetry) {
        addWeaveExporter(
            weaveOtelBaseUrl = "WEAVE_TELEMETRY_URL",
            weaveApiKey = "WEAVE_API_KEY",
            weaveEntity = "WEAVE_ENTITY",
            weaveProjectName = "WEAVE_PROJECT_NAME"
        )
    }
}

Ktor 整合：提供即插即用的 Ktor 插件，可快速將 Koog 代理部署到 Ktor API 後端。

fun Application.module() {
    install(Koog) {
        llm { openAI(apiKey = "your-openai-api-key") }
    }
}
// Usage in routes
routing {
    route("/ai") {
        post("/chat") {
            val output = aiAgent(strategy = reActStrategy(), model = OpenAIModels.Chat.GPT4_1, input = userInput)
            call.respond(HttpStatusCode.OK, output)
        }
    }
}

原生結構化輸出：支援部分 LLM 的原生結構化輸出，並帶有實用的防護措施，如重試和修復策略，確保獲得預期資料格式。

@Serializable @LLMDescription("Weather forecast for a location")
data class WeatherForecast(val location: String, val temperature: Int, val conditions: String)
val weather = requestLLMStructured<WeatherForecast>(
    fixingParser = StructureFixingParser(fixingModel = OpenAIModels.Chat.GPT4o, retries = 5),
    examples = listOf(WeatherForecast("New York", 22, "cloudy"))
)

此外，新增 iOS 目標支持，支持 GPT-5 和自定義 LLM 參數（如 reasoningEffort），並引入生產級重試機制處理 LLM 調用超時、工具故障或網路問題。

⚡ ReSharper 的新進程外引擎將 Visual Studio UI 凍結減少 80%

Source: https://blog.jetbrains.com/dotnet/2025/08/28/resharper-s-new-out-of-process-engine-cuts-ui-freezes-in-visual-studio-by-80/

ReSharper 2025.2 引入了全新的「進程外 (Out-of-Process)」引擎，將大部分代碼分析工作移至獨立的 64 位工作進程，不再與 Visual Studio UI 進程共享，顯著減少 UI 凍結。
在 Orchard Core 解決方案上的測試顯示，Visual Studio 啟動期間 100 毫秒或更長的 UI 凍結時間，從 ReSharper 2025.1.4 的 26 秒降至 2025.2 進程外模式的 10.1 秒，減少 61%。
底層變革：大多數分析工作在單獨進程中運行，不會阻塞 Visual Studio UI 線程；更智能的排程減少了打字、完成和導航時的爭用；緩存和索引存放在獨立進程中，避免 Visual Studio 內部額外工作。
已知限制：目前進程外模式尚不支持 AI 驅動功能、調試器整合、性能分析工具、模板編輯器和圖表工具，這些功能將在後續版本中逐步引入。
啟用方式：可透過 Visual Studio 菜單（Extensions | ReSharper | R# Out-of-Process）、Go to action (Ctrl+Shift+A) 或狀態欄按鈕切換到進程外模式，或使用 /ReSharper.OOP 旗標啟動 Visual Studio。

⚙️ 系統配置管理開發：建構 CLI 和 API

Source: https://dzone.com/articles/system-configuration-management-cli-api

此文章是系列「Development of system configuration management」的第 2.2 部分。
本篇文章聚焦於建構系統配置管理的 CLI (Command Line Interface) 和 API (Application Programming Interface) 部分。
（文章內容為系列概述，未提供具體技術細節。）

💾 超越鍵值：Redis 中的數據結構化

Source: https://dzone.com/articles/designing-redis-keys-and-data-structure

Redis 是一個廣受歡迎的開源記憶體內資料儲存庫，以其卓越的速度聞名，尤其在讀取操作上表現極佳。
許多開發者熟悉各種快取技術，如 Cache-Aside, Write-Through, Write-Behind, Read-Through 等。
（文章內容為開頭簡介，未深入闡述數據結構化方法。）

📊 使用 AI 和 SQL 建構推薦引擎

Source: https://dzone.com/articles/building-recommendation-engines-with-your-data-wit

提供個性化體驗對於吸引用戶和推動業務增長至關重要，而推薦引擎是提升用戶參與度和滿意度的核心，其背後由人工智能 (AI) 和大數據驅動。
本文將探討如何結合 AI 和 SQL，利用現有的數據基礎設施，構建強大的推薦引擎，提供客製化洞察。
（文章內容為開頭簡介，未深入闡述建構推薦引擎的方法。）

❄️ Snowflake 性能調優實用指南：結合 SQL 和 AI 增強

Source: https://dzone.com/articles/optimize-snowflake-performance

許多 Snowflake 用戶面臨查詢速度慢、計算成本高昂的問題。
本文旨在提供 13 種實戰優化技術，基於作者在多個環境中調優慢速查詢、分析 QUERY_HISTORY 和模式的經驗，幫助提升 Snowflake 性能，節省時間、降低成本並提高查詢效率。
（文章內容為開頭簡介，未深入闡述具體優化技術。）

⚖️ 設計可擴展的政策與執行數據攝取和訪問層

Source: https://dzone.com/articles/scalable-data-ingestion-access-policy-enforcement

在信任和安全系統中，即時獲取風險分數、政策標誌或執行狀態等訊號對於防止濫用和實現安全自動決策至關重要。
這些系統需要以低延遲攝取和暴露高容量數據，而傳統資料庫系統難以滿足此類工作負載需求。
平台日益將 Apache Spark 用於可擴展數據攝取，並結合記憶體內資料網格 (in-memory data grids) 以支持對關鍵任務數據的亞秒級訪問。
（文章內容為開頭簡介，未深入闡述數據攝取和訪問層的設計細節。）

🤯 如何理解代理型 AI 中的湧現行為：混沌還是智慧？

Source: https://dzone.com/articles/how-to-understand-emergent-behavior-in-agentic-ai

湧現行為 (Emergent Behavior) 在代理型 AI 中是當代軟體系統中最引人入勝的現象之一，指相對簡單的組件在開放環境中互動時，產生意想不到的複雜行為。
在語言模型驅動的代理中，系統不僅回應提示，還能規劃、適應、使用工具、儲存上下文，甚至提出未直接要求的解決方案。
LangChain 的 ReAct 模式、Auto-GPT 的遞歸規劃迴圈和 CrewAI 的多代理結構等框架加速了這一趨勢，這些行為源於上下文、記憶和工具互動塑造的機率推理。
文章旨在探討如何理解這種行為，區分其是混沌還是智慧的體現。
（文章內容為開頭簡介，未深入闡述如何理解湧現行為。）

🔐 哭泣與認證：AI 如何改變安全

Source: https://dzone.com/articles/ai-psychology-future-authentication

文章探討 AI 如何改變現有安全範式，尤其是在身份驗證方面。
傳統上，多重密碼和雙因素驗證廣泛應用，但帳戶被駭、被盜用等問題依然普遍存在。
作者認為 AI 有潛力解決這些傳統安全方法的痛點，使安全系統更具智慧和適應性。
（文章內容為開頭簡介，未深入闡述 AI 如何改變安全或身份驗證。）

🛂 從運行時火災到飛行前控制：Spark SQL 的守門人模型

Source: https://dzone.com/articles/building-a-spark-sql-syntax-validator

傳統上，Spark SQL 查詢中的錯誤（如語法錯誤）直到運行時才被發現，導致計算資源浪費和效率低下。
作者面臨因 SQL 查詢中的小錯誤導致集群儀表板變紅、資源阻塞的問題後，決定構建一個「守門人」(gatekeeper) 模型。
這個守門人模型旨在在 Spark 啟動執行之前，即時檢查查詢的有效性，一旦發現問題就立即阻止，實現「飛行前控制」(Pre-Flight Control)。
（文章內容為開頭簡介，未深入闡述守門人模型的實現細節或程式碼。）

✅ 在 AI 時代，您的數據有多健康？評估數據準確性、治理和 AI 就緒的深入核對清單

Source: https://dzone.com/articles/healthy-data-ai-checklist

數據已從業務流程的副產品演變為創新和戰略決策的關鍵資產，尤其隨著 AI 能力的提升和整合。
AI 的有效性高度依賴高品質、可靠的數據；缺乏良好數據，即使最先進的 AI 工具也可能失敗。
組織必須自問：「我們的數據有多健康？」，本文旨在提供一份深入的核對清單，以評估數據準確性、治理和 AI 就緒程度。
（文章內容為開頭簡介，未深入闡述核對清單的細節。）

💾 使用 HWM 邏輯回收 Oracle 表空間空間：本地和雲端感知自動化

Source: https://dzone.com/articles/reclaiming-oracle-tablespace-space-using-hwm-logic

在企業級 Oracle 環境中，高效的存儲管理對 DBA 而言至關重要，但表空間內的空間浪費是一個常見挑戰。
Oracle 動態分配 extents，但在段被刪除、截斷或重組後，資料文件不會自動收縮，導致未使用的已分配空間隨時間累積。
本文介紹了一個強大的 PL/SQL 腳本，旨在透過計算高水位線 (High Water Mark, HWM) 並發出安全、有條件的 resize 命令，自動回收 Oracle 表空間中未使用的空間，適用於多種 Oracle 部署模型。
（文章內容為開頭簡介，未深入闡述 PL/SQL 腳本的實現細節或程式碼。）

🤖 GitHub Models 如何幫助開源維護者專注於核心工作​

🔒 我們如何使用 Copilot 加速秘密保護工程​

🛡️ 設計即安全：Testcontainers、Docker Scout 和強化映像檔的左移方法​

🧠 利用規則掌握 Amazon Q Developer​

🌟 宣布推出 Awesome Copilot MCP Server​

⚙️ IntelliJ IDEA 2025.1.5 發布！​

🤖 Koog 0.4.0 發布：可觀測、可預測，並可部署於任何地方​

⚡ ReSharper 的新進程外引擎將 Visual Studio UI 凍結減少 80%​

⚙️ 系統配置管理開發：建構 CLI 和 API​

💾 超越鍵值：Redis 中的數據結構化​

📊 使用 AI 和 SQL 建構推薦引擎​

❄️ Snowflake 性能調優實用指南：結合 SQL 和 AI 增強​

⚖️ 設計可擴展的政策與執行數據攝取和訪問層​

🤯 如何理解代理型 AI 中的湧現行為：混沌還是智慧？​

🔐 哭泣與認證：AI 如何改變安全​

🛂 從運行時火災到飛行前控制：Spark SQL 的守門人模型​

✅ 在 AI 時代，您的數據有多健康？評估數據準確性、治理和 AI 就緒的深入核對清單​

💾 使用 HWM 邏輯回收 Oracle 表空間空間：本地和雲端感知自動化​