把终端命令交给 AI 执行，安全吗？在自己的机器上、在可以回滚的仓库里、并且只有在你读过即将执行的内容之后——是安全的。一旦工具把模型输出未经确认就直接灌进 shell——就不安全。下面是这个答案背后的威胁模型。
1. 你到底交出了什么
拥有 shell 权限的智能体能做你这个用户账号能做的一切：读取环境变量——以及里面的令牌；读取 ~/.ssh 和 ~/.aws/credentials；修改配置文件；安装能在重启后存活的服务。这不是「AI 变坏」的假设，一次失误就够了。
2. 「建议」和「执行」的区别
$ clai 删除所有已停止的容器和未使用的镜像→ docker system prune -a⚠ CAUTION — 将删除所有没有被运行中容器使用的镜像是否执行？输入 yes 确认：生成和执行是两个独立的步骤。把模型输出直接灌进 shell 的工具，拆掉了模型的一次笔误和你硬盘之间唯一的屏障。
3. 值得区分的三个风险等级
SAFE——只读命令：ls、ps、df、git log。出错的代价是时间。
CAUTION——改变状态的命令：docker prune、git reset、systemctl restart、chmod -R。出错的代价是返工。
DANGER——不可逆的命令：rm -rf、dd、mkfs、DROP TABLE、强制推送。出错的代价是数据。
标签本身不是重点，重点是它逼你在错误代价陡增的那个点停下来。
4. 先要一次空跑
$ clai 把这个文件夹同步到生产环境，但先告诉我会做什么→ rsync -av --dry-run ./build/ deploy@prod:/var/www/几乎每个破坏性操作都有「只显示」模式：rsync --dry-run、git clean -n、不带 -delete 的 find。只要涉及生产环境，先要这个模式。
5. 限制的是波及范围，不是信任
给智能体任务单独开一个用户。令牌权限最小、有效期短。生产环境只通过带审查的独立通道触碰。这和第一天上班的新人要遵守的规则一样，而且有效的原因也一样：它们不依赖模型有多好。
6. 核对到底执行了什么
$ clai 显示我通过 clai 运行的最近 20 条命令→ cliai log --tail 20本地请求日志能让你事后复盘。出问题时，你能看清是哪句话生成了哪条命令。
坑
- 危险的不只是破坏性命令，还有泄露。 调试时打印环境变量的智能体，刚把你的令牌写进了日志，而这份日志可能会离开这台机器。
- 「我以后再看」不管用。 命令要在按下 Enter 之前读，按下之后你读到的已经是后果。
- 自己机器上的自动模式和生产环境上的自动模式，是两个不同的决定。 在一次性沙盒或 git 仓库里，自动执行合理；在存着真实数据的服务器上，不合理。
相关问题
可以给 AI 终端访问权限吗？ 对于可逆的工作——git 仓库、沙盒、自己的机器——可以，前提是执行前要确认。对于生产环境，只用「给我看，我来决定」模式。
这和从 Stack Overflow 复制粘贴有什么区别？ 原则上没有区别，这正是关键所在。从网上复制的命令你执行前也会读一遍。唯一的区别是，这条命令是为你的系统生成的。
如果还是执行错了命令怎么办？ 停止进程，查看本地请求日志，评估损失。这正是为什么不可逆操作需要输入确认，而不是按一个键就完事。
另请参阅
CliAI 会先给你看命令，等你确认后才会执行任何破坏性操作——从这里开始。