10 篇文章 含有標籤「CloudComputing」

🚨 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 工具更智能和安全。

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 應用屬於此類，適尺寸模型能以極小成本提供接近大型模型的性能，同時具備更高的開發速度、靈活性和安全性。

🚀 初級開發者並未過時：如何在 AI 時代蓬勃發展​

Source: https://github.blog/ai-and-ml/generative-ai/junior-developers-arent-obsolete-heres-how-to-thrive-in-the-age-of-ai/

• 人工智慧並不會讓初級開發者過時；相反地，新進學習者因具備 AI 工具的應用能力，反而處於有利位置。
• GitHub 執行長 Thomas Dohmke 強調，熟悉 AI 程式碼生成工具的新人才，能帶來更好的想法。
• 提供初級開發者在 AI 時代脫穎而出的五種方法：
  1. 利用 AI 加速學習，而非僅加速編碼： 將 GitHub Copilot 設定為個人導師，教導概念和最佳實踐，而非直接提供完整解決方案。可以透過 VS Code 命令面板運行 Chat: New Instructions File 並貼上以下指令：

     ---
     applyTo: "**"
     ---
     I am learning to code. You are to act as a tutor; assume I am a beginning coder. Teach me concepts and best practices, but don’t provide full solutions. Help me understand the approach, and always add: "Always check the correctness of AI-generated responses."
     

     此外，練習在不使用自動完成功能的情況下解決問題（可透過在專案根目錄 .vscode/settings.json 中設定 {"github.copilot.enable": {"*": false}} 來禁用）。
  2. 建立公開專案以展示技能（和 AI 熟練度）： 利用 GitHub Copilot Chat 的 /new 指令來啟動新專案，並使用以下 Git 命令將其發布：

     git init && git add . && git commit -m "Initial commit" && git push
     

  3. 透過核心 GitHub 工作流程提升開發工具包： 掌握 GitHub Actions 自動化、參與開源專案以及透過 Pull Request 進行協作。Copilot Chat 可協助排除故障。
  4. 透過程式碼審查磨練專業知識： 積極提問、尋找模式、做筆記並保持謙遜。
  5. 運用 AI 更智慧、更快速地除錯： 使用 Copilot Chat 指令如 /fix、/tests、/explain 和 /doc 來即時解釋錯誤、生成修復方案、創建測試案例和理解根本原因。

加速 Docker 強化映像的 FedRAMP 合規性 🚀​

Source: https://www.docker.com/blog/fedramp-compliance-with-hardened-images/

• FedRAMP 合規挑戰： 聯邦風險與授權管理計畫 (FedRAMP) 合規成本高昂（45 萬至 200 萬美元以上），且需耗時 12 至 18 個月，這期間競爭對手可能已搶佔政府合約。企業需面對 NIST SP 800-53 中超過 400 項嚴格的安全控制要求。
• Docker 強化映像 (DHI) 解決方案： Docker 硬化映像提供自動化、可稽核的安全解決方案，旨在加速 FedRAMP 合規流程並降低維護成本。DHI 是一系列精簡的映像，持續更新以確保幾乎沒有已知的 CVE。
• FIPS 140 合規性： DHI 支援 FIPS 140 驗證的密碼學模組，預配置並經過測試，可確保正確功能。每個 FIPS 合規映像都附有簽名的證明，列出使用的 FIPS 驗證軟體及其 CMVP 認證和測試結果連結，支援 OpenSSL、Bouncy Castle 和 Go 等主要開源密碼學模組。
• STIG 強化映像： Docker 根據國防信息系統局 (DISA) 發布的通用作業系統 (GPOS) SRG，創建了客製化的容器 STIG。STIG 強化映像在安全建構過程中會使用 OpenSCAP 進行掃描，結果會作為簽名證明提供，其中包含易於查看的 STIG 合規分數，並支援輸出為 HTML 和 XCCDF 格式，便於稽核。
• 持續合規性：
  • 漏洞減少： DHI 起始攻擊面減少高達 95%（按包數量計算），持續更新以確保幾乎沒有已知 CVE，並掃描病毒和機密。
  • 漏洞檢測與修復： Docker 持續監控 CVE 來源，DHI 對嚴重/高風險漏洞的修復 SLA 為 7 天，中/低風險為 30 天，幫助滿足 FedRAMP 修復時限。提供 VEX (Vulnerability Exploitability eXchange) 證明來過濾不適用漏洞。
  • 供應鏈透明度： DHI 使用 SLSA Build Level 3 安全建構管道，確保建構可驗證性與防篡改。提供簽名證明和多種 SBOM 格式。
  • 稽核證據： DHI 證明符合 in-toto 證明標準，作為 provenance、資產管理、漏洞掃描及 FIPS 合規性的安全證據。

Rust 與 Java：為您的專案選擇正確的工具 💻​

Source: https://blog.jetbrains.com/rust/2025/08/01/rust-vs-java/

• 兩者對比：Rust以其安全性與效能備受讚譽，學習曲線較陡峭但社群成長迅速；Java則因其成熟度與廣泛應用而成為企業級解決方案的基石。Rust的用戶群在2024年達到約227萬開發者，而Java因其成熟且穩健的生態系仍吸引數千萬開發者。
• Rust的演進與核心理念：起源於2006年Mozilla的專案，於2015年發布1.0穩定版。其核心原則是在沒有垃圾回收的情況下確保記憶體安全，並透過「所有權」（ownership）和「借用」（borrowing）概念避免資料競爭。它杜絕了空指針解引用、懸空指針或緩衝區溢位等常見錯誤。
• Rust的熱門應用場景：主要用於系統級軟體（如作業系統、嵌入式系統）、WebAssembly、命令列介面（CLIs）、遊戲開發以及Web3領域，因其對記憶體、效能及安全性的嚴格控制而表現出色。
• Java的歷史與核心理念：可追溯到1991年，於1995年發布。其核心理念是「一次編寫，到處執行」（Write Once, Run Anywhere），透過將程式碼編譯為位元組碼並由Java虛擬機（JVM）解釋執行實現跨平台。Java也嚴格遵循物件導向程式設計（OOP）和DRY（Don’t Repeat Yourself）原則。
• Java的當前用途：廣泛應用於企業級軟體（如Amazon, Google, Netflix）、Android應用程式開發、網頁服務以及大數據處理（如Apache Hadoop, Spark, Kafka）。
• 技術差異：
  • 執行時：Java依賴JVM，提供自動垃圾回收和JIT編譯，易於跨平台開發但有記憶體和啟動時間開銷。Rust則提供最小化執行時（zero-cost abstractions），無垃圾回收器，提供精細的記憶體和速度控制。
  • 效能：Rust因無垃圾回收和對資源的精細控制，提供可預測的高速執行。Java依賴JIT編譯器在執行時優化效能，但可能因垃圾回收導致啟動時間較長和不可預測的暫停。
  • 記憶體管理：Java透過垃圾回收自動管理記憶體。Rust則在編譯時透過所有權和借用系統強制執行記憶體安全，無需執行時垃圾回收，提供高效能和可靠性。
  • 學習曲線：Java對初學者較為友好，尤其是熟悉物件導向程式設計的開發者。Rust的學習曲線較陡峭，其所有權概念和借用檢查器可能讓新手感到挫折，但提供了穩定高效的程式碼。
• 工具與生態系差異：
  • IDEs：Java有IntelliJ IDEA、Eclipse、NetBeans等成熟IDE。Rust在IDE支援上進步顯著，有RustRover，IntelliJ IDEA也透過插件支援Rust。
  • 建構系統與套件管理器：Rust擁有統一的工具鏈Cargo，集建構系統、套件管理器和依賴管理器於一身，使用簡單。Java則有多種建構工具，如Maven和Gradle，功能強大但配置較為複雜。
  • 除錯與分析工具：Java擁有數十年發展的成熟除錯和分析工具。Rust除錯依賴GDB或LLDB，但生態系仍在演進。
  • 開發者體驗：Java提供成熟的企業級開發體驗。Rust的體驗更現代、簡化且社群化，尤其適合注重安全性、效率和簡潔工具流程的開發者。
• 社群與採用差異：
  • 社群規模與活躍度：Java擁有龐大且成熟的社群。Rust的社群雖較新，但活躍且快速成長。
  • 函式庫與框架：Java擁有龐大的函式庫與框架生態系，如Spring、Jakarta EE。Rust的函式庫生態系仍在擴展，在系統程式設計、嵌入式開發、遊戲引擎等領域表現出色。
  • 行業採用與職缺趨勢：Java在企業軟體、Android和後端開發領域仍有高需求。Rust的職缺市場雖小但快速成長，被Mozilla、Dropbox、Amazon等公司用於效能或安全關鍵應用。
• 共同點：兩者都旨在防止常見的記憶體相關錯誤；提供強大的並行支援（Java使用傳統線程和java.util.concurrent，Rust強調「無畏並行」和async/await）；具備跨平台能力（Java透過JVM，Rust編譯為原生機器碼並支援WebAssembly）；支援現代語言特性（如泛型和函數式程式設計）；均可用於後端或伺服器端開發。
• 選擇建議：Rust適用於需要低層次控制、極致效能和記憶體安全的場景（如作業系統、設備驅動、高效能運算、WebAssembly）。Java則適用於大型企業應用，重視穩定性、可維護性和成熟生態系（如Android、網路服務、大數據處理）。
• 互操作性：可透過Java Native Interface (JNI) 將Rust編譯的函式庫整合到Java專案中，結合兩者的優勢。

Onboarding your AI peer programmer: Setting up GitHub Copilot coding agent for success 🚀​

Source: https://github.blog/ai-and-ml/github-copilot/onboarding-your-ai-peer-programmer-setting-up-github-copilot-coding-agent-for-success/

• GitHub Copilot 提供兩種代理功能：coding agent (自主，生成 PR) 與 agent mode (互動式，即時執行多步驟任務)。
• coding agent 的工作流程包括創建分支與 PR、在 GitHub Actions 容器中建立環境、閱讀問題、探索專案、迭代解決方案並最終更新 PR。
• 可透過自訂 GitHub Actions workflow 檔案（例如 .github/workflows/copilot-setup-steps.yml）來配置 Copilot 的執行環境，確保其能存取所需的工具和服務。

  name: "Copilot Setup Steps"
  
  on:
    workflow_dispatch:
    push:
      paths:
        - .github/workflows/copilot-setup-steps.yml
    pull_request:
      paths:
        - .github/workflows/copilot-setup-steps.yml
  
  jobs:
    copilot-setup-steps:
      runs-on: ubuntu-latest
      permissions:
        contents: read
      steps:
        - name: Checkout code
          uses: actions/checkout@v4
  
        - name: Set up Python
          uses: actions/setup-python@v4
          with:
            python-version: "3.13"
            cache: "pip"
  
        - name: Install Python dependencies
          run: pip install -r requirements.txt
  
        - name: Install SQLite
          run: sudo apt update && sudo apt install sqlite3
  

• 撰寫清晰明確的 Issue 與提示對 Copilot 成功生成高品質 PR 至關重要，應包含問題陳述、重現步驟、相關歷史、建議方法等。
• 透過優化專案結構（README、代碼註釋、良好命名）和自訂指令文件（copilot-instructions.md 或 <file-name>.instructions.md）來提供 Copilot 上下文資訊和組織規範。

  # Classic arcade
  
  This project hosts a classic arcade, themed after the 1980s 8-bit games.
  
  ## Standard player flow
  
  1. Player opens app and sees list of games.
  2. Player selects game to play.
  3. Player sees a splash screen with the message "Insert quarter".
  4. Player presses space to start game and plays game
  6. After game ends, the "Game over" message is displayed.
  7. The player score is checked against high scores. If the score is in top 10, user is prompted for their initials (3 initials).
  8. High scores are displayed, and an option to return to the main menu to start over again.
  
  ## Frameworks
  
  - Python `arcade` library is used for the arcade itself
  - SQLite is used to store all scores
  
  ## Coding guidelines
  
  - All games must inherit from `BaseGame`
  - Python code should follow PEP8 practices, including docstrings and type hints
  
  ## Project structure
  
  - `data`: Stores data abstraction layer and SQLite database
  - `games`: Stores collection of games and `BaseGame`
  - `app`: Stores core app components including menuing system
  

• 可利用 Model Context Protocol (MCP) 擴展 Copilot 的上下文和工具，例如透過 Azure MCP server 支持 Bicep 程式碼生成。

  {
    "mcpServers": {
      "AzureBicep": {
        "type": "local",
        "command": "npx",
        "args": [
          "-y",
          "@azure/mcp@latest",
          "server",
          "start",
          "--namespace",
          "bicepschema",
          "--read-only"
        ]
      }
    }
  }
  

• Copilot coding agent 內建防火牆，可限制對核心服務的存取，以管理數據外洩風險；遠端 MCP server 或網路資源存取需更新允許列表。

如何使用 GitHub MCP 伺服器實用指南 🚀​

Source: https://github.blog/ai-and-ml/generative-ai/a-practical-guide-on-how-to-use-the-github-mcp-server/

• GitHub Managed Model Context Protocol (MCP) 伺服器提供全託管端點，免除本地 Docker、存取權杖管理與手動更新的麻煩，讓開發者專注於程式碼交付。
• 從本地 MCP 設定升級至 GitHub 託管端點，可獲得 OAuth 身份驗證、自動更新，並存取更豐富的 AI 工作流程工具組。
• 預設工具集包括：儲存庫智慧（Repository intelligence）、議題與拉取請求自動化（Issue and pull request automation）、CI/CD 可見性（CI/CD visibility）、安全洞察（Security insights），並可進行細粒度控制。
• 託管伺服器與本地 Docker 設置的對比：
  • 本地 Docker 伺服器：需手動維護 Docker 映像、管理個人存取權杖（PATs）、僅限 localhost 存取、預設完整寫入權限。
  • 託管 MCP 端點：GitHub 自動修補與升級、一次性 OAuth 登入、可從任何 IDE 或遠端開發環境存取、內建唯讀模式與按工具集旗標控制。
• 安裝步驟簡便：在 VS Code 中執行 GitHub MCP: Install Remote Server 並完成 OAuth 流程；其他客戶端則設定伺服器 URL 為 https://api.githubcopilot.com/mcp/。可透過 curl -I https://api.githubcopilot.com/mcp/healthz 驗證連接。
• 彈性配置存取控制：
  • 設定唯讀模式以安全探索，例如：

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

  • 透過 toolsets 陣列限制作用範圍，例如：

    "toolsets": ["context", "issues", "pull_requests"]
    

• 實際應用範例：
  • 新增 CODEOWNERS 檔案並開啟拉取請求：提示 Copilot Agent 即可自動創建檔案、開啟 PR 並指派審閱者。
  • 偵錯失敗的工作流程：提示 Why did the release.yml job fail last night? 即可分析日誌並建議修復。
  • 分類安全警報：提示 List critical Dependabot alerts across all my repos and create issues for each. 即可列出警報並創建對應議題。
• 未來展望：MCP 伺服器將支援 AI 生成秘密掃描（Secret scanning）及阻擋，並能直接指派議題給 Copilot，實現代理對代理（agent-to-agent）的協作工作流程。

GitHub 全新開源播客：從初次提交到大型專案 🎧​

Source: https://github.blog/open-source/maintainers/from-first-commits-to-big-ships-tune-into-our-new-open-source-podcast/

• GitHub 推出全新播客，深入探討開源生態系的故事、專案、人物與理念，強調開源作為軟體創新的重要發射台，尤其在 AI agents、edge runtimes、climate-tech dashboards 等領域。
• 播客由 Abby Cabunoc Mayes、Cassidy Williams、Kedasha Kerr 和 Andrea Griffiths 等資深開源貢獻者輪流主持，分享社群建設、開源科學、開發者教育和公開構建等多元視角。
• 首集介紹主持人如何參與開源，並探討在內容飽和的世界中創建初學者內容的重要性。
• 節目每兩週更新一集，將邀請 Jason Lengstorf 和 Keeley Hammond 等特別嘉賓分享他們的開源旅程和見解。
• 亮點開源專案預覽：
  • Anime.JS: 視覺效果出眾的 JavaScript 動畫函式庫。
  • Docs: 法國和德國政府合作開發的開源文件協作編輯器。
  • CSS Zero: 簡化網頁開發的無構建前端入門套件。
• 後續主題將深入探討 Model Context Protocol (MCP) 如何提升 AI 工具的透明度和互操作性。

🌾 GitHub Copilot 助力小農戶擴大影響力​

Source: https://github.blog/open-source/social-impact/scaling-for-impact-how-github-copilot-supercharges-smallholder-farmers/

• 願景與擴展： One Acre Fund 成立於 2006 年，從肯亞的 40 個農戶發展至今已服務非洲十個國家的 500 萬農戶。他們的目標是到 2030 年每年支援 1000 萬農戶，透過開源技術和 AI 創造 10 億美元的新收入。
• 技術賦能小農戶： 組織提供肥料、種子、培訓和服務，幫助小農戶提高作物產量、改善土壤健康、種植樹木，並增強對氣候變化的抵禦能力。農民對技術的態度從最初的猶豫轉變為積極。
• GitHub Copilot 的影響： GitHub Copilot 極大地加速了 One Acre Fund 的開發進度，使專案完成速度提升三倍，超過 30% 的工作由 AI 輔助完成。這使他們能夠設定並達成更多目標。
• 開源解決方案的優勢： 作為非營利組織，One Acre Fund 選擇開源技術是為了平衡「解決方案成熟度與靈活性」，同時避免隨規模擴展而指數級增長的許可費用。他們已將核心營運系統大部分遷移到開源。