想让 AI 禁掉 push -f？手把手教你自定义 Agent Skills 的指令黑名单

在 AI 代理（AI Agents）权限日益扩大的今天，赋予 AI 操作终端的能力就像是给新来的实习生开了 root 权限。虽然像 Claude Code 这样的工具极大地提升了效率，但它们偶尔会为了“解决问题”而采取一些极端手段——比如当你本地分支落后于远程时，它可能会毫不犹豫地执行 git push -f。

作为架构师，我们要做的不是禁用 AI，而是为其安装“护栏”。利用 Agent Skills 的自定义能力，我们可以轻松构建一套指令黑名单（Command Blacklist），在灾难发生前勒住 AI 的缰绳。

---

1. 为什么“只靠叮嘱”是不够的？

你可能在 System Prompt 里写过：“请不要执行强制推送”。但在复杂的 debug 过程中，当 AI 陷入逻辑死角时，它会优先选择能够“跑通流程”的指令。

架构师排雷：

• 表现： 远程仓库的提交历史被 AI 覆盖，导致团队其他成员代码丢失。
• 原因： AI 无法评估“强制推送”对协作流的毁灭性影响，它只关注当前的本地任务是否成功。
• 解法： 在底层 Skill 执行层引入硬性拦截逻辑。

---

2. 深度定制：如何编写 git-guardrail 的黑名单规则

在 Matt Pocock 的 skills 架构中，护栏（Guardrails）本质上是一层中间件。要自定义拦截规则，你需要修改或扩展技能的 prompt.md 或 metadata.json。

拦截目标	风险场景	拦截策略 (Guardrail Policy)
git push -f	覆盖远程历史	全量拦截：除非包含特定安全后缀，否则直接报错。
rm -rf /	毁掉开发环境	权限降级：禁止删除非项目目录下的任何文件。
git reset --hard	丢失未提交工作	状态自检：执行前必须先运行 git status 并报告风险。

---

3. 如何配置一个“带解释的”拦截器？

一个好的拦截器不应该只是简单的 Access Denied，它应该告诉 AI 为什么被拦截，并引导它使用更安全的替代方案。

你可以尝试在自定义 Skill 中加入如下逻辑：

1. 正则匹配层：识别指令字符串中是否包含 -f, --force, reset --hard 等关键字。
2. 上下文注入：当检测到黑名单指令时，立即向 AI 返回一条伪造的系统错误：“System Policy: Force push is disabled. Please use git pull --rebase or resolve conflicts manually.”
3. 二次确认机制：要求 AI 在执行高危操作前，必须先生成一份“操作后果评估报告”。

---

4. 让安全策略跟随技能走

真正的工程化管理不应该依赖于每个开发者的自觉，而应该让安全策略变成可插拔的插件。

为了帮你彻底封堵 AI 误操作的风险，我已经在 GitCode 发布了 《Agent Skills 自定义拦截器：Git 强制操作防弹配置包》。这套配置包预设了 15 条最常见的危险指令黑名单，并内置了引导式回复模板，能让你的 AI 助手在被拦截时自动学会正确的操作方式。访问 GitCode，领取这套防弹配置，给你的代码库买一份“终身保险”。

[在 GitCode 领取《Git 强制操作防弹配置包》，为 AI 助手安装物理护栏。]