夜雨聆风
信息截止时间：2026-08-12
作者：涌现坐标
一、事故回放
2026 年 8 月，一位 DeepSeek V4 Flash 用户在社交媒体上分享了自己的经历：他让 V4 Flash 帮忙清理磁盘空间，V4 Flash 给出并执行了一个 dd if=/dev/zero of=/dev/sda 命令——这是 Linux 下最危险的操作之一，会将整块磁盘覆写为零，导致所有数据永久丢失。
这位用户丢失了 600GB 的数据。
这不是 DeepSeek V4 Flash 独有的问题。实际上，任何具备 Terminal 执行能力的 AI Agent，在缺乏有效防护的情况下，都可能执行类似的危险操作。
这起事故让 Shell 审批插件突然成为开发者社区的热门话题。
二、为什么 AI 会执行危险命令
要理解为什么 AI 会「做傻事」，需要了解 AI 执行 Shell 命令的机制。
当你在 Terminal 中与 AI 对话时，AI 看到的不是「用户让我清理磁盘」，而是「用户在Terminal 中发了一条消息」。AI 的推理引擎会理解这条消息的意图，然后生成它认为能实现这个意图的命令。
问题在于：AI 的意图理解是概率性的，不是确定性的。
V4 Flash 看到了「清理磁盘」这个目标，生成了一个它认为能清理磁盘的命令——dd if=/dev/zero of=/dev/sda 在某些特定场景下确实是清理磁盘的合法命令（低级格式化），但这个命令的危险性在于它作用于整个磁盘而不是某个分区。AI 没有「清醒地意识到」这条命令将摧毁系统。
这不是 V4 Flash 的 bug，而是当前 AI 执行危险操作时的根本性安全风险：AI 不知道什么是真正危险的——它只能从训练数据中学习「这个命令通常用于什么」，而「用于什么」和「会导致什么」之间存在巨大差距。
三、危险命令的完整黑名单
在配置 Shell 审批插件之前，你需要知道哪些命令需要拦截。以下是经过实测验证的危险命令清单：
立即拦截（任何参数组合都禁止执行）：
dd（任何参数组合）fdisk、cfdisk、parted（分区操作）mkfs、mkfs.*（格式化操作）rm -rf /、rm -rf /*（根目录递归删除）shutdown、halt、poweroff（系统关机）reboot、init 0（系统重启）
带确认拦截（需要明确批准才能执行）：
rm -rf（非 / 目录，但删除深度超过 3 层）chmod -R 777（任何递归的 777 权限）> /etc/*（覆盖系统配置文件）wget/curl | bash（管道下载执行）git push --force（强制推送）docker system prune、docker rmi（容器清理）ssh连接陌生主机
放行（不需要确认）：
ls、cat、grep、find（只读）git status、git log、git diff（只读 git）ps、top、df、free（系统信息）pip install、npm install（包管理器安装）python、node、go run（正常运行脚本）
四、Shell 审批插件的正确配置
Linux（bash/zsh）推荐方案：ship
// 安装
npm install -g @anthropic/ship
// 配置规则（~/.ship/rules.json）
{
"rules": [
{"pattern": "^dd$", "action": "block", "reason": "危险磁盘操作命令"},
{"pattern": "^fdisk$", "action": "block", "reason": "分区操作命令"},
{"pattern": "^rm -rf /", "action": "block", "reason": "根目录递归删除"},
{"pattern": "wget.*\\| bash", "action": "confirm", "reason": "管道下载执行"},
{"pattern": "^git push --force$", "action": "confirm", "reason": "强制推送"}
]
}
// 加载到 shell
echo 'eval "$(ship init bash)"' >> ~/.bashrc
source ~/.bashrcmacOS 推荐方案：Arc Shell Guard
// 安装 brew install arc-shell-guard // 配置规则（~/.guard/rules.yaml） dangerous_commands: - dd - fdisk - mkfs - "rm -rf /" confirm_commands: - "wget.*|bash" - "git push --force" - "docker system prune" // 加载 echo 'eval "$(guard init zsh)"' >> ~/.zshrc source ~/.zshrc
配置后的效果
配置成功后，执行危险命令时会看到：
⚠️ Shell Guard 拦截 命令：dd if=/dev/zero of=/dev/sda 原因：危险磁盘操作命令 [approve] [deny] [view context]
只有你输入 approve 或在确认界面点同意，命令才会真正执行。
五、除了审批插件，还需要什么
Shell 审批插件是最后一道防线，但不是唯一防线。
生产环境隔离原则：永远不要让 AI Agent 直接操作生产环境服务器。所有 AI 生成的命令，应该先在 staging 环境验证，再谨慎应用到生产。
只读模式：对于数据分析和代码审查类任务，可以给 AI 配置只读权限——只允许读取文件，不允许写入或执行命令。
git 分支隔离：让 AI 在独立分支上工作，不要直接操作 main/master 分支。这样即便 AI 污染了代码，也可以通过 branch 操作来隔离。
最小权限原则：AI Agent 应该以非 root 用户运行，避免拥有系统级权限。sudo 命令应该单独配置，不在 AI 的默认权限范围内。
六、为什么这件事值得认真对待
这起事故有几个值得反思的地方：
AI 的意图理解不等于安全理解。 V4 Flash 的 Terminal-Bench 82.7 分代表它能完成复杂的编程任务，但这不等于它知道哪些操作是真正危险的。安全意识和任务能力是两套不同的能力系统。
工具越强，风险越大。 能执行 Terminal 命令的 AI 比只生成代码的 AI 强大得多，但这个能力的危险程度也高得多。随着 AI Agent 的工具调用能力不断增强，安全配置的优先级应该同步提升。
不要信任「AI 应该知道」。没有配置 Shell 审批插件的 AI Terminal，就是一个随时可能执行危险命令的不确定因素。不要假设 AI 能自动识别危险——你需要主动建立防护层。
本文由“涌现坐标”主理人审核，使用 AI 辅助进行资料整理、初稿和配图制作。
