从我不再需要在每次新对话里重复解释自己怎么写代码开始，Claude Code 就明显好用了很多。我用 AI 写代码差不多两年，过去大约半年主要在用 Claude Code。对我帮助最大的改进，简单得甚至有点不好意思说出口：把默认规则写进 ~/.claude/CLAUDE.md，让 Claude 一开始就先从这里读起。
在那之前，我总得反复说同样的话。要严格类型。不要加我没要求的兜底逻辑。改动尽量小。别一兴奋就重写半个文件。Claude 通常也会照做，但这些要求我还是得一遍遍重复。
现在还没开始谈仓库本身，这层基线就已经先立住了。
我的 Claude Code 全局指令放在哪里
Anthropic 的 Claude Code 文档把这套东西分成几层。~/.claude/CLAUDE.md 是用户级文件，./CLAUDE.md 或 ./.claude/CLAUDE.md 是项目共享层，CLAUDE.local.md 则用来放你自己的项目备注，也就是那些不该进 git 的内容。
这几乎就是我想要的结构：
~/.claude/CLAUDE.md放长期稳定的编码偏好- 项目里的
CLAUDE.md写仓库特有的架构和命令 CLAUDE.local.md放不该进 git 的个人项目笔记
我不想每打开一个仓库，都重新粘贴同样的个人规则。如果“不要静默加兜底逻辑”是全局偏好，那它就该放在全局文件里。如果“跑测试前先执行某个古怪的内部初始化命令”只和某个仓库有关，那它就该写进项目文件。
下面是我现在在 Claude Code 里用的版本：
我真正使用的 Claude Code 规则
这段内容我故意写得很无聊。好规则通常就是这样。我不是想提前穷举所有边角情况，只是想让 Claude Code 别再反复犯那些完全可以预见的错误。
# Global Rules
## Code Style
- Comments in English only
- Prefer functional programming over OOP
- Use OOP classes only for connectors and interfaces to external systems
- Write pure functions - only modify return values, never input parameters or global state
- Follow DRY, KISS, and YAGNI principles
- Use strict typing everywhere - function returns, variables, collections
- Check if logic already exists before writing new code
- Avoid untyped variables and generic types
- Never use default parameter values - make all parameters explicit
- Create proper type definitions for complex data structures
- All imports at the top of the file
- Write simple single-purpose functions - no multi-mode behavior, no flag parameters that switch logic
## Error Handling
- Always raise errors explicitly, never silently ignore them
- Use specific error types that clearly indicate what went wrong
- Avoid catch-all exception handlers that hide the root cause
- Error messages should be clear and actionable
- No fallbacks unless I explicitly ask for them
- Fix root causes, not symptoms
- External API or service calls: use retries with warnings, then raise the last error
- Error messages must include enough context to debug: request params, response body, status codes
- Logging should use structured fields instead of interpolating dynamic values into message strings
## Language Specifics
- Prefer structured data models over loose dictionaries
- Avoid generic types like `Any`, `unknown`, or `List[Dict[str, Any]]`
- Use modern package management files like `pyproject.toml` and `package.json`
- Use the language's strict type features when available
## Libraries and Dependencies
- Install dependencies in project environments, not globally
- Add dependencies to project config files, not as one-off manual installs
- If a dependency is installed locally, read its source code when needed instead of guessing
- Update project configuration files when adding dependencies
## Testing
- Respect the current repository testing strategy and existing test suite
- Do not add new unit tests by default
- When tests are needed, prefer integration, end-to-end, or smoke tests that validate real behavior
- Use unit tests only rarely, mainly for stable datasets or pure data transformations
- Never add unit tests just to increase coverage numbers
- Avoid mocks when real calls are practical
- It is usually better to spend a little money on real API or service calls than to maintain fragile mock-based coverage
- Add only the minimum test coverage needed for the requested change
## Terminal Usage
- Prefer non-interactive commands with flags over interactive ones
- Always use non-interactive git diff: `git --no-pager diff` or `git diff | cat`
- Prefer `rg` for searching code and files
## Claude Code Workflow
- Read the existing code and relevant `CLAUDE.md` files before editing
- Keep changes minimal and related to the current request
- Match the existing style of the repository even if it differs from my personal preference
- Do not revert unrelated changes
- If you are unsure, inspect the codebase instead of inventing patterns
- When project instructions include test or lint commands, run them before finishing if the task changed code
## Documentation
- Code is the primary documentation - use clear naming, types, and docstrings
- Keep documentation in docstrings of the functions or classes they describe, not in separate files
- Separate docs files only when a concept cannot be expressed clearly in code
- Never duplicate documentation across files
- Store knowledge as current state, not as a changelog of modifications
这段规则已经覆盖了我平时最在意的大部分事情。
没有这层约束时，Claude 总会朝几个很熟悉的方向跑偏。它会“以防万一”补上兜底逻辑。它会嫌严格类型麻烦，于是顺手把类型放宽。它会给本来很简单的函数套上额外几层。它还会因为太想显得配合，最后修错真正的问题，因为它努力的是迁就你，而不是准确地解决问题。
我宁可一次花十分钟把全局文件写好，也不想在每个新会话里继续一条条纠正这些老毛病。
先有全局 CLAUDE.md，再有项目 CLAUDE.md
我不想要一个把所有东西都塞进去的巨型 CLAUDE.md。
我的全局文件应该回答这些问题：
- 我希望类型有多严格？
- 我希望错误如何处理？
- 我想要尽量小的改动，还是大规模重构？
- 我希望看到什么样的文档？
而项目文件应该回答另一组问题：
- 这个项目要怎么运行？
- 哪些命令是安全且推荐的？
- 架构边界里哪些最重要？
- 测试放在哪里？
- 哪些约定只属于这个仓库？
落到实际使用上：
- 全局
CLAUDE.md说明我是怎么工作的 - 项目
CLAUDE.md说明这个仓库是怎么工作的
如果把这两类内容混在一起，文件最后只会变成一团糨糊。一半太泛，一半太局部，而 Claude 每做一个任务都得背着整包上下文。
Anthropic 也建议把这些文件写得简洁一点。这点我同意。过长的指令文件，往往像是有人想把整本工程手册一股脑塞进提示词里，通常不会有好结果。
会话进行到一半时会出什么问题
规则有帮助，但救不了一场已经乱掉的会话。
如果我花了二十条消息讨论某个子系统，然后突然切到另一个完全不同的问题，Claude 还是可能卡在前面的思路里。这很正常。我不会把一条长对话当成必须一直续下去的东西。
所以我的实际做法是：
- 当任务从探索切到实现时，开一个新会话
- 当问题从一个子系统跳到另一个完全不同的子系统时，开一个新会话
- 让项目指令足够简短，免得我在每一轮都要额外消耗上下文
这也是我为什么喜欢用 markdown 文件来记计划和笔记。如果任务很大，我宁可把当前状态明确存下来，也不愿意赌一条超长会话能一直保持干净。
我实际采用的 Claude Code 规则落地顺序
如果今天让我从零开始重新设置，我会按这个顺序来。
1. 创建 ~/.claude/CLAUDE.md
先写那些你不会退让的规则。不是人生建议，也不是工程宣言，只写那些会在不同仓库里反复起作用的东西。
对我来说，这包括：
- 严格类型
- 显式错误处理
- 尽量小的改动
- 不要静默加兜底逻辑
- 把文档字符串（
docstring）放在该放的地方 - 非交互式终端习惯
光是这些，对输出结果的影响就已经比大多数提示词技巧更大。
2. 添加项目级 CLAUDE.md
把命令、架构、命名和边界写进仓库里的文件。Anthropic 提供了 /init 来起草一版，这确实有用。但我之后还是会手动改，因为自动生成的内容只是草稿，不是成品。
3. 保持项目规则简短
不要把项目文件写成你个人文件的第二份拷贝。把仓库特有的命令、架构说明和本地约定放在这里，把长期稳定的个人偏好留在全局文件里。
为什么这比花哨的提示词技巧更重要
很多关于 AI 编码助手“终极配置”的内容，很快就会滑向一种表演式的复杂化。
真正改善我日常工作的，其实简单得多：
- 一个稳定的用户级
CLAUDE.md - 一个干净的项目级
CLAUDE.md
这套组合会让 Claude 更稳。随机冒出来的兜底逻辑更少，自作聪明的抽象更少，也更少出现那种过了十分钟我才发现 Claude 和我其实在解决两个略微错位的问题的情况。
如果你同时在用几个 AI 编码工具，别的产品上也会出现同样的模式。产品不同，结论一样：把基线一次讲清楚，别每天早上重新谈判。
如果你还想看配套文章，可以从这里继续：
