Update avaliable. Click RELOAD to update.
📱 安装应用到主屏幕,获得更好体验
目录

CLAUDE.md 最佳实践:10 个必写章节让你的 AI 编程效率翻倍

CLAUDE.md 最佳实践

CLAUDE.md 是 Claude Code 理解项目上下文的核心文件。它相当于 AI 的”项目入职指南”——当 Claude 在项目中编写或修改代码时,第一件事就是读取 CLAUDE.md 文件。本文分享如何编写一份高质量的 CLAUDE.md,让 AI 编程效率倍增。

CLAUDE.md 文件位置与格式

CLAUDE.md 文件通常放在项目根目录。例如,如果你在使用 React 项目,目录结构应该是:

CLAUDE.md 文件位置

文件本身是 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 建立上下文。用通俗语言说明:

最佳实践: 保持简短精炼,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 在项目中如鱼得水。关键在于:

  1. 清晰优于全面 — 精炼的心理模型比冗长的描述更有用
  2. 规则要可执行 — Claude 需要能自动遵循的明确规则
  3. 禁止比允许更重要 — 明确说不用什么,和说明用什么同样重要
  4. 保持更新 — CLAUDE.md 要随着项目演进及时更新

如果你已经在使用 Claude Code,花 30 分钟写一份好的 CLAUDE.md,它会以更高质量的代码产出回馈你。

版权所有,本作品采用知识共享署名-非商业性使用 3.0 未本地化版本许可协议进行许可。转载请注明出处:https://www.wangjun.dev//2026/05/claude-md-best-practices/