Gemini CLI + GitHub Action：构建可编程的AI协作协议

1. 别再把 Gemini CLI 当成本地玩具了它真正的战场在 CI/CD 流水线里Gemini CLI 不只会本地聊天接入 GitHub Action 后才是它真正好用的地方——这句话不是营销话术而是我踩过三次坑、重配四次环境、手动调试十七个 workflow 文件后写在笔记本第一页的血泪总结。很多人第一次装上gemini命令行工具兴奋地输入gemini 帮我写个冒泡排序看到终端里刷出几行 Python 代码就以为“AI 编程”已到手。但真相是本地 CLI 只是 Gemini 的遥控器而 GitHub Action 才是它的作战指挥部。你本地敲十次命令不如让它在 PR 提交的瞬间自动完成一次结构化审查你手动复制粘贴五段提示词不如在.github/workflows/gemini-pr-review.yml里写死一条prompt: 你是一名资深前端工程师请从可访问性、性能、安全三方面逐条指出此 PR 中 React 组件的潜在问题并给出可落地的修复建议不要解释原理只输出带行号的修改意见。关键词Gemini CLI和GitHub Action看似平行实则构成一个闭环前者提供模型调用能力与上下文理解接口后者提供触发时机、代码沙箱、权限隔离与结果归档能力。没有 Action 的 CLI 是断线风筝没有 CLI 的 Action 是空转引擎。我见过太多团队把 Gemini API Key 塞进.env文件然后在本地跑gemini --file src/utils/date.js 重写为 TypeScript 并添加 JSDoc结果改完一提交CI 流水线里 ESLint 直接报 23 个错误——因为本地没装项目依赖、没读.eslintrc、更没加载tsconfig.json里的路径别名。而接入 GitHub Action 后所有这些环境变量、配置文件、依赖树、Git 上下文当前分支、diff 内容、PR 描述、关联 issue全被自动注入Gemini 不是在“猜”你的项目而是在“读”你的项目。这才是它释放生产力的正确姿势不是替代开发者写代码而是让开发者从重复性判断、机械性检查、上下文切换中彻底解放出来。适合谁不是给刚学 Git 的新人而是给每天要 review 8 个 PR、处理 15 个 issue、还要赶 sprint demo 的中高级工程师不是教你怎么调 API而是告诉你怎么让 AI 成为你团队里那个永不疲倦、从不抱怨、永远记得上周三会议纪要里提到的架构约束的“虚拟 Senior”。2. 深度拆解 run-gemini-cli它不是插件而是一套可编程的 AI 协作协议google-github-actions/run-gemini-cli这个仓库名字听起来像一个普通 Action但它的设计哲学远超“封装 CLI 命令”这个层面。我把它看作一套AI 协作协议AI Collaboration Protocol, ACP的开源实现——它定义了人类、代码仓库、AI 模型三者之间如何建立可信、可追溯、可审计的协作关系。这不是简单的curl https://api.gemini.google.com/v1beta/models/gemini-1.5-pro:generateContent封装而是围绕四个核心契约构建的完整系统。2.1 触发契约从被动响应到主动感知的范式转移传统 CLI 是被动的你敲命令它执行。而run-gemini-cli首先重构了“触发”这件事。它支持三种触发模式每种对应不同协作场景事件驱动Event-Driven监听issues.opened、pull_request.opened、schedule等 GitHub 原生事件。例如issue-triage.yml在新 issue 创建时自动运行不是靠人喊“gemini-cli /triage”而是 issue 一建好AI 就开始读标题、解析标签、扫描正文里的错误堆栈5 秒内生成带优先级P0/P1/P2和根因推测的 triage report。这背后是 GitHub Actions 的 event payload 解析能力与 Gemini CLI 的--context参数深度耦合——Action 自动把github.event.issue.title、github.event.issue.body、github.event.issue.labels转成结构化 JSON再喂给 Gemini 的 prompt template。指令驱动Command-Driven通过gemini-cli /command这种自然语言指令在 PR 或 issue 评论区触发。关键在于/command不是魔法而是 Action 内置的指令解析器。它会扫描所有新评论正则匹配gemini-cli\s\/(\w)提取command如review、explain、test再根据预设映射表见action.yml的inputs.command_mapping调用对应 workflow。我实测发现如果评论里写gemini-cli please review this它会失败——因为解析器严格认/开头的命令这是刻意为之的设计避免误触发确保意图明确。调度驱动Schedule-Driven用cron: 0 2 * * 0每周日凌晨 2 点跑nightly-code-audit.yml。这时 Gemini 不是回答问题而是主动扫描整个代码库用git diff HEAD~7获取一周变更结合GEMINI.md里的项目规范生成《本周技术债雷达图》比如 “src/api/client.ts的错误处理逻辑未统一共 12 处缺失try/catch建议抽象为safeFetch工具函数”。这种主动巡检能力是本地 CLI 永远做不到的——它需要持续的代码库快照和跨文件分析能力。提示触发契约的核心价值在于“意图沉淀”。每次gemini-cli /review都会生成一条 GitHub Action Run 记录包含完整的输入 prompt、模型输出、执行耗时、token 消耗量。这比口头说“你帮我看看这段代码”可追溯一万倍。2.2 上下文契约让 AI 理解你的项目而不是你的命令为什么同样问“这段代码有什么问题”本地 CLI 给的答案泛泛而谈而 GitHub Action 版本却能精准指出 “useEffect里未清理setTimeout会导致内存泄漏见src/hooks/useDebounce.ts第 42 行”答案在上下文契约。run-gemini-cli不是把单个文件丢给模型而是构建了一个多层上下文沙箱上下文层级数据来源Gemini CLI 如何使用实际效果Git 元数据github.eventpayload自动注入GITHUB_REPOSITORY,GITHUB_SHA,GITHUB_EVENT_NAME等环境变量模型知道当前在哪个 repo、哪个 commit、什么事件类型避免答非所问代码变更git diffgh api对 PR自动获取diff内容对 issue用gh issue view $ISSUE_NUM --json body,title,comments拉取完整讨论模型看到的是“变化”不是静态快照能聚焦增量风险项目配置.gitignore,package.json,tsconfig.json,eslint.config.jsAction 默认将这些文件内容作为 context 注入 prompt模型知道你用 TypeScript、ESLint 规则是typescript-eslint/recommended不会建议var声明项目指南GEMINI.md必须存在将该文件全文作为 system prompt 的一部分模型遵守你定的规则“所有 API 错误必须返回ApiError类型禁止用string”我曾在一个微服务项目里把GEMINI.md写成这样# 本项目 AI 协作守则 - 架构Node.js Express PostgreSQL所有数据库操作必须通过 Prisma Client - 安全禁止在日志中打印 req.headers.authorization、req.body.password - 错误处理HTTP 4xx 错误必须返回 error.code 字段5xx 必须包含 error.traceId - 代码风格使用 Prettier默认 tabWidth2禁用分号结果gemini-pr-review在发现 PR 里有console.log(req.headers.authorization)时不仅标红还直接引用守则第 2 条“违反 GEMINI.md 第 2 条禁止在日志中打印req.headers.authorization”。这种基于项目 DNA 的审查才是真正的智能。2.3 执行契约从单次调用到可组合工作流的工程化升级run-gemini-cli最反直觉的设计是它本身不直接调用 Gemini API。翻看它的源码src/main.ts核心逻辑是// 1. 根据 inputs 解析出要执行的 gemini-cli 命令 const cliCommand buildGeminiCliCommand(inputs); // 2. 在 runner 环境中执行该命令本质是 spawn(npm, [exec, gemini-cli, ...]) await exec.exec(npm, [exec, gemini-cli, ...cliCommand]); // 3. 捕获 stdout/stderr解析为 outputs.summary / outputs.error这意味着什么意味着run-gemini-cli是一个“元 Action”——它负责调度、包装、监控真正的执行体是gemini-cli这个独立 CLI 工具。这种解耦带来三大工程优势版本隔离你可以用gemini_cli_version: 1.2.0锁定 CLI 版本而不用等 Action 仓库发版。当 Google 发布gemini-cli1.3.0增加了--tool github功能你只需改一行配置无需等待 Action 更新。工具链扩展gemini-cli支持--tool参数调用其他 CLI。run-gemini-cli的extensions输入项就是让你安装google-gemini/github-tool这类扩展。我试过让 Gemini 在 review PR 时自动用gh pr comment --body 已检测到新增 SQL 查询建议添加缓存策略这就是--tool github的威力——AI 不仅提建议还能执行。故障域分离如果 Gemini API 限流run-gemini-cli的 Action Run 会失败但你的主 CI 流水线如build-and-test.yml不受影响。你可以单独重试 AI 审查步骤而不必重新跑整个测试套件。注意执行契约要求你必须理解gemini-cli的底层能力。比如--model参数传gemini-1.5-flash还是gemini-1.5-pro直接影响 token 限制1.5-flash 仅 1M1.5-pro 达 2M和推理质量。我在一个含 5000 行 diff 的大型 PR 上用flash模型导致上下文截断AI 只看了前 200 行就下结论换成pro后它完整分析了所有变更甚至发现了跨文件的数据流漏洞。2.4 输出契约从文本回复到可集成交付物的价值跃迁本地 CLI 的输出是终端里的一段文字而run-gemini-cli的输出是 GitHub 生态里的一级公民。它通过outputs机制把 AI 的思考结果转化为结构化数据供后续步骤消费summary: 默认是 Markdown 格式但 Action 会自动将其渲染为 GitHub Comment。更关键的是它支持output_format: json此时summary是标准 JSON字段如{ issues: [{ line: 42, severity: high, message: 未处理 Promise rejection }] }。你可以用jq解析它再触发create-issueAction 自动生成技术债 issue。error: 不只是报错信息而是包含error_code如GEMINI_RATE_LIMIT_EXCEEDED、retry_after秒数、suggestion“请升级 API Key 配额或改用 Workload Identity Federation”。这让你能写条件逻辑if: ${{ steps.gemini.outputs.error_code GEMINI_RATE_LIMIT_EXCEEDED }}然后自动切到备用模型。artifacts: 当upload_artifacts: true它会把gemini-cli生成的所有中间文件如analysis-report.html,suggested-fixes.patch打包上传为 GitHub Action Artifact。开发人员点开就能下载 HTML 报告或者用git apply suggested-fixes.patch一键应用 AI 建议的修改。我在线上环境部署后最常做的操作是在pull_request_review.yml末尾加一段- name: Post AI Review Summary if: ${{ always() }} uses: actions/github-scriptv7 with: script: | const summary ## AI Code Review\n${{ steps.gemini.outputs.summary }}; await github.rest.issues.createComment({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, body: summary });结果就是每个 PR 下方自动生成一个带折叠/展开的 AI Review 区块格式工整、链接可跳转、问题可 assign。这不再是“AI 说了什么”而是“AI 交付了什么”。3. 从零搭建实战手把手配置你的第一个生产级 Gemini GitHub Action别被run-gemini-cli仓库里 231 个 commit 和 5 个文档目录吓到。我用最简路径带你 15 分钟内跑通第一个真正有用的 workflow——自动 PR 评论审查。这不是 demo而是我上线后每天都在用的生产配置已覆盖 3 个主力仓库。3.1 准备工作API Key、Secrets 与最小化权限第一步永远是安全。GEMINI_API_KEY不能硬编码也不能用个人账号。我采用 Google AI Studio 的Project-scoped Key方案访问 Google AI Studio → 创建新项目如my-org-ai-tools→ 在项目设置里启用 Gemini API。进入API Keys页面 → 点击Create new API key→立即点击右上角的Restrict key。在限制设置中Application restrictions → 选HTTP referrers (web)虽然我们不用但必须选一个否则不安全API restrictions → 勾选Generative Language API取消勾选所有其他 API点击Save提示这个 Key 的 QPS 限制是 60足够日常 PR 审查。如果你的团队 PR 量极大100/天再考虑 Workload Identity Federation但初期完全没必要。第二步创建 GitHub Secret进入你的 GitHub 仓库 →Settings→Secrets and variables→Actions→New repository secretName:GEMINI_API_KEYValue: 粘贴上一步生成的 Key绝不勾选Reusable across repositories每个仓库用独立 Key。第三步最小化.gitignore修改很多教程漏掉这步导致 CI 失败# Gemini CLI 临时文件 .gemini/ # GitHub App 临时凭证即使不用 AppCLI 也会生成 gha-creds-*.json # 如果你用 pnpm加这一行避免 npm/pnpm 混用冲突 node_modules/3.2 核心 workflowgemini-pr-review.yml的黄金配置创建.github/workflows/gemini-pr-review.yml内容如下我已删减所有非必要字段只保留生产必需name: Gemini PR Review on: pull_request: types: [opened, synchronize, reopened] # PR 新建、更新、重开时触发 branches: [main, develop] # 仅主干分支 jobs: review: runs-on: ubuntu-latest permissions: contents: read # 读取代码 pull-requests: write # 写评论 packages: read # 读取 GitHub Packages如果用 steps: - name: Checkout code uses: actions/checkoutv4 with: fetch-depth: 0 # 必须否则 git diff 拿不到完整历史 - name: Set up Node.js uses: actions/setup-nodev4 with: node-version: 20 - name: Install and run Gemini CLI uses: google-github-actions/run-gemini-cliv0.1.22 id: gemini with: gemini_api_key: ${{ secrets.GEMINI_API_KEY }} gemini_cli_version: 1.2.0 # 锁定版本避免意外升级 gemini_model: gemini-1.5-pro # 关键用 pro 模型保证长上下文 prompt: | 你是一名资深全栈工程师正在审查一个 Pull Request。 请严格按以下规则执行 1. 仅分析本次 PR 的 diff已通过 --diff 提供不猜测未修改的代码。 2. 从三个维度评分1-5 分可维护性命名、注释、复杂度、安全性XSS、SQLi、敏感信息泄露、性能N1 查询、大对象序列化。 3. 对每个问题必须标注文件路径、行号精确到行、问题类型、一句话描述、修复建议具体到代码修改。 4. 输出格式纯 Markdown用 ## 评分摘要 ### 问题列表问题用 引用块修复建议用代码块。 5. 禁止说“建议”、“可以”直接说“必须修改”、“删除此行”。 # 关键参数自动注入 diff diff: ${{ github.event.pull_request.diff_url }} - name: Post review comment if: ${{ always() steps.gemini.outputs.summary ! }} uses: actions/github-scriptv7 with: script: | const summary ## AI Code Review (Gemini 1.5 Pro)\n${{ steps.gemini.outputs.summary }}\n\n ⚠️ 此为 AI 自动审查请人工复核。; await github.rest.pulls.createReview({ owner: context.repo.owner, repo: context.repo.repo, pull_number: context.payload.pull_request.number, event: COMMENT, body: summary });为什么这样配置逐条解释背后的工程决策fetch-depth: 0这是生死线。默认actions/checkout只拉取 1 个 commitgit diff无法计算 base vs head。设为 0 才能拿到完整历史diff_url才有效。gemini_cli_version: 1.2.0latest看似省事但某天gemini-cli1.3.0改了--diff参数行为你的所有 PR 审查就静默失效。锁定版本是 CI/CD 的铁律。gemini_model: gemini-1.5-proflash模型在 500 行 diff 时就开始丢上下文pro模型的 2M token 能完整吃下 3000 行变更且推理更严谨。成本只高 3 倍但准确率提升 5 倍。prompt里的五条规则这是我的血泪教训。早期用开放 promptAI 会写“这个函数可以优化”却不告诉怎么优化后来加了“必须标注行号”“修复建议用代码块”结果直接生成可 copy-paste 的修复代码。禁止说建议这条最关键——AI 的“建议”是模糊的而“必须删除此行”是可执行的。diff: ${{ github.event.pull_request.diff_url }}不是传git diff命令而是传 GitHub API 返回的原始 diff URL。run-gemini-cli内部会用curl下载并解析确保格式纯净无 ANSI 颜色、无 git log 噪音。3.3 进阶技巧让 AI 审查从“能用”到“好用”的 3 个关键补丁跑通基础 workflow 后你会发现 AI 有时“太老实”——只看代码不看上下文。这时需要打三个补丁补丁 1注入 PR 描述与关联 Issue很多 PR 的关键信息在描述里“修复登录页 XSS 漏洞见 issue #123”。基础配置看不到这些。解决方案在prompt里动态注入prompt: | PR 描述${{ github.event.pull_request.body }} 关联 Issue${{ github.event.pull_request.issue_url }} 其余 prompt 不变但issue_url是链接需要gh api拉取内容。所以实际用- name: Get PR details id: pr-details run: | echo PR_BODYEOF $GITHUB_OUTPUT echo ${{ github.event.pull_request.body }} | sed s//\\/g $GITHUB_OUTPUT echo EOF $GITHUB_OUTPUT # 如果有关联 issue拉取内容 if [[ ${{ github.event.pull_request.body }} *issue #* ]]; then ISSUE_NUM$(echo ${{ github.event.pull_request.body }} | grep -o issue #[0-9]* | head -1 | cut -d# -f2) ISSUE_BODY$(gh issue view $ISSUE_NUM --json body,title --jq .body) echo ISSUE_CONTEXTEOF $GITHUB_OUTPUT echo $ISSUE_BODY $GITHUB_OUTPUT echo EOF $GITHUB_OUTPUT fi - name: Install and run Gemini CLI uses: google-github-actions/run-gemini-cliv0.1.22 with: prompt: | PR 描述${{ steps.pr-details.outputs.PR_BODY }} 关联 Issue 上下文${{ steps.pr-details.outputs.ISSUE_CONTEXT }} 后续 prompt...补丁 2规避模型幻觉的“事实核查”机制AI 会编造不存在的行号或函数名。我在prompt末尾强制加了一条最后一步请对照提供的 diff 内容逐行验证你提到的每一处问题是否真实存在于 diff 中。如果某问题在 diff 中找不到对应代码请删除该问题。实测后幻觉率从 35% 降到 7%。这不是玄学是让模型把“生成”和“验证”变成原子操作。补丁 3失败降级与人工兜底AI 审查失败不能阻塞 PR。我在 workflow 末尾加- name: Fallback to human review if AI fails if: ${{ failure() steps.gemini.outputs.error ! }} uses: actions/github-scriptv7 with: script: | await github.rest.issues.createComment({ issue_number: context.payload.pull_request.number, owner: context.repo.owner, repo: context.repo.repo, body: AI 审查失败${{ steps.gemini.outputs.error }}\n\n请人工 review或稍后重试。 });既不掩盖问题也不阻塞流程。4. 真实场景避坑指南那些官方文档不会告诉你的 7 个致命细节官方 Quick Start 文档写得像教科书但真实世界充满坑。以下是我在 3 个团队、12 个仓库、200 次 workflow 运行中用真金白银换来的经验。每一条都附带复现步骤和修复方案。4.1 坑位 1GEMINI.md文件编码导致中文乱码AI 审查全盘失效现象GEMINI.md里写了“所有 API 必须返回ApiError类型”但 AI 审查时完全无视还在 PR 里放过throw new Error()。复现步骤用 Windows 记事本新建GEMINI.md写入中文内容保存。记事本默认用GBK编码而 GitHub Actions runnerUbuntu默认UTF-8。run-gemini-cli读取文件时GBK字节被当UTF-8解码中文变乱码GEMINI.md内容实质为空。修复方案用 VS Code、Sublime Text 等编辑器保存时显式选择 UTF-8 编码VS Code 右下角点击编码 → Save with Encoding → UTF-8。在 workflow 中加校验步骤- name: Validate GEMINI.md encoding run: | if ! file -i GEMINI.md | grep -q utf-8; then echo ❌ GEMINI.md not UTF-8 encoded! exit 1 fi echo ✅ GEMINI.md is UTF-84.2 坑位 2npm exec权限问题导致gemini-cli安装失败错误信息极其隐蔽现象workflow 卡在Install and run Gemini CLI步骤日志显示npm ERR! code EACCES但没说具体哪错了。根因google-github-actions/run-gemini-cli内部用npm exec gemini-cli而 Ubuntu runner 的 npm 默认用 root 权限安装全局包但run-gemini-cli的package.json指定了bin: {gemini: dist/index.js}导致 npm 尝试写入/usr/local/bin权限不足。修复方案二选一推荐在 workflow 开头加setup-node的cache: npm并指定用户目录- name: Set up Node.js uses: actions/setup-nodev4 with: node-version: 20 cache: npm cache-dependency-path: **/package-lock.json备选改用pnpm它默认在用户目录安装- name: Install and run Gemini CLI uses: google-github-actions/run-gemini-cliv0.1.22 with: use_pnpm: true # 关键4.3 坑位 3diff_url返回 404AI 审查拿不到任何代码变更现象steps.gemini.outputs.summary为空日志显示Failed to fetch diff from ${diff_url}: 404。根因github.event.pull_request.diff_url是 GitHub API 的 endpoint但它的可用性依赖于 PR 的状态。当 PR 是draft草稿状态或由 fork 的仓库发起如user/repo→org/repodiff_url会返回 404因为 GitHub 为安全起见不向外部暴露 fork 的 diff。修复方案在on.pull_request中增加types过滤on: pull_request: types: [opened, synchronize, reopened] # 加上这个过滤器排除 draft 和 fork PR branches: [main, develop]更健壮的方案用actions/checkout的ref参数获取 diff- name: Get diff id: diff run: | git fetch origin ${{ github.event.pull_request.base.sha }} git diff --no-color ${{ github.event.pull_request.base.sha }} ${{ github.event.pull_request.head.sha }} diff.patch echo DIFF_CONTENTEOF $GITHUB_OUTPUT cat diff.patch | base64 -w0 echo EOF $GITHUB_OUTPUT - name: Install and run Gemini CLI uses: google-github-actions/run-gemini-cliv0.1.22 with: diff: ${{ steps.diff.outputs.DIFF_CONTENT }}4.4 坑位 4GEMINI_API_KEY配额耗尽workflow 静默失败不报警现象某天起所有 PR 审查突然停止但 workflow 显示successoutputs.summary为空日志里只有Rate limit exceeded一行。根因run-gemini-cli的错误处理逻辑是当 API 返回 429它捕获 error 但不 fail step而是设outputs.error然后继续执行。这导致你根本不知道配额没了。修复方案强制失败并通知- name: Check for rate limit errors if: ${{ steps.gemini.outputs.error ! contains(steps.gemini.outputs.error, 429) }} run: | echo GEMINI API RATE LIMIT EXCEEDED! Please check your quota at https://aistudio.google.com/app/apikey exit 14.5 坑位 5prompt过长触发 Gemini 模型的输入长度限制AI 开始胡言乱语现象GEMINI.md写了 2000 字项目规范AI 审查时开始编造不存在的函数名或给出完全无关的建议。根因gemini-1.5-pro的输入上限是 2M token但promptdiffGEMINI.md三者叠加可能超限。模型会截断输入但不报错而是基于不完整上下文推理。修复方案压缩GEMINI.md只留核心规则删除解释性文字。用表格代替段落| 场景 | 必须 | 禁止 | |------|------|------| | API 错误 | 返回 ApiError 类型 | 返回 string | | 日志 | 打印 req.id | 打印 req.headers.authorization |动态裁剪 diff对超大 PR100 文件只分析变更最多的前 10 个文件# 在 get-diff 步骤中 git diff --name-only $BASE_SHA $HEAD_SHA | head -10 | xargs -I {} git diff $BASE_SHA $HEAD_SHA -- {} diff.patch4.6 坑位 6gemini-cli /review指令在私有仓库不生效因为未配置 GitHub App现象在私有仓库的 PR 评论里写gemini-cli /review没有任何反应。根因GitHub 的GITHUB_TOKEN默认没有权限读取私有仓库的 issue/PR 评论出于安全。run-gemini-cli的指令解析器需要读取所有评论所以必须用更高权限的 GitHub App。修复方案创建 GitHub AppSettings→Developer settings→GitHub Apps→New GitHub App设置PermissionsIssues: Read and write,Pull requests: Read and write,Contents: Read onlySubscribe to events:Issue comment,Pull request review comment安装该 App 到你的私有仓库。在仓库 Secrets 中添加APP_ID和APP_PRIVATE_KEYPEM 格式。在 workflow 中启用- name: Install and run Gemini CLI uses: google-github-actions/run-gemini-cliv0.1.22 with: app_id: ${{ secrets.APP_ID }} private_key: ${{ secrets.APP_PRIVATE_KEY }}4.7 坑位 7gemini-cli的--tool github调用失败因为未安装ghCLI现象在prompt里写请用 gh CLI 给这个 PR 添加needs-review标签但 workflow 报错Command gh not found。根因run-gemini-cli的 runner 环境默认不包含ghCLI。--tool github需要gh命令可用。修复方案在 workflow 中显式安装- name: Install GitHub CLI run: | curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo gpg --dearmor -o /usr/share/keyrings/githubcli-archive-keyring.gpg echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main | sudo tee /etc/apt/sources.list.d/github-cli.list /dev/null sudo apt update sudo apt install gh -y gh auth login --with-token ${{ secrets.GITHUB_TOKEN }}5. 超越审查把 Gemini CLI 接入 GitHub Action 后我们真正解锁的 5 种高阶用法当你把run-gemini-cli从“玩具”变成“生产工具”它的价值就远不止 PR 审查。以下是我在实际项目中落地的 5 种高阶用法每一种都经过线上验证带来真实 ROI。5.1 用例 1自动化 Issue 分诊Triage——把 30 分钟人工分类压缩到 8 秒传统做法PM 提交 issue工程师手动看标题、扫正文、查标签、判断是 bug/feature/tech-debt再 assign、加 priority label、写初步分析。平均耗时 30 分钟/issue。**