Issue 与 PR 自动化
Gemini CLI 官方仓库自动化流程：issue triage、CI、PR label sync、scheduled triage、release automation。
Gemini CLI 官方仓库本身也大量使用自动化。它的参考价值不在“照抄 workflow 名字”，而在如何把 issue、PR、CI、label 和 release 串成闭环。
自动化质量取决于输入结构。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 教程扩展成可维护栏目，建议也加自动化：
采集官方文档 -> 对比变更 -> 标记需更新页面 -> 生成更新草案 -> 人工复核 -> 发布这样才能跟上 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 流程原样搬到教程站。
最小可用闭环
如果把这套方法用于教程站，最小闭环可以这样设计：
- 官方文档变化触发待更新记录。
- 对应教程页进入 needs-update 状态。
- Agent 生成更新草案和来源链接。
- 人工复核事实、格式和截图。
- 构建通过后发布。
这比“发现变化后直接改文档”更稳，因为内容质量、官方事实和站点展示都被纳入同一个闭环。
权限边界
Issue/PR 自动化要先读后写。第一阶段只读 issue、PR、diff 和官方来源；第二阶段只写评论或草稿；第三阶段才考虑 label、分支、提交和发布。每升一级权限，都要增加触发者校验、审计日志和失败回滚，避免自动化越权、刷屏或误标。
接下来去哪
本地开发
继续看如何在本地搭建和验证 Gemini CLI 开发环境。
GitHub Action
回看 Action 接入、permissions、fork PR 和 secret 边界。
Release notes
排障和版本更新还要进入 release notes 与 npm package 页面。