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 頁面。