整合與自動化

Gemini CLI 不只適合在終端聊天。真正落地時，它會進入 IDE、Shell 指令碼、CI、GitHub issue、PR review 和本地開發環境。

這一組頁面解決“如何把 Gemini CLI 放進工作流”的問題。先選入口，再看許可權、輸入輸出和失敗兜底。

學習路徑

flowchart LR
    IDE["IDE integration"] --> Hooks["Hooks"]
    Hooks --> Headless["Headless mode"]
    Headless --> Automation["Shell / CI automation"]
    Automation --> GitHub["GitHub Action"]
    GitHub --> IssuePR["Issue / PR automation"]
    IssuePR --> LocalDev["Local development"]
    LocalDev --> Troubleshooting["Troubleshooting"]

    style IDE fill:#dbeafe,stroke:#3b82f6
    style Headless fill:#dcfce7,stroke:#22c55e
    style GitHub fill:#fef3c7,stroke:#f59e0b

IDE + Hooks

人在編輯器裡工作時，先看 IDE companion 和 lifecycle hooks。

Headless + Automation

需要指令碼化或 CI 呼叫時，從 headless mode 開始。

GitHub Action

需要 issue、PR、review 自動化時，進入 run-gemini-cli GitHub Action。

頁面	適合場景
IDE 整合	需要編輯器上下文、原生 diff、ACP
Hooks	需要在工具呼叫前後插入校驗、阻斷或日誌
Headless mode	需要非互動式呼叫 Gemini CLI
自動化指令碼	需要把 CLI 放進 Shell、CI 或批處理
GitHub Action	需要在 GitHub workflow 裡執行 Gemini CLI
Issue 與 PR 自動化	需要自動分診 issue、生成回覆、輔助 PR review
本地開發	需要貢獻 Gemini CLI 或排查 CLI 自身 bug

選擇方式

人在 IDE 里工作     IDE companion 或 ACP
需要流程拦截        hooks
需要脚本调用        headless mode
需要 CI 自动处理    run-gemini-cli GitHub Action
需要改 Gemini CLI   本地开发流程

進入前檢查

檢查項	為什麼重要
輸入是否可重複	自動化必須能在無人工補充的情況下復跑
輸出是否可審計	CI、issue 和 PR 場景要能追蹤 Gemini 做了什麼
許可權是否收窄	hooks、headless、GitHub Action 都可能放大工具許可權
失敗是否可兜底	自動化失敗要回到日誌、人工 review 或普通 CLI

下一步

先讀：IDE 整合。