付费方式：两种
┌──────────────────────────────────────────────────────┐
│ Claude Code 认证方式对比 │
├──────────────────────────────────────────────────────┤
│ │
│ 方式一：Claude Pro / Max 订阅 │
│ ├── 固定月费，适合高频使用者 │
│ ├── 首次启动时浏览器弹窗登录 │
│ └── 推荐给日常开发使用的同学 │
│ │
│ 方式二：API Key（按量付费） │
│ ├── 用多少付多少，适合偶尔使用或自动化场景 │
│ ├── 在 Anthropic Console 获取 Key │
│ └── 设置环境变量： │
│ export ANTHROPIC_API_KEY="your-key-here" │
│ （加到 ~/.zshrc 或 ~/.bashrc 中持久生效） │
│ │
│ 选择建议： │
│ 如果你每天都用 → 订阅更划算 │
│ 如果你主要跑自动化脚本 → API Key 更灵活 │
│ │
└──────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────┐
│ Claude Code 四大核心命令 │
├──────────┬───────────────────┬───────────────────────────┤
│ 命令 │ 用途 │ 比喻 │
├──────────┼───────────────────┼───────────────────────────┤
│ claude │ 启动交互模式 │ 开一场面对面会议 │
│ claude -p│ 单次执行 │ 发一条微信消息 │
│ claude -c│ 继续上次对话 │ 昨天的会议今天接着开 │
│ claude -r│ 从检查点恢复 │ 游戏读档 │
└──────────┴───────────────────┴───────────────────────────┘
┌──────────────────────────────────────────────────────┐
│ Claude Code 能做但 Cursor 做不到的事 │
├──────────────────────────────────────────────────────┤
│ │
│ 场景一：每天凌晨自动扫描代码仓库，生成质量报告 │
│ 场景二：每个 PR 提交后自动做 AI 代码审查 │
│ 场景三：用 TypeScript SDK 构建自定义开发工具 │
│ 场景四：多个 AI 子代理并行工作，各司其职 │
│ 场景五：连接 GitHub、数据库、文档系统，跨平台协作 │
│ │
│ 关键词：脚本化、SDK、子代理、MCP、Hooks、Plugins │
│ → 这些都是本系列后续文章的重点内容 │
│ │
└──────────────────────────────────────────────────────┘
## 权限系统到底在干嘛？
┌──────────────────────────────────────────────────────────┐
│ Claude Code 权限三层模型 │
├──────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ Claude 想做某个操作 │
│ │ 请求发出│ │
│ └────┬─────┘ │
│ ↓ │
│ ┌──────────┐ 在 deny 名单里？ │
│ │ deny 层 │── 是 → 直接拒绝，连问都不问 │
│ └────┬─────┘ │
│ ↓ 不在 │
│ ┌──────────┐ 在 ask 名单里？ │
│ │ ask 层 │── 是 → 弹窗问你"可以吗？" │
│ └────┬─────┘ │
│ ↓ 不在 │
│ ┌──────────┐ 在 allow 名单里？ │
│ │ allow 层 │── 是 → 自动通过，丝滑执行 │
│ └────┬─────┘ │
│ ↓ 都不在 │
│ ┌──────────┐ │
│ │ 默认行为 │── 根据当前模式决定（后面详细讲） │
│ └──────────┘ │
│ │
│ 优先级：deny > ask > allow > 默认行为 │
│ 记住这个顺序，永远是 deny 优先 │
│ │
└──────────────────────────────────────────────────────────┘
## 五种权限模式：从"保姆模式"到"全自动"
┌──────────────────────────────────────────────────────────┐
│ 五种权限模式对比 │
├────────────┬──────────────────┬──────────────────────────┤
│ 模式 │ 行为 │ 适用场景 │
├────────────┼──────────────────┼──────────────────────────┤
│ │ 读文件自动通过 │ │
│ default │ 写文件需要确认 │ 新手期，建立信任 │
│ (默认) │ 命令需要确认 │ │
├────────────┼──────────────────┼──────────────────────────┤
│ │ 读文件自动通过 │ │
│ acceptEdits│ 写文件自动通过 │ 日常开发主力模式 │
│ │ 命令需要确认 │ │
├────────────┼──────────────────┼──────────────────────────┤
│ │ 只能读和分析 │ │
│ plan │ 不能写、不能执行 │ 探索不熟悉的代码库 │
│ │ 只出方案不动手 │ │
├────────────┼──────────────────┼──────────────────────────┤
│ │ 读写命令全自动 │ │
│ dontAsk │ 不再询问你 │ 熟练后的高信任场景 │
│ │ 但不跳过安全检查 │ │
├────────────┼──────────────────┼──────────────────────────┤
│ bypass │ │ │
│ Permissions│ 完全跳过所有检查 │ 仅限 Docker 容器内 │
│ 危险 │ 相当于 sudo │ 绝不建议本地使用 │
└────────────┴──────────────────┴──────────────────────────┘
## 权限规则实战：打造你的"黄金配置"
### 配置文件在哪？
┌──────────────────────────────────────────────────────────┐
│ 权限配置文件位置 │
├──────────────────────────────────────────────────────────┤
│ │
│ ~/.claude/settings.json │
│ ├── 全局配置，所有项目通用 │
│ └── 你对 Claude Code 的"底线要求" │
│ │
│ 项目根目录/.claude/settings.json │
│ ├── 项目级配置，提交到 Git 跟团队共享 │
│ └── 这个项目专属的权限规则 │
│ │
│ 项目根目录/.claude/settings.local.json │
│ ├── 个人本地配置，不提交到 Git │
│ └── 你自己的偏好，不影响队友 │
│ │
│ 优先级：local > project > global │
│ → 越具体的配置，优先级越高 │
│ │
└──────────────────────────────────────────────────────────┘
### 项目的权限配置实操
项目根目录下创建 `.claude/settings.json` 文件，内容如下：
```json
{
"permissions": {
"defaultMode": "acceptEdits",
"allow": [
"Read",
"Edit(./src/**)",
"Write(./src/**)",
"MultiEdit(./src/**)",
"Bash(npm run dev)",
"Bash(npm run build)",
"Bash(npm run lint)",
"Bash(npm run test *)",
"Bash(npx tsc --noEmit)",
"Bash(git status)",
"Bash(git diff *)",
"Bash(git add *)",
"Bash(git commit *)",
"Bash(git log *)",
"Bash(ls *)",
"Bash(cat *)",
"Bash(mkdir *)"
],
"ask": [
"Bash(git push *)",
"Bash(npm install *)",
"Bash(npx prisma migrate *)"
],
"deny": [
"Bash(rm -rf *)",
"Bash(sudo *)",
"Bash(curl *)",
"Read(./.env*)",
"Read(./secrets/**)",
"Edit(./.env*)",
"WebFetch"
]
}
}
┌───────────────────────────────────────────────────────┐ │ 权限规则语法参考 │ ├───────────────────────────────────────────────────────┤ │ │ │ 工具类规则： │ │ Read → 允许读取所有文件 │ │ Read(./src/) → 只允许读 src 目录及子目录 │ │ Edit(./src/) → 只允许编辑 src 目录及子目录 │ │ Write(./src/**) → 只允许在 src 目录创建新文件 │ │ │ │ 命令类规则： │ │ Bash(npm run *) → 允许所有 npm run 开头的命令 │ │ Bash(git status) → 只允许 git status 这一个命令 │ │ Bash(git diff *) → 允许 git diff 加任意参数 │ │ │ │ 通配符： │ │ * → 匹配任意字符 │ │ ** → 匹配任意层级的目录 │ │ │ │ 特殊注意： │ │ deny 里的 Read 和 Edit 是独立的！ │ │ deny Read(.env) 不会阻止 Edit(.env) │ │ 如果要完全封锁，两个都要写 │ │ │ └───────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────┐ │ @mentions 四种引用方式 │ ├──────────────────────────────────────────────────────────┤ │ │ │ ① 单文件引用 │ │ @src/app/page.tsx │ │ → Claude 获得这个文件的完整内容 │ │ │ │ ② 多文件引用 │ │ @src/app/page.tsx @src/app/layout.tsx │ │ → Claude 同时获得两个文件的上下文 │ │ │ │ ③ 目录引用 │ │ @src/components/ │ │ → Claude 获得该目录下所有文件的上下文 │ │ │ │ ④ 图片引用 │ │ 直接拖拽图片或粘贴截图 │ │ → Claude 分析图片内容（设计稿、报错截图等） │ │ │ └──────────────────────────────────────────────────────────┘
┌───────────────────────────────────────────────────────────┐ │ 五大高频快捷键 │ ├────────────┬────────────────────┬─────────────────────────┤ │ 快捷键 │ 作用 │ 使用场景 │ ├────────────┼────────────────────┼─────────────────────────┤ │ Ctrl+C │ 中断当前操作 │ Claude 跑偏了，紧急刹车 │ │ Ctrl+D │ 退出会话 │ 干完活了，下班 │ │ Esc Esc │ 撤销最近的修改 │ Claude 改出 Bug 了 │ │ Shift+Tab │ 切换权限模式 │ 临时调整自动/手动 │ │ Ctrl+R │ 搜索历史提示词 │ 复用之前输过的 prompt │ └────────────┴────────────────────┴─────────────────────────┘
┌──────────────────────────────────────────────────────────┐ │ Claude Code 记忆系统全景图 │ ├──────────────────────────────────────────────────────────┤ │ │ │ ┌────────────────────────────────────┐ │ │ │ 第 1 层：全局 CLAUDE.md │ │ │ │ ~/.claude/CLAUDE.md │ │ │ │ → 所有项目通用的个人偏好 │ │ │ │ → "我喜欢 2 空格缩进" │ │ │ └──────────┬─────────────────────────┘ │ │ ↓ 叠加 │ │ ┌────────────────────────────────────┐ │ │ │ 第 2 层：项目 CLAUDE.md │ │ │ │ 项目根目录/CLAUDE.md │ │ │ │ → 项目专属信息，提交到 Git │ │ │ │ → "本项目用 Next.js 14 + TS" │ │ │ └──────────┬─────────────────────────┘ │ │ ↓ 叠加 │ │ ┌────────────────────────────────────┐ │ │ │ 第 3 层：个人本地 CLAUDE.local.md │ │ │ │ 项目根目录/CLAUDE.local.md │ │ │ │ → 个人偏好，不提交到 Git │ │ │ │ → "用中文回答我" │ │ │ └──────────┬─────────────────────────┘ │ │ ↓ 叠加 │ │ ┌────────────────────────────────────┐ │ │ │ 第 4 层：子目录 CLAUDE.md │ │ │ │ src/components/CLAUDE.md │ │ │ │ → 按需加载，操作该目录时才读取 │ │ │ │ → "组件必须用函数式声明" │ │ │ └──────────┬─────────────────────────┘ │ │ ↓ 叠加 │ │ ┌────────────────────────────────────┐ │ │ │ 第 5 层：Auto Memory（自动记忆） │ │ │ │ ~/.claude/projects/<项目>/memory/ │ │ │ │ → Claude 自己记的笔记 │ │ │ │ → 自动记录，无需你维护 │ │ │ └────────────────────────────────────┘ │ │ │ │ 叠加规则：所有层级同时生效，不是覆盖关系 │ │ 冲突时：越具体的层级优先级越高 │ │ │ └──────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────┐ │ CLAUDE.md 内容取舍原则 │ ├──────────────────────────────────────────────────────────┤ │ │ │ 该写的（每次会话都需要知道的信息） │ │ ├── 项目是什么、用了什么技术栈 │ │ ├── 项目目录结构的关键说明 │ │ ├── 编码规范和命名约定 │ │ ├── 日常开发要跑的命令（dev/build/test/lint） │ │ ├── 重要的架构决策和约束 │ │ └── 常踩的坑和特殊注意事项 │ │ │ │ 不该写的 │ │ ├── "写出高质量代码" — 太模糊，等于没说 │ │ ├── "遵循最佳实践" — Claude 自己知道，不用你教 │ │ ├── 完整的 API 文档 — 太长，用 @docs/ 引用 │ │ ├── 频繁变动的信息 — 放到对话里说就行 │ │ ├── 所有可能用到的命令 — 只写高频的 │ │ └── SOLID 原则的定义 — Claude 比你还熟 │ │ │ │ 核心思路： │ │ 想象你给一个高级工程师写交接文档 │ │ 他什么都会，只是不了解"你这个项目的特殊情况" │ │ 你只需要写特殊情况，不需要教他基础知识 │ │ │ └──────────────────────────────────────────────────────────┘
┌────────────┬──────────────────────┬──────────────────────┐ │ 维度 │ 差的 │ 好的 │ ├────────────┼──────────────────────┼──────────────────────┤ │ 项目描述 │ "一个网站" │ "基于 Next.js 14 的 │ │ │ │ 技术博客平台" │ ├────────────┼──────────────────────┼──────────────────────┤ │ 技术栈 │ "用了 React" │ "Next.js 14 + TS │ │ │ │ strict + Tailwind" │ ├────────────┼──────────────────────┼──────────────────────┤ │ 编码规范 │ "写干净的代码" │ "function 声明组件， │ │ │ │ Props 命名 XxxProps"│ ├────────────┼──────────────────────┼──────────────────────┤ │ 常用命令 │ 没有 │ 完整的 dev/build/ │ │ │ │ test/lint/migrate │ ├────────────┼──────────────────────┼──────────────────────┤ │ 信息密度 │ 3 行 │ 80-100 行 │ ├────────────┼──────────────────────┼──────────────────────┤ │ 效果 │ Claude 不断追问 │ Claude 上手就能干活 │ └────────────┴──────────────────────┴──────────────────────┘
DevPulse/ ├── CLAUDE.md ← 项目全局上下文 ├── src/ │ ├── components/ │ │ └── CLAUDE.md ← 组件开发规范 │ ├── app/api/ │ │ └── CLAUDE.md ← API 开发规范 │ └── lib/ │ └── CLAUDE.md ← 工具函数规范 └── tests/ └── CLAUDE.md ← 测试编写规范
加载时机：子目录的 CLAUDE.md 不是启动时就加载的，而是按需加载——当 Claude 读取或操作该目录下的文件时，才会自动读取对应的 CLAUDE.md。
这就是"渐进式披露"的具体应用：Claude 写组件的时候加载组件规范，写 API 的时候加载 API 规范，不用的时候不加载，节省宝贵的上下文窗口空间。
举个例子，src/components/CLAUDE.md 可以这么写：
# 组件开发规范
## 文件组织
- 每个组件一个文件，文件名与组件名一致（PascalCase）
- 复杂组件可以建子目录：ComponentName/index.tsx + 子组件
- 基础 UI 组件放 ui/，业务组件放 features/
## 组件结构顺序
1. 'use client'（如果需要）
2. import 语句
3. Props 接口定义
4. 组件函数
5. 辅助函数（组件外部）
## 样式规范
- 优先使用 Tailwind 工具类
- 超过 5 个类名时用 clsx/cn 函数合并
- 响应式断点：sm:640 md:768 lg:1024 xl:1280
- 暗色模式使用 dark: 前缀
## 性能注意事项
- 列表渲染必须有稳定的 key（不用 index）
- 大列表考虑虚拟滚动
- 图片使用 next/image 的 sizes 属性优化加载
而 src/app/api/CLAUDE.md 的内容完全不同：
# API Routes 开发规范
## 文件结构
- 每个路由放在对应目录下：api/posts/route.ts
- 使用 Route Handler 语法（export async function GET/POST/PUT/DELETE）
## 错误处理
- 所有路由必须有 try-catch 包裹
- 统一错误格式：{ error: string, code: string }
- 使用 NextResponse.json() 返回响应
- 4xx 错误返回用户友好的提示，5xx 记录日志但返回通用提示
## 数据校验
- 请求体用 zod schema 校验
- 校验失败返回 400 + 具体的字段错误信息
## 认证
- 需要认证的路由使用 getServerSession() 检查
- 未认证返回 401，无权限返回 403
两份规范，两个场景，各管各的，互不干扰。
2025 年底，Claude Code 上线了一个叫 Auto Memory（自动记忆） 的功能。它跟 CLAUDE.md 互补：
CLAUDE.md：你写给 Claude 的指令（"你必须遵守这些规范"） Auto Memory：Claude 自己记的笔记（"我发现这个项目有个坑……"） 自动记忆的存储位置：~/.claude/projects/<项目名>/memory/
目录结构：
~/.claude/projects/xxx/memory/
├── MEMORY.md ← 索引文件，启动时加载前 200 行
├── debugging.md ← Claude 记录的调试经验
├── patterns.md ← Claude 发现的代码模式
└── api-conventions.md ← Claude 总结的 API 约定
你可以主动告诉 Claude 记住某件事：
记住：这个项目的数据库连接偶尔会超时，
如果 Prisma 报连接错误，先检查 DATABASE_URL 是否正确，
再检查 PostgreSQL 服务是否在运行
Claude 会把这条信息写入它的 MEMORY.md 文件。下次遇到数据库报错，它会自动回忆起这条经验。
也可以用 /memory 命令直接编辑 MEMORY.md
Auto Memory 和 CLAUDE.md 的分工： ┌──────────────────────────────────────────────────────────┐ │ CLAUDE.md vs Auto Memory 分工 │ ├────────────────┬─────────────────────────────────────────┤ │ CLAUDE.md │ Auto Memory │ ├────────────────┼─────────────────────────────────────────┤ │ 你写的 │ Claude 自己写的 │ │ 指令和规范 │ 经验和发现 │ │ 提交到 Git │ 本地保存 │ │ 团队共享 │ 个人专属 │ │ 启动时全量加载 │ 启动时加载前 200 行 │ │ 你负责维护 │ Claude 自动维护 │ ├────────────────┼─────────────────────────────────────────┤ │ 该写什么： │ 该记什么： │ │ 技术栈、规范、 │ 调试经验、踩过的坑、 │ │ 命令、架构约束 │ 发现的项目特殊模式 │ └────────────────┴─────────────────────────────────────────┘
.claude/rules/ ├── typescript.md ← TypeScript 规范 ├── testing.md ← 测试规范 ├── api-design.md ← API 设计规范 └── git-workflow.md ← Git 工作流规范
每个规则文件可以通过 frontmatter 指定作用范围：
---
globs: ["src/**/*.tsx", "src/**/*.ts"]
---
# TypeScript 代码规范
- 禁止使用 any，使用 unknown 替代
- 函数返回值必须有显式类型标注
- ...
这份规则只在 Claude 操作匹配 src//*.tsx 或 src//*.ts 的文件时才会加载。
什么时候用 rules/ 而不是子目录 CLAUDE.md？
按文件类型区分规则 → 用 rules/（比如所有 .tsx 文件遵循同一套规范） 按目录/模块区分规则 → 用子目录 CLAUDE.md（比如 components/ 和 api/ 有不同规范） 两者可以混合使用。
刚开始 3 个命令就够了。但用着用着你会发现更多可以自动化的场景，命令慢慢变多。这时候需要一个清晰的组织结构。 ┌──────────────────────────────────────────────────────────┐ │ 推荐的命令目录结构 │ ├──────────────────────────────────────────────────────────┤ │ │ │ .claude/commands/ ← 项目级（提交到 Git） │ │ ├── review.md # 代码审查 │ │ ├── test.md # 生成测试 │ │ ├── doc.md # 生成文档 │ │ ├── commit.md # Git 提交 │ │ └── pr-review.md # PR 审查 │ │ │ │ ~/.claude/commands/ ← 个人级（所有项目通用） │ │ ├── explain.md # 解释代码逻辑 │ │ ├── refactor.md # 重构建议 │ │ └── perf.md # 性能分析 │ │ │ │ 分工原则： │ │ 项目级 = 跟项目绑定的命令（用这个项目的规范和工具） │ │ 个人级 = 通用命令（任何项目都能用） │ │ │ │ 数量原则： │ │ 3 个精心设计的核心命令 > 20 个随便写的命令 │ │ 只给真正高频的操作建命令 │ │ │ └──────────────────────────────────────────────────────────┘
命令做好了，还有一个影响效率和成本的关键因素——你用哪个模型来执行任务。
Claude Code 支持三个主力模型，各有各的长处： ┌──────────────────────────────────────────────────────────┐ │ 三大模型定位对比 │ ├──────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────────────────────────────┐ │ │ │ Opus 4.6（旗舰） │ │ │ │ 推理能力最强，适合复杂任务 │ │ │ │ Token 费用最高 │ │ │ │ 响应速度最慢 │ │ │ │ │ │ │ │ 适合：架构设计、复杂 Bug 调试、 │ │ │ │ 跨文件重构、技术方案评估 │ │ │ │ 不适合：简单格式化、写 commit message │ │ │ └─────────────────────────────────────────┘ │ │ ↑ 最强 │ │ │ │ │ ┌─────────────────────────────────────────┐ │ │ │ Sonnet 4.5（主力） 日常默认 │ │ │ │ 性能和速度的最佳平衡 │ │ │ │ 费用适中 │ │ │ │ 响应速度快 │ │ │ │ │ │ │ │ 适合：代码审查、功能实现、Bug 修复、 │ │ │ │ 测试编写、日常 90% 的任务 │ │ │ └─────────────────────────────────────────┘ │ │ │ │ │ ↓ 最快 │ │ ┌─────────────────────────────────────────┐ │ │ │ Haiku 4.5（轻量） │ │ │ │ 基础推理能力 │ │ │ │ 费用最低 │ │ │ │ 响应速度最快 │ │ │ │ │ │ │ │ 适合：生成 commit message、简单格式化、│ │ │ │ 文件重命名、写注释 │ │ │ │ 不适合：复杂代码逻辑、架构分析 │ │ │ └─────────────────────────────────────────┘ │ │ │ └──────────────────────────────────────────────────────────┘
用了大半年总结出来的经验： ┌────────────────────────────────────────────────────────┐ │ 模型选择速查表 │ ├───────────────────┬────────────────────────────────────┤ │ 任务类型 │ 推荐模型 │ ├───────────────────┼────────────────────────────────────┤ │ 日常编码、功能开发│ Sonnet（默认） │ │ 代码审查 │ Sonnet │ │ 测试编写 │ Sonnet │ │ Bug 修复 │ Sonnet，复杂问题切 Opus │ │ 架构设计/评审 │ Opus │ │ 复杂多文件重构 │ Opus │ │ 生成 commit msg │ Haiku │ │ 写注释/文档 │ Haiku 或 Sonnet │ │ 简单格式化 │ Haiku │ │ 解释代码逻辑 │ Sonnet │ │ 技术方案对比 │ Opus │ └───────────────────┴────────────────────────────────────┘
一句话总结： Sonnet 是你的日常主力（80% 的任务） Opus 是你的"大杀器"（复杂推理时启用） Haiku 是你的"跑腿小弟"（简单重复任务）
┌──────────────────────────────────────────────────────────┐ │ 内置命令速查（精选高频） │ ├──────────────┬───────────────────────────────────────────┤ │ 命令 │ 作用 │ ├──────────────┼───────────────────────────────────────────┤ │ /help │ 查看所有可用命令（含你的自定义命令） │ │ /model │ 切换 AI 模型 │ │ /compact │ 压缩当前对话历史，释放上下文空间 │ │ /clear │ 清空对话，从零开始 │ │ /init │ 自动分析项目并生成 CLAUDE.md │ │ /permissions │ 交互式管理权限规则 │ │ /memory │ 编辑 Auto Memory │ │ /config │ 打开设置面板 │ │ /context │ 查看当前加载的上下文（哪些文件被读了） │ │ /cost │ 查看本次会话的 Token 消耗和费用 │ │ /bug │ 向 Anthropic 报告 Bug │ └──────────────┴───────────────────────────────────────────┘
瓶颈一：上下文窗口是有限的。
打个比方：你的桌子就这么大（上下文窗口就这么多 Token）。你让 Claude 同时看 20 个文件、记住你的编码规范、理解项目架构、还要分析性能问题——桌子上堆满了纸，它开始翻不过来了。分析质量肉眼可见地下降。
瓶颈二：不同任务需要不同的"专业视角"。
代码审查要关注的点和安全审计要关注的点完全不同。让一个 Agent 同时扮演审查专家和安全专家，就像让一个医生同时做心脏手术和脑科手术——不是做不到，是做不好。
瓶颈三：串行处理，效率有上限。
主 Agent 处理任务是排队的——先做 A、再做 B、再做 C。但很多任务其实可以并行——审查代码和写测试完全可以同时进行。
子代理系统解决了这三个问题： ┌────────────────────────────────────────────────────────────┐ │ 子代理解决的三个核心问题 │ ├────────────────────────────────────────────────────────────┤ │ │ │ 问题 子代理的解决方案 │ │ ───────────────────────────────────────── │ │ 上下文窗口不够用 每个子代理有独立的上下文窗口 │ │ → 互不干扰，各自深度分析 │ │ │ │ 缺少专业分工 每个子代理有专属系统提示 │ │ → 代码专家只管代码，安全专家只管安全│ │ │ │ 串行效率低 最多 7 个子代理并行工作 │ │ → 三份报告同时出，时间不变 │ │ │ └────────────────────────────────────────────────────────────┘
在动手之前，先花一分钟理解子代理是怎么运行的：
┌──────────────────────────────────────────────────────────────┐ │ 子代理运行流程 │ ├──────────────────────────────────────────────────────────────┤ │ │ │ 你: "审查 @src/app/api/ 下的所有 API 路由" │ │ ↓ │ │ ┌──────────────────────────────────────┐ │ │ │ 主 Agent（调度中心） │ │ │ │ 分析任务 → 选择合适的子代理 │ │ │ │ 或者：你手动指定用哪个子代理 │ │ │ └──────┬──────────┬──────────┬─────────┘ │ │ ↓ ↓ ↓ │ │ ┌──────────┐┌──────────┐┌──────────┐ │ │ │code ││test ││security │ │ │ │reviewer ││writer ││auditor │ │ │ │ ││ ││ │ │ │ │独立上下文││独立上下文││独立上下文│ │ │ │独立权限 ││独立权限 ││独立权限 │ │ │ │专属提示词││专属提示词││专属提示词│ │ │ └──────┬───┘└──────┬───┘└──────┬───┘ │ │ ↓ ↓ ↓ │ │ ┌──────────────────────────────────────┐ │ │ │ 主 Agent（汇总结果） │ │ │ │ 整合三份报告 → 呈现给你 │ │ │ └──────────────────────────────────────┘ │ │ │ │ 关键特性： │ │ • 每个子代理有自己的上下文窗口（最大 200K） │ │ • 子代理只接收自己的系统提示，不会继承主 Agent 的全部上下文 │ │ • 最多 7 个子代理同时并行 │ │ • 子代理完成后返回摘要给主 Agent │ │ │ └──────────────────────────────────────────────────────────────┘
Claude Code 目前支持 14 个生命周期事件。日常最常用的是这几个： ┌────────────────────────────────────────────────────────────┐ │ Hooks 生命周期（精选高频事件） │ ├────────────────────────────────────────────────────────────┤ │ │ │ SessionStart │ │ → 会话启动时触发 │ │ → 适合：加载环境变量、注入开发上下文 │ │ ↓ │ │ UserPromptSubmit │ │ → 用户提交提示词时触发 │ │ → 适合：校验输入、注入额外上下文 │ │ ↓ │ │ PreToolUse │ │ → Claude 准备执行操作前触发 │ │ → 适合：拦截危险命令、修改操作参数 │ │ → matcher 过滤：Bash / Edit / Write / Read 等 │ │ ↓ │ │ [Claude 执行操作] │ │ ↓ │ │ PostToolUse │ │ → 操作完成后触发 │ │ → 适合：自动格式化、运行 lint、记录日志 │ │ → matcher 过滤：同上 │ │ ↓ │ │ Stop │ │ → Claude 完成回答时触发 │ │ → 适合：收尾操作、发送通知 │ │ │ │ 其他事件： │ │ PermissionRequest — 权限弹窗时触发（可自动放行/拦截） │ │ SubagentStop — 子代理完成时触发 │ │ PostToolUseFailure — 工具执行失败时触发 │ │ Notification — 通知事件（适合发桌面提醒） │ │ │ └────────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────────┐ │ 三种 Hook 处理器 │ ├────────────┬──────────────────┬────────────────────────────┤ │ 类型 │ 工作方式 │ 适合场景 │ ├────────────┼──────────────────┼────────────────────────────┤ │ command │ 执行 bash 命令 │ 确定性操作：格式化、lint、 │ │ │ （最常用） │ 日志记录、文件校验 │ ├────────────┼──────────────────┼────────────────────────────┤ │ prompt │ 调用 LLM 评估 │ 需要智能判断：代码质量评 │ │ │ │ 安全风险分析 │ ├────────────┼──────────────────┼────────────────────────────┤ │ agent │ 启动子代理处理 │ 复杂任务：全面审查、 │ │ │ │ 多维度分析 │ └────────────┴──────────────────┴────────────────────────────┘
┌───────────────────────────────────────────────────────────┐ │ Claude Code 扩展体系总览 │ ├───────────────────────────────────────────────────────────┤ │ │ │ ┌──────────┐ ┌───────────┐ ┌─────────┐ ┌──────────┐ │ │ │ Commands │ │ Agents │ │ Skills │ │ Hooks │ │ │ │ 快捷命令 │ │ 子代理 │ │ 技能包 │ │ 自动触发 │ │ │ │ 你主动调 │ │ 专家分工 │ │ 自动匹配│ │ 确定性 │ │ │ │ 用 │ │ 独立上下文│ │ 渐进加载│ │ 执行 │ │ │ └────┬─────┘ └────┬──────┘ └────┬────┘ └────┬─────┘ │ │ │ │ │ │ │ │ └──────┬──────┴──────┬───────┘ │ │ │ ↓ ↓ │ │ │ ┌──────────────────────────┐ │ │ │ │ MCP Servers │ │ │ │ │ 外部工具连接（GitHub、│ │ │ │ │ 数据库、文档查询等） │ │ │ │ └──────────────────────────┘ │ │ │ │ │ │ ┌─────────────────────────────────────────┘ │ │ ↓ │ │ ┌──────────────────────────────────────────────┐ │ │ │ Plugin（打包分发） │ │ │ │ = Commands + Agents + Skills + Hooks + MCP │ │ │ │ 一键安装，团队统一 │ │ │ └──────────────────────────────────────────────┘ │ │ │ │ 选择指南： │ │ "我要重复执行某个操作" → Command │ │ "我要专业分工和并行" → Agent │ │ "我要自动加载知识" → Skill │ │ "我要在每一步自动执行" → Hook │ │ "我要连接外部工具" → MCP │ │ "我要打包分发给团队" → Plugin │ │ │ └───────────────────────────────────────────────────────────┘