上一篇讲了怎么装 Claude Code。话说回来，这篇聊装好之后第一天能做什么。

如果你第一次启动后盯着终端的光标不知道输入什么很正常。下面这 5 个场景都是日常开发中最常见的，每个我都给出了完整的指令和你会看到的反馈。你可以直接复制粘贴去试，

使用者痛点：刚装好工具。往往不清楚它到底长什么样、该怎么交互，导致犹豫不前。

在项目目录下输入 claude 启动，你会看到这样的界面：

Claude Code v2.x.x
Type /help for available commands.
> 

那个 就是输入提示符。把指令输进去，按回车，它就开始干活了。

Claude Code 工作的时候，终端会实时显示它在干什么：

 Reading pom.xml...
> Searching for similar patterns in codebase...

当它要修改文件或输入命令时会弹出一个确认框。类似这样：

Edit src/main/java/com/example/DeptController.java?Allow │ Deny │ Always Allow │ ──┐
───────────────────────────────────┘

刚开始用的时候，每次都点 Allow 看一眼它改了什么。用熟了再把读文件、跑测试这种安全操作加白名单。

场景一这方面。新功能开发

传统耗时：数小时 AI 辅助后耗时：几分钟

使用者痛点：手动创建实体、Mapper、Service、Controller 等文件，需要反复参考已有代码，容易遗漏或风格不统一。

步骤 1 – 让 Claude 给出实现计划：

/plan 参照 UserController，为 sys_dept 表新增一套部门管理的 CRUD。按理说，从包括来看，Entity、Mapper、Service、ServiceImpl、Controller、SaveDTO、UpdateDTO、QueryDTO、VO。Controller 接口方法用 /api/dept。

You’ll see a plan like:

📋 Plan.
Read UserController.java,UserService.java,UserMapper.java to learn pattern.
Create DeptEntity.java .
Create DeptMapper.java + DeptMapper.xml.
Create DeptService.java + DeptServiceImpl.java.
Create DeptController.java.
Create DeptSaveDTO.java。DeptUpdateDTO.java,DeptQueryDTO.java,DeptVO.java
Estimated files: new,modified

If plan looks good,reply “开始执行” 或 “start”。Claude 会依次生成所有文件。

步骤 2 – 自动跑单元测试：

mvn test

If tests fail。Claude 会自动定位并修复，直到全部通过。

步骤 3 – 代码审查:

/simplify

/simplify 会启动三个 AI Agent 并行审查你的代码：重复逻辑检查、常用方法校验、性能风险检测。根据反馈逐条修改后记得提交代码。

场景二这方面。快速体验

使用者痛点：装完工具后没有快速验证手段，担心“装了没用”。通过一个小玩具可以立刻确认 Claude 正常工作。怎么说呢，

步骤 1 – 创建空目录并启动 Claude：

mkdir claude-test
cd claude-test
claude

步骤 2 – 给出需求。让 Claude 编写小游戏：

/write
程序随机生成 1~100 之间的数字。玩家有 7 次机会，每次猜完告诉玩家“太大了”还是“太小了”。猜对了说“恭喜”并结束，7 次都没猜中说出正确答案。写完后直接运行它，

C几秒后 Claude 会创建一个 guess_number.py 文件，并自动执行 python guess_number.py. 交互示例：

Guess number . You have 7 chances.
Enter your guess: 50
Too low!其实，Enter your guess: 75
Too high!...
Congratulations!You guessed it.

玩完后按 退出游戏，再输入 /exit 完全退出 Claude Code。

从场景三来看，Bug 排查

使用者痛点：# 手动定位日志和代码关联繁琐；# 常常只能靠经验猜测根因。

步骤 – 把问题描述给 Claude，让它直接阅读代码和日志：

线上订单创建接口偶发超时大概 5% 的请求会卡住超过 3 秒。话说回来，再看报错日志，java.lang.TimeoutException: Order creation timed out...
相关代码在 OrderService.java:
public Order createOrder { ... }
订单表 order_info 当前约有 200 万行数据。帮我排查根因，

C 输出分析报告示例：

🔍 Analysis.
Read OrderService.java:
- Found N+ query pattern in method createOrder
- Each order creation triggers extra user_info queries inside a loop.
Checked order_info indexes:
- Missing composite index on .
Root cause: N+ query at OrderService.java:112
说到Fix，Add batch query before loop.
Possible solutions:
A. Add IN query to batch load user_info.
B. Add @BatchSize annotation on relationship.

Acknowledged root cause and ask Claude to apply方案 A 并跑测试：

按方案 A 帮我修改代码。运行 OrderServiceTest 验证。

至于场景四。代码重构

User Pain Point:# 重构前缺少安全网，一旦行为变更难以定位；# 手工拆分方法容易遗漏细节。

OrderService.createOrder 方法现在有 200 行。包含：
- 参数校验
- 库存检查
- 价格计算
- 优惠券抵扣
- 订单创建
- 积分计算
请把它拆分成独立的小方法，每个只做一件事，不改变业务逻辑。先生成测试覆盖，接下来再重构。

• A. Claude 生成对应的单元测试。
• B. 在所有测试通过的前提下执行重构。
• C. 若出现失败，Claude 会自动定位并修复对应测试。
• D. 完成后使用 /simplify) 做一次最终审查。

从场景五来看，写技术方法文档

User Pain Point:# 从零起草技术方法需要大量时间收集需求、设计表结构和接口；# 文档格式经常不统一，需要反复排版。

说到需求要点。• 使用者下单获得积分，订单金额每满100元得10积分；• 积分可抵扣金额，比例为1积分=0.1元；• 积分按自然年过期，每年12月31日清空当年积分；按理说，• 积分变动需要流水记录，便于对账。请在 docs/credit-system-design.md 中生成完整技术方法文档。包括：
‑ 背景与目标
‑ 数据库表设计
‑ 主要 RESTful 接口定义
‑ 积分过期策略：批量扫任务 vs 按需计算对比
‑ 风险点与应对措施

Creates /docs/credit-system-design.md. The generated draft already包含章节标题、字段说明和示例 API JSON，可直接在此基础上补充业务细节，再提交到仓库即可。

如果它改错了怎么办？

C​laude Code 每次修改都会自动创建检查点。改错了有三种回退方式：

• /rewind: 回到上一个状态，对话历史保留。
• Dbl‑click ESC : 弹出时间线选择界面可恢复到任意历史版本。
• `git checkout -- <文件名>` : 使用 Git 常规回退。

TIPS: 每次让 AI 改代码前先手动 . 如出现大面积回滚。只需执行 ,最保险！)

退出和恢复会话

• /exit 或 Ctrl+C → 退出当前会话。
• `claude --resume` → 恢复上一次会话。
`
• `claude --list` → 列出所有历史会话，可任选其一恢复。

---