第一次用 Claude Code，我整理的上手路径和高频工作流
-
第一次用 Claude Code，不建议你上来就让它“写一个完整功能”。这样很容易失望，因为你会发现它动了很多文件，但你心里没底。
我更推荐这个顺序：
- 先让它解释项目结构
- 再让它解释一个报错
- 然后让它补一两个测试
- 最后才让它改代码
这几个步骤的风险是逐渐增加的。读代码几乎没风险，补测试可以验证，改代码才是真正需要你 review 的地方。
还有一个特别有用的小习惯：在项目根目录写一份 CLAUDE.md。不用长，写清楚技术栈、启动命令、测试命令、目录约定、不要碰哪些文件。这个文件对 Claude Code 的影响比很多人想象得大。
我现在比较常用的工作流是：
- “先不要改，先读这几个文件，告诉我你理解的调用链”
- “基于这个理解，给我一个最小改动计划”
- “按计划改第一步，改完跑测试”
这样用起来，它更像一个能执行任务的同事，而不是一个随机生成代码的聊天窗口。
如果你已经在用 Claude Code，可以分享一下你的 CLAUDE.md 怎么写的，我也想看看大家的实战模板。
-
第一次用 Claude Code，不建议你上来就让它“写一个完整功能”。这样很容易失望，因为你会发现它动了很多文件，但你心里没底。
我更推荐这个顺序：
- 先让它解释项目结构
- 再让它解释一个报错
- 然后让它补一两个测试
- 最后才让它改代码
这几个步骤的风险是逐渐增加的。读代码几乎没风险，补测试可以验证，改代码才是真正需要你 review 的地方。
还有一个特别有用的小习惯：在项目根目录写一份 CLAUDE.md。不用长，写清楚技术栈、启动命令、测试命令、目录约定、不要碰哪些文件。这个文件对 Claude Code 的影响比很多人想象得大。
我现在比较常用的工作流是：
- “先不要改，先读这几个文件，告诉我你理解的调用链”
- “基于这个理解，给我一个最小改动计划”
- “按计划改第一步，改完跑测试”
这样用起来，它更像一个能执行任务的同事，而不是一个随机生成代码的聊天窗口。
如果你已经在用 Claude Code，可以分享一下你的 CLAUDE.md 怎么写的，我也想看看大家的实战模板。