这个领域将"使用 Claude Code 的人"和"为团队配置 Claude Code 的人"区分开来。它是配置最密集的领域。你要么知道文件放在哪里、选项是什么，要么不知道。
01 CLAUDE.md 层级
三个级别，各有不同的作用域和可见性：
| 级别 | 位置 | 适用于 | 版本控制 | 团队共享 |
|---|---|---|---|---|
| 用户级 | ~/.claude/CLAUDE.md | 仅限你自己 | 否 | 否 |
| 项目级 | .claude/CLAUDE.md 或根目录 CLAUDE.md | 项目中的所有人 | 是 | 是 |
| 目录级 | 子目录 CLAUDE.md 文件 | 该目录中的文件 | 是 | 是 |
考试最爱出的陷阱
新团队成员没有收到指令。开发者 A 的 Claude Code 完美遵循 API 命名规范。上周刚加入的开发者 B 从 Claude Code 获得的命名不一致。
根本原因： 指令在开发者 A 的用户级配置（~/.claude/CLAUDE.md）中，而非项目级配置。用户级配置不进行版本控制，不通过 git 共享。新团队成员克隆仓库时不会获得这些指令。
修复： 将团队标准移至项目级配置（.claude/CLAUDE.md）。
模块化组织
@import语法 从 CLAUDE.md 引用外部文件（按包导入相关标准）.claude/rules/目录 用于主题特定的规则文件（testing.md、api-conventions.md、deployment.md），替代一个巨大的单一文件
使用 /memory 命令验证加载了哪些记忆文件。这是诊断跨会话行为不一致的调试工具。
02 自定义斜杠命令与技能
目录结构
| 位置 | 作用域 | 共享 |
|---|---|---|
.claude/commands/ | 项目级 | 是（版本控制） |
~/.claude/commands/ | 个人 | 否 |
.claude/skills/ 包含 SKILL.md 文件 | 按需调用 | 是 |
技能前置元数据选项
---
context: fork # 在隔离的子智能体上下文中运行
allowed-tools: # 限制可用工具
- Read
- Grep
argument-hint: "请提供要审查的文件路径"
---context: fork— 在隔离的子智能体上下文中运行。冗长输出被限制在内部。主对话保持干净。用于代码库分析、头脑风暴等产生大量输出的任务。allowed-tools— 防止技能执行期间的破坏性操作。argument-hint— 在无参数调用时提示开发者输入必需参数。
关键区分
| 类型 | 用途 | 加载时机 |
|---|---|---|
| 技能 | 按需的、任务特定的工作流 | 需要时调用 |
| CLAUDE.md | 始终加载的通用标准 | 自动应用 |
不要将任务特定的流程放在 CLAUDE.md 中。不要将通用标准放在技能中。
个人技能自定义
在 ~/.claude/skills/ 中使用不同名称创建个人变体。避免影响团队成员的同时允许个人工作流自定义。
03 路径特定规则
.claude/rules/ 目录支持带 YAML 前置元数据的文件：
---
paths: ["**/*.test.tsx"]
---
所有测试文件必须使用 `describe/it` 模式。
Mock 外部服务，永远不要 mock 数据库。
每个测试文件必须至少包含一个集成测试。规则仅在编辑匹配 glob 模式的文件时加载。
为什么这比目录级 CLAUDE.md 更好
| 特性 | 路径特定规则 | 目录级 CLAUDE.md |
|---|---|---|
| 模式匹配 | Glob 模式覆盖 整个 代码库 | 仅该目录中的文件 |
| 50+ 目录的测试规范 | 单个规则文件 **/*.test.tsx | 需要在每个目录放 CLAUDE.md |
| Token 效率 | 仅在编辑匹配文件时加载 | 在该目录中始终加载 |
练习场景
代码库在 50+ 个目录中有与源文件共存的测试文件。团队希望所有测试遵循相同规范。答案： 使用 glob 模式的路径特定规则。不是每个目录放 CLAUDE.md。不是单个根 CLAUDE.md（在非测试文件上浪费 token）。不是技能（通用标准用错了机制）。
04 计划模式 vs 直接执行
决策框架
使用计划模式：
- 涉及大规模变更的复杂任务
- 存在多种有效方法
- 需要架构决策
- 多文件修改（如跨 45+ 文件的库迁移）
- 需要先探索再修改
使用直接执行：
- 范围明确、理解充分的变更
- 有明确堆栈跟踪的单文件 Bug 修复
- 添加日期验证条件
- 正确方法已知
Explore 子智能体
将冗长的发现输出与主对话隔离。返回摘要以保留主对话上下文。在多阶段任务中使用，防止上下文窗口耗尽。
组合模式
- 计划模式 用于调查和设计
- 直接执行 用于实施已规划的方案
这种混合模式在实践中很常见，也是考试测试的内容。
练习场景
对每个任务进行分类：
| 任务 | 模式 | 原因 |
|---|---|---|
| 将单体架构重构为微服务 | 计划模式 | 复杂，多种有效方案 |
| 修复单个函数中的空指针异常 | 直接执行 | 范围明确，方法已知 |
| 跨 30 个文件迁移日志库 | 计划模式 | 多文件，需先评估影响 |
05 迭代优化
技术层级（按效果排序）
- 具体的输入/输出示例（2-3 个展示前后对比）— 每次都胜过文字描述
- 测试驱动迭代 — 先写测试，分享失败结果以引导改进
- 访谈模式 — 让 Claude 在实现前先提问（在不熟悉的领域中浮现你可能遗漏的考量）
批量 vs 顺序反馈
| 方式 | 适用场景 |
|---|---|
| 单条消息（批量） | 修复之间相互影响 — 改一个会影响其他 |
| 顺序迭代 | 问题相互独立 — 修一个不影响其他 |
练习场景
开发者用文字描述代码转换。Claude Code 每次的理解都不一样。修复： 切换到具体的输入/输出示例。展示 2-3 个预期转换的示例。模型从示例中泛化比从描述中泛化更可靠。
06 CI/CD 集成
-p 标志
以 非交互模式（打印模式）运行 Claude Code。没有它，CI 作业会挂起等待交互输入。
# 错误 — 无限期挂起
claude "分析这个 PR"
# 正确 — 非交互式运行
claude -p "分析这个 PR"这在考试中直接被测试。务必记住。
结构化 CI 输出
claude -p --output-format json --json-schema schema.json "审查这个 PR"生成机器可解析的结构化发现。自动化系统可将发现作为行内 PR 评论发布。
会话上下文隔离
生成代码的同一个 Claude 会话审查自己的变更时 效果更差。它保留了推理上下文，使其不太可能质疑自己的决策。使用独立的审查实例进行代码审查。
增量审查上下文
重新运行审查时：
- 在上下文中包含先前的审查发现
- 指示 Claude 仅报告新的或仍未解决的问题
- 防止重复评论侵蚀开发者信任
CI 中的 CLAUDE.md
记录测试标准、有价值的测试标准和可用的 fixture。CI 调用的 Claude Code 使用这些来生成高质量测试。没有它，测试生成会产出低价值的模板代码。
07 动手构建
搭建一个项目：
- CLAUDE.md 层级（项目级 + 目录级）
.claude/rules/包含测试文件和 API 文件的 glob 模式- 一个使用
context: fork的自定义技能 .mcp.json中配置 MCP 服务器，使用环境变量扩展- 使用
-p标志和 JSON 输出的 CI 脚本
在多文件重构上测试计划模式，在单个 Bug 修复上测试直接执行。体验二者的差异。