用了半年 Claude，我才明白自己之前全用错了

不是 Claude 不行，是你在用「石器时代」的方式跟它对话。掌握这些技巧，你的 AI 协作效率至少翻 3 倍。

先问你一个问题：你用 Claude 写代码，是不是经常遇到这种情况——

第一天：哇，这也太神了，我一个下午干完了以前三天的活！
第三天：emmm 它怎么开始说废话了……
第一周后：算了，还是自己写吧。

然后你得出结论：「AI 不过如此。」

但事实是：不是 AI 退步了，是你的用法从一开始就不对。

Claude 本质上是一个「对上下文极度敏感」的协作者——你给的信息越结构化、越精准，它给你的代码就越靠谱。就像你新入职一个厉害的外包同事，第一天啥也没交代直接扔任务，结果能好才怪。

问题不在 Claude，在于你没跟它「交接」

Claude 没有跨对话的记忆。每次打开新窗口，它就是一个什么都不知道的新人。

你叫它写代码，它会写——用它认为"通用"的方式，而不是你项目里约定的方式。

这不是 Bug，这是特性。你得学会跟它说清楚。

下面 7 个技巧，是我结合国内开发场景总结出来的，从最基础的说起。

技巧一：用 XML 标签说话，别跟它聊天

很多人跟 Claude 交互就像发微信消息——一句话扔过去，然后抱怨结果不对。

Claude 其实更喜欢「结构化输入」。用 XML 标签把你的需求拆开，它能更准确地理解你在说什么。

反面教材（聊天式）：

帮我写一个登录接口，用 Spring Boot，要有参数校验和错误处理，返回 token

正确姿势（结构化）：

<instructions>
  实现用户登录接口
</instructions>

<context>
  Spring Boot 3.x + MyBatis Plus，使用 Sa-Token 做鉴权
  参考项目里已有的 UserController.java 风格
</context>

<requirements>
  - 参数校验用 @Valid 注解
  - 密码用 BCrypt 加密对比
  - 返回格式统一用项目里的 Result<T> 封装
  - 错误码参考 ErrorCode.java 枚举
</requirements>

<constraints>
  - 不要引入新的依赖
  - 不要写任何 System.out.println
</constraints>

别嫌麻烦。你多写 30 秒，它少返工 3 次。

技巧二：给它「封官加职」

Claude 默认会给你一个「通用答案」，就像你问路，对方给你说「往前走」一样没什么用。

但如果你在开头告诉它它是谁，输出质量会明显不同。

区别看这里：

❌ 帮我 review 这段 SQL，看看有没有问题

✅ 你是一名专注于 MySQL 性能调优的高级 DBA，
   当前系统日均查询量约 500 万次。
   请 review 这段 SQL，重点找出在大数据量下可能出现的慢查询风险。

国内常用场景的角色模板：

// 代码安全审查
你是一名熟悉 OWASP Top 10 的安全工程师，
同时了解国内等保 2.0 合规要求，请审查以下代码。

// 架构设计
你是一名设计过日活百万 App 后端架构的技术专家，
当前团队使用阿里云全家桶，请给出系统设计方案。

// Bug 排查
你是一名专注于 JVM 调优和内存泄漏排查的 Java 专家，
请分析以下堆栈日志并给出排查思路。

💡 角色描述控制在 1-2 句话，太长反而会稀释重点。

技巧三：CLAUDE.md——让它永远记住你的项目

这是 Claude Code 里最被低估的功能，没有之一。

在项目根目录创建一个 CLAUDE.md 文件，Claude 每次启动时会自动读取它。相当于你提前帮它写好了「入职文档」。

在终端里运行：

/init

它会帮你生成一个初始模板，然后根据你的项目补充内容：

# 项目：XX电商后台管理系统

## 技术栈
- 后端：Java 17 + Spring Boot 3.2 + MyBatis Plus
- 前端：Vue 3 + TypeScript + Element Plus
- 数据库：MySQL 8.0 + Redis 7
- 部署：阿里云 ECS + OSS，CI/CD 用 Jenkins

## 代码规范
- 接口返回统一用 Result<T>（见 common/Result.java）
- 异常统一抛 BusinessException，不要自己 try-catch 吞掉
- 所有 Service 方法必须写 Javadoc
- 禁止在 Service 层直接写 SQL，必须走 Mapper

## 禁止事项
- 不准硬编码任何配置项，统一走 application.yml + Nacos
- 不准用 System.out.println，统一用 Lombok 的 @Slf4j
- 不准随意引入新依赖，需先在群里确认

## 接口规范
- RESTful 风格，统一加 /api/v1 前缀
- 分页参数：pageNum / pageSize
- 时间字段统一用 LocalDateTime，序列化格式：yyyy-MM-dd HH:mm:ss

你花 1 小时写好这个文件，能省掉后续无数次「上下文复读机」的痛苦。

技巧四：上下文管理——别让它变成「金鱼」

这个技巧很多人完全没意识到，但影响极大。

Claude 的上下文窗口有限。当你在一个对话里聊了太多乱七八糟的内容，它的「注意力」就会开始涣散，后续输出质量明显下降。

研究表明，上下文使用率超过 40% 后，输出质量就开始明显下滑。

几个关键命令要记住：

# 清空上下文，切换新任务时必用
/clear

# 压缩上下文，保留关键信息
/compact

# 带提示的压缩（效果更好）
/compact 保留认证模块的重构进度，删除之前调试日志的部分

# 回退到上次失败前的状态
/rewind

正确的工作节奏：

❌ 错误做法
一个对话里：修 Bug → 加新功能 → 重构代码 → 再修 Bug
→ Claude 越来越乱，代码越来越离谱

✅ 正确做法
任务1：/clear → 修登录 Bug → commit → /clear
任务2：/clear → 加导出 Excel 功能 → commit → /clear
→ 每次都是满血状态

记住一个原则：rewind 比纠错强。Claude 写错了，别急着让它改——直接 /rewind 回到出错前，重新描述需求，比让它在错误代码上打补丁要好得多。

技巧五：先让它出卷子，再让它写代码

这是区分「用 AI 做玩具」和「用 AI 做生产项目」最关键的习惯。

直接让 Claude 写代码，对于简单需求没问题。但凡涉及业务逻辑稍复杂的功能，先规划再动手，最终结果往往更好、返工更少。

Claude Code 有个 Plan 模式，Shift+Tab 可以切换进去。

另一个更实用的方式，是用这个提示词让它先问你问题：

我想做一个：[需求简述]

在写代码之前，请先深度采访我，问清楚：
- 业务逻辑和边界情况
- 与现有模块的集成方式
- 性能和并发要求
- 我可能没想到的坑

不要问显而易见的问题，只问核心的、影响架构决策的问题。

采访完成后，输出完整的技术方案文档保存到 SPEC.md，
我确认后再开始编码。

实战工作流：

Session 1（规划）：
→ 用上面的提示词采访 + 生成 SPEC.md
→ 你 review 并修改 SPEC.md
→ /clear

Session 2（开发）：
→ 加载 SPEC.md
→ 按模块逐步实现
→ 每个模块完成后 commit

感觉多了一步，实际上省了后期大量返工。

技巧六：让两个 Claude 互相「挑刺」

这个方法略显"奢侈"，但效果出奇的好。

核心思路：写代码的 Claude 和 review 代码的 Claude，不能是同一个上下文。

写代码的 Claude 对自己写的东西有"感情"，找不出问题。但一个全新的、什么都不知道的 Claude，会更客观。

# 终端1 —— 开发者 Claude
> 实现一个基于 Redis 滑动窗口的接口限流中间件，
  每个用户 IP 每分钟最多 60 次请求

[写完代码]

# 终端2 —— 评审者 Claude（全新窗口）
> 你是一名专注于高并发场景的资深 Java 工程师。
  请严格审查以下限流中间件代码，重点关注：
  1. 高并发下的线程安全问题
  2. Redis 操作的原子性是否有保障
  3. 极端情况下的绕过风险
  4. 内存和性能问题

  [粘贴终端1的代码]

如果没有条件开两个终端，也可以用「自我批判」模式：

请先完成 [任务]。
完成后，以一个挑剔的技术 leader 的视角，
列出至少3个你觉得这段代码可能存在的问题，
然后基于这些问题重新优化代码。

技巧七：把你们团队的「暗知识」写进命令

这是让 Claude 从「个人工具」升级为「团队工具」的关键。

在 CLAUDE.md 里定义自定义命令，把你们团队约定好的流程固化下来：

## 自定义命令

### /plan
开始任何开发任务前：
1. 问清楚需求和验收标准
2. 列出所有需要修改的文件
3. 评估对现有功能的影响
4. 写出分步骤的实施计划
5. 等待我确认后再开始写代码

### /review
代码审查清单：
1. 安全：有没有 SQL 注入风险？敏感信息有没有泄露？
2. 性能：有没有 N+1 查询？循环里有没有数据库操作？
3. 异常：所有异常是否正确处理，有没有被吞掉？
4. 规范：是否符合项目里的命名和分层规范？
5. 测试：核心逻辑有没有对应的单元测试？

### /ship
提交前自检：
1. 跑完所有单元测试，确认全绿
2. 检查有没有遗留的调试代码和 TODO
3. 确认没有硬编码的密码、密钥、IP 地址
4. git diff 看一眼完整改动
5. 写规范的 commit message：type(scope): 描述

用起来很简单：

/plan 新增订单超时自动取消功能
/review  [粘贴代码]
/ship

新人入职，直接给他看 CLAUDE.md，不用再口头交代一遍编码规范。

把这 7 个技巧串起来

最后说一句

Claude 就像一个能力极强但完全不了解你公司的外包。

你不交代清楚，他就按自己理解来，写出来的东西你不满意，然后你说「AI 没用」。

但你要是花时间把项目规范、技术约束、验收标准都说清楚——他会让你觉得身边多了个不用发工资的高级工程师。

这 7 个技巧，本质上都是在做一件事：把你脑子里的"默认知识"，变成 Claude 也能理解的显式规则。

学会了，vibe coding 才能真的起飞。