前言:AI浪潮下,大家一定用过Claude Code吧,在我看来,Claude Code不仅是一个"会写点代码的聊天机器人",更是一个结对编程伙伴。用得好,它能显著提升个人效率,也能在团队里形成统一的工程规范。接下来,本文将介绍我在项目中关于Claude Code的使用技巧。
一、先统一一个心智:把 Claude Code 当"快速实习生"
1. 不要把 Claude 当"答案机"
更好的定位是:一个非常能干、记忆力变态好、但需要你给清晰任务的实习生。
这会直接影响你怎么写指令、怎么验收结果:
- 不指望"随便一问就给完美答案"
- 而是像带实习生一样:给目标、给边界、给上下文,让它帮你干具体活
2. 你负责"要什么",它负责"怎么做"
- 你负责 :
- 业务目标(要实现什么功能/解决什么问题)
- 约束条件(架构分层、不跨层调用、安全要求等)
- 风格与规范(命名规则、日志规范、DTO 字段类型等)
- 它负责 :
- 找文件、读代码、分析依赖
- 设计实现方案(plan 模式下给出计划)
- 修改代码、跑测试、写提交信息草稿
3. 一定要配合 Git 使用
- 大改动前 :先自己
git commit一次,保证有可回滚的基线 - Claude 改完一轮 :自己再用
git diff快速扫一遍 - 不满意的改动 :直接
git checkout回滚这次修改,然后重写更清晰的指令让它再来
二、三步完成"从 0 到能干活"的配置
1. 安装 + 验证:两个关键点
强调两个别踩坑的地方:
- Node 版本必须 ≥ 18
bash
node --version # 确认版本号,推荐 18+ 或 20+
- 安装完成要立刻自检
bash
npm install -g @anthropic-ai/claude-code
claude --version
claude --help
如果你还使用 Claude Code Router(CCR),也记得安装并登录:
bash
npm install -g @musistudio/claude-code-router@1.0.33
ccr --version
ccr login
2. 首次认证:记得先"科学地球"
然后在项目根目录:
bash
cd your-project-directory
claude
按提示完成浏览器 OAuth 认证即可。
3. 必做的项目初始化:/init + CLAUDE.md
在每个项目第一次使用 Claude Code 时,建议由一个人执行:
bash
cd your-project-directory
claude
/init
这将自动:
- 生成项目级
CLAUDE.md文件:- 项目概述(技术栈、架构、分层等)
- 代码风格约定(lint、格式化、命名习惯等)
- 测试策略与覆盖率目标
- 部署流程与分支策略
- 创建
.claude/目录:- 用来保存项目自定义命令和配置
之后所有人在这个仓库里启动 Claude Code,都会自动读取并遵守这些规则。
三、日常使用的"高性价比组合拳"
1. 优先使用 plan 模式:先看计划再执行
Claude Code 提供三种工作模式:
- default:默认模式,每次操作前都要你确认
- plan :先生成一份计划,再由你确认哪些步骤执行(强烈推荐)
- acceptEdits:自动接受编辑,适用于非常熟悉的项目 + 小范围改动
实用启动方式:
bash
# 在项目中启动,并默认使用 plan 模式
claude --permission-mode plan
# 继续上次会话
claude --permission-mode plan --continue
使用建议:
- 复杂改动、跨多文件/多模块的任务,一律用 plan 模式
- 你重点做一件事:审核这份计划是否与你"心里那版"一致,不对就在计划阶段要求它调整
2. 熟悉后再启用 bypass 模式提速
对十分熟悉的项目,可以大胆启用"跳过权限确认"的模式:
bash
claude --dangerously-skip-permissions --permission-mode plan --continue
适用场景:
- 批量重构同类代码(批量修改接口签名、DTO 字段等)
- 自动生成大量重复模式的样板代码
前提:
- 一定要有 Git 做兜底,保持工作区变更可控
- 对项目结构和影响范围足够熟悉
3. 会管理"上下文",Claude 才能一直清醒
长对话中,Claude 像人类一样,会被大量历史消息"拖累",导致回答开始跑偏。文档里两个命令非常关键:
text
/clear # 完全清空当前会话上下文
/compact # 压缩上下文,只保留关键信息
经验法则:
- 从"开发功能"切换到"排查 bug",建议先
/clear - 同一任务聊了很久,回答开始飘,就
/compact一下 - 当你自己需要往上翻很多页才能想起上下文时,就该用
/compact或/clear了
4. 会写指令,比会写代码还重要
糟糕的指令:
text
修复这个 bug
高质量的指令:
text
分析登录组件中的错误处理逻辑,修复用户输入无效凭据时没有显示错误消息的问题。请确保:
1. 错误消息对用户友好(不暴露技术细节)
2. 不暴露敏感信息(不要区分是用户名错还是密码错)
3. 在后端增加合适的日志记录,方便后续排查
4. 使用项目现有的日志工具类,不要新引入第三方库
和 AI 合作,一个简单原则:越"啰嗦"越高效。
5. 善用 @ 引用,让 Claude 精准看对地方
在 Claude Code 中,@ 是你的"激光笔",用来精确指定要看的文件或资源:
text
@src/modules/user/UserService.ts
@frontend/src/pages/LoginPage.tsx
@logs/auth-error-2025-08-01.log
@docs/sequence-diagram.png
典型用法:
- 查 bug :
请分析 @auth-error-2025-08-01.log 中的错误,并结合 @UserService.ts 找出根因并给出修复方案 - 做重构 :
请重构 @UserForm.tsx,将其拆分为更小的组件,保持对外 props 接口不变
这样 Claude 不需要在整个仓库"乱跑",可以快速聚焦到你真正关心的地方。
6. 模型切换策略:日常 Sonnet,大活儿 Opus
在会话中随时切换模型:
text
/model # 查看当前和可用模型
/model opus # 切到 Opus(复杂架构、深度分析)
/model sonnet # 切回 Sonnet(日常开发使用)
启动时指定模型:
bash
claude --model opus
简单策略:
- 日常开发、单文件改动、小功能实现 → Sonnet
- 复杂架构讨论、跨模块重构、性能优化专项 → Opus
四、把项目规则"喂进" CLAUDE.md,形成团队统一习惯
项目根目录下的 CLAUDE.md,是整个团队与 Claude 协作的"宪法"。你已经在其中写明了很多关键规则,可以这样利用。
1. 语言与文档规范要写在最前
典型约定:
- 所有对话和文档都使用中文
- 文档统一使用 markdown 格式
效果是:任何人在该仓库中启动 Claude Code,默认为中文输出,并以 Markdown 组织内容。
2. 把"工程约束"写死在 CLAUDE.md
例如:
- Service 类不单独建接口(除非架构文档另有要求)
- 少量代码不建议过度拆成私有方法
- 除
File操作外,通常不需要手写try { ... } catch { ... } - DTO 中的长数值类型字段(如登记序号、纳税人序号、应征凭证序号)使用
String
对 Claude 下指令时,直接引用这些规则:
text
按照本项目 CLAUDE.md 中的规范:
1. 本次新增的 Service 直接使用类实现,不再单独定义接口
2. 所有新增 DTO 中涉及xxx等长整型编号字段,统一使用 String 类型
3. 除 File 相关操作外,不需要显式 try/catch
请在工xxxx模块中,新增一个查询接口实现,并补齐必要的 DTO 与单元测试。
Claude 会自动对齐这些约定,减少偏差和返工。
3. 分层架构与技术规范:用规则"防跑偏"
CLAUDE.md 中已经指定了多个规范文件:
architecture.mdc:分层架构、调用关系、职责分工channel.mdc:项目规范app.mdc:APP 工程规范spec.mdc等:特定工程规范dcommon.mdc:通用能力、缓存规范
在给 Claude 指任务时,可以明确要求:
- 架构边界 :
必须严格遵守 architecture.mdc 的分层规范,禁止跨层调用 - 缓存 :
所有缓存使用应遵守 ehcache.mdc,不缓存个人和单位敏感数据 - 数据库访问 :
涉及原生 SQL 的部分统一通过xxxx执行 - 通用组件 :
优先使用 common.mdc 中已有的工具类、常量、枚举和 DTO
这样一来,Claude 生成的代码天然就会"长得像团队原有代码"。
五、用 MCP 把 Claude 变成"多功能瑞士军刀"
1. 本地文件系统(强烈推荐)
bash
claude mcp add filesystem -s user -- npx -y @modelcontextprotocol/server-filesystem ~/Documents ~/Projects ~/Desktop
作用:
- 让 Claude 直接访问这些目录下的文件
- 可以自己打开文件、修改、保存,而不需要你手动复制粘贴代码
2. GitHub 集成(有云仓库就装)
bash
claude mcp add github -s user -e GITHUB_TOKEN=your-token -- npx -y @modelcontextprotocol/server-github
典型用途:
- 让 Claude 帮你分析 PR、生成 review 意见
- 自动关联 issue 与对应代码位置
- 批量梳理仓库中某类代码异味
3. 浏览器、数据库、Fetch 等按需开启
- Puppeteer:自动化网页操作、UI 测试、简单爬虫
- Postgres:直接连接数据库查询分析
- Fetch 工具:让 Claude 代表你去调各种 REST API
建议做法:遇到实际需求再添加,并在项目 CLAUDE.md 中记录:
- MCP 服务器名称
- 使用场景(测试环境/预发/生产只读等)
- 安全注意事项
4. 作用域选择:local / user / project 怎么选?
- local :仅当前项目目录可用
→ 适合项目私有的 MCP 配置 - user :当前用户所有项目可用
→ 适合个人常用工具(文件系统、时间、搜索引擎等) - project :写入
.mcp.json,整个团队共享
→ 适合团队统一使用的 MCP 服务器(如统一的内部服务、日志平台等)
可以记一句话:团队工具用 project,个人习惯用 user,特殊项目用 local。
六、常见坑
1. 安装与权限相关问题
- Node 版本不对 → 先
node --version检查 - 全局安装权限不足 → 给 npm 设置用户目录前缀,而不是一味
sudo:
bash
npm config set prefix ~/.npm-global
echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.bashrc
source ~/.bashrc
2. MCP 名称与路径问题
- 报错中提到
tools.custom.name pattern→ MCP 名称中不要包含空格和特殊符号,只用字母数字和_、- - Windows 路径报错 → 使用
/或\\,避免混用C:\Users\...这种形式
3. Claude 回答开始"胡说八道"
- 立刻
/clear或/compact清理上下文 - 把关键代码、日志文件用
@引用清楚 - 用一段简明扼要的新指令重新描述问题和目标
4. 会话成本与性能问题
- 使用
/cost查看当前会话耗费:
text
/cost
- 避免长时间在同一会话里堆叠无关话题
- 使用
/clear//compact减少上下文长度 - 大文件分析时,尽量只引用必要片段或具体文件,而不是"看整个仓库"
七、团队协作视角:让整个项目都"会用 Claude"
1. 统一 /init,让 Claude 读同一本"项目说明书"
团队约定:
- 新项目创建后,指定负责人执行一次
/init - 完整检查自动生成的
CLAUDE.md,补充:- 项目背景与业务概述
- 技术栈与分层架构说明
- 与现有
architecture.mdc、channel.mdc等文档的关系 - 项目特有的命名规则、日志规范、异常处理策略
- 提交
CLAUDE.md和.claude/目录到版本库
所有人之后在该项目中使用 Claude Code 时,都在同一套规则下协同。
2. 用自定义命令固化团队工作流
在 .claude/commands 中编写团队统一的工作流,例如 feature-workflow.md:
markdown
# 新功能开发工作流(团队统一用法)
请严格按照以下步骤执行:
1. 基于当前分支,创建一个新的特性分支,命名规则:feature-<模块拼音首字母>-<简短描述>
示例:feature-search
2. 通读与本需求相关的 @业务文档 和 @需求文档(如存在)
3. 使用 /overview 和 /tree 快速了解相关模块结构
4. 先编写或完善测试用例(单元测试/集成测试),采用 TDD 流程
5. 按照 CLAUDE.md 中的分层规范设计改动,避免跨层调用
6. 所有 DTO 中可能为长整型的编号字段一律使用 String 表示
7. 实现完成后运行项目约定的测试命令(如 npm test / mvn test 等)
8. 测试通过后生成一次提交,提交信息遵循团队约定格式
9. 在必要时更新相关文档(README、API 文档等)
之后只要在会话中输入:
text
/feature-workflow
就能让 Claude 自动按这套流程来指导开发。
3. 利用项目 ID 信息,让 Claude 更懂业务模块
如果已经在规则中明确了各中心的项目 ID,可以在 CLAUDE.md 中补充说明,并在指令中明确目标模块:
text
本次改动仅针对xxxx中心(项目ID 1234),请:
1. 在现有架构下实现 XX 功能,不与其他中心逻辑耦合
2. 严格遵守 architecture.mdc 的分层规范
3. DTO 中新增的长整型编号字段一律使用 String
4. 结合 common.mdc 中已有 DTO 和工具类,避免重复造轮子
这样 Claude 会自然以"模块"为单位来考虑影响范围。
八、调试 & 故障排查:把 Claude 当"日志分析助手"
1. 标准化 bug 排查流程模版
可以将下面这段写成命令 /debug-bug,或在需要时直接粘贴使用:
text
我有一个 bug 需要排查,请按以下步骤进行:
1. 先通读 @错误日志 文件,概括异常信息和出现频次
2. 结合 @相关代码文件,列出 2~3 个可能的原因假设
3. 为每个假设设计一个最小验证步骤(如增加日志、构造特定输入、增加断言等)
4. 按优先级逐一验证,并在需要额外信息时明确告诉我
5. 在确认原因后,给出最小修复方案,并说明可能影响的上下游模块
6. 帮我生成一段简要的 bug 修复说明,便于记录在提交信息或缺陷单中
这样每次调试都能保持相对固定的"套路"。
2. 巧用 /mcp + 文件系统 / 日志服务器
执行:
text
/mcp
可以看到当前已配置的 MCP 服务器。如果你挂载了日志目录或远程日志服务,那么可以让 Claude:
- 自动打开最近的错误日志文件
- 筛选指定时间段或关键字
- 按错误类型聚合,帮你梳理出"哪类问题最常见"
3. 三步排查 Claude 本身的异常表现
当你感觉 Claude "怪怪的"时,可以按以下顺序排查:
- 查配置:
bash
claude --version
claude --help
- 开调试(特别是 MCP 问题):
bash
claude --mcp-debug
- 看日志 :
- macOS:
~/Library/Logs/claude-code/ - Linux:
~/.local/share/claude-code/logs/ - Windows:
%APPDATA%\claude-code\logs\
- macOS:
九、进阶:让 Claude 参与设计与重构,而不仅仅是"写代码"
1. 先让 Claude 画出你当前的"系统地图"
当你觉得系统"有点乱"时,可以先让 Claude 做一次现状分析:
text
请你基于本项目代码,完成一次架构现状盘点:
1. 使用 /overview 和 /tree 了解项目的整体结构
2. 用文字总结当前的分层架构现状(Controller / Service / Repository / DTO 等)
3. 指出目前存在的明显架构违规现象(如跨层调用、大量工具类直接操作数据库等)
4. 结合 CLAUDE.md 与 architecture.mdc 中的规范,列出 3 个最需要重点重构的区域,并说明理由
这一步实质上是让 Claude 帮你做一份"技术债清单"。
2. 用渐进重构方案,而不是"一键重构全世界"
在拿到问题清单后,可以要求 Claude 设计一个可落地的重构路线:
text
针对你刚才列出的三个重构重点,请遵守以下约束:
1. 重构必须分阶段进行,每个阶段尽量只影响有限模块
2. 每个阶段结束时,项目必须可编译、测试可通过
3. 优先处理技术债高且变更频率高的模块
4. 每个阶段写出清晰的变更说明和风险点,便于代码评审和回滚
请设计一个最多 3 个阶段的重构方案,每个阶段分别说明:
- 目标
- 主要改动点
- 风险与回滚策略
确认方案后,再让它用 plan 模式逐步实施每个阶段。
3. 性能优化:让 Claude 当"性能顾问",别一上来就乱改
性能问题最忌"头脑一热就动手改",可以先让 Claude 从代码角度做"假设 + 验证":
text
目前在以下场景存在性能问题(简单描述场景和接口):
请按以下步骤协助我:
1. 结合 @Controller.ts, @Service.ts, @Repository.ts 等相关代码,从代码结构上猜测可能的性能瓶颈(列出 2~3 个)
2. 对每个瓶颈给出验证方式(需要哪些日志、监控指标或压测)
3. 推荐应该增加哪些监控点(响应时间、错误率等)
4. 在不改变业务逻辑的前提下,列出 2~3 个低风险、高收益的优化建议
然后再选择其中一两个建议,交给它具体实现并补充测试。
十、把这些"技巧"固化进项目:一个简单落地动作
最后,建议你在当前仓库的 CLAUDE.md 末尾增加一个小节,比如:
markdown
## Claude Code 使用建议(项目内约定)
1. 所有开发、调试、重构对话默认使用 plan 模式,重要改动前务必先 review 计划。
2. 涉及本项目代码的所有对话,必须遵守本文件及相关 *.mdc 架构与规范文档,禁止跨层调用。
3. DTO 中所有涉及长整型编号的字段一律使用 String 类型表示。
4. 除 File 操作外,不额外引入 try/catch,异常处理遵循既有架构规范。
5. 使用 /clear 和 /compact 管理对话上下文,避免长会话导致回答偏移。
6. 优先复用 common.mdc 中的工具类、常量、枚举和 DTO,避免重复造轮子。
7. 所有大改动必须在 Git 干净工作区基础上进行,改动完成后由人工使用 git diff 做最终审核。
8. 建议通过 .claude/commands 维护团队统一工作流命令(如 /feature-workflow, /review-me, /debug-bug)。
大家还有什么使用技巧呢?欢迎讨论交流。