跳到主要内容

Gemini CLI 快速开始

这页适合什么场景​

  • 你想要一个轻量终端入口，重点是 context file 和命令证据。
  • 任务更像日常维护，而不是长链路 feature。
  • 你要验证的是“规则有没有约束住输出”，而不是“聊天有没有很聪明”。

前置条件​

  • 你已经看过 Gemini CLI 概览，知道它更适合轻量 terminal-first 入口。
  • 当前仓库至少有一个稳定验证命令。
  • 这次任务最好是 bugfix、补测试或脚本调整，而不是长链路 feature。

20 分钟交付目标​

第一次 quick start 只需要做到：

  • 写出一个最小 context file，而不是一套大而全规则。
  • 让 Gemini CLI 真正读仓库、跑命令、回报结果。
  • 留下一段足够给下一位读者接手的交付说明。

推荐第一条任务​

优先选这些任务：

  • 修一个已知 bug
  • 补一条缺失测试
  • 跑脚本并解释结果

第一次不要选：

  • 需要多阶段推进的结构性改动
  • 还没有可执行验证命令的仓库
  • 需要大量平台协作和 review 收口的任务

步骤​

第 1 步：先写最小 context file​

第一次不要写大而全的规则，只保留：

  • 哪些目录允许改
  • 哪些目录不要碰
  • 默认验证命令是什么
  • 输出里必须回报什么证据

如果仓库里已经有统一规则，也可以先参考 仓库规则文件体系。

第一次可以用这个最小模板：

允许改动：
禁止改动：
默认验证命令：
输出必须包含：

第 2 步：只交一个小任务​

优先选这些任务：

  • 修一个已知 bug
  • 补一条缺失测试
  • 跑脚本并解释结果

如果你今天主要就是终端内维护任务，直接搭配 Terminal-First Repo Pairing Runbook。

第 3 步：强制它回报真实命令结果​

第一次成功的关键不是“它会聊很多”，而是：

  1. 真正读了仓库
  2. 真正执行了命令
  3. 真正回报了结果

第一次可以直接把要求写死：

先根据 context file 复述范围和禁止修改区。
只推进这一轮最小任务。
结束后必须给出真实命令结果、改动摘要和剩余风险，不能只给口头结论。

第 4 步：把交付收成简短说明​

至少留下三样东西：

  • 改了什么
  • 跑了什么命令
  • 还剩什么风险

如果后续要进入 PR 流，再接 Issue / Jira -> Draft PR Runbook。

验收清单​

  • context file 真的被用来约束范围，而不是摆设。
  • 命令结果是真实执行结果，不是口头复述。
  • 最终说明足够让下一位读者知道做了什么和没做什么。
  • 你能明确说出这次为什么还只是轻量终端任务。

常见失误​

  • context file 写成一大堆泛规则，第一次就把维护成本拉高。
  • 没有验证命令，却还期待 CLI 给出可信结论。
  • 只让它“分析一下”，不要求实际命令和证据。
  • 任务已经明显超出轻量终端范围，却还不切到更强执行栈。

下一步​

来源​