TechSummary 2025-10-13

2025年10月14日 · 閱讀時間約 8 分鐘

AI Assistant

🚀 GitHub Copilot CLI 入門

Source: https://github.blog/ai-and-ml/github-copilot/github-copilot-cli-how-to-get-started/

GitHub Copilot CLI 將 AI 輔助直接帶入終端機，讓開發者無需切換編輯器或瀏覽器，即可在 CLI 中完成程式碼撰寫、除錯、環境設定等工作，保持開發流程的連續性。
快速安裝與驗證：
- 全域安裝 @github/copilot-cli 套件，要求 Node v22+ 和 npm v10+。
- 啟動 copilot 並使用 /login 透過現有的 GitHub Copilot Pro/Business 帳戶進行身份驗證。
```
npm install -g @github/copilot-cli
copilot
/login
```
多樣化的使用情境：
- 新專案上手： 詢問 Explain the layout of this project. 以理解專案結構。
- 環境準備： 透過 Make sure my environment is ready to build this project. 自動檢查並安裝依賴。
- 尋找任務： 使用 Find good first issues in this repository and rank them by difficulty. 篩選合適的入門級問題。
- 實作與提交： 透過 Start implementing issue #1234. Show me the diff before applying. 讓 Copilot 草擬修復，並以 Stage changes, write a commit referencing #1234, and open a draft PR. 快速提交並開啟草稿 Pull Request。
- 解決常見問題： 應對埠佔用等問題，如 What process is using port 8080? Kill it and verify the port is free.
使用者控制與安全性： Copilot CLI 在執行任何指令或存取目錄前，都會先提示使用者（Allow once, Allow always, Deny），確保使用者對 AI 的操作保持完全控制。
擴展與自訂： 支援 MCP (Microsoft Copilot Protocol) 伺服器，使用者可以透過 /mcp 指令整合其他工具，如 Playwright 或企業內部工具，進一步擴展功能。

💡 使用代理原語與上下文工程構建可靠的 AI 工作流程

Source: https://github.blog/ai-and-ml/github-copilot/how-to-build-reliable-ai-workflows-with-agentic-primitives-and-context-engineering/

該指南提出一個三層框架，旨在將 AI 探索從隨機提示轉變為可重複、可靠的工程實踐，核心概念是「代理原語」(Agentic Primitives) 和「上下文工程」(Context Engineering)。
AI 原生開發框架公式： Markdown 提示工程 + 代理原語 + 上下文工程 = 可靠性。

第一層：Markdown 提示工程

利用 Markdown 的結構（標題、列表、連結）為 AI 提供清晰、精確和富含上下文的提示，以引導 AI 推理並獲得更可預測的輸出。
技術應用： 上下文載入 (連結到檔案或網站)、結構化思維、角色激活、工具整合 (MCP tool)、精確語言和驗證門檻。

範例： 將模糊的「Find and fix the bug」改為詳細的結構化指令，包含角色、參考文件、步驟、工具和人類驗證點。

You are an expert debugger, specialized in debugging complex programming issues.

You are particularly great at debugging this project, which architecture and quirks can be consulted in the [architecture document](./docs/architecture.md).

Follow these steps:
1. Review the [error logs](./logs/error.log) and identify the root cause.
2. Use the `azmcp-monitor-log-query` MCP tool to retrieve infrastructure logs from Azure.
3. Once you find the root cause, think about 3 potential solutions with trade-offs
4. Present your root cause analysis and suggested solutions with trade-offs to the user and seek validation before proceeding with fixes - do not change any files.

第二層：代理原語 (Agentic Primitives)
- 指的是可重複使用的簡單檔案或模組，為 AI 代理提供特定能力或規則，將提示工程的洞察轉化為可配置的系統。
- 核心代理原語類型：
  - .instructions.md：透過模組化檔案部署結構化指導。
  - .chatmode.md：透過基於角色的專業知識和 MCP 工具邊界部署。
  - .prompt.md：部署可重用的提示工作流程。
  - .spec.md：透過規範檔案創建實作藍圖。
  - .memory.md：透過記憶體檔案保留跨會話知識。
  - .context.md：透過上下文助手檔案優化資訊檢索。
- 範例： frontend.instructions.md 檔案，透過 YAML Frontmatter 的 applyTo 選擇性應用於特定檔案類型，並定義開發準則、上下文載入和結構化輸出要求。
```
---
applyTo: "**/*.{ts,tsx}"
description: "TypeScript development guidelines with context engineering"
---
# TypeScript Development Guidelines

## Context Loading
Review [project conventions](../docs/conventions.md) and
[type definitions](../types/index.ts) before starting.

## Deterministic Requirements
- Use strict TypeScript configuration
- Implement error boundaries for React components
- Apply ESLint TypeScript rules consistently

## Structured Output
Generate code with:
- [ ] JSDoc comments for all public APIs
- [ ] Unit tests in `__tests__/` directory
- [ ] Type exports in appropriate index files
```

第三層：上下文工程 (Context Engineering)

策略性地管理 AI 的上下文視窗，確保其專注於相關資訊，避免無關上下文或有限記憶體導致的失敗，提升可靠性和效率。
關鍵技術： 會話分離、模組化和自定義規則、記憶體驅動開發、上下文優化和認知專注優化。

範例： backend-engineer.chatmode.md 定義了後端開發專家的角色、工具限制和模型選擇，透過 tools 列表限制 AI 只能使用特定工具，確保安全邊界。

---
description: 'Backend development specialist with security focus'
tools: ['changes', 'codebase', 'editFiles', 'runCommands', 'runTasks',
        'search', 'problems', 'testFailure', 'terminalLastCommand']
model: Claude Sonnet 4
---
You are a backend development specialist focused on secure API development, database design, and server-side architecture. You prioritize security-first design patterns and comprehensive testing strategies.

## Domain Expertise
- RESTful API design and implementation
- Database schema design and optimization
- Authentication and authorization systems
- Server security and performance optimization

## Tool Boundaries
- **CAN**: Modify backend code, run server commands, execute tests
- **CANNOT**: Modify client-side assets

工具生態系統演進： 將代理原語視為軟體，需要類似傳統程式碼的基礎設施支援。

Agent CLI 運行時： 如 GitHub Copilot CLI，用於在終端機中執行、調試和自動化 AI 工作流程。

APM (Agent Package Manager)： 提供統一的運行時管理和套件分發，類似 npm，支援安裝和配置多個 Agent CLI 運行時，以及管理依賴和編譯代理原語。

curl -sSL https://raw.githubusercontent.com/danielmeppiel/apm/main/install.sh | sh
apm runtime setup copilot          # 安裝 GitHub Copilot CLI
apm install                        # 安裝 MCP 依賴
apm compile                        # 編譯代理原語檔案
apm run copilot-sec-review --param pr_id=123 # 執行工作流程

生產部署： 透過 APM GitHub Action 將打包的代理原語整合到 CI/CD 流程中，實現自動化 AI 工作流程。

# .github/workflows/security-review.yml
name: AI Security Review Pipeline
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  security-analysis:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        script: [copilot-sec-review, codex-sec-review, copilot-debug]
    steps:
    - uses: actions/checkout@v4
    - name: Run Security Review (${{ matrix.script }})
      uses: danielmeppiel/action-apm-cli@v1
      with:
        script: ${{ matrix.script }}
        parameters: |
          {
            "pr_id": "${{ github.event.pull_request.number }}"
          }
      env:
        GITHUB_COPILOT_PAT: ${{ secrets.COPILOT_CLI_PAT }}

關鍵結論： 代理原語是可執行的自然語言程式，需要專業工具基礎設施；運行時多樣性實現擴展；套件管理是可移植和可共享的關鍵；生產就緒的工具鏈支援 CI/CD 中的自動化 AI 工作流程；包管理基礎設施促進了蓬勃發展的生態系統。

🔒 100% 透明度與五大支柱：容器安全強化指南

Source: https://www.docker.com/blog/100-transparency-and-five-pillars/

隨著容器成為雲原生應用和 AI 應用程式運行的主流形式，確保容器安全變得至關重要。Docker 指出許多聲稱提供「強化映像」(hardened images) 的供應商，其實並未能滿足真正的安全標準。
Docker 的容器安全願景：五大核心要素 + 100% 透明度。
五大支柱：最大化容器安全的關鍵要素
1. 最小攻擊面 (Minimal Attack Surface)： 強化映像僅包含絕對必要的軟體，平均可消除 98% 以上的 CVE 暴露。
2. 100% 完整軟體物料清單 (SBOM - Software Bill of Materials)： 必須 100% 完整（根據 CISA 指導），包含直接、間接和傳遞性依賴，可透過 SPDX 或 CycloneDX 等開放標準驗證回溯來源。
3. 可驗證的建構出處 (Verifiable Build Provenance)： 建立從原始碼到部署物件的完整監管鏈。SLSA Build Level 3 提供不可偽造的建構證明，確保來源可信。
4. 標準化可利用性評估 (Standardized Exploitability Assessment)： 使用 OpenVEX 提供機器可讀的漏洞狀態聲明，澄清哪些漏洞影響特定部署上下文，幫助團隊專注於實際風險。
5. 加密驗證 (Cryptographic Verification)： 透過 Sigstore 和 Cosign 等現代方法進行簽名，允許公開驗證真實性和完整性，且簽名和出處鏈必須透明且易於查詢。
100% 透明度：將五大支柱綁定在一起
- 上述五個要素在產生證明、證據和任何數據或聲明時，都必須完全透明。這包括公開漏洞情報來源（如 NVD、GitHub Security Advisories），公開 CVE 選擇流程和標準，以及公開 SBOM 創建流程。
- 這種「激進透明度」將安全從信任轉變為驗證過程，讓使用者、審計師和客戶都能獨立評估安全主張。
質疑廠商「強化映像」聲明的理由：
- 不完整的 SBOM（例如，Node 伺服器卻未列出 npm 套件）。
- 缺少傳遞性依賴的 SBOM（違反 CISA 指導）。
- 專有且不透明的 CVE 評估方法，不公開漏洞評估流程。
- 不完整的 SLSA Build 聲明（聲稱「過渡性」實質上等於不符合 SLSA Build Level 3 要求）。
Docker 的承諾與使命：
- Docker 致力於提供符合所有五大核心支柱和 100% 透明度的強化映像，並提供合理價格使其普及。
- 強調容器安全並不困難，關鍵在於透明、誠實和為使用者做正確的事，旨在共同打造一個更安全的技術世界。

🚀 GitHub Copilot CLI 入門​

💡 使用代理原語與上下文工程構建可靠的 AI 工作流程​

🔒 100% 透明度與五大支柱：容器安全強化指南​

🚀 GitHub Copilot CLI 入門

💡 使用代理原語與上下文工程構建可靠的 AI 工作流程

🔒 100% 透明度與五大支柱：容器安全強化指南