Release notes
Gemini CLI release notes：stable、preview、nightly 三個渠道，以及如何根據風險選擇版本。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| Release notes | 版本說明 | 各版本變化的官方記錄。 |
| 版本核驗 | check | 確認某功能在目前版本是否可用。 |
| 破壞性變更 | breaking | 升級中改變行為的變更。 |
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你用 Release notes 核驗功能可用性、讀懂版本變化。
你是 Gemini CLI 版本核驗顧問。
【角色】
Gemini CLI 版本核驗顧問，按分層定位、一次只改一個變數的原則幫我找根因，每條結論落到能照做的步驟。
【輸入】
- 想確認的功能或變化：___
- 目前用的版本：___
- 擔心的相容問題：___
- 用途（自用 / 寫教學 / 升級）：___
- 經驗水平：___
【工作流程】
1. 定位相關版本條目
2. 判斷功能在我的版本是否可用
3. 標出破壞性變更
4. 給升級 / 核驗建議
5. 給驗證
【輸出規範】
▌一、相關條目
▌二、在我版本是否可用
▌三、破壞性變更
▌四、升級建議 + 驗證
【硬約束】
- 以官方 release notes 為準，不靠記憶
- 破壞性變更重點標出
- 寫教學引用時標註核驗日期
- 不要替我臆測原因或編造不存在的設定，資訊不全先問清
- 不確定的機制或報錯一律以官方文件為準，禁止照搬過時寫法Gemini CLI 更新很快。看 release notes 的目的不是追新，而是判斷你目前教學、工作流和指令碼有沒有被版本變化影響。
教學、自動化指令碼和 CI 不應預設跟 nightly。除非文章明確寫“實驗能力”，否則以 stable 為基準，並記錄驗證日期。
三個渠道
stable 推薦給普通使用者和生產工作流
preview 給願意提前反饋新功能的使用者
nightly 每日構建，風險最高安裝命令：
npm install -g @google/gemini-cli@latest
npm install -g @google/gemini-cli@preview
npm install -g @google/gemini-cli@nightly官方釋出節奏
官方 release 文件描述了 stable、preview、nightly 的晉級流程。大體上，main 分支的新變化先進入 nightly，再進入 preview，最後晉級 stable。
官方文件還描述了每週釋出節奏：新的 stable 和 preview 通常按周釋出，nightly 每天從 main 釋出。穩定釋出會經過 promotion；patch 會針對 stable / preview 按需修復。
渠道選擇表
| 使用場景 | 推薦渠道 | 需要記錄 |
|---|---|---|
| 新手教學、公開課程、團隊 SOP | stable / latest | CLI 版本、驗證日期、認證方式 |
| 預覽即將上線的能力 | preview | 具體版本、回退方式、差異說明 |
| 復現 main 分支新 bug 或新功能 | nightly | 安裝時間、npm 版本、是否可回 stable |
| CI / GitHub Action | stable，必要時 pin 版本 | workflow 輸入、許可權、失敗記錄 |
| 截圖教學 | stable + 固定驗證日期 | UI 是否隨版本變化 |
看 release notes 的順序
- 先看目前安裝版本：
gemini --version。 - 再看 npm dist-tag：
latest、preview、nightly。 - 對比 changelog latest 和 preview。
- 如果教學依賴實驗功能，記錄具體版本和驗證日期。
- 如果自動化指令碼失敗，先查是否有 CLI 引數、輸出格式、approval mode 或工具名變更。
NPM dist-tag 是版本渠道判斷的關鍵來源。遇到“我明明裝了 preview/nightly，但行為像 stable”的情況，先查 npm 目前 tag、command -v gemini 和安裝來源，再判斷是不是 PATH 或包管理器混用。
教學維護建議
Gemini CLI 欄目要定期檢查這些變化：
- 新命令。
- 設定欄位變更。
- 模型預設值變更。
- sandbox 和許可權策略變化。
- hooks、skills、subagents 這類 agent 能力變化。
- GitHub Action 輸入、許可權和 secret 變化。
推薦把 release 複檢拆成三類：
| 變化型別 | 需要檢查的頁面 |
|---|---|
| 新命令 / 引數 | CLI reference、commands、quickstart |
| 許可權 / sandbox / policy | security、tools、automation |
| 模型 / quota / 認證 | authentication、quota、models、privacy |
| GitHub Action | automation、issue / PR automation |
| 包結構 / 安裝 | installation、uninstall、npm package |
不建議
不要把 nightly 行為寫成穩定教學。可以寫“實驗能力”，但要標清版本和驗證日期。
驗收方式
教學更新前用 stable 復跑核心路徑，再用 preview 檢查即將變化的 UI 和命令。只要發現命令、設定欄位、預設模型、許可權提示發生變化，就把對應頁面標記為需複核，而不是隻改一處截圖。
下一步
NPM package
版本和釋出問題繼續看 package 結構和 workspace 邊界。
Release channels
普通讀者如何選擇 stable / preview / nightly，回看釋出渠道頁。
GitHub Action
CI 自動化受版本影響時，回看 GitHub Action 設定。