Shell 命令

Gemini CLI 可以执行 Shell 命令。这个能力让它能跑测试、构建、Git、脚本和系统任务，也带来最直接的风险。你要把 shell 当成真实终端，不要当成“AI 沙盒里的玩具命令”。

Shell 是高风险能力：凡是删除、覆盖、发布、部署、改权限、动密钥、动生产数据，都必须人工确认。

1. 直接执行命令

!ls -la
!git status
!npm test

! 会把命令直接交给 shell 执行，并把输出记录到当前 session 上下文。

官方 commands reference 说明，! 命令在 Linux/macOS 上走 shell，在 Windows 上走 PowerShell 相关执行路径；执行时还会设置 GEMINI_CLI=1，方便脚本识别它是在 Gemini CLI 内部运行。

Shell tool 的返回会包含命令、目录、stdout、stderr、error、exit code、signal 和后台 PID。教程里不要只看自然语言总结；排错时先看 exit code 和 stderr，再判断是否需要改代码。

如果连续执行很多命令，可以输入 ! 后回车进入 Shell mode。之后输入会直接发送到 shell，直到你退出。

这个模式适合手动排查，不适合交给 agent 长时间失控执行。

Run the unit tests. If any fail, analyze the error and propose a fix before editing.

推荐要求它先提出修复计划，再授权编辑。不要让它在失败后无限循环尝试。

一个合格的测试任务应该包含停止条件：

Gemini CLI 可以启动 dev server 或 watcher。查看后台进程可用：

/shells

如果服务跑飞，应及时查看日志并停止。

后台进程要收尾：启动 dev server、watcher、数据库、本地队列或浏览器调试进程后，要记录端口和用途。任务结束前确认是否保留，不要让后台进程长期占端口。

官方 shell tutorial 建议处理不可信代码或新项目时启用 sandbox：

gemini --sandbox

sandbox 能降低风险，但不能替代人工判断。

官方 sandbox 文档也提醒：sandbox 减少风险，不消除风险。新项目、下载代码和不可信脚本可以先开 sandbox，但删除、发布、数据库迁移这类动作仍然需要人工确认。

命令类型	例子	默认策略
只读状态	`git status`、`pwd`、`ls`	可以低风险执行
项目验证	`npm test`、`pnpm typecheck`	先确认目录和耗时
写入生成	formatter、codegen、build cache	先说明生成物和 diff
外部影响	deploy、database migration、cloud CLI	必须人工确认
破坏性命令	delete、reset、permission change	默认拒绝，除非明确授权

让 Gemini CLI 执行 shell 前，检查三件事：命令是否在正确目录，是否只读或低风险，失败后是否有停止条件。执行后要求它总结退出码、关键输出和下一步，而不是把长日志原样甩给用户。

涉及后台 dev server 时，记录端口和 session，任务结束前确认是否还需要保留进程。CI、发布、部署、删除文件这类命令，不应让模型自己连续试错。

如果命令失败，不要马上让 Gemini CLI 改实现。先让它解释失败来自命令不存在、依赖缺失、权限问题、测试断言、网络问题还是目录错误。分类清楚后再决定下一步。