昨天我还在教你怎么安装Claude Code，今天我已经让它帮我重构了3个模块，写了20个测试，还自动生成了API文档。
如果你昨天跟着我的教程装好了Claude Code，恭喜你，你已经迈出了第一步。但说实话，那只是Claude Code 10%的能力。
今天，我要带你进入真正的“高手区”——那些让Claude Code从“聪明实习生”变成“王牌搭档”的进阶技巧。
一、 从“能用”到“好用”的转折点
昨天我让Claude Code写了个宠物系统，它确实写出来了。但今天早上，当我打开代码准备优化时，发现了一个问题：
它把所有逻辑都塞在了一个文件里。
这就像让实习生写代码，他确实写了，但没考虑架构、没考虑维护、没考虑扩展。
于是我意识到：用Claude Code，不是让它“写代码”，而是让它“设计代码”。
二、 核心技巧1：/plan模式——你的“安全气囊”
这是Claude Code最重要的功能，没有之一。
错误用法：
帮我重构用户模块
正确用法：
/plan
任务：重构用户模块，按DDD分层
范围：@src/user/
排除：@src/user/tests/（测试文件不动）
请输出：
1. 将修改的文件列表
2. 每个文件的具体改动
3. 执行顺序建议
4. 风险评估
等我确认后再执行
区别在哪里？
- 错误用法：AI直接动手，可能改坏代码
- 正确用法：AI先出“施工图”，你审核，你点头了它才动工
实测效果：用/plan模式，复杂任务的一次性成功率提升60%。
三、 核心技巧2：会话管理——别让AI“失忆”
你有没有遇到过这种情况：
- 上午让AI修Bug，下午让它加功能
- 结果它把上午的决策全忘了
- 给出的方案前后矛盾
这是因为Claude Code的上下文窗口有限（就像人的短期记忆）。
解决方案：会话管理三件套
1. /rename：给会话起名
/rename user-module-refactor
这样你就能记住：“哦，这个会话是专门重构用户模块的”。
2. /resume：恢复会话
下午继续工作时：
/resume user-module-refactor
AI瞬间恢复上午的“记忆”，继续推进任务。
3. /clear：及时清理
一个任务结束了，马上：
/clear
释放上下文空间，避免干扰下一个任务。
我的习惯：
- 一个功能 = 一个会话
- 一个Bug = 一个会话
- 一个重构 = 一个会话
这样等于有了自动生成的开发日志。
四、 核心技巧3：CLAUDE.md——给AI写“员工手册”
昨天我让Claude Code写代码，它用了var声明变量（我们团队要求用let和const）。
问题：每次都要提醒它“用const别用var”，太累了。
解决方案：在项目根目录创建CLAUDE.md
# 项目规范手册
## 编码规范
- 变量声明：必须用 `let` 或 `const`，禁止用 `var`
- 函数命名：用 camelCase，动词开头
- 组件命名：用 PascalCase
## 项目结构
- `src/api/`：API接口
- `src/components/`：React组件
- `src/utils/`：工具函数
## 禁止行为
- 禁止修改 `package.json` 中的依赖版本
- 禁止删除已有测试用例
- 禁止直接操作数据库（必须通过Repository）
## 验证命令
- 前端：`pnpm lint && pnpm test`
- 后端：`mvn test -pl 模块名`
效果：Claude Code每次启动都会自动读取这个文件，犯错率下降70%。
五、 核心技巧4：调试技巧——别让AI“猜”
昨天我遇到一个Bug：
TypeError: Cannot read property 'id' of undefined
错误做法：
帮我修这个Bug
正确做法：
这是错误信息：
TypeError: Cannot read property 'id' of undefined
at OrderService.createOrder (src/services/order.ts:89:23)
相关代码在 src/services/order.ts 第85-95行
请：
1. 分析根本原因
2. 给出最小修复方案
3. 说明可能影响的上下游
4. 帮我生成Bug修复说明
核心原则：给AI运行时数据，而不是让它猜。
六、 实战：用AI团队并行开发
昨天我做宠物系统是“单打独斗”，今天我要试试Agent Teams——让多个AI智能体并行工作。
场景：同时开发用户模块和订单模块
第一步：开启实验功能
在~/.claude/settings.json中添加：
{
"experimental": {
"agentTeams": true
}
}
第二步：创建AI团队
/create-team ecommerce-team
第三步：分配任务
# 给团队A：用户模块
assign-to: team-a
任务：实现用户注册、登录、资料修改
范围：@src/user/
# 给团队B：订单模块
assign-to: team-b
任务：实现下单、支付、退款
范围：@src/order/
第四步：监控进度
用tmux分屏，同时看两个团队的输出。
结果：
- 以前：我一个个模块写，需要2天
- 现在：两个AI团队并行，4小时完成
七、 效率提升数据（第二天）
| 指标 | 第一天 | 第二天 | 提升 |
|---|---|---|---|
| 代码产出 | 500行/天 | 1200行/天 | 140% |
| Bug数量 | 每100行2个 | 每100行0.5个 | -75% |
| 架构质量 | 一般 | 优秀（DDD分层） | 显著提升 |
| 我的参与度 | 全程紧盯 | 审核方案+关键决策 | 从执行者变架构师 |
八、 避坑指南（第二天版）
坑1：让AI读整个目录
症状：@src/ 分析这个项目 → token耗尽，分析质量差
正确做法：
先列出 src/ 下的目录结构
然后找出核心Service类在哪里
坑2：对话超长不清理
症状：第30轮对话，AI开始“失忆”
判断标准：
- 超过20轮 → 执行
/compact - 超过40轮 → 考虑
/clear重开 - 超过60轮 → 任务应该拆分成多个会话
坑3：一次改太多文件
症状：AI一次改了10个文件，出问题不知道回滚哪里
正确做法：
先只改 UserService.java
改完我确认后再改其他文件
九、 我的工作流升级
昨天的工作流：
- 想需求
- 告诉AI
- AI写代码
- 我运行测试
今天的工作流：
- 想需求
/plan出方案（AI）- 我审核方案
- AI按方案执行
- AI自动运行测试
- AI生成文档
- 我最终验收
最大的变化：我从“写代码的”变成了“设计方案的”。
