跳至主要内容

6 篇文章 含有標籤「.NET」

檢視所有標籤

TechSummary 2025-09-18

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

🚀 將 GitHub Copilot 編碼代理更深入地整合到您的工作流程的 5 種方法​

Source: https://github.blog/ai-and-ml/github-copilot/5-ways-to-integrate-github-copilot-coding-agent-into-your-workflow/

  • GitHub Copilot 編碼代理不僅限於基礎任務指派與 PR 審核，本教學將探討五種策略，將其更深入地整合到開發工作流程中。
  • 透過代理面板處理技術債務： 將重複但必要的任務（如依賴升級、小型重構）批次交給 Copilot 處理，讓開發者專注於功能開發。
    • 任務範例： 
      “Update the extension manifest to support VS Code 1.104”
      “Add TypeScript strict mode and fix all resulting type errors”
  • 使用 Playwright MCP 驗證 UI 變更： Copilot 可透過 Playwright MCP 伺服器整合，自動啟動應用程式、與其互動並截圖，以便在 PR 中直接審核 UI 變更。
    • 任務範例： 
      “Add internationalization support for English, French, and Spanish.”
  • 安全地試驗分支策略： Copilot 支援從任意分支作為起點建立 copilot/ 分支進行實驗，並開啟草稿 PR 供審閱與回饋，無需影響主分支。
  • 選擇正確的任務入口點： 針對不同情境選擇最適合的入口點，例如：代理面板適用於瀏覽 GitHub 時的臨時任務；GitHub Issues 適用於團隊追蹤工作；VS Code 適用於即時重構；GitHub Mobile 適用於離線小任務。
  • 使用 MCP 伺服器擴展 Copilot 編碼代理： 除了內建的 Playwright 和 GitHub MCP，還可透過自訂 MCP 伺服器（如 Notion MCP、Hugging Face MCP）提供更多上下文，提升 Copilot 的智慧，並可透過開源 MCP Registry 發現或發佈整合。

TechSummary 2025-09-17

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

如何使用 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）正常存取網路。

TechSummary 2025-09-02

· 閱讀時間約 27 分鐘
Gemini
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-19

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

Agents panel: Launch Copilot coding agent tasks anywhere on GitHub 🚀​

Source: https://github.blog/news-insights/product-news/agents-panel-launch-copilot-coding-agent-tasks-anywhere-on-github/

  • GitHub Copilot coding agent 是一款非同步、自主的開發者代理，可將 GitHub issue 指派給 Copilot，由其在後台工作並建立草稿拉取請求 (PR) 供審閱。
  • 新推出的 Agents panel 允許開發者從 GitHub.com 上的任何頁面快速將任務委託給 Copilot，並追蹤其進度而無需中斷工作流程。
  • Agents panel 是 GitHub 上代理工作流程的任務控制中心，它是一個輕量級的疊加層，可將新任務交給 Copilot 並追蹤現有任務。
  • 可用的功能包括：無需切換頁面即可分配後台任務、實時監控運行中的任務、以及在準備好審閱時跳轉到拉取請求。
  • 支援從 GitHub.com、GitHub Mobile、Copilot Chat、VS Code 或支援 MCP 的工具發起任務。
  • Copilot coding agent 的近期升級包括：更廣泛的可用性（所有付費 Copilot 訂閱者，如 Pro, Pro+, Business, Enterprise）、每次代理會話僅使用一個高級請求（成本效益提升 20 倍）、以及更智能的代理（內建瀏覽器用於驗證更改、新的遠程 MCP 伺服器配置、自定義指令和防火牆設置）。
  • 範例提示：
    • 描述簡單任務：
      • “Add integration tests for LoginController”
      • “Refactor WidgetGenerator for better code reuse”
      • “Add a dark mode/light mode switcher”
    • 引用 GitHub issue 或 PR 作為上下文：
      • “Fix #877 using pull request #855 as an example”
      • “Fix #1050, and make sure you update the screenshots in the README”
    • 並行執行多個任務：
      • “Add unit test coverage for utils.go” + “Add unit test coverage for helpers.go”

TechSummary 2025-08-18

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

🚀 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 核心的方法更接近。

TechSummary 2025-07-25

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

⚙️ Upcoming Changes to JetBrains .NET Tools​

Source: https://blog.jetbrains.com/dotnet/2025/07/25/upcoming-changes-to-dotnet-tools/

  • JetBrains 將依據用戶回饋和使用數據，對其 .NET 工具進行一系列精簡與調整，旨在提升工具效能並聚焦核心功能。
  • 2025.2 版本更新重點：
    • dotCover 精簡化： 獨立的 dotCover 工具將被精簡以提升性能並降低複雜度。命令列運行器已現代化，指令整合至統一的 dotcover cover 介面，配置檔從 XML 轉換為簡潔的純文字參數檔。
    • 移除部分不常用過濾選項（方法/類別過濾器、檔案路徑過濾器、原始碼註解過濾器），並終止對舊版應用程式類型（如 IIS Express, WCF, WinRT, 外部 .NET 程序）的支援。
    • Rider 中 Mono 和 Unity 專案的程式碼覆蓋率分析終止： Rider 2025.2 起將不再提供 Mono 和 Unity 專案的覆蓋率分析，因使用率低且增加了技術債。待 Unity 遷移至 CoreCLR（預計 Unity 7 LTS 後）將恢復 Unity 專案的覆蓋率分析。
    • Visual Studio 的 TeamCity 擴充功能終止： 為了簡化工具鏈並專注於更具影響力的開發體驗，此擴充功能將被停用。
  • 2025.3 版本更新重點：
    • Rider 中的動態程式分析 (DPA) 功能整合： DPA 將不再作為獨立工具，其分析能力將進一步整合到 Monitoring 工具中，並作為 dotUltimate 許可證的一部分提供（與 dotTrace 和 dotMemory 分析器相同）。
  • 這些變更旨在釋放開發資源，以持續改進工具的性能、穩定性和核心功能。