这是啥
读完 入门 你已经能用起来。这一篇是下一步：把 Claude Code 从”能用”调教成”合你工作流”。三件事：
- settings.json：权限、默认模型、env 变量——你的个性化配置中心
- hooks：Claude 做某事前/后自动触发脚本——自动化陷阱
- plugins：打包好的能力集（agents + skills + commands + hooks）——一键装一套工作流
settings.json：配置的总闸门
来源：claude-code-docs/settings.md。
Claude Code 按优先级读三层 settings.json，后者覆盖前者：
| 层 | 路径 | 作用域 |
|---|---|---|
| 全局 | ~/.claude/settings.json | 你所有项目 |
| 项目共享 | <project>/.claude/settings.json | 本项目 + 全团队（进 git） |
| 项目本地 | <project>/.claude/settings.local.json | 本项目 + 只你本机（不进 git） |
最常用的 5 个字段
{
"model": "claude-opus-4-7",
"permissions": {
"allow": ["Bash(bun run test:*)", "Bash(git status)"],
"deny": ["Bash(rm -rf:*)"]
},
"env": { "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "90" },
"hooks": { /* 见下文 */ },
"enabledMcpjsonServers": ["slack", "github"]
}（来源：settings.md 字段表 + permissions.md allow/deny 语法）
permissions 的三种态度
permissions.md 明确给出三档：
allow：不问，直接做（把你验证过的安全命令放这）ask：默认值，每次弹窗让你确认deny：永远不做（危险命令写这里）
Boris 的做法（how-boris-uses-cc.md tip 10）：不用 --dangerously-skip-permissions，改用 /permissions 命令把常用安全命令一条条 pre-allow，团队共享 .claude/settings.json 里的 allow 列表。
hooks：事件驱动的自动化
来源：claude-code-docs/hooks.md + hooks-guide.md + Boris tip 9。
基础概念在 hook-slash-command 写过了。这里只讲进阶用法。
五个触发时机
hooks.md 列的完整事件类型：
| 事件 | 什么时候跑 | 典型用途 |
|---|---|---|
PreToolUse | Claude 准备调工具前 | 拦截危险命令、加前置检查 |
PostToolUse | Claude 用完工具后 | 自动格式化、自动跑测试 |
UserPromptSubmit | 你刚输入 prompt 时 | 记录意图、预处理 prompt |
Stop | Claude 回答完一轮 | 记日志、发通知 |
Notification | 需要你介入时 | 响铃、push 通知 |
matcher 语法（hooks-guide.md）
matcher 决定 hook 对哪些工具/事件生效：
{
"PostToolUse": [
{
"matcher": "Write|Edit",
"hooks": [
{ "type": "command", "command": "bun run format || true" }
]
}
]
}上面：只对 Write 和 Edit 工具触发。| 是或，也支持正则。
Boris 的三条 hook 经验（tip 9）
“Claude generates well-formatted code 90% of the time, the hook catches edge cases to prevent CI failures.”
|| true是关键——hook 失败不该中断 Claude- hook 的 exit code 会被 Claude 看见——非 0 等于告诉 Claude”这步出错了”，它会反应
- PreToolUse hook 可以 block——返回特定 exit code Claude 就不执行原工具（危险命令拦截器）
plugins：成套工作流打包
来源：claude-code-docs/plugins.md + plugin-marketplaces.md。
是什么
一个 plugin 是一个目录，里面同时打包了 agents / skills / commands / hooks。装上一个 plugin = 一次性获得一整套工作流。
目录结构（plugins.md）：
my-plugin/
├── plugin.json ← 元数据
├── agents/
│ └── code-reviewer.md
├── skills/
│ └── my-skill/
│ └── SKILL.md
├── commands/
│ └── review.md
└── hooks/
└── on-commit.json
marketplaces
plugin-marketplaces.md 说明：plugin 可从 marketplace 安装，也可本地目录直接引用。现阶段官方推荐 claude-plugins-official 和社群的 superpowers / ralph-loop 等。
什么时候该做 plugin
plugins.md 隐含的门槛：当你有 3+ 个相关 agent/skill/command，且要让别人也能一键用时。单独的 skill 还没到打包成 plugin 的必要。
场景三则
下面三则不是概念解释，而是你真的会在项目里遇到的配置组合。看这三则，能更快判断：什么时候该上 hooks，什么时候只改 settings，什么时候已经值得打包成 plugin。
场景 1：Claude 改完代码，测试自动跑；危险命令在前面就被掐掉
一个典型团队流是：PostToolUse 盯 Write|Edit，每次 Claude 改完文件就自动跑 bun run test 或 bun run lint；同时再用 PreToolUse 盯 Bash，把 rm -rf、乱删 lockfile 这类命令拦在执行前。
没 hook 时，Claude 可能写完代码就直接收工，CI 才告诉你红了；或者它在 panic 状态下乱试危险 bash。
有 hook 时，节奏变成：写完立刻验证，危险命令先过门卫。你把”记得跑测试”从提示词期待，变成了确定会发生的系统行为。
场景 2：settings.json 调好后，Claude 会安静很多
很多人觉得 Claude Code “太吵”，本质上不是模型吵，是权限配置没沉淀。比如团队稳定使用 bun run test:*、git status、rg、find 这些命令，却每次都走 ask 流。此时把它们沉到项目级 .claude/settings.json 的 permissions.allow，再把你的个性偏好留在 .claude/settings.local.json，Claude 会一下子安静很多。
这时再配合 sandboxing，效果更明显：安全命令少确认，越界命令照样挡。
所以 settings.json 的真正作用不是”多一个配置文件”，而是把高频、低风险、重复确认的那部分摩擦先抹平。
场景 3：一个团队共享 skill 包，值得升级成 plugin
如果你团队已经有：
- 代码审查 agent
- PR 描述生成 command
- 提交前校验 hook
- 两三个常用 skill
这时继续靠”把 .claude/ 整个复制进每个仓库”会越来越乱：版本不同步、谁改了不清楚、一个 repo 的 hotfix 很难回流。
把它们打成 plugin 之后，新项目只需要启用同一个 marketplace / plugin 名，就能拿到同一套 agent、skill、command、hook。这时 plugin 不只是”分享方便”，而是把团队工作流变成可版本化、可升级、可回滚的组件。
升级路径（从 入门 到这一层）
基于 Boris tip 和官方 docs 的交叉推断，典型升级节奏大概是：
- 入门 → 1 周：只用 CLAUDE.md + 原生对话
- 1 周 → 1 月：加 3-5 个 slash command（
/commit、/pr等） - 1 月 → 3 月：
settings.json的 permissions allow 逐步扩展；偶尔加 1-2 个 PostToolUse hook - 3 月+：把稳定工作流打包成 plugin；自建 MCP server
注意：这是按素材推断的”一种升级路径”——不是唯一路径，也不是”业界共识”，仅供参考。
陈彬视角
“settings.json 升级得比 CLAUDE.md 快”是典型初学者错位。正确顺序：先把 CLAUDE.md 写厚（规则写明白），再上 hook（自动化），最后才是 plugin（打包分发）。很多人反了——还没把规则想清楚，就先搞一堆 hook，结果是”AI 行为不可预测 + 配置黑魔法 + 自己都不敢改”。
hook 的隐形代价：每加一个 hook，你的 session 启动时会多一层复杂度。hook 挂了、hook 间冲突、hook 吃了太多 token，都是常见坑。保守建议：同一件事你已经手动做了 5 遍以上，再上 hook。
坑点与恢复
最典型的反例：hook 写坏了，结果不是”偶尔误伤”，而是”每次 tool 调用都被 block”。 常见原因有两个：
matcher写太宽，比如用*或裸Bash，把本来只想拦截rm的逻辑挂到了所有工具上- hook 脚本默认
exit 2，或者 stderr 里一直报错，Claude 于是把每次调用都当失败处理
排查顺序别乱：
- 先跑
/hooks：看是哪个事件、哪个 matcher、哪个 source location 在生效 - 先恢复通路：在本地 settings 里临时加
"disableAllHooks": true，把控制权抢回来 - 缩 matcher，不要一把兜底：例如把
Bash收窄成if: "Bash(rm *)"，或把PostToolUse只挂在Write|Edit - 把危险 hook 先放项目本地或本机层测试：别一上来就进团队共享配置或 plugin
- 再开一条 harmless 命令复测：例如
git status或一次普通Edit，确认只在该拦的时候拦
一句话：hook 最大的坑不是不会写，而是写得太宽、太硬、太早共享。
关联
- 前置：入门 · CLAUDE.md · hook-slash-command
- 并列：MCP（外部连接）
- 进阶：Boris 怎么用 Claude Code（真实团队配置样本）