很多人卡在这一步

我发现一个有意思的现象：

网上讲 Claude Code 配置的文章越来越多，什么 CLAUDE.md、rules、commands、hooks，讲得头头是道。

但真正动手的时候，很多人懵了：

"配置文件我都写好了，然后呢？"

这篇文章就解决这一个问题：配置体系搭好之后，日常开发到底怎么配合 Claude Code 工作。

---

先搞清楚一件事：配置是怎么生效的

很多人以为配置文件写完就万事大吉了，Claude 会自动"学会"。

不完全对。

你需要理解 Claude Code 的加载机制：

启动时自动加载的：

• CLAUDE.md（项目根目录）
• .claude/rules/ 下的所有规则文件
• .claude/settings.json 里的配置
• hooks.json 里定义的钩子

需要主动调用的：

• .claude/commands/ 里的命令（用 /命令名 触发）
• .claude/agents/ 里的专用代理（用 @代理名 调用）
• .claude/skills/ 里的方法论（在命令或代理里引用）

换句话说：rules 是自动生效的底线，commands 和 agents 是你主动使用的工具。

---

启动：从打开终端开始

第一步：进入项目目录

cd your-project

第二步：启动 Claude Code

claude

就这么简单。

Claude Code 启动后会自动扫描当前目录，读取所有配置文件。你会看到它加载了哪些 rules、识别了什么技术栈。

小技巧： 第一次启动时，可以问一句：

你了解这个项目吗？简单介绍一下

如果它能准确说出项目的技术栈、目录结构、构建命令，说明 CLAUDE.md 写得到位。如果它说得模模糊糊，回去改 CLAUDE.md。

---

日常开发：五个最常见的场景

场景一：接到新需求

错误做法：

帮我实现用户注册功能，要支持手机号验证码登录

直接开干，Claude 可能理解偏差，改一堆文件，最后发现方向错了，返工。

正确做法：

/plan 实现用户注册功能，支持手机号验证码登录

/plan 命令会强制 Claude 先做这几件事：

1. 复述需求 —— 确认它理解对了
2. 列出改动范围 —— 会动哪些文件
3. 识别风险点 —— 可能踩什么坑
4. 给出验收标准 —— 怎么算做完了

你看完确认没问题，再说：

确认，开始实现

这时候它才真正动手写代码。

为什么这样更好？

因为"规划"的成本远低于"返工"。花 2 分钟确认方向，省下 2 小时重写。

---

场景二：代码写完，要 Review

传统做法： 自己肉眼看，或者等同事有空。

Claude Code 做法：

/review src/services/userService.ts

Claude 会按照你在 commands/review.md 里定义的维度来审查。

一个典型的 review 命令配置长这样：

# /review 命令

审查代码时，按以下维度逐项检查：

## 安全性
- 是否有硬编码的密钥或敏感信息
- 用户输入是否做了校验
- 是否有 SQL 注入或 XSS 风险

## 健壮性
- 边界条件是否处理
- 错误处理是否完善
- 是否有潜在的空指针

## 可维护性
- 命名是否清晰
- 函数是否过长
- 是否有重复代码

## 性能
- 是否有不必要的循环
- 数据库查询是否合理
- 是否有内存泄漏风险

输出格式：按维度列出问题，标注严重程度（严重 中等 建议）

这样每次 review 的维度都是一致的，不会因为心情好就放水，心情差就挑刺。

---

场景三：构建失败，一堆报错

最烦的情况： CI 挂了，一屏幕红字，不知道从哪看起。

Claude Code 做法：

直接把报错贴进去：

构建失败了，报错如下：

[粘贴报错信息]

帮我分析原因并修复

或者如果你配置了 /fix-build 命令：

/fix-build

Claude 会：

1. 分析报错的根本原因
2. 按照 rules 里的约束来修复（不会乱改代码风格）
3. 告诉你改了什么、为什么这样改

进阶技巧： 如果是复杂的构建问题，可以调用专用 agent：

@debugger 分析这个构建错误

debugger agent 会用更系统的方式排查，不只是头痛医头。

---

场景四：重构一段祖传代码

重构是最容易出事的操作。改着改着，功能就坏了。

安全的做法：

/plan 重构 src/utils/legacy.js，目标是：
1. 拆分成多个小函数
2. 添加 TypeScript 类型
3. 保持所有现有功能不变

Claude 会输出详细的重构计划，包括：

• 每个函数的拆分方案
• 类型定义的设计
• 需要补充的测试用例
• 分几步完成，每步怎么验证

你确认后，它会分步骤执行，每一步都可以验证功能是否正常。

关键点： 重构时一定要配合测试。如果原来没有测试，先让 Claude 补测试：

先给 legacy.js 的核心功能写单元测试，确保重构后能验证功能不变

---

场景五：上线前的安全检查

上线前最怕什么？漏了安全问题，被人搞了。

Claude Code 做法：

@security-auditor 检查这个 PR 的所有改动，重点关注：
1. 认证授权相关的代码
2. 用户输入处理
3. 敏感信息暴露

security-auditor 是一个专用 agent，它的 prompt 会让 Claude 用"安全专家"的视角来审查代码，比普通对话更专注、更系统。

一个典型的 security-auditor.md 长这样：

# Security Auditor Agent

你是一个专注于安全审计的专家。审查代码时，始终从"攻击者视角"思考。

## 检查清单

### 认证授权
- 是否有未授权访问的端点
- Token 验证是否完整
- 权限检查是否到位

### 输入处理
- 所有外部输入是否校验
- 是否有注入风险（SQL、命令、XSS）
- 文件上传是否安全

### 敏感信息
- 日志是否泄露敏感数据
- 错误信息是否暴露内部细节
- 配置文件是否有硬编码密钥

### 依赖安全
- 是否有已知漏洞的依赖
- 依赖版本是否锁定

输出格式：按风险等级排序，给出修复建议

---

Hooks：你不需要做任何事，它自动生效

前面讲的 commands 和 agents 都需要你主动调用。

Hooks 不一样，它是自动触发的。

典型场景 1：跑长命令时自动提醒

你让 Claude 执行 npm test，hook 自动弹出提示：

⏱ 这个命令可能需要一段时间，建议在 tmux 里运行，避免会话断开丢失输出

典型场景 2：编辑代码后自动格式化

Claude 改完一个 .ts 文件，hook 自动执行：

npx prettier --write [文件路径]
npx tsc --noEmit

你不需要手动跑格式化，也不用担心忘记检查类型错误。

典型场景 3：危险操作前自动拦截

Claude 要执行 git push origin main，hook 拦住：

 你确定要推送到 main 分支吗？
- 测试跑过了吗？
- Code review 做了吗？
输入 "确认" 继续，或 "取消" 停止

Hooks 的本质：把团队的"血泪教训"变成自动化护栏。

那些"大家都知道应该做，但经常忘记"的事情，交给 hooks 来保证。

---

一个完整的开发流程示例

假设你接到一个需求：给用户中心添加"修改密码"功能。

Step 1：规划

/plan 用户中心添加修改密码功能
要求：
1. 需要验证旧密码
2. 新密码要符合强度要求
3. 修改成功后所有设备下线

Claude 输出计划，你确认。

Step 2：实现

确认，开始实现

Claude 按计划写代码。hooks 自动格式化、检查类型。

Step 3：自审

/review src/services/passwordService.ts
/review src/controllers/userController.ts

根据 review 结果修复问题。

Step 4：安全检查

@security-auditor 检查密码修改功能的安全性

重点关注密码存储、传输、验证逻辑。

Step 5：补充测试

给修改密码功能补充单元测试，覆盖：
1. 旧密码错误
2. 新密码强度不够
3. 正常修改成功
4. 修改后 token 失效

Step 6：提交

帮我写 commit message

Claude 按照 rules 里定义的 commit 规范生成 message。

执行 git push 时，hook 自动提醒确认。

---

常见问题

Q：命令不生效怎么办？

检查几个点：

1. 命令文件是否放在 .claude/commands/ 目录下
2. 文件名是否正确（比如 plan.md 对应 /plan 命令）
3. 重启 Claude Code 再试

Q：Rules 好像没起作用？

Rules 是"约束"，不是"指令"。它告诉 Claude "不能做什么"，而不是"必须做什么"。

如果你想让某个动作"必须发生"，应该用 hooks，不是 rules。

Q：Agent 和普通对话有什么区别？

Agent 有独立的 system prompt，会让 Claude 进入特定的"角色"和"视角"。

普通对话是通用模式，agent 是专家模式。

Q：配置太多会不会拖慢速度？

会有一点影响，但通常可以忽略。

如果你发现明显变慢，检查一下是不是 rules 文件写得太长太杂。rules 应该短而硬，不是长篇大论。

---

最后

配置体系是"基建"，日常使用才是"生产"。

基建做得再好，不会用也是白搭。

记住这个核心流程：

新需求 → /plan → 确认 → 实现 → /review → 修复 → 提交

把这个流程跑顺了，你会发现 Claude Code 不再是"聊天机器人"，而是真正的"AI 结对编程伙伴"。

从今天开始，试着用 /plan 开始你的下一个任务。
 

Claude Code 团队落地指南：从“个人神器“到“团队基建“的完整方法论