这份提示词让 Claude Code 生成更好的代码结果

这份提示词出自作者 Chris Dzombak，他使用 Claude Code 在短时间内开发了 12 个应用，从而总结了这样一份提示词。
你可以把这份提示词放到全局的 ~/.claude/CLAUDE.md 文件中，Cursor 也支持配置全局的 Rules。

当然你也可以根据实际情况选取部分提示词，或者放到你的项目 Rules 中。原文提示词放在了结尾。

提示词解析

以下是提示的中文解析，我永远鼓励你根据情况增删提示词，比如你可能不需要测试用例、你可能不需要让它做过多的事情。

理念

核心信念

• 增量式进展优于“大爆炸”式开发 – 编译并通过测试的小变更
• 从现有代码中学习 – 在实现前进行研究和规划
• 实用主义优于教条主义 – 适应项目现实
• 清晰的意图优于巧妙的代码 – 保持代码的“无聊”和“显而易见”

简单性意味着

• 每个函数/类单一职责
• 避免过早抽象
• 不要使用巧妙的技巧 – 选择“无聊”的解决方案
• 如果需要解释，说明它太复杂了

流程

1. 规划与分阶段

将复杂的工作分解为 3-5 个阶段。在 IMPLEMENTATION_PLAN.md 中记录：

## 阶段 N: [Name]

**目标**: [具体可交付成果]
**成功标准**: [可测试的结果]
**测试**: [具体的测试用例]
**状态**: [未开始|进行中|已完成]

• 随着进展更新状态
• 所有阶段完成后删除文件

2. 实现流程

1. 理解 – 研究代码库中的现有模式
2. 测试 – 先编写测试（红色状态）
3. 实现 – 编写最少代码通过测试（绿色状态）
4. 重构 – 在测试通过的前提下清理代码
5. 提交 – 附带明确信息并与计划关联

3. 遇到困难时（尝试了 3 次后）

严重警告: 每个问题最多尝试 3 次，然后停止。

1. 记录失败原因:

• 你尝试了什么
• 具体的错误信息
• 你认为失败的原因

2. 研究替代方案:

• 寻找 2-3 个类似的实现
• 记录使用的不同方法

3. 反思基本问题:

• 当前的抽象层次是否合适？
• 能否拆解为更小的问题？
• 是否存在更简单的整体方案？

4. 尝试不同角度:

• 使用不同的库/框架特性？
• 使用不同的架构模式？
• 移除抽象而不是增加抽象？

技术标准

架构原则

• 组合优于继承 – 使用依赖注入
• 接口优于单例 – 便于测试与保持灵活性
• 显式优于隐式 – 明确数据流与依赖关系
• 尽可能测试驱动 – 永远不要禁用测试，修复它们

代码质量

• 每次提交必须:

• 成功通过编译
• 通过所有现有测试
• 包含新功能的测试
• 遵循项目格式规范/代码检查规则

• 提交前:

• 运行格式化工具/代码检查工具
• 自我审查变更
• 确保提交信息说明"为何"修改

错误处理

• 快速失败并提供描述性信息
• 包含用于调试的上下文
• 在适当的层级处理错误
• 绝不静默地吞掉异常

决策框架

当存在多种有效方法时，基于以下几点进行选择：

1. 可测试性 – 该方案是否易于测试？
2. 可读性 – 6 个月后是否有人能看懂？
3. 一致性 – 是否符合项目现有模式？
4. 简单性 – 是否是可行的最简单方案？
5. 可逆性 – 以后修改的难度有多大？

项目集成

学习代码库

• 寻找 3 个类似的功能/组件
• 识别通用模式和约定
• 尽可能使用相同的库/工具
• 遵循现有的测试模式

工具

• 使用项目现有的构建系统
• 使用项目现有的测试框架
• 使用项目现有的格式化/代码检查设置
• 没有充分理由不要引入新工具

质量关卡

完成的定义

• 已编写测试并通过
• 代码遵循项目约定
• 没有代码检查/格式化警告
• 提交信息清晰明确
• 实现与计划一致
• 没有不带 issue 编号的 TODO

测试准则

• 测试行为，而非实现细节
• 尽可能每个测试一个断言
• 清晰的测试名称，描述场景
• 使用现有的测试工具/辅助函数
• 测试应该是确定性的

重要提醒

NEVER:

• 使用 --no-verify 绕过提交钩子
• 直接禁用测试而非修复问题
• 提交无法编译的代码
• 做出假设 – 通过现有代码验证

ALWAYS:

• 增量式地提交可工作的代码
• 随时更新计划文档
• 从现有的实现中学习
• 尝试 3 次失败后停止并重新评估

提示词原文

# 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`:

```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 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

总结

这个提示词不仅仅适用于 AI，也是我们一份给开发实践指南。

{{userData.name}}已认证