我更推荐这个顺序：

1. 先让它解释项目结构
2. 再让它解释一个报错
3. 然后让它补一两个测试
4. 最后才让它改代码

这几个步骤的风险是逐渐增加的。读代码几乎没风险，补测试可以验证，改代码才是真正需要你 review 的地方。

还有一个特别有用的小习惯：在项目根目录写一份 CLAUDE.md。不用长，写清楚技术栈、启动命令、测试命令、目录约定、不要碰哪些文件。这个文件对 Claude Code 的影响比很多人想象得大。

我现在比较常用的工作流是：

• “先不要改，先读这几个文件，告诉我你理解的调用链”
• “基于这个理解，给我一个最小改动计划”
• “按计划改第一步，改完跑测试”

这样用起来，它更像一个能执行任务的同事，而不是一个随机生成代码的聊天窗口。

如果你已经在用 Claude Code，可以分享一下你的 CLAUDE.md 怎么写的，我也想看看大家的实战模板。