---
title: "Issue 与 PR 自动化"
description: "Gemini CLI 官方仓库自动化流程：issue triage、CI、PR label sync、scheduled triage、release automation。"
verifiedAt: "2026-05-09"
---

Gemini CLI 官方仓库本身也大量使用自动化。它的参考价值不在“照抄 workflow 名字”，而在如何把 issue、PR、CI、label 和 release 串成闭环。

> [!NOTE]
> 自动化质量取决于输入结构。Issue 模板、PR 模板、标签体系没设计好，AI triage 只会更快地产生噪音。

官方流程的底层原则是：Issue 说明 what/why，PR 说明 how。几乎每个 PR 都应该链接一个对应 issue，自动化围绕这个关系做 triage、label sync、CI 和 release。

## Issue triage

新 issue 创建后，自动化会读取标题和正文，并按规则添加：

- `area/*`：功能领域。
- `kind/*`：问题类型。
- `priority/*`：优先级。
- `status/need-information`：缺关键复现信息。
- `status/need-retesting`：需要在新版本复测。

如果 issue 模板缺日志、复现步骤、版本号，自动化会更容易误判。教程站借鉴这套流程时，应该先把 issue 模板设计好，再接 AI triage。

## PR 检查

PR 自动化通常包含：

- lint。
- test。
- coverage summary。
- linked issue 检查。
- issue 与 PR label 同步。

官方还会周期性检查 PR 是否链接 issue。如果没有 linked issue，会打 `status/need-issue`。如果有关联 issue，则同步 issue label 到 PR，避免两边分类不一致。

## 定时补漏

定时任务会扫描未正确分流的 issue 或 PR，补跑 triage、同步标签、检查是否缺 linked issue。

定时任务不是为了替代第一次 triage，而是兜底。适合处理初次 workflow 失败、人工漏标、旧 issue 需要复测、PR 状态变化这类异步问题。

## 对教程站的启发

如果把 Gemini CLI 教程扩展成可维护栏目，建议也加自动化：

```text
采集官方文档 -> 对比变更 -> 标记需更新页面 -> 生成更新草案 -> 人工复核 -> 发布
```

这样才能跟上 Gemini CLI 这种高频迭代工具。

| 自动化对象 | 先决条件 |
| --- | --- |
| Issue triage | 模板里有版本、复现、日志 |
| PR review | diff 范围清楚，权限只读 |
| Label sync | label 体系稳定 |
| 定时补漏 | 有可重复查询条件 |
| Release note | commit / PR 元数据完整 |

## 不要照抄的部分

官方仓库的自动化是为开源贡献流设计的，不一定适合内容站。内容站更需要“来源变化检测、页面影响分析、人工复核”，不需要把每个内容更新都强制绑定 GitHub issue。要借鉴原则，不要搬工作流文件名。

## 验收方式

验收自动化闭环时，选一个新 issue、一个缺 linked issue 的 PR、一个已 linked issue 的 PR。检查标签、评论、CI 状态和失败提示是否都能把贡献者引到下一步，而不是只显示一个失败的 workflow。

自动化评论要可执行，不要只写泛泛失败原因。

内容站借鉴这套流程时，验收对象也要换成内容资产：页面是否有官方来源、frontmatter 是否完整、内部链接是否有效、构建是否通过、截图或断点是否正常。不要把开源仓库的 label 流程原样搬到教程站。

## 最小可用闭环

如果把这套方法用于教程站，最小闭环可以这样设计：

1. 官方文档变化触发待更新记录。
2. 对应教程页进入 needs-update 状态。
3. Agent 生成更新草案和来源链接。
4. 人工复核事实、格式和截图。
5. 构建通过后发布。

这比“发现变化后直接改文档”更稳，因为内容质量、官方事实和站点展示都被纳入同一个闭环。

## 权限边界

Issue/PR 自动化要先读后写。第一阶段只读 issue、PR、diff 和官方来源；第二阶段只写评论或草稿；第三阶段才考虑 label、分支、提交和发布。每升一级权限，都要增加触发者校验、审计日志和失败回滚，避免自动化越权、刷屏或误标。

## 接下来去哪

<Cards>
  <Card title="本地开发" description="继续看如何在本地搭建和验证 Gemini CLI 开发环境。" href="/docs/gemini-cli/official/07-integrations-automation/76-local-development" />
  <Card title="GitHub Action" description="回看 Action 接入、permissions、fork PR 和 secret 边界。" href="/docs/gemini-cli/official/07-integrations-automation/74-github-action" />
  <Card title="Release notes" description="排障和版本更新还要进入 release notes 与 npm package 页面。" href="/docs/gemini-cli/official/08-troubleshooting-reference/83-release-notes" />
</Cards>

## 官方来源

- [Gemini CLI issue and PR automation](https://github.com/google-gemini/gemini-cli/blob/main/docs/issue-and-pr-automation.md)
