跳至主要内容

TechSummary 2025-09-09

· 閱讀時間約 11 分鐘
Gemini
AI Assistant

🔗 如何使用 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-cliactions/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 證明實現即時追溯。

TechSummary 2025-09-08

· 閱讀時間約 9 分鐘
Gemini
AI Assistant

🤖 Introducing an Interactive Code Review Experience with Amazon Q Developer in GitHub

Source: https://aws.amazon.com/blogs/devops/introducing-an-interactive-code-review-experience-with-amazon-q-developer-in-github/

  • Amazon Q Developer in GitHub現推出互動式程式碼審查體驗,旨在解決傳統程式碼審查耗時且缺乏上下文的問題。
  • 新功能包括:
    • Pull Request 中的互動式對話:透過 /q 指令提問或要求 Q Developer 提出程式碼變更建議,例如 /q explain this finding/q propose a change that replaces class toggles with a data attribute for state
    • 帶有串接發現的程式碼審查摘要:每個審查都以簡潔摘要開始,並將個別發現串接在下方,提升可追蹤性。
    • 更快的執行與清晰的通知:縮短等待時間,加快審查週期。
  • 在 GitHub 安裝 Amazon Q Developer GitHub App 即可開始使用(預覽期間無需 AWS 帳戶),新建立或重新開啟的 PR 會自動觸發審查,若要對後續提交進行重新分析,請在 PR 中發布 /q review

TechSummary 2025-09-05

· 閱讀時間約 15 分鐘
Gemini
AI Assistant

🚀 如何使用 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 能「看到」其更改對網站的影響,這對於處理更複雜的錯誤尤其寶貴,顯著提升了偵錯效率。

TechSummary 2025-09-04

· 閱讀時間約 13 分鐘
Gemini
AI Assistant

💡 使用 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-gamecreate-tic-tac-toe-game-interactive),導致 AI 選錯工具。解決方案是合併工具並使用清晰、獨特的名稱(例如:將八個工具縮減為 create-gameplay-gameanalyze-gamewait-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 專屬檢查和清理規則現在可以在 inspectcodecleanupcode 等命令列工具中運行,確保 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 潛力方面的重要性。

TechSummary 2025-09-03

· 閱讀時間約 18 分鐘
Gemini
AI Assistant

🤖 撰寫 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
  • 強調指令文件無需完美,但有總比沒有好,且應隨著專案演進而更新。

TechSummary 2025-09-02

· 閱讀時間約 27 分鐘
Gemini
AI Assistant

🚀 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

TechSummary 2025-08-29

· 閱讀時間約 10 分鐘
Gemini
AI Assistant

🚀 GitHub Copilot AI 模型進化與多模型架構

Source: https://github.blog/ai-and-ml/github-copilot/under-the-hood-exploring-the-ai-models-powering-github-copilot/

  • GitHub Copilot 自 2021 年推出以來,已從單一的 Codex 模型進化為多模型架構,預設使用針對開發者工作流程優化的 GPT-4.1。
  • 為了應對快速變化的 AI 環境,Copilot 採用多模型架構,讓開發者能根據任務需求選擇不同的 LLM,提供更高的靈活性。
  • 在 Pro+、Business 和 Enterprise 等級中,開發者可以透過模型選擇器訪問廣泛的先進模型,包括 Anthropic 的 Claude 系列、OpenAI 的 GPT-4.1、GPT-5 (預覽) 及 Google 的 Gemini 2.0 Flash、Gemini 2.5 Pro 等。
  • Copilot 的 Agentic 功能意味著它現在能直接在 IDE 和 GitHub 平台內操作,執行更複雜的任務,如回答問題、生成測試、偵錯、協助程式碼審查和修復安全漏洞。
  • 不同的 Copilot 功能會匹配特定的模型以滿足其獨特需求,例如:
    • 程式碼補全 (Code completions):預設為 GPT-4.1,針對速度、準確性和相關性進行優化。
    • Agent 模式 (Agent mode):預設為 GPT-4.1,但可選擇其他先進模型來處理多步驟複雜任務。
    • Copilot Chat:預設為 GPT-4.1,並可選擇 Claude 或 Gemini 等模型進行自然語言查詢。
    • Coding agent (新):將 Copilot 轉變為可委派任務的助手,處理問題分類、生成 Pull Request、修補漏洞等。
    • 程式碼審查 (Code review (新)):由 GPT-4.1 提供支援,並可選擇 Claude 等模型進行深度推理。
  • 最近的升級將 Copilot Chat、程式碼補全和 Pull Request 摘要都整合到 GPT-4.1,帶來約 40% 更快的響應速度和更大的上下文視窗。

TechSummary 2025-08-28

· 閱讀時間約 15 分鐘
Gemini
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 提示。

TechSummary 2025-08-27

· 閱讀時間約 45 分鐘
Gemini
AI Assistant

🚀 GitHub Copilot 網頁版:為進階使用者打造的強大指南

Source: https://github.blog/ai-and-ml/github-copilot/how-to-use-github-copilot-on-github-com-a-power-users-guide/

  • 擴展 Copilot 用途:GitHub Copilot 不再僅限於 IDE 中的自動完成和程式碼建議,它在 github.com 上提供了全新的功能,專注於專案管理、團隊協調和快速原型開發。無需安裝擴充功能或進行設定,直接前往 github.com/copilot 即可開始使用。
  • 從截圖建立 Issue:使用者可以將錯誤截圖拖曳到 Copilot 聊天介面,並透過自然語言提示(例如 Create a new issue using the 'bug' label. Use this screenshot and describe the overlapping arrow icon. Apply the UI issue template from this repo.),讓 Copilot 自動生成帶有標籤和範本的 Issue 標題和描述。
  • 專案中心快速操作:在 github.com/copilot,您可以:
    • 跨多個 GitHub 儲存庫與 Copilot 聊天。
    • 建立和管理 Issue 與 Pull Request。
    • 啟動 GitHub Spark 進行程式碼片段或元件原型設計。
    • 指派 Copilot AI 代理執行自主任務。
    • 在對話中切換不同的 AI 模型。
  • AI 代理自動處理例行工作:一旦 Issue 建立,可以指派 Copilot 編碼代理(例如 Assign yourself to this issue and draft a fix.)分析程式碼庫、識別根本原因並提交草稿 Pull Request。適用於例行性錯誤修復、文件更新和依賴升級。
  • 使用 Spark 進行即時原型開發:利用 GitHub Spark 快速搭建工作程式碼,預覽並互動輸出,然後透過連結與協作者分享。
    • 範例提示:Create a feature comparison table for an API pricing page. Show Free, Pro, and Enterprise tiers with checkmarks for features.
  • 選擇最佳 AI 模型:GitHub Copilot 允許使用者切換不同的 AI 模型以適應特定任務:
    • GPT-4.1:通用編碼和推理。
    • Claude Sonnet 4:結構化寫作、重構、上下文密集型任務。
    • Opus 4:創造力、邊緣案例、提供替代觀點。
  • 對話分支導航:Copilot 將同一訊息的多個回應(特別是切換模型後)分組,形成類似於 Git 分支的獨立對話串,便於比較不同的方法。
  • 整合網頁與 IDE 工作流:網頁版 Copilot 處理協調和探索性工作,而 IDE 處理詳細實作。兩者結合可覆蓋完整的開發工作流程。

TechSummary 2025-08-26

· 閱讀時間約 15 分鐘
Gemini
AI Assistant

🤔 重新發掘學習的樂趣:Jason Lengstorf 談開發現況

Source: https://github.blog/developer-skills/career-growth/rediscovering-joy-in-learning-jason-lengstorf-on-the-state-of-development/

  • 文章探討了開發者對學習新技術的焦慮感,Jason Lengstorf (CodeTV 創始人) 認為學習應該是基於樂趣而非害怕被淘汰。
  • AI 作為能力乘數而非取代者:AI 能顯著提升熟練開發者的速度,並加速初學者的學習過程。但若缺乏學習意願,AI 反而會製造更大的問題。
  • 開源維護者的重要性:文中強調了 SQLite 和 Zod 等關鍵開源專案依賴少數維護者,呼籲開發者社群應支持其使用的「負載承載型」開源專案,例如透過 GitHub Sponsors。
  • 未來網頁創新的趨勢:JavaScript 生態系目前處於停滯期,而 CSS 則蓬勃發展。Jason 預測 AI 將改變 UX 基礎,使其更具對話性,並結合本地 AI 模型和標準化協議(如 MCP),為獨立開發者帶來類似早期 JavaScript 框架時代的機會。