我的 Claude Code 最佳实践

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

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

让 Claude Code 来写 CLAUDE.md

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

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

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

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

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

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

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

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

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

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

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

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

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

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

markdown:hard-review.md 复制代码

---
description: 反复审查和修正直到没有问题
---

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

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

写提交信息太麻烦，让 Claude Code 来写吧。

但是手动编辑后等情况下，Claude Code 的记忆可能与实际不符，写出错误的信息。提交前让它先确认 diff 吧。

我做成了命令，用 /commit 调用。

markdown:commit.md 复制代码

---
description: 创建提交
---

确认 diff 后写出合适的提交信息并提交。

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

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

会持续更新的。