Claude Code Mods 怎么用:3 种自定义规则防止 AI 乱改代码
你让 Claude Code 帮你改一段代码,结果它一口气把三个文件全改了,还顺手删了一段你根本没让它动的逻辑。这种"AI 越界改代码"的情况,几乎每个新手都踩过。核心答案其实很简单:用 Claude Code 的模块化自定义规则(Mods)给 AI 套上"护栏",让它先列计划、再动手,凡是改生产文件必须你点头。本文基于官方文档里的权限与钩子机制,给你 3 种可落地的自定义规则写法,覆盖从"写死硬规则"到"运行时拦截"的完整链路。看完你就能在自己项目里配好护栏,既享受 AI 编程的速度,又不用再担心它乱改。

先看结论
三种规则各管一段,建议叠加使用而不是只选一个。下面这张表帮你按自己的风险偏好直接做决定。
| 规则方式 | 适合场景 | 生效时机 | 上手成本 | 防护强度 |
|---|---|---|---|---|
| CLAUDE.md 硬规则 | 想让 AI 永远记住"别碰某目录" | 每次对话开始 | 低,写一段文字即可 | 中,靠模型自觉 |
| 权限设置收住工具 | 想禁止 AI 直接写文件 | 每次调用工具时 | 中,改一个 JSON | 高,系统级拦截 |
| PreToolUse 钩子 | 想对敏感文件做二次确认 | 工具执行前 | 高,要写脚本 | 最高,可强制阻断 |
💡 小提示:Claude Code Mods 的本质是把"项目约定"变成机器能执行的约束。三件套一起上,防护最稳。想系统学基础命令,可以先翻 Claude Code 编程技能教程。
一、用 CLAUDE.md 写死 Mods 硬规则
最省事的一层护栏,是直接把规矩写进项目的 CLAUDE.md。这个文件会被 Claude Code 在每次对话开始时自动读取,相当于给 AI 的一份"项目说明书"。它不靠系统强制,而是让模型在生成动作前先对照你的要求。
新建或打开项目根目录的 CLAUDE.md,用大白话写清楚三条边界:哪些目录绝对不能改、改代码前必须先给计划、生产配置要单独确认。更细的字段说明可以看 Claude Code 核心技能。
# 本项目与 Claude Code 协作规则
- 禁止直接修改 `prod/`、`migrations/` 与 `.env` 下的任何文件,需要先列出改动计划等我确认。
- 任何涉及写文件的动作,先输出"将要改哪些文件、为什么改",不要直接动手。
- 删除或重命名文件前必须显式问我一次,默认不执行。
- 运行测试请用 `pytest -q`,不要把测试输出当成已验证结论。
上面这段就是一份最基础的 Claude Code Mods 配置文件。它不强求语法,关键是把"禁止""必须先""默认不"这类确定性词写清楚。模型会把它当作最高优先级的上下文。
⚠️ 注意:
CLAUDE.md是"软约束",依赖模型遵守。它适合挡住大部分误操作,但挡不住模型在复杂任务里"忘了"某条规则。所以高风险项目一定要再叠一层硬拦截。

二、用权限设置收住改写工具
第二层护栏是 settings.json 里的权限规则。和 CLAUDE.md 不同,权限设置是系统级拦截:当 AI 想调用写文件类工具时,如果没被授权,Claude Code 会直接停下来等你确认,而不是"先斩后奏"。
在项目的 .claude/settings.json 里,把默认权限模式设为 default(即每个写操作都问你),并只显式放行安全的只读工具。
{
"permissions": {
"defaultMode": "default",
"allow": [
"Read(*)","Grep(*)","Glob(*)"
],
"deny": [
"Write(prod/**)","Edit(prod/**)","Bash(rm:*)"
]
}
}
这段配置做了两件事:允许读与搜索,但把 prod/ 目录下的写入和一切删除命令直接拉黑。当 AI 试图改生产文件时,会被 deny 规则拦下,必须你手动放行。这就是把"防止 AI 乱改代码"从"靠它自觉"升级成"系统替你把关"。
预期结果(未在本机执行,依据官方权限文档):AI 在动 prod/ 下文件时会弹出确认,而不是静默写入。如果你的版本字段名略有差异,以安装版本的官方说明为准。想了解更完整的工程化思路,可以补 AI 编程技能教程。
三、用 PreToolUse 钩子做写入前拦截
第三层也是最硬的一层:钩子(Hook)。PreToolUse 钩子会在工具真正执行前被调用,你可以写一段脚本,判断"这次要改的文件是不是敏感文件",是就直接拒绝,甚至要求输入验证码才放行。
在项目 .claude/settings.json 里挂一个 PreToolUse 钩子,指向一个本地脚本:
{
"hooks": {
"PreToolUse": [
{
"matcher": "Write|Edit",
"hooks": [
{ "type": "command", "command": "bash .claude/guard.sh" }
]
}
]
}
}
guard.sh 读取 Claude Code 传入的工具参数,命中敏感路径就返回非零退出码,工具调用会被强制中断:
#!/usr/bin/env bash
# 从标准输入读取工具调用参数(Claude Code 以 JSON 传参)
INPUT=$(cat)
PATH_FIELD=$(echo "$INPUT" | grep -o '"file_path":"[^"]*"' | head -1)
if echo "$PATH_FIELD" | grep -qE 'prod/|migrations/|\.env'; then
echo "拦截:禁止修改生产敏感文件 $PATH_FIELD" >&2
exit 1
fi
exit 0
运行与验证(未在本机执行):当你让 AI 改 prod/app.py 时,钩子脚本退出码为 1,写操作被阻断并提示原因;改成 src/app.py 时退出码 0,正常放行。这层护栏不依赖模型自觉,是真正的"代码安全"最后一道闸门。涉及 JSON 配置时,Python3 教程 里的数据结构基础能帮你读懂字段。

四、上线前自检清单
护栏配完别急着交给团队,先用这张清单过一遍,避免"配了等于没配"。
- 改
prod/或.env前,AI 是否会先弹出确认而不是静默写入?没有就回头查deny规则。 CLAUDE.md里写的"禁止项"是否够具体?只写"别乱改"模型会自己解读,必须写成"禁止改 prod/ 与 migrations/"。- PreToolUse 钩子是否只在敏感路径拦截?用
src/下的正常改动测一次,确认不会被误伤。 - 三种规则是否叠加而非只选一个?高风险项目建议三件套全上,防护最稳。
- 验证动作是否在本机真正跑过?至少确认一次"改 prod 被拦、改 src 放行"的双向行为。
清单全过,Claude Code Mods 才算真正生效;任一项存疑,都先补上再交付。
总结
给 Claude Code 套护栏,核心不是限制它的能力,而是把"你信任它但不放任它"这件事变成可执行规则。三层叠加最稳:用 CLAUDE.md 写清协作约定,用 settings.json 权限收住写文件工具,再用 PreToolUse 钩子对敏感路径做强制拦截。这样 AI 编程助手既能提速,又不会越界乱改你的代码。下一步建议把这三件套沉淀成团队共享的模板,新项目一键复用。
常见问题
Q:CLAUDE.md 和 settings.json 到底先信哪个?
A:先信 settings.json。CLAUDE.md 是软约束,靠模型遵守;权限设置和钩子是系统级硬拦截。重要项目一定要用后者兜底,别只靠文字约定。
Q:钩子脚本报错了会不会让 AI 完全动不了文件?
A:不会。钩子只在你写的匹配规则命中时才拦截,比如只拦 prod/ 下的写入。普通 src/ 下的改动只要脚本返回 0 就正常放行,不影响日常开发。
Q:这些规则会拖慢 AI 写代码的速度吗?
A:会多一两次确认,但代价很小。相比一次误删生产配置带来的回滚成本,这点确认时间完全值得。你可以只对最敏感的目录设硬拦截,其余保持流畅。
Q:团队多人怎么共享同一套护栏?
A:把 CLAUDE.md、.claude/settings.json 和钩子脚本一起提交到仓库,新人克隆即用。注意钩子脚本要写相对路径,并先 chmod +x .claude/guard.sh 赋执行权限,否则在别人机器上会报找不到命令。
延伸学习
想把 AI 协作这套能力系统补齐,可以按这个顺序往下看:
- 想直接上手实战项目,TRAE AI 开发实战课程 是边学边练的形式;
- 也看看这篇笔记 Claude Code 多项目打开方法,了解多项目下的配置隔离;
- 想横向对比另一款工具,TRAE 编程中文教程 能帮你快速建立认知。

TRAE-AI编程



