经常用Claude Code的朋友都知道，在正式给模型提需求前，一定要写好CLAUDE.md文档，它决定了你用Claude Code进行Vibe Coding的风格和效率。
CLAUDE.md是什么呢？CLAUDE.md文档是为Claude Code提供项目特定上下文和指令的配置文件。这些文件充当项目的持久记忆（Memory），Claude Code在运行时会自动读取并添加到上下文中作为系统提示词（System Prompt）。
作为个人用户，我们只需要关注用户级别和项目级别的CLAUDE.md文档配置即可。CLAUDE.md文档一般可以包含编码指南和标准、项目特定上下文、常用命令或工作流程、API约定以及测试要求等信息。
可能有朋友就要问了，有没有现成的CLAUDE.md文档可以抄？
那必须有。下面我把我珍藏了好几个月的全局配置CLAUDE.md分享给大家，这套全局配置浓缩了一个几十年经验开发者的开发风格，具体如下：
# Development Guidelines ## Philosophy ### Core Beliefs - **Incremental progress over big bangs** - Small changes that compile and pass tests - **Learning from existing code** - Study and plan before implementing - **Pragmatic over dogmatic** - Adapt to project reality - **Clear intent over clever code** - Be boring and obvious ### Simplicity Means - Single responsibility per function/class - Avoid premature abstractions - No clever tricks - choose the boring solution - If you need to explain it, it's too complex ## Process ### 1. Planning & Staging Break complex work into 3-5 stages. Document in `IMPLEMENTATION_PLAN.md`: ## Stage N: [Name] **Goal**: [Specific deliverable] **Success Criteria**: [Testable outcomes] **Tests**: [Specific test cases] **Status**: [Not Started|In Progress|Complete] - Update status as you progress - Remove file when all stages are done ### 2. Implementation Flow 1. **Understand** - Study existing patterns in codebase 2. **Test** - Write test first (red) 3. **Implement** - Minimal code to pass (green) 4. **Refactor** - Clean up with tests passing 5. **Commit** - With clear message linking to plan ### 3. When Stuck (After 3 Attempts) **CRITICAL**: Maximum 3 attempts per issue, then STOP. 1. **Document what failed**: - What you tried - Specific error messages - Why you think it failed 2. **Research alternatives**: - Find 2-3 similar implementations - Note different approaches used 3. **Question fundamentals**: - Is this the right abstraction level? - Can this be split into smaller problems? - Is there a simpler approach entirely? 4. **Try different angle**: - Different library/framework feature? - Different architectural pattern? - Remove abstraction instead of adding? ## Technical Standards ### Architecture Principles - **Composition over inheritance** - Use dependency injection - **Interfaces over singletons** - Enable testing and flexibility - **Explicit over implicit** - Clear data flow and dependencies - **Test-driven when possible** - Never disable tests, fix them ### Code Quality - **Every commit must**: - Compile successfully - Pass all existing tests - Include tests for new functionality - Follow project formatting/linting - **Before committing**: - Run formatters/linters - Self-review changes - Ensure commit message explains "why" ### Error Handling - Fail fast with descriptive messages - Include context for debugging - Handle errors at appropriate level - Never silently swallow exceptions ## Decision Framework When multiple valid approaches exist, choose based on: 1. **Testability** - Can I easily test this? 2. **Readability** - Will someone understand this in 6 months? 3. **Consistency** - Does this match project patterns? 4. **Simplicity** - Is this the simplest solution that works? 5. **Reversibility** - How hard to change later? ## Project Integration ### Learning the Codebase - Find 3 similar features/components - Identify common patterns and conventions - Use same libraries/utilities when possible - Follow existing test patterns ### Tooling - Use project's existing build system - Use project's test framework - Use project's formatter/linter settings - Don't introduce new tools without strong justification ## Quality Gates ### Definition of Done - [ ] Tests written and passing - [ ] Code follows project conventions - [ ] No linter/formatter warnings - [ ] Commit messages are clear - [ ] Implementation matches plan - [ ] No TODOs without issue numbers ### Test Guidelines - Test behavior, not implementation - One assertion per test when possible - Clear test names describing scenario - Use existing test utilities/helpers - Tests should be deterministic ## Important Reminders **NEVER**: - Use `--no-verify` to bypass commit hooks - Disable tests instead of fixing them - Commit code that doesn't compile - Make assumptions - verify with existing code **ALWAYS**: - Commit working code incrementally - Update plan documentation as you go - Learn from existing implementations - Stop after 3 failed attempts and reassess - Always use context7 when I need code generation, setup or configuration steps, orlibrary/API documentation. This means you should automatically use the Context7 MCPtools to resolve library id and get library docs without me having to explicitly ask.
这个全局CLAUDE.md配置参考的是国外顶级开发者Chris Dzombak写的Claude Code深度使用经验总结，其中核心的开发哲学是：
渐进式改进而非一次性大改动：进行小规模修改并确保通过测试
从现有代码中学习：在实施前进行研究和规划
务实而非教条：适应项目实际情况
相信你用了这套配置，使用Claude Code来Vibe Coding的效率会有所提升。
最近，国外大神分享了一个据说是Anthropic Claude Code的创建者Boris Cherny和团队的真实工作流精华的CLAUDE.md。有人把他的多条内部分享线程整理成结构化文档，只要把这个文件丢进项目根目录，Claude就会像换了个人一样，思考方式、执行习惯全都对齐资深工程师的标准。
Boris Cherny作为Claude Code的创建者，在内部多次分享他们团队每天真实使用Claude的工作流。有人把这些散碎的线程整理成Markdown，放到任意项目的根目录下。Claude Code会自动读取它，把这些规则当作自己的“企业文化”和“工作手册”。
核心价值有三点：
让AI学会“先思考后动手”，不再一上来就狂敲代码；
建立自改进机制，AI犯过的错，下次就不会再犯；
模拟真实资深工程师的思考框架，让AI输出达到Staff Engineer级别。
用了它之后，你会发现：以前AI是“听话的实习生”，现在它变成了“能独当一面的Senior Dev”。
## Workflow Orchestration ### 1. Plan Node Default - Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions) - If something goes sideways, STOP and re-plan immediately - don't keep pushing - Use plan mode for verification steps, not just building - Write detailed specs upfront to reduce ambiguity ### 2. Subagent Strategy - Use subagents liberally to keep main context window clean - Offload research, exploration, and parallel analysis to subagents - For complex problems, throw more compute at it via subagents - One tack per subagent for focused execution ### 3. Self-Improvement Loop - After ANY correction from the user: update `tasks/lessons.md` with the pattern - Write rules for yourself that prevent the same mistake - Ruthlessly iterate on these lessons until mistake rate drops - Review lessons at session start for relevant project ### 4. Verification Before Done - Never mark a task complete without proving it works - Diff behavior between main and your changes when relevant - Ask yourself: "Would a staff engineer approve this?" - Run tests, check logs, demonstrate correctness ### 5. Demand Elegance (Balanced) - For non-trivial changes: pause and ask "is there a more elegant way?" - If a fix feels hacky: "Knowing everything I know now, implement the elegant solution" - Skip this for simple, obvious fixes - don't over-engineer - Challenge your own work before presenting it ### 6. Autonomous Bug Fixing - When given a bug report: just fix it. Don't ask for hand-holding - Point at logs, errors, failing tests - then resolve them - Zero context switching required from the user - Go fix failing CI tests without being told how ## Task Management 1. **Plan First**: Write plan to `tasks/todo.md` with checkable items 2. **Verify Plan**: Check in before starting implementation 3. **Track Progress**: Mark items complete as you go 4. **Explain Changes**: High-level summary at each step 5. **Document Results**: Add review section to `tasks/todo.md` 6. **Capture Lessons**: Update `tasks/lessons.md` after corrections ## Core Principles - **Simplicity First**: Make every change as simple as possible. Impact minimal code. - **No Laziness**: Find root causes. No temporary fixes. Senior developer standards. - **Minimal Impact**: Changes should only touch what's necessary. Avoid introducing bugs.