53 篇文章 含有標籤「AI」

GitHub Universe 2025：九大空間激發創造力與連結 🚀​

Source: https://github.blog/news-insights/company-news/explore-the-best-of-github-universe-9-spaces-built-to-spark-creativity-connection-and-joy/

• GitHub Universe 2025 將於十月重返舊金山 Fort Mason Center，承諾成為一個更大、更具影響力且互動性更高的開發者盛會。
• 活動將提供超過 100 場由專家主導的會議，並設有九個獨特空間，旨在激發創造力、促進連結並帶來樂趣。
• 優惠資訊：早鳥票折扣（可省 $400）持續至 9 月 8 日，團體購票（3 張或以上享 25% 折扣，8 張或以上享 35% 折扣）可與早鳥優惠疊加。
• 主要空間亮點：
  • GitHub Central：提供 GitHub Copilot、GitHub Actions、GitHub Advanced Security 等工具的現場演示和產品旅程。
  • GitHub Expert Center：提供與 AI、GitHub Actions、安全等專家進行 1 對 1 深度技術交流的機會。
  • Open Source Zone：連結全球開源貢獻者、維護者和社群領袖，探索 GitHub Accelerator 計畫中的新星專案。
  • Career Corner：提供 1 對 1 職涯教練諮詢，協助優化履歷、GitHub/LinkedIn 個人資料，並準備面試。
  • GitHub Learn：提供來自 GitHub 和 Microsoft Learn 的教程、認證和角色導向學習路徑。
  • 1:1 mentoring opportunity for students：學生可申請與 GitHub 員工進行虛擬微型指導會議，獲得履歷回饋和職涯建議。
  • Recess：非開發主題的休息交流區，例如樂高搭建或與高管輕鬆交流。
  • Makerspace：創意空間，讓程式碼與藝術、音樂、機器人等結合，鼓勵實驗和探索。
  • Hack your badge：所有現場參與者均可獲得一個可客製化和編程的會議徽章。
  • The Shop：提供獨家 GitHub 商品和紀念品。
• 鼓勵與會者充分利用這些空間，客製化其在 GitHub Universe 的體驗。

🌍 誰將維護未來？為新一代重新思考開源領導力​

Source: https://github.blog/open-source/maintainers/who-will-maintain-the-future-rethinking-open-source-leadership-for-a-new-generation/

• 開源社群「老齡化」問題： 根據 Tidelift 2024 年維護者調查，46-65 歲維護者的比例自 2021 年以來翻了一倍，而 26 歲以下貢獻者則從 25% 下降到 10%。這揭示了開源社群面臨的傳承危機和潛在的知識流失。
• Gen Z 貢獻者「Sam」視角： 文章引入一位 23 歲 Gen Z 貢獻者「Sam」的人格設定，他們渴望為有意義的氣候科技專案貢獻，透過 YouTube 自學程式碼，擅長線上社群管理，但對公開儲存庫感到畏懼。他們尋求目標、彈性及歸屬感。
• 「參與之山」框架： 為了幫助像 Sam 這樣的貢獻者茁壯成長，文章提出一個包含六個階段的框架：「參與之山」——發現、首次接觸、參與、持續參與、網絡參與、領導力。
• 針對 Gen Z 需求調整傳統最佳實踐：
  • 發現階段： Gen Z 透過 TikTok、Discord 和 YouTube 發現專案，他們希望在 README 中直接看到專案宗旨，並偏好行動裝置學習。專案需在 Gen Z 活躍的平台露面。
  • 首次接觸： 需提供行動友善、視覺優先的登陸體驗，以及像 Discord 這樣輕鬆開放的聊天頻道，讓新手可以潛水觀察。
  • 參與階段： Gen Z 偏好即時回饋、沙盒環境進行嘗試，以及提供允許學習而非僅限展示的空間，例如 FreeCodeCamp 和 Kubernetes 的貢獻者遊樂場模式。
  • 持續參與： 重視可分享的認可（徽章、提及、作品集），更關注影響力而非層級晉升。
  • 網絡參與： 偏好具名的、可分享的角色（如 Discord 版主、社群嚮導），非正式交流，以及同儕主導的領導模式（如 Rust 的共識驅動治理）。
  • 領導階段： 期望共同管理而非自上而下的控制，並尋求補償或專業成長，例如 TensorFlow 的貢獻者階梯。
• 具體行動建議： 將 README 轉化為 60 秒解說影片、建立首次貢獻者的沙盒空間、啟動 Discord 或非主題頻道以培養歸屬感、明確並公開專案使命。

🚀 Git 2.51 更新亮點​

Source: https://github.blog/open-source/git/highlights-from-git-2-51/

• 無碎片的 Multi-Pack Indexes (MIDXs)：
  • Git 2.51 引入新的打包行為，允許將無法到達的物件（“cruft pack” 中的物件）儲存在 MIDX 之外，解決了先前將它們排除在 MIDX 之外的困難。
  • 透過 repack.MIDXMustContainCruft 配置選項，可使非碎片套件集在可達性上是封閉的。
  • 這項改進在 GitHub 內部應用中，顯著縮小了 MIDXs 檔案大小（約 38%），寫入速度提升（35%），整體儲存庫讀取性能提高（約 5%）。
• Path Walk 實現更小尺寸的 Packfiles：
  • Git 2.49 引入了 "name-hash v2" 以改進物件的 Delta 壓縮。
  • Git 2.51 更進一步，引入了新的「path walk」物件收集方式，在打包時一次性處理來自相同路徑的所有物件。
  • 這種方法避免了名稱哈希啟發式，並可在已知位於相同路徑的物件組內尋找 Delta，從而產生通常更小尺寸的 Packfiles。可透過 --path-walk 命令列選項試用。
• Stash 交換格式：
  • 過去 Git Stash 內部透過創建三個提交來儲存狀態，且 refs/stash 只儲存一個 Stash 項目，導致跨機器遷移困難。
  • Git 2.51 引入了新的 Stash 內部表示形式，允許將多個 Stash 項目表示為一系列提交，類似於普通的提交日誌，新的 Stash 提交包含四個父級。
  • 新版本新增了 git stash export --to-ref 和 git stash import 子命令，使得 Stash 內容可以像普通分支或標籤一樣進行匯出、推送和拉取，實現跨機器遷移。

  # 在一台機器上
  git stash export --to-ref refs/stashes/my-stash
  git push origin refs/stashes/my-stash
  
  # 在另一台機器上
  git fetch origin '+refs/stashes/*:refs/stashes/*'
  git stash import refs/stashes/my-stash
  

• git cat-file 改進：
  • git cat-file 是用於列印物件原始內容的專用工具。
  • 在 Git 2.51 之前，查詢子模組路徑會顯示 missing。
  • Git 2.51 改善了此輸出，使其在指令碼場景中更有用，現在能正確識別子模組物件 ID 和類型。

  # [ pre-2.51 git ]
  echo HEAD:sha1collisiondetection | git cat-file --batch-check
  # HEAD:sha1collisiondetection missing
  
  # [ git 2.51 ]
  echo HEAD:sha1collisiondetection | git cat-file --batch-check
  # 855827c583bc30645ba427885caa40c5b81764d2 submodule
  

• Bloom Filter 改進：
  • Git 2.51 增加了對使用多個路徑規範項目的支持，例如 git log -- path/to/a path/to/b，這些以前無法利用已更改路徑的 Bloom filter。
• git switch 和 git restore 不再是實驗性命令：
  • 這兩個命令自 Git 2.23 引入以來，已穩定運行六年，其命令列介面已穩定並向後相容。
• git whatchanged 命令被棄用：
  • 此命令已被標記為棄用，並計畫在 Git 3.0 中移除，但仍可透過 --i-still-use-this 旗標使用。
• Git 3.0 的重大變更預告：
  • reftable 後端將成為 Git 3.0 中新建立儲存庫的預設格式。
  • SHA-256 哈希函數將成為 Git 3.0 中初始化新儲存庫的預設哈希函數。
• Git 內部開發流程更新：
  • 允許在程式碼庫中使用 C99 bool 關鍵字。
  • 修訂了貢獻補丁的準則，允許貢獻者使用其合法姓名以外的身份提交補丁，與 Linux 核心的方法更接近。

🔒 Docker @ Black Hat 2025：CVE 漏洞應對之道​

Source: https://www.docker.com/blog/docker-black-hat-2025-secure-software-supply-chain/

• 在 Black Hat 2025 大會上，CVE 漏洞成為核心議題，業界正從被動掃描轉向主動在軟體供應鏈源頭消除安全負債。
• 前進方向包括：使用強化版映像 (Hardened Images)、符合法規的工具以及強大的生態系合作夥伴關係 (如 Docker 與 Wiz)。
• 會議指出六大安全主題，強調掃描不足以應對，需要「零 CVE」的起始點，並透過提供 Debian 和 Alpine 等不同發行版，以及靈活的客製化能力來滿足企業需求。
• Docker Hardened Images (DHI) 提供零 CVE 的基礎映像，並附帶 SLA、SBOM (軟體物料清單) 和簽名證明，消除安全性與易用性之間的權衡。
• 即使是新興的 AI 工作負載，也能受益於既有的容器安全模式（隔離、閘道控制、執行前驗證），DHI 作為 AI 系統的可信啟動平台至關重要。

GPT-5 在 GitHub Copilot：我如何在 60 秒內建構一款遊戲 🚀​

Source: https://github.blog/ai-and-ml/generative-ai/gpt-5-in-github-copilot-how-i-built-a-game-in-60-seconds/

• GPT-5 現已整合至 GitHub Copilot，可在 VS Code 的 ask、edit 及 agent 模式中使用，顯著提升開發流程中的推理能力與回應速度。
• 啟用方式簡單，僅需在 Copilot 介面中開啟模型選擇器並選取 GPT-5 即可。企業用戶需經管理員啟用。
• 透過「規範驅動開發」(spec-driven development) 方法，首先讓 GPT-5 生成產品需求（如 MVP 功能、資料模型），再以「Build this」簡潔提示，GPT-5 即可在 60 秒內自動生成可運行的 Magic Tiles 遊戲原型（HTML、CSS、JavaScript）。
• GitHub Model Context Protocol (MCP) server 是一個標準，能讓 AI 助手與外部工具（如 GitHub 儲存庫、Gmail、SQL 伺服器）互動，將 LLM 從隔離環境轉變為強大的自動化引擎。
• 設定 GitHub MCP 伺服器僅需不到 5 分鐘，透過在工作空間根目錄建立 .vscode/mcp.json 配置檔並進行 GitHub OAuth 驗證即可。
• 實際應用範例包含透過自然語言創建 GitHub 儲存庫及批量建立議題，大幅減少上下文切換，提高開發效率。
• 這個工作流程的優勢在於 GPT-5 的處理速度、上下文保留能力，以及將自然語言作為開發介面，同時保持「人機協同」的控制。

🚨 GitHub 2025 年 7 月可用性報告​

Source: https://github.blog/news-insights/company-news/github-availability-report-july-2025/

• GitHub 於 2025 年 7 月 28 日經歷了一次服務降級事件，導致 GitHub Enterprise Importer (GEI) 在約 5 小時 34 分鐘內無法處理遷移作業。
• 事件根源在於 GEI 基礎設施的一個組件在例行內部改進過程中被錯誤地移除服務，且無法恢復到先前的配置，需重新佈建資源解決。
• 為了解決此問題，GitHub 已識別並實施了基礎設施恢復、單元測試以及使用測試數據進行更好驗證的改進。
• 受影響的用戶需更新其 IP 允許清單，新增 GEI 的新 IP 範圍 20.99.172.64/28 和 135.234.59.224/28，並移除不再使用的舊 IP 範圍 40.71.233.224/28 和 20.125.12.8/29。

🌐 從私有到公開：聯合國組織如何分四步開源其技術​

Source: https://github.blog/open-source/social-impact/from-private-to-public-how-a-united-nations-organization-open-sourced-its-tech-in-four-steps/

• 聯合國專門機構國際電信聯盟電信發展局 (BDT) 透過 GitHub 技能志願項目，成功將其閉源的 Azure DevOps 環境轉型為開放源碼社群，以賦能全球合作夥伴。
• 對於聯合國組織和非營利組織，開源能有效應對預算有限和團隊規模小的挑戰，大幅擴大其影響力。
• 開源轉型分為四個關鍵步驟：
  1. 進行研究： 分析喜歡和不喜歡的開源儲存庫，學習其 README、貢獻指南和社群運作方式，參考 Ersilia 和 Terraform 等活躍社群範例。
  2. 優化開源心態與程式碼： 清理敏感信息、提供範例數據，並創建清晰的「入門指南」(Getting Started) 和 CONTRIBUTING.md 文件，確保有自動化測試以維持程式碼品質。
  3. 釐清授權方式： 使用 choosealicense.com 等資源選擇合適的開源許可證（如 ITU 選擇了 BSD-2 許可證），並確保與專案依賴項的兼容性。
  4. 與開源社群互動： 將專案中的「小問題」標記為 good first issue，吸引新貢獻者快速上手並熟悉程式碼庫。
• BDT 與 GitHub 的合作不僅提升了其開源專業知識，也為其開源未來奠定了堅實基礎。

🔗 為何 GitHub 開源 MCP 伺服器，以及這對您的意義​

Source: https://github.blog/open-source/maintainers/why-we-open-sourced-our-mcp-server-and-what-it-means-for-you/

• 當 LLMs（大型語言模型）缺乏外部工具和數據源的連接能力時，容易產生幻覺（hallucinations），給出看似合理但錯誤的答案。
• Model Context Protocol (MCP) 是一個開放協議，旨在標準化 LLM 應用程式如何連接並使用外部工具和數據源，其角色類似於程式語言伺服器協議 (LSP) 之於程式語言，可以視為「LLM 的 LSP」。
• GitHub 已開源其 MCP 伺服器，作為 GitHub 平台與任何 LLM 之間的「真相來源」介面，有助於減少幻覺並啟用新的自動化工作流程。
• GitHub 的 MCP 伺服器允許使用者以自然語言發出請求（例如「列出所有開放的議題」），這些請求會被自動轉換為結構化、語義豐富的 API 調用，從而獲取 GitHub 上的即時數據。
• 該架構概念上簡單但功能強大，將語言模型、用戶體驗和數據/工具訪問分離，使每一層都模組化、可測試和可替換。
• 要在 VS Code 中使用 GitHub MCP 伺服器，需添加以下設定並完成 OAuth 流程：

  {
    "servers": {
      "github": {
        "type": "http",
        "url": "https://api.githubcopilot.com/mcp/"
      }
    }
  }
  

• 實際應用案例包括：將 GitHub Issues 自動轉換為 Markdown 內容文件、編譯每週團隊摘要的輕量級機器人、基於聊天的專案助手，以及個人化的 LLM 儀表板，這些都證明了 MCP 伺服器透過提供真實、結構化的上下文，使 AI 工具更智能和安全。

🔗 大規模保障供應鏈安全：從 71 個重要開源專案做起​

Source: https://github.blog/open-source/maintainers/securing-the-supply-chain-at-scale-starting-with-71-important-open-source-projects/

• Log4j 零日漏洞事件後，凸顯了開源庫安全性對整個軟體供應鏈的巨大影響，促使 GitHub 於 2024 年 11 月啟動「GitHub 安全開源基金」（GitHub Secure Open Source Fund）。
• 該基金為維護者提供資金支援，參與為期三週的專案，內容包含安全教育、導師指導、工具、認證及安全意識社群等，旨在提升安全影響力、降低風險，並大規模保護軟體供應鏈。
• 前兩期專案已集合來自 71 個重要開源專案的 125 位維護者，取得了顯著成果：
  • 修復了 1,100 多個由 CodeQL 檢測到的漏洞。
  • 發布了 50 多個新的常見漏洞與暴露（CVE），保護下游依賴項。
  • 阻止了 92 個新機密洩漏，並檢測和解決了 176 個已洩漏的機密。
  • 80% 的專案啟用了三個或更多基於 GitHub 的安全功能，63% 的專案表示對 AI 和 MCP 安全有更好理解。
  • 維護者利用 GitHub Copilot 進行漏洞掃描、安全審計、定義和實施模糊測試策略等。
• 專案涵蓋了 AI/ML 框架（如 Ollama, AutoGPT）、前端/全端框架（如 Next.js, shadcn/ui）、Web 伺服器/網路/閘道（如 Node.js）、DevOps/建置工具（如 Turborepo）、安全框架/身份/合規工具（如 Log4j）、以及開發者工具/CLI 助手（如 Charset-Normalizer, nvm, JUnit）等多個關鍵領域。
• 該計劃的成功關鍵在於：資金支援結合時間限制的專注訓練、互動式編碼經驗以及建立一個以安全為重點的社群，促進了維護者之間的快速交流與協作。

Remocal 與最小可行模型：為何適尺寸模型優於 API 過度依賴 🚀​

Source: https://www.docker.com/blog/remocal-minimum-viable-models-ai/

• AI API 使用的痛點： 傳統上過度依賴大型 AI API 導致企業面臨每月數百至數萬美元的高昂成本、高達 2-3 秒的響應延遲、敏感資料的隱私與合規性問題，以及開發者受限於龐大遠端模型的窘境。例如，一個簡單的情緒分析器每月可能花費 $847，一個聊天機器人則可能高達 $15,000。
• Remocal 混合開發策略： Remocal (remote + local) 是一種結合本地開發與雲端資源的混合方法。它允許開發者在本地使用較小型模型進行快速迭代與測試，並在 AI 應用場景或工作負載超出本地能力時，無縫地擴展到雲端 GPU 資源，解決了傳統開發中部署摩擦大、雲端管理複雜等問題。
• 最小可行模型 (Minimum Viable Model, MVM) 的概念： MVM 指的是部署能夠有效解決核心業務問題的最小、最有效率的模型。將 MVM 與 Remocal 方法結合，意味著可以首先在本地使用輕量級模型進行開發，僅在絕對必要時才調用更強大的雲端模型或運算資源，從而極大降低成本並加速開發迭代。
• 適尺寸模型技術突破： 許多創新技術讓模型在縮小體積的同時仍能保持高性能，使得 MVM 策略更加可行：
  • 策展資料小型語言模型 (SLMs)： 例如 Microsoft 的 Phi-4 系列，透過精心篩選的高品質訓練資料，使參數小於 15B 的模型在語言、編碼和數學基準上媲美甚至超越大型模型，大幅降低記憶體與延遲需求。
  • 量化 (Quantization)： 將模型權重壓縮至 4-bit 塊，並搭配低秩適配器層，可減少約 75% 的 GPU RAM 使用量，同時僅損失約 1% 的準確度，使筆記型電腦也能執行訓練或推論。
  • 稀疏專家混合 (Sparse Mixture-of-Experts, MoE)： 如 Mistral 的 Mixtral 8x7B，每次推論只啟用少於 25% 的參數，但性能可與密集型模型匹敵，有效降低服務成本。
  • 記憶體高效注意力核心 (Memory-efficient attention kernels)： 如 FlashAttention-2，透過優化讀寫，使注意力機制更適合片上 SRAM，倍增吞吐量並允許在普通 GPU 上處理更大上下文。
  • 設備端「奈米」模型 (On-device “nano” models)： 如 Google Gemini Nano 直接嵌入 Chrome 和 Android，證明參數小於 4B 的模型能在手機和瀏覽器上實現隱私、低延遲的本地推論。
• MVM 友善的生產就緒模型範例： 許多模型已針對高效能和低資源消耗進行優化：
  • Microsoft Phi-4 (14B)： 透過高度策展的訓練資料，在複雜推理、數學和編碼任務上表現優異，能以 4-bit 量化在 10-15GB VRAM 的環境下運行，性能超越大型模型。
  • Gemma 3 (27B)： 支援多模態與多語言，利用優化的量化技術，能在單一 RTX 3090 或 H100 GPU (約 7GB VRAM) 下提供與大型模型接近的性能。
  • SmolLM3 (3B)： 具雙模式推理、多語言及長上下文處理能力，僅需約 6GB VRAM，可在筆記型電腦或邊緣設備上運行，展現出超越其體積的強大效能。
• 選擇模型準則：
  • 何時選擇 API 模型： 當您需要廣泛的世界知識、複雜的多步驟跨領域推理、構建通用對話 AI、每月請求量少於 1,000 次，或 2-5% 的準確度提升能合理化 100 倍的成本時。
  • 何時選擇適尺寸模型： 當您的任務明確（如分類、程式碼補全、文件處理）、需要一致的低延遲響應、每次推論成本對業務模式至關重要、有資料隱私或合規性要求，或希望擺脫 API 速率限制時。大多數生產 AI 應用屬於此類，適尺寸模型能以極小成本提供接近大型模型的性能，同時具備更高的開發速度、靈活性和安全性。

🚀 提升程式碼審查與 Pull Request 效率：GitHub Copilot 的應用​

Source: https://github.blog/ai-and-ml/github-copilot/how-to-use-github-copilot-to-level-up-your-code-reviews-and-pull-requests/

• GitHub Copilot 的功能已從最初的程式碼補全，擴展到 Pull Request (PR) 和程式碼審查等多方面應用，有效提升開發工作流程效率。
• 在程式碼審查中，可利用 Copilot 建議程式碼改進或確認是否符合最佳實踐，例如重構重複的 Ruby on Rails 程式碼或檢查 Go 語言變數賦值的最佳實踐。

  "Can you refactor this Ruby on Rails code to reduce repetition?"
  

  "Is this code addition following Go best practices for variable assignment? If not, can you suggest improvements?"
  

• Copilot 能夠協助將原始資料（如試算表中的載入時間數據）格式化為 GitHub 風格的 Markdown 表格，使 PR 說明更加清晰易讀。

  Load Time Before (in seconds)   Load Time After Updates (in seconds)
  1.3 1.2
  1.2 1.1
  1.1 0.885
  1.3 1.3
  1.2 0.918
  
  Average 1.22    1.0806
  

  Copilot 輸出範例：

  | Test Run | Load Time Before (seconds) | Load Time After Updates (seconds) |
  |----------|---------------------------|-----------------------------------|
  | 1        | 1.3                       | 1.2                               |
  | 2        | 1.2                       | 1.1                               |
  | 3        | 1.1                       | 0.885                             |
  | 4        | 1.3                       | 1.3                               |
  | 5        | 1.2                       | 0.918                             |
  | **Average** | **1.22**                  | **1.0806**                         |
  

• Copilot 可為 Pull Request 摘要提供撰寫起點，即使需要編輯，也能有效降低撰寫門檻。
• 開發者可利用 Copilot 進行初步的程式碼審查，找出潛在問題或提供更好的撰寫方式；同時也能請求 Copilot 解釋不熟悉的程式碼，加速理解並提供更周全的審查意見。