零零散散记几个日常用 Claude Code 攒下来的习惯，都是踩过一些无谓的坑之后才养成的，不算什么高深技巧，纯粹是”早知道就好了”那种。
CLAUDE.md 这个文件一开始没太当回事，随便写了两行项目介绍就扔那了。后来发现这个文件的性价比其实很高，尤其是把那些”每次都要口头纠正一遍”的偏好写进去之后，重复被纠正的次数明显少了。比如团队约定提交信息不要带 emoji、测试文件命名要用 _test 后缀不是 .test、某个目录下的代码是自动生成的不要手动改，这些琐碎但容易忘记交代的规则写进 CLAUDE.md 之后基本不用再操心了。唯一要注意的是这个文件也会过期，项目规范变了但 CLAUDE.md 没跟着改，反而会带来误导，跟代码里的注释一样，得有人隔一阵子回头看看是不是还准。
上下文管理这块吃过亏。早期习惯在一个长会话里把好几个不相关的任务连着做，改完 bug A 接着改 feature B，中途还夹杂了几次探索性的提问,结果到后面发现它对最初几轮的细节已经开始混淆，答非所问的概率变高。后来养成习惯，一个任务做完了、確定告一段落，就开个新会话，不图省事硬凑在一起。相关性强的连续任务留在同一个会话里没问题，但跨度大、话题跳跃的场景,分开反而效率更高，不用担心它把两件事的上下文搅在一起。
子 agent（也就是 Task 工具那套）用起来最有感觉的场景是大范围的代码探索，比如”这个功能在代码库里哪里实现的”这种问题，直接丢给一个只读的探索型 agent 去满仓库翻，比自己一个个文件夹点开找快得多，而且不会占用主对话的上下文——探索过程中翻的那些无关文件不会把主线任务的上下文搅浑。一开始不太敢放手用，总怕它自己乱来，后来发现只读、无副作用的探索类任务完全可以放心交出去，真正需要谨慎盯着的是会改文件、会执行有副作用命令的操作。
计划模式（plan mode）这东西一开始觉得多此一举，改代码而已直接改不就行了。后来在一个牵扯好几个文件的重构任务上吃了亏——它一上来就直接动手改，改到一半发现理解错了需求方向，回滚清理花的时间比直接沟通清楚方向要多得多。后来但凡是涉及面广、有点复杂度的任务，都先让它过一遍计划模式，看看它对任务的理解和拆解思路对不对，觉得没问题了再放它去动手，比事后返工划算太多。反倒是简单明确的小改动没必要走这个流程，直接说直接改，走计划模式纯粹是多一道手续。
还有个小习惯是让它先复述一遍任务再动手，尤其是需求本身带点模糊性的时候。有次让它”优化一下这个接口的性能”，没多解释，它上来就是加缓存,但实际问题其实是一个明显的 N+1 查询，加缓存只是勉强把症状盖住了，根子没解决。后来但凡是这种描述不够具体的任务,会多问一句”你打算怎么做”或者干脆让它先分析问题所在再讨论方案,而不是直接让它埋头开始改，这样双方对齐一次比返工便宜。
最后一个体会是遇到它给出的方案没有说服力、或者哪里感觉不对的时候，直接怼回去说清楚哪里不对，不用担心语气委婉不委婉，它不会往心里去，而模糊地说”再想想”效果往往不如直接指出具体问题所在，比如”这个方案没考虑并发场景”比”感觉不太好，再改改”能拿到精准得多的回应。跟真人协作里那种照顾情绪的沟通方式在这不太适用，直接、具体，效率反而更高。