CLAUDE.md咒语要学吗？解读Karpathy内部指南与AI编程未来

社区中有人基于Karpathy在X平台发表的看法，在GitHub上创建了andrej-karpathy-skills仓库，目前已经收获184K个星标：

https://github.com/multica-ai/andrej-karpathy-skills

我向来觉得这类通用规则似乎无需特意编写，大模型或AI编码工具迟早会内化这些准则。为此，我特意查看了Claude Code在用户全局级设置的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 & StagingBreak complex work into 3-5 stages. Document in `IMPLEMENTATION_PLAN.md`:```markdown## 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 Flow1. **Understand** - Study existing patterns in codebase2. **Test** - Write test first (red)3. **Implement** - Minimal code to pass (green)4. **Refactor** - Clean up with tests passing5. **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 failed2. **Research alternatives**:   - Find 2-3 similar implementations   - Note different approaches used3. **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 FrameworkWhen 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<!-- CODEGRAPH_START -->## CodeGraphIn repositories indexed by CodeGraph (a `.codegraph/` directory exists at the repo root), reach for it BEFORE grep/find or reading files when you need to understand or locate code:- **MCP tools** (when available): `codegraph_explore` answers most code questions in one call — the relevant symbols' verbatim source plus the call paths between them. `codegraph_node` returns one symbol's source + callers, or reads a whole file with line numbers. If the tools are listed but deferred, load them by name via tool search.- **Shell** (always works): `codegraph explore "<symbol names or question>"` and `codegraph node <symbol-or-file>` print the same output.If there is no `.codegraph/` directory, skip CodeGraph entirely — indexing is the user's decision.<!-- CODEGRAPH_END -->

不清楚这份文件是何时生成的，但对比网络上流传的各种“神奇咒语”，感觉内容其实大同小异吧。