分享给 Java 开发者的 Claude Code Rules & Skills

Claude Code 上下文的完整加载机制

优先级规则

• 项目规则 > 用户规则（冲突时项目规则覆盖全局）
• 支持子目录组织：~/.claude/rules/frontend/*.md 也会被递归发现

Claude Code 的代码编写规范限制

从上面的加载机制中，可以很快地出结论，可以将我们的某类开发语言 (Go / Java / Vue) 的规范放到项目规则或项目内存中

所以我就会把我的我的规范 md 放到项目的 .claude/rules 文件夹中 (其实也可以放到全局的规则文件夹中，我一开始也是放到全局规则文件夹中，后面项目多了才放到项目规则文件夹中)，得到如下

放入后，重启一下 Claude Code，然后使用 /memory 查看一下，有没有加载到你添加的规则文件

可以参考的 java-spring 规范 md，都是用 Claude Code 以来，很多 CC 不怎么遵守的，根据自己的项目与实际情况微调一下

规则 Gists: https://gist.githubusercontent.com/anlostsheep/b2a6e9d24c5b67b50fdeb1dcec4182ea/raw/cda9755a31a3f20aef211279cda38c0f5360ad92/java-spring.md

为什么不用 Skill 做代码编写规范？

确实使用 skill 更符合现在的方向，减少使用 tokens 以及上下文占用，

但是 skill 的调用如果是自动调用的情况下，不管是 opus 或者 sonnet 都会选择性执行 (模型要想偷懒)，触发都是不稳定的，除非显式地在 prompts 中说明调用，但是 prompts 中我们更多是跟模型对话一整个功能的实现，很少会说：帮我修改 xx 类 / 帮我优化一下这个类的代码

所以我选择把这个 skill 做成一个代码审查的操作，然后每次代码完成输出后，显式地调用这个 skill 进行审查

按照这样的格式构建 skill 文件夹 java-review, 文件夹放入 SKILL.md，得到如下：

显式执行效果：

skill Gists: https://gist.githubusercontent.com/anlostsheep/be83fea55777c932267d2ba2a4ee7395/raw/c14f226b138517199d70367452f16314629a916d/SKILL.md

hook 函数

skill 的方式始终触发不稳定情况，可以添加一个 hook 函数，让 Claude Code 再每次执行了新增 / 修改操作的工具时收到一个提示 (也可以放到 git 提交的时候触发，根据自己实际情况修改)，修改到了 java 代码，需要执行 java-review 进行规范审查，不过最终模型也会根据这个修改的文件复杂程度来决定是否触发这个 skill (简而言之就是想省事一点)

修改配置文件： ~/.claude/setting.json，补充一下这个 PostToolUse 的

"hooks": { "PostToolUse": [ { "hooks": [ { "command": "filepath=\"$CLAUDE_FILE_PATH\"; if [[ \"$filepath\" == *.java ]]; then echo '⚠️ [Java文件修改] 建议执行 /java-review 进行代码审查'; fi", "type": "command" } ], "matcher": "Edit|Write|MultiEdit" } ] } 

效果：

claude-code-guide Agent 的妙用

这个子 Agent 是 Claude Code 内置的指导使用 Claude Code 的代理，有很多我不明白怎么使用 Claude Code 的地方我都会使用这个代理进行分析

比如：

• 配置 Hook 的环境变量不生效，提问解决

  

• 插件配置问题导致启动失败 (claude-mem)

  

对于配置和使用 Claude Code 方面，相关的问题还是十分好解决的，只能说 A/ 在护城河这方面真的做得挺好的