这是啥
读完 Claude Code 入门 你已经能用起来。这一篇是下一步：把 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 的必要。
升级路径（从 Claude Code 入门 到这一层）
基于 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。
关联
- 前置：Claude Code 入门 · CLAUDE.md 完全解读 · 什么是 Hook 和 Slash Command
- 并列：什么是 MCP（外部连接）
- 进阶：案例_Boris 怎么用 Claude Code（真实团队配置样本）