我的 Claude Code 最佳实践

我不会把大任务丢给 Claude Code 让它自己跑，而是把它当作结对编程的搭档来用。

虽然深入使用还没多久，但在这过程中总结出了一些个人最佳实践。

C 让 Claude Code 来写 CLAUDE.md

自己只写大致的方针，代码库的结构和指南就交给 Claude Code 来写。

内容只需要写到「哪里有什么」这种程度的项目指南就够了。写太详细的话，忘记更新时就会给 Claude Code 传递错误的信息。Claude Code 能自己找到需要的信息，有个指南就足够了。

注意 DRY 原则

同样的信息出现在多处，更新遗漏就会导致「到底哪个是对的」的困惑。这类信息越多，Claude Code 的表现也会越差。 #AI编程 #AI 编程

本来 Claude Code 就不怕查找和追溯信息。为了人类阅读方便而牺牲 DRY 原则的做法，必要性已经降低了。建议把这条作为规则写进 CLAUDE.md。

设置默认权限

不设置的话，Claude Code 每次执行命令都会请求确认。在 ~/.claude/settings.json 中预先给低风险的命令授权吧。

参考: 我的 settings.json

任务要小

「把整个应用重构一下」不如「改进这个函数的错误处理」效果好。再细化到「按这样改进」，就能得到更符合预期的结果。

如开头所述，我不会把大任务直接丢给 Claude Code。

1. 传达最终目标，商量设计方案
2. 「先把这个推进一下」逐步给出指示
3. 审查后 git add，再要求改进
4. 没问题了就 commit，进入下一步

这样按小单位边审查边推进，遵循了代码审查的最佳实践。

提供线索

适当提供任务的上下文，可以减少不必要的搜索，提高精度并节省时间。

如果有「帖子评论看不到」这样的任务，而你有头绪的话，就随便给点信息，比如「可能是 posts/comments/view 那边的问题」。

使用 TODO 注释

把「想在这里写这样的代码」这类具体指示写进文件后，让 Claude Code「把刚写的 TODO 处理掉」，就能更简单地在特定位置给出具体指示。

常用提示词做成命令

常用的提示词可以做成命令。不方便放在项目里的，在 ~/.claude/commands 定义为个人命令。

自我审查

也可以让 Claude Code 审查自己写的代码。在自己过目之前先让它做，能大幅减少明显的错误。

我做成了命令，用 /hard-review 调用。

```markdown:hard-review.md

请重复以下步骤直到找不到问题：

1. 确认对象并审查
2. 有问题就修正
3. 修正后再次审查

## C 让 Claude Code 来提交写提交信息太麻烦，让 Claude Code 来写吧。但是手动编辑后等情况下，Claude Code 的记忆可能与实际不符，写出错误的信息。提交前让它先确认 diff 吧。我做成了命令，用 `/commit` 调用。```markdown:commit.md确认 diff 后写出合适的提交信息并提交。

不能让 Claude Code 直接编辑生成文件。特别是 package-lock.json 和 yarn.lock 等锁文件要注意。直接编辑可能导致版本不一致或指定不存在的版本。

在 CLAUDE.md 中明确写出生成命令和生成目录，注明「不要直接编辑，通过命令更新」。

会持续更新的。

原文: sijiaoh.com/zh/posts/my…