从12个项目总结出的Claude Code最佳实践指南

最近国外有个开发者，利用AI 编程工具在短时间内开发了12个应用，总结了一份提示词并分享出来了，今天就来解析一下这份提示词。

理念

核心理念

• 渐进优于颠覆- 确保小改动能编译通过测试
• 从现有代码学习- 实施前先研究规划
• 务实而非教条- 适应项目实际情况
• 意图清晰优于代码巧妙- 选择简单明了的方案

简单性原则

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

流程

1. 规划

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

## 阶段N: [名称]
**目标**: [具体交付物]
**成功标准**: [可测试结果]
**测试**: [具体测试用例]
**状态**: [未开始|进行中|完成]

2. 实现

1. 理解- 研究代码库现有模式
2. 测试- 先写测试
3. 实现- 最小编码通过测试
4. 重构- 在测试通过前提下优化
5. 提交- 附带说明关联计划的清晰信息

3. 遇到阻碍时

当每个问题最多尝试3次，如果还没修复，就立即停止下来：

1. 记录失败情况：

• 尝试了哪些方法
• 具体错误信息
• 认为失败的原因

• 研究替代方案：
• 寻找2-3个类似实现
• 记录采用的不同方法
• 质疑基础假设：
• 抽象层级是否合适？
• 能否拆分为更小问题？
• 是否存在更简单的整体方案？
• 尝试不同角度：
• 使用不同库/框架功能？
• 采用不同架构模式？
• 移除而非增加抽象？

技术原则

架构原则

• 组合优于继承- 使用依赖注入
• 接口优于单例- 便于测试和灵活调整
• 显式优于隐式- 明确数据流和依赖关系
• 尽可能测试驱动- 绝不禁用测试，而是修复

代码质量

• 每次提交必须：
• 成功编译或运行
• 通过所有现有测试
• 包含新功能测试
• 遵循项目格式/linter要求
• 提交前：
• 运行格式化/linter工具
• 自我审查变更
• 确保提交信息说明"原因"

错误处理

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

决策理念

存在多个有效方案时，基于以下标准选择：

1. 可测试性- 能否轻松测试？
2. 可读性- 半年后他人能否理解？
3. 一致性- 是否符合项目模式？
4. 简洁性- 这是最简单的可行方案吗？
5. 可逆性- 后续修改难度如何？

项目集成

熟悉代码库

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

工具使用

• 使用项目现有构建系统
• 使用项目测试框架
• 使用项目格式化/linter设置
• 无充分理由不引入新工具

重要提醒

绝不：

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

始终：

• 增量提交可工作代码
• 随进度更新计划文档
• 从现有实现学习
• 3次失败后停止并重新评估

总结

你完全可以根据你的项目情况，对这份提示词做部分修改，或者直接放到你的rules或者CLAUDE.md中，进一步提升AI编码的效率！