CLAUDE.md 最佳实践:10 个必写章节让你的 AI 编程效率翻倍
CLAUDE.md 是 Claude Code 理解项目上下文的核心文件。它相当于 AI 的”项目入职指南”——当 Claude 在项目中编写或修改代码时,第一件事就是读取 CLAUDE.md 文件。本文分享如何编写一份高质量的 CLAUDE.md,让 AI 编程效率倍增。
CLAUDE.md 文件位置与格式
CLAUDE.md 文件通常放在项目根目录。例如,如果你在使用 React 项目,目录结构应该是:
文件本身是 Markdown 格式。Anthropic 官方文档指出,CLAUDE.md 是 Claude Code 项目记忆的一部分,在每次对话开始时加载,Claude 将其视为上下文信息而非硬性约束。
基础的 CLAUDE.md 示例:
## Project Overview
项目的简短说明。
## Tech Stack
- TypeScript
- Next.js
- Tailwind
- ShadCN
## Architecture
解释文件夹结构和设计模式。
## Coding Rules
- 使用函数式 React 组件
- 优先使用服务端组件
- 使用 Tailwind 工具类而非自定义 CSS
## Design System
- 遵循 ShadCN 设计模式
- 使用 /styles/tokens.ts 中的令牌
## Commands
- 开发:npm run dev
- 构建:npm run build
10 个关键章节详解
虽然每个项目不同,但以下 10 个章节对大多数项目都适用:
1. 项目概述(Project Overview)
这是最有价值的部分,为 Claude 建立上下文。用通俗语言说明:
- 产品是什么
- 目标用户是谁
- 应用优化的核心目标
- 最重要的业务或 UX 约束
最佳实践: 保持简短精炼,Claude 更擅长处理清晰的心理模型而非长篇品牌故事。
❌ 差的做法:
公司的长篇历史故事
"我们重视创新"之类的空泛陈述
与实现无关的营销文案
✅ 好的做法:
"这是一个面向运营经理的 B2B 分析仪表盘。"
"核心目标:缩短从数据到洞察的时间。"
示例:
## Project Overview
本项目是一个面向产品设计师的 AI 落地页生成和优化 Web 应用。
主要用户是创业公司创始人和营销人员,追求快速获得高质量输出。
产品优化目标:
- 视觉精致度
- 迭代速度
- 干净响应式代码
- 工程交接便利性
避免过度工程化,优先简洁而非炫技。
💡 提示: 此章节应让 Claude 能回答”这是什么样的产品,它应该优化什么?”
2. 技术栈(Tech Stack)
这一部分能避免大量错误假设。没有它,Claude 可能会引入技术上正确但不符合你项目的库。
最佳实践: 明确列出实际使用的技术,并注明禁止使用的技术。
## Tech Stack
- Next.js 15 with App Router
- TypeScript
- Tailwind CSS
- shadcn/ui
- React Hook Form + Zod (表单处理)
- Supabase (认证与数据)
- Vitest (单元测试)
除非明确要求,否则不要引入:
- Redux
- styled-components
- Material UI
3. 架构(Architecture)
教 Claude 了解仓库的组织方式。需要描述:
- 主要目录及其职责
- 数据流向
- 关注点分离原则
- 新代码应该放在哪里
最佳实践: 重点描述决策规则,而非仅仅列出文件夹名。
## Architecture
- `app/` 包含路由和服务端组件
- `components/ui/` 包含可复用的设计系统组件
- `components/marketing/` 包含落地页区块
- `lib/` 包含工具函数、API 助手和共享配置
- `features/` 包含特定功能的业务逻辑
- `types/` 包含共享 TypeScript 类型
规则:
- 页面级组合放在路由文件中
- 重复 UI 提取为可复用组件
- 尽量将副作用排除在 UI 组件之外
- 除非需要客户端交互,否则优先服务端数据获取
4. 编码规范(Coding Conventions)
这与项目概述并列最重要的章节,直接影响 Claude 产出代码的质量。
最佳实践: 使用明确的规则而非模糊偏好。
❌ 弱: “写干净的代码” ✅ 强: “除了路由文件,一律使用具名导出”
## Coding Conventions
- 严格使用 TypeScript,避免 `any`
- 优先使用函数式组件
- 共享模块使用具名导出
- 使用 async/await 代替链式 Promise
- 保持组件专注和可组合
- 将重复逻辑提取为 hook 或工具函数
- 使用描述性变量名,避免缩写
- 仅在意图不明显时添加注释
- 不要遗留死代码或注释掉的代码块
5. UI 与设计系统规则
对于前端项目,这一章节非常关键。
## UI and Design Rules
- 默认使用 shadcn/ui 基础组件
- 偏好宽敞布局和强视觉层次
- 克制使用颜色,依赖字体排印、间距和对比度
- 使用 8px 间距节奏
- 按钮应有明确的主/次层级
- 表单应简洁、可扫描、移动友好
- 每个交互元素必须有可见的 hover、focus 和 disabled 状态
- 满足对比度、标签和键盘导航的无障碍标准
💡 提示: 不要只说”做得现代一点”,这没有操作意义。始终将风格转化为实现指导。
6. 内容与文案指南
这个章节常被低估,但对落地页和产品类项目尤其重要。
最佳实践: 说明文案风格应如何呈现,并提供优秀示例。
## Content Guidelines
- 使用简洁、自信的语言
- 避免夸大和空洞的营销用语
- 标题先求清晰再求巧妙
- 正文聚焦用户收益
- 优先使用短段落和可扫描结构
- 避免行话,除非目标受众明确期望
7. 测试与质量门槛
Claude 需要知道工作完成的验证标准。
## Testing and Quality
在标记任务完成前:
- 运行类型检查
- 运行 lint
- 运行修改逻辑的相关测试
测试规则:
- 为可复用逻辑添加单元测试
- 不要为简单的展示区块添加繁重的测试脚手架
- 确保 UI 变更的响应式行为
- 验证空状态、加载状态和错误状态
8. 文件与组件放置规则
这一独立章节能有效防止仓库结构混乱,尤其在成熟项目中。
## File Placement Rules
- 新的落地页区块添加到 `components/marketing/sections`
- 可复用的基础组件添加到 `components/ui`
- 共享工具函数放在 `lib`
- 不要为一次性使用创建新的抽象层
- 优先编辑现有组件,而非创建近似的副本
9. 安全变更规则
告诉 Claude 哪些内容不应随意修改,减少”技术上正确但操作上风险高”的编辑。
## Safety Rules
- 除非明确要求,不要重命名公开 API 路由
- 不要修改数据库 schema,除非明确说明
- 除非任务需要,不要修改认证流程
- 保持共享组件的向后兼容性
- 在实现重大架构变更前先标记出来
10. 具体命令(Specific Commands)
Anthropic 建议给 Claude 具体的项目操作命令。
## Commands
- 安装依赖:`pnpm install`
- 开发:`pnpm dev`
- 构建:`pnpm build`
- Lint:`pnpm lint`
- 类型检查:`pnpm typecheck`
- 测试:`pnpm test`
总结
一份好的 CLAUDE.md 文件能让 Claude Code 在项目中如鱼得水。关键在于:
- 清晰优于全面 — 精炼的心理模型比冗长的描述更有用
- 规则要可执行 — Claude 需要能自动遵循的明确规则
- 禁止比允许更重要 — 明确说不用什么,和说明用什么同样重要
- 保持更新 — CLAUDE.md 要随着项目演进及时更新
如果你已经在使用 Claude Code,花 30 分钟写一份好的 CLAUDE.md,它会以更高质量的代码产出回馈你。
版权所有,本作品采用知识共享署名-非商业性使用 3.0 未本地化版本许可协议进行许可。转载请注明出处:https://www.wangjun.dev//2026/05/claude-md-best-practices/

