个人全局偏好 ~/.claude/CLAUDE.md

适用场景

你每次开新项目，都要重复说一遍「用简体中文回答」「别直接推送到 main」「先看代码再动手」。这些与项目无关、只与你本人有关的习惯，应该放在用户级文件 ~/.claude/CLAUDE.md 里，对你机器上的所有项目生效。

团队共享的约定不要放在这里，那些属于项目的 CLAUDE.md。判断标准很简单：换一个人来做这个项目，这条规则还成立吗？成立就是项目规则，不成立就是个人偏好。

模板

保存为 ~/.claude/CLAUDE.md（Windows 是 %USERPROFILE%\.claude\CLAUDE.md）：

# 个人偏好（适用于所有项目）

## 沟通
- 默认使用简体中文回复；代码、命令、文件名、报错原文保持原样。
- 先给结论，再给依据；明确区分「已验证的事实」和「我的推测」。
- 不确定就直说，不要编造 API、参数或命令；涉及工具特性时优先查官方文档。
- 中英文之间加空格，使用中文标点。

## 工作方式
- 动手前先阅读相关代码，改动保持最小，不顺手重构无关部分。
- 完成后自己验证（运行测试、构建或实际查看结果），汇报时附上真实输出。
- 需求有关键歧义时，先问最关键的一个问题，不要一次抛出一长串。
- 保留工作区里我已有的未提交改动，不要回退或覆盖。

## 安全边界
- 未经我明确要求，不执行破坏性操作：删除数据、强制推送、改写历史、修改生产环境。
- 密钥只通过环境变量或被 .gitignore 忽略的本地文件使用，不写进源码和提交。
- 发现已提交的密钥时，告诉我并建议轮换。
- 不直接推送到 main 或默认分支，不绕过 hook。

## Git
- 提交前先看 `git status` 和 `git diff`，只提交与本次任务相关的文件。
- 提交信息第一行概述改了什么，必要时空一行写原因。

## 代码风格
- 注释解释「为什么」，不复述代码「做了什么」。
- 新增依赖前先告诉我理由。

怎么用 / 怎么改

1. 创建目录并写入文件后，开一个新会话，运行 /context，在 Memory files 里确认它被加载。也可以用 /memory 直接打开并编辑，如果文件不存在，选中它会先创建。
2. 加载顺序是从大范围到小范围：先用户级，再项目级。同一条内容两处冲突时，Claude 可能照任何一条执行，所以个人规则要避免和项目规则打架，比如个人写「用 npm」而项目写「用 pnpm」。
3. 偏好变多以后，可以拆成 ~/.claude/rules/ 下的多个文件（如 preferences.md、workflows.md）。用户级规则会在项目规则之前加载。
4. 只在某个项目里想覆盖的个人习惯，写进该项目根目录的 CLAUDE.local.md，并加入 .gitignore。
5. 想让多个 worktree 共享同一份个人说明，可以在项目的 CLAUDE.md 里引用家目录文件，例如 @~/.claude/my-project-instructions.md。项目里的这类外部引用第一次出现时，会弹出批准提示；用户级文件里的引用则不会。

常见问题或注意事项

• 语言设置还有另一条路。 官方设置里有 language 字段，值为任意语言名字符串，Claude Code 不做校验，可以写在 ~/.claude/settings.json 里，让回复默认使用该语言。它和 CLAUDE.md 里的语言规则可以并用，前者更像开关，后者可以写得更细（比如「代码注释也用中文」）。
• 这是建议，不是强制。 「不要强推」之类的安全规则，如果必须零例外，请同时在权限规则里写 deny，或者用 PreToolUse hook 拦截。
• 别把它写成百科全书。 每一行都问一句「删掉它，Claude 会犯错吗」。答案是否，就删。
• 和其他工具共用偏好。 如果你同时使用别的编码智能体，它们各有自己的全局文件。可以只维护一份，再用 @路径 引用到 ~/.claude/CLAUDE.md 里，避免两份内容慢慢漂移。