很多人第一次打开 Claude Code，会把它当成"命令行里的聊天框"：丢一句"帮我写个登录功能"，然后对着生成的代码叹气。问题不在模型，而在于你没有把它当成一个需要上下文的搭档。
这篇指南总结我在三个真实项目里沉淀下来的用法，按上手顺序排列。
一、先让它读，再让它写
Claude Code 最大的价值是它能自己翻代码库。新任务开始前，先让它做一轮侦察：
> 先不要改任何代码。读一下 src/auth 目录和相关的测试，
> 告诉我现在的登录流程是怎么走的，涉及哪几个文件。
这一步看似浪费时间，实际上是在给后续的修改"对齐认知"。它复述的流程如果和你的理解不一致，说明你们对代码库的认识有偏差，先纠正偏差再动手。
二、任务描述要写"完成标准"
差的描述是"优化一下这个页面"。好的描述包含验收条件：
把 /orders 页面的加载时间降下来。完成标准：首屏不再一次性渲染全部订单，改为分页加载，每页 20 条；已有的筛选功能不能回归。
有完成标准，它才知道什么时候算做完，你 review 时也有据可依。
三、大改动先进入计划模式
涉及多文件的改动，先按 Shift+Tab 进入计划模式，让它输出实施方案再批准。计划阶段发现方向错了，成本是一句话；代码写完再发现，成本是一整个下午。
四、小步提交，随时可回滚
我的经验法则：每个可独立验证的改动就提交一次。Claude Code 改代码很快，但出错时回滚也应该很快。不要让它连续改三个小时而中间一次都不提交。
五、CLAUDE.md 是你的长期记忆
在项目根目录维护一个 CLAUDE.md，写上：
- 构建和测试命令（它每次都能自己跑测试验证）
- 目录结构和各模块职责
- 项目的特殊约定（比如"所有金额以分为单位存储"）
这个文件会在每次会话自动加载，相当于给搭档的入职文档。
六、让它自己跑测试
明确告诉它"改完后跑 npm test 确认通过"。它能读测试输出、定位失败、迭代修复——这是它比网页版对话强得多的地方。不跑测试的 AI 代码，一律视为半成品。
七、一句话总结
把 Claude Code 当成一个能力很强但对你项目一无所知的新同事：先给上下文，再下清晰的任务，小步验收，保留文档。做到这四点，它的产出质量会稳定得多。