🛡️ Destructive Command Guard：给 AI 代理装上“安全刹”，再也不用担心 rm -rf 毁灭世界了

你有没有经历过这样的惊魂时刻：凌晨三点，睡眼惺忪地敲下一行 rm -rf / home/user/project，回车之后才意识到多了一个空格？或者更可怕——你让 AI 助手帮你“推送代码到远程仓库”，结果它执行了 git push --force origin main，把团队一周的努力直接送走。随着 AI Coding Agent 的崛起，这类灾难正在从偶然事故变成系统性风险。

今天在 GitHub Trending 上发现一个宝藏项目——Destructive Command Guard（简称 dcg），它专门用来拦截代理、脚本甚至是你自己无意间发出的危险 Git 和 Shell 命令。就像给终端装上了一道主动防御系统，让你可以放心地把部分控制权交给 AI，同时也防止人类自己手滑。

🔥 为什么我们需要一个“命令守卫”？

现代开发环境越来越依赖自动化。从 GitHub Copilot 自动补全，到 Devin、Sweep 这类全自动代理，AI 已经开始直接操作 Shell。但问题来了：这些代理对后果的理解还停留在概率层面，它们不会真正“害怕”丢失数据。

举个例子，你让一个 AI 代理“清理一下当前分支”，它可能给出的最优解是：

git reset --hard HEAD~1
git push --force origin feature-branch

如果这是你悉心维护的主分支，后果不堪设想。更不用说各种脚本里潜伏的 rm -rf、sudo 高危组合，或者在生产环境误执行 shutdown now。传统的做法是权限控制或者人工审核，但在高频交互中完全不现实。我们需要一个智能中间层，在命令真正抵达 Shell 之前做出判断。

这就是 dcg 诞生的理由：它不是一个简单的别名替换，而是一个可插拔的运行时拦截器，对 Zsh 和 Bash 的命令执行流程进行深度挂钩。

⚡ Destructive Command Guard 速览

来自开发者 Dicklesworthstone 的 destructive_command_guard（GitHub 地址）是一个轻量但威力巨大的 Shell 插件。它的核心逻辑非常简单：在你按下回车键之后、命令真正执行之前，用一个规则引擎扫描整条命令，如果匹配到危险模式，立刻拦截并要求二次确认，甚至直接拒绝执行。

项目目前已经完全开源，采用 MIT 协议，短短几天就冲上了 Trending。看完它的代码和设计，你会发现它既像一位细心的安全审计员，又像一把可调节的“安全刹”，你随时可以调整灵敏度。

🛠️ 它如何拦截那些“要命”的命令？

dcg 的工作原理基于 Zsh 的 preexec hook 和 Bash 的 trap DEBUG 机制。当你在终端输入任何命令后，这个 hook 会在命令执行前触发，捕获整条字符串并交给 dcg 的规则引擎。规则引擎使用 Python 编写（没错，核心检测逻辑用 Python，但最终集成进 Shell 函数），支持复杂的模式匹配与上下文分析。

内置的规则库已经相当丰富，比如：

Git 高危操作：git push --force、git reset --hard、git clean -fd，甚至针对受保护分支（如 main/master）的强制推送。
文件系统毁灭者：rm -rf /*、dd if=/dev/zero of=/dev/sda、mkfs.* 等。
权限升级与系统命令：sudo su、chmod 777 -R /、shutdown、reboot。
网络敏感操作：比如通过 curl | bash 直接执行远程脚本。

拦截发生时，dcg 不会悄无声息地放行，而是会用醒目的红色警告提醒你，并要求输入“yes”或额外口令确认。你也可以配置它完全禁止某些命令，连确认的机会都不给。

🔍 技术亮点：不仅仅是正则匹配

初看起来，你可能觉得这就是一堆正则表达式的堆砌，但深入代码会发现几个巧妙的设计：

上下文感知的规则引擎

dcg 并非简单地 grep 关键词。它会解析命令结构，识别参数和子命令。例如，它会区分 rm -rf /tmp/safe-folder 和 rm -rf /，后者路径为根目录才触发拦截。对于 Git 命令，它能够检测当前分支名称，如果你在 main 分支上执行 git push --force，拦截概率远高于在 feature 分支上。这种上下文感知极大地减少了误报，让日常操作不被打扰。

高度可定制的规则与扩展

dcg 使用 YAML 配置文件定义规则，你可以轻松添加自己的“雷区”。比如公司内部禁用的 kubectl delete namespace 或者数据库危险操作。规则支持白名单、黑名单、正则和自定义脚本。把它想象成 Shell 版本的 ESLint 就对了。

零延迟的注入方式

通过 preexec 而不是外部代理进程的方式，dcg 几乎不增加命令执行的延迟。Python 脚本会被预编译并缓存，仅在需要时快速调用。实测中，对于普通命令你完全感受不到它的存在。

🖐️ 快速上手：像安装 Oh My Zsh 插件一样简单

项目提供了非常友好的安装脚本，克隆仓库后执行一行命令即可完成安装：

git clone https://github.com/Dicklesworthstone/destructive_command_guard.git
cd destructive_command_guard
./install.sh

安装脚本会自动检测你使用的 Shell（Zsh 或 Bash），并将必要的 source 命令添加到 .zshrc 或 .bashrc 中。之后重启终端，你就能看到 dcg 的启动标志。默认配置下，它会以“警告但允许确认”的模式运行。如果你想要更严格的安全策略，编辑 ~/.dcg_config.yaml，把某些规则的 action 从 confirm 改为 deny 即可。

例如，禁止任何 sudo shutdown 命令：

rules:
  - name: forbid-shutdown
    pattern: "sudo\\s+shutdown"
    action: deny
    message: "Shutdown command is strictly forbidden here!"

让我们测试一下效果：

$ git push --force origin main
🚨 Destructive Command Guard Alert!
   Command: git push --force origin main
   Risk: Force push to protected branch 'main'
   Action: Confirm (type 'yes' to proceed):

输入 yes 之后，命令才会真正执行。如果你不小心手滑或是代理发起的，大概率会被这个确认步骤拦住。

🎯 适用场景：从个人开发者到企业级防护

dcg 定位非常清晰，它能保护的环境远不止一台开发机：

AI Coding Agent 安全沙箱：无论是 GitHub Copilot Chat、Devin，还是自己搭建的 LangChain Agent，让它们运行在安装了 dcg 的终端里，相当于给了它们一张“禁行地图”。
CI/CD 流水线：在 Docker 镜像或 Runner 中预装 dcg，防止脚本误删除缓存、错误推送代码或执行危险系统管理命令。
生产环境跳板机：运维人员登录跳板机时，dcg 可以封锁 rm -rf、iptables 等高危操作，即使拥有 root 权限也需额外确认，减少人为事故。
教学与培训场景：给新手一个受保护的 Shell 环境，让他们自由尝试又不至于搞崩系统。

🚀 未来可期：走向策略即代码

目前 dcg 还处于早期阶段，但已经展现了极强的可扩展性。结合最近很火的 OPA（Open Policy Agent）或 Rego 策略语言，未来甚至可以用“策略即代码”的方式管理整个公司的 Shell 安全规则。想象一下，将所有终端操作日志和拦截事件统一发送到 SIEM，那将是一个极细粒度的内部威胁防护系统。

另外，项目维护者计划增加对 Fish Shell 的支持，并且正在开发一个基于终端的规则管理 TUI，让非技术用户也能通过上下左右键管理规则。同时，社区也开始贡献更多针对 Kubernetes、Docker、云 CLI（如 aws、gcloud）的危险命令库。

💡 总结：是时候给你的终端加一道“安全带”了

Destructive Command Guard 不是在解决一个虚构的问题。当我们的终端越来越智能，能帮我们执行越来越复杂的任务时，必须有一个与之匹配的防御机制。它没有复杂概念，也不需要改变你的工作流，只是默默地在回车后做最后一道安检。

如果你正在使用任何 AI 代理操作代码库，或者曾经被 rm -rf 吓出冷汗，今晚就可以装上一个 dcg。它或许会在关键时刻，救下你辛辛苦苦写的代码——或者至少，救下你的睡眠。🛌

项目地址：https://github.com/Dicklesworthstone/destructive_command_guard
Star 一下，为你的 Shell 安全投上一票 ⭐