Enterprise config
Gemini CLI enterprise configuration：組織賬號、Cloud project、Vertex AI、許可、固定策略和團隊預設設定。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| Enterprise config | 企業設定 | 管理員統一下發的設定。 |
| 強制 vs 預設 | req/default | 必須遵守 vs 可覆蓋。 |
| 分發 | distribute | 給團隊統一下發的方式。 |
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你設計 Gemini CLI 的企業設定下發（強制項 vs 預設值）。
你是 Gemini CLI 企業設定顧問。
【角色】
Gemini CLI 企業設定顧問，按最小夠用、安全合規優先的原則給可落地方案，每條結論都落到能照做的步驟或示例，不停留在空泛建議。
【輸入】
- 團隊規模和風險偏好：___
- 必須統一的安全 / 行為約束：___
- 想保留的使用者自由度：___
- 現有 IT 體系：___
- 經驗水平：___
【工作流程】
1. 區分強制項和預設值
2. 設計設定分發方式
3. 對接現有 IT 體系
4. 給變更和審計
5. 給驗證
【輸出規範】
▌一、強制 vs 預設
▌二、分發方式
▌三、對接 IT 體系
▌四、變更審計 + 驗證
【硬約束】
- 安全相關走強制，體驗類留預設
- 設定變更可審計
- 對接現有體系，不另起爐灶
- 不要替我臆測情況或編造不存在的設定，資訊不全先問清
- 不確定的設定或介面一律以官方文件為準，禁止照搬過時寫法企業設定的重點不是“裝上 CLI”，而是統一身份、專案、許可權、模型、記錄和成本邊界。
企業設定要看最終合併結果，不只看某個 settings 檔案。使用者級、專案級、系統級和環境變數可能互相覆蓋。
官方企業文件的核心是兩層設定：系統級 settings 提供集中預設值和覆蓋值，Admin Controls 提供本地不可覆蓋的組織策略。系統級 settings 能防誤用，但不能防擁有本機管理員許可權的人刻意繞過。
企業使用者要先確認
- 賬號型別：Workspace / organization / personal。
- Gemini Code Assist license。
- Google Cloud Project。
- Vertex AI 是否啟用。
- IAM 角色。
- 計費和配額。
- telemetry 和合規要求。
系統級設定層級
Gemini CLI 企業設定會合並四類 settings。單值欄位按優先順序覆蓋：
- System Defaults：
system-defaults.json - User Settings：
~/.gemini/settings.json - Workspace Settings：
<project>/.gemini/settings.json - System Overrides：
settings.json
System Overrides 擁有最終決定權。陣列和物件欄位會合並，例如 includeDirectories 可能拼接，mcpServers 可能按 key 合併。
Firecrawl 抓到的官方企業頁也強調：allowlist 比 blocklist 更穩，tools.core 適合明確允許哪些內建工具，tools.exclude 更適合少量補充限制。企業預設策略不要只靠 exclude。
系統級 settings 路徑：
- Linux：
/etc/gemini-cli/settings.json - macOS：
/Library/Application Support/GeminiCli/settings.json - Windows：
C:\ProgramData\gemini-cli\settings.json
也可以用 GEMINI_CLI_SYSTEM_SETTINGS_PATH 指定路徑。企業落地時通常會用 wrapper script 固定這個環境變數，避免使用者隨意改到另一份 settings。
共享環境隔離
在 CI、共享構建機或實驗平臺上，不要複用預設 ~/.gemini 狀態。官方支援用 GEMINI_CLI_HOME 把 Gemini CLI 的設定和歷史隔離到指定目錄：
export GEMINI_CLI_HOME="/tmp/gemini-job-123"
gemini這樣能減少不同使用者、不同 job 之間的設定汙染。
設定建議
個人偏好不要覆蓋組織策略。團隊預設設定應透過專案級 settings 和企業系統級 settings 統一管理。高風險工具不要只靠口頭約定，應該結合 tools.core allowlist 和 policy engine 控制。
| 設定目標 | 推薦落點 |
|---|---|
| 個人 UI 偏好 | 使用者級 settings |
| 團隊 MCP 預設 | 專案級或系統級 settings |
| 企業不可繞過策略 | Admin controls / system overrides |
| CI 隔離 | GEMINI_CLI_HOME |
| 成本和審計 | telemetry + Cloud project |
Rollout 順序
企業落地不要一次性全員強推。更穩的順序是：
- 在測試機器上驗證系統級 settings。
- 給一組試點使用者啟用預設設定。
- 驗證 policy、MCP、telemetry、模型選擇和成本歸屬。
- 再推廣到團隊或組織。
- 保留回復路徑和設定版本記錄。
這樣可以把“設定語法正確”和“組織實際可用”分開驗收。
驗收方式
企業設定驗收要看“最終合併結果”，不能只看某一份檔案。至少驗證三件事：系統覆蓋是否高於使用者設定，MCP server 是否按企業設定生效，GEMINI_CLI_HOME 或系統 settings 路徑是否沒有洩露到普通使用者可寫目錄。
還要驗證使用者是否能透過環境變數改到另一份系統 settings。若使用 GEMINI_CLI_SYSTEM_SETTINGS_PATH，wrapper script 和終端入口都要統一，不要只改一臺測試機。
接下來去哪
Enterprise controls
繼續看組織級 controls、policy、telemetry 和不可覆蓋邊界。
Policy engine
工具許可權要進入 policy，而不是隻靠團隊口頭約定。
Telemetry
企業落地還要設計記錄、審計和可觀測性。