手写一个 CLAUDE.md——从空白到最佳实践上篇我们聊了 CLAUDE.md 的概念——它是给 AI 看的项目手册告诉 AI 你的项目怎么跑、有什么约定。但概念归概念真让你写你可能还是不知道从哪里下笔。这篇我们用一个真实的前端项目为例从空白开始一步步写出一份高质量的 CLAUDE.md。2.1 先认识我们的项目假设你有一个电商后台管理系统技术栈是框架React 18 Next.js 14 (App Router) 语言TypeScript (strict mode) 样式Tailwind CSS 状态管理Zustand API 请求React Query axios 测试Vitest Testing Library 包管理pnpm 目录src/ 下的标准 Next.js 结构这是一个很常见的项目结构。没有 CLAUDE.md 的时候你让 Claude “帮我加一个用户列表页面”它生成的代码可能用的是 class component、CSS 文件放在 styles/ 下、API 请求直接写在组件里——完全不匹配你的项目风格。每次你都得纠正它“我们用函数组件”“API 放 services/ 下”“不要用 CSS 文件用 Tailwind”。有了 CLAUDE.md这些只需要写一次。2.2 第一步项目概览先把项目的基本信息告诉 AI。不用长篇大论几句话说清楚就行。# 电商后台管理系统 面向公司内部运营团队的后台系统管理订单、商品、用户和数据报表。为什么要写面向公司内部因为 AI 可能会默认这是一个公开产品考虑 SEO、SSR、性能优化——这些都是不必要的。让 AI 知道使用场景它的建议会更对路。2.3 第二步技术栈技术栈是 CLAUDE.md 最重要的部分之一。写清楚 AI 就不会推荐错误的技术方案。## 技术栈 ### 核心 - React 18 Next.js 14 (App Router) - TypeScriptstrict modeeslint 配置在项目根目录 - Tailwind CSS ### 状态与数据 - Zustand全局状态 - React Query v5服务端状态和缓存 - axiosHTTP 客户端 - zod运行时类型校验 ### 测试 - Vitest React Testing Library - PlaywrightE2E 测试 ### 工具 - pnpm包管理禁止使用 npm 或 yarn - ESLint Prettier - husky lint-staged这里有一个细节版本号。React Query v4 和 v5 的 API 差别很大写清楚版本号AI 生成的代码就不会用错 API。还有一个更重要的细节禁止事项。“禁止使用 npm 或 yarn”——如果你不写这一句AI 可能哪天就给你跑了个npm install把你的pnpm-lock.yaml搞乱。2.4 第三步开发命令把日常命令都列出来AI 就不用猜了。特别是那些不常用的命令——AI 记不住pnpm vitest --coverage但你写在 CLAUDE.md 里它就知道了。## 开发命令 # 安装 pnpm install # 安装依赖新增依赖也要用 pnpm add pnpm update # 更新依赖 # 开发 pnpm dev # 启动开发服务器 → http://localhost:3000 pnpm build # 生产构建 pnpm start # 启动生产服务器 # 代码质量 pnpm lint # ESLint 检查 pnpm lint:fix # ESLint 自动修复 pnpm type-check # TypeScript 类型检查 pnpm format # Prettier 格式化 # 测试 pnpm test # 运行单元测试 pnpm test:watch # 监听模式 pnpm test:coverage # 覆盖率报告 pnpm test:e2e # E2E 测试 # 数据库 pnpm db:migrate # 运行数据库迁移 pnpm db:seed # 填充测试数据你可能会觉得这些太基础了AI 应该知道。但真实情况是AI 经常猜错命令。它可能猜npm start但实际上项目用的是pnpm dev。也可能会漏掉type-check这个重要步骤。每一条命令都是给 AI 省一次猜测。2.5 第四步编码规范这是最有价值的部分也是拉开差距的地方。## 编码规范 ### 组件 - 使用函数组件 Hooks禁止使用 class 组件 - 组件文件使用 PascalCaseUserProfile.tsx - 非组件文件使用 kebab-caseuser-api.ts - 每个组件一个文件 - 页面组件放在 app/ 目录下业务组件放在 components/ 下 ### TypeScript - 启用 strict mode - 禁止使用 any优先使用 unknown - API 请求和响应的类型定义在 types/api.ts - 共享类型定义在 types/ 目录下 ### 样式 - 使用 Tailwind CSS 类名禁止编写自定义 CSS 文件 - 复杂的样式使用 apply 指令提取到组件同级文件中 - 颜色使用 Tailwind 的预设色板不要使用十六进制颜色 ### API 请求 - 所有 API 请求放在 services/ 目录下 - 每个模块一个文件services/user.ts、services/order.ts - 使用 React Query 的 useQuery / useMutation - query key 统一管理在 lib/query-keys.ts ### 状态管理 - 全局状态用 Zustandstores/ 目录 - 服务端状态用 React Query - 组件内状态用 useState / useReducer - URL 参数用 useSearchParams ### Git - 使用 Conventional Commits 格式 - 分支命名feature/xxx、fix/xxx、chore/xxx - PR 标题格式type(scope): description看到区别了吗这些不是通用的 JavaScript 规范而是你的项目的专属规范。有些是常识“使用函数组件”但更多的是只有你的团队才知道的约定“query key 统一管理在 lib/query-keys.ts”“禁止使用十六进制颜色”。这些约定新人来了要学一两周写在 CLAUDE.md 里AI 一遍就学会了。2.6 第五步目录结构告诉 AI 代码放在什么地方它就不会把组件乱放了。## 目录结构 src/ ├── app/ # Next.js App Router │ ├── layout.tsx # 根布局 │ ├── page.tsx # 首页/登录页 │ ├── dashboard/ # 仪表盘页面 │ ├── orders/ # 订单管理 │ ├── products/ # 商品管理 │ └── users/ # 用户管理 ├── components/ # 共享组件 │ ├── ui/ # 基础 UI 组件Button、Modal、Table 等 │ ├── layout/ # 布局组件Sidebar、Header 等 │ └── shared/ # 业务共享组件 ├── services/ # API 请求 │ ├── http.ts # axios 实例和拦截器 │ ├── user.ts # 用户相关 API │ ├── order.ts # 订单相关 API │ └── product.ts # 商品相关 API ├── stores/ # Zustand stores ├── types/ # TypeScript 类型定义 ├── lib/ # 工具函数和配置 │ ├── query-keys.ts # React Query key 管理 │ └── utils.ts # 通用工具函数 ├── hooks/ # 自定义 Hooks └── styles/ # 全局样式Tailwind 配置目录结构写清楚之后你让 Claude “在订单管理页面加一个搜索功能”它会直接去src/app/orders/下找对应的文件而不是在pages/或者containers/下面新建文件。2.7 第六步边界与约束这一步很多人会忽略但它往往是 CLAUDE.md 里最有价值的部分。## 重要的约束 1. 不要修改 src/lib/ 下的文件除非有明确说明 2. lib/utils.ts 中的工具函数必须有单元测试覆盖 3. 数据库 schema 的修改必须同时更新 types/ 下的类型定义 4. 不要引入新的 npm 包除非经过技术评审 5. API 接口的字段命名使用 snake_case前端代码使用 camelCase 6. 所有新增文件必须包含 TypeScript 类型定义约束告诉 AI什么不能做这比告诉它能做什么更能避免问题。2.8 完整的 CLAUDE.md把前面六步拼起来就是一份高质量的 CLAUDE.md# 电商后台管理系统 面向公司内部运营团队的后台系统管理订单、商品、用户和数据报表。 ## 技术栈 ### 核心 - React 18 Next.js 14 (App Router) - TypeScriptstrict mode - Tailwind CSS ### 状态与数据 - Zustand全局状态 - React Query v5服务端状态 - axiosHTTP 客户端 - zod运行时类型校验 ### 工具 - pnpm包管理禁止使用 npm 或 yarn - Vitest React Testing Library - PlaywrightE2E 测试 - ESLint Prettier husky ## 开发命令 - pnpm dev — 启动开发端口 3000 - pnpm build — 生产构建 - pnpm test — 运行单元测试 - pnpm test:e2e — E2E 测试 - pnpm lint — ESLint 检查 - pnpm type-check — 类型检查 ## 编码规范 - 函数组件 Hooks禁止 class 组件 - 文件命名组件 PascalCase其他 kebab-case - 禁止使用 any优先 unknown - 使用 Tailwind禁止自定义 CSS 文件 - API 请求放 services/React Query key 管理在 lib/query-keys.ts - 全局状态用 Zustand服务端状态用 React Query ## 目录结构 src/ ├── app/ # 页面App Router ├── components/ # 共享组件 ├── services/ # API 请求 ├── stores/ # Zustand stores ├── types/ # 类型定义 ├── lib/ # 工具函数 ├── hooks/ # 自定义 Hooks └── styles/ # 全局样式 ## 约束 - 不要直接修改 lib/ 下的文件 - 新增依赖需经评审 - API 字段 snake_case前端代码 camelCase - 所有新增文件必须有类型定义这份 CLAUDE.md 大概 500 字。占用上下文不多但它能让 AI 生成的代码从一开始就符合你的项目标准。2.9 这些内容分别放在哪个层级你可能注意到了前面的六步都是在项目级 CLAUDE.md的视角下写的。但根据第 1 篇CLAUDE.md 有三个层级。那六步的内容是不是都应该放项目级不是。区分清楚什么放哪才能发挥分层管理的优势。放用户级~/.claude/CLAUDE.md跟个人习惯相关、跟项目无关的内容。# 我的个人偏好 - 代码使用双引号 - 注释用中文写 - Git commit 使用英文写 - 默认用 pnpm没有再用 npm什么时候用你有自己的一套写法习惯但不想强迫整个团队。比如团队规范用单引号但你个人偏好双引号——放用户级你自己的项目生效不影响团队。放项目级项目根目录/CLAUDE.md跟具体项目绑定的、所有团队成员都应该遵守的内容。步骤内容放项目级第一步项目概览项目用途和技术栈✅ 必须第二步技术栈框架、版本、工具✅ 必须第三步开发命令启动、测试、构建✅ 必须第四步编码规范团队规范✅ 必须第五步目录结构代码组织方式✅ 必须第六步边界约束什么不能做✅ 必须这些都应该放项目级。因为它们是项目本身的属性不随人变。放子目录级子目录/CLAUDE.md项目内特定模块或子包专用的信息。比如你的项目根目录的 CLAUDE.md 已经写了通用规范但apps/admin/目录下的后台管理有额外的规范# apps/admin/CLAUDE.md 本目录是后台管理系统跟前台应用不同 - 使用 Ant Design 组件库前台用 Tailwind - 所有页面都需要权限校验 - API 路径前缀是 /api/admin/ - 不需要考虑 SEO什么时候用monorepo 中的子包、大型项目中某个有特殊规范的模块。一张表看懂内容放哪原因个人代码风格偏好用户级跟项目无关项目技术栈和命令项目级所有人都要用团队编码规范项目级统一标准子模块特有规范子目录级不污染其他模块个人工作流偏好用户级不影响团队一个反例有人把个人偏好写进项目级的 CLAUDE.md# 项目 CLAUDE.md ## 技术栈 - React 18 - TypeScript ## 编码规范 - 使用双引号注这是张三的个人偏好其他人可以不遵守这就违背了 CLAUDE.md 的初衷——项目级应该写项目规范而不是个人偏好。如果张三离职了这条注释要不要删如果李四也用这个项目她看到可以不遵守会不会困惑正确的做法张三把使用双引号放自己的用户级 CLAUDE.md项目级只写团队统一认可的规范。2.10 写完怎么测试CLAUDE.md 写完了怎么知道它有没有效果几个简单的测试方法测试 1问项目信息这个项目用什么技术栈 怎么启动 测试怎么跑AI 应该能直接从 CLAUDE.md 中找到答案而不是猜测。测试 2让它生成代码帮我新建一个用户管理页面列出所有用户生成的代码应该文件放在src/app/users/下使用函数组件API 请求写在services/user.ts中使用 React Query 管理请求状态用 Tailwind 样式如果生成的代码在这些方面有偏差说明 CLAUDE.md 还需要补充或调整。测试 3检查约束帮我安装 react-selectAI 应该提醒你这个项目需要经过技术评审才能引入新依赖——因为 CLAUDE.md 里写了约束。2.10 小结写一份好的 CLAUDE.md 只需要六步项目概览这个项目是干什么的技术栈用什么技术、什么版本、什么禁止用开发命令所有常用命令包括不常用的编码规范你们团队独有的约定最有价值的部分目录结构代码放在哪约束什么不能做但写在哪同样重要项目规范技术栈、命令、编码规范→项目级模块特有规范子项目特殊规则→子目录级个人偏好代码风格、语言习惯→用户级 ~/.claude/CLAUDE.md每部分放对层级个人偏好不干扰项目规范项目规范不被个人偏好覆盖。CLAUDE.md 的价值在于——你写一次AI 每次都用。不像你口头交代说完了 AI 可能转头就忘。上一篇CLAUDE.md 是什么——AI 协作的项目手册
手写一个 CLAUDE.md——从空白到最佳实践
手写一个 CLAUDE.md——从空白到最佳实践上篇我们聊了 CLAUDE.md 的概念——它是给 AI 看的项目手册告诉 AI 你的项目怎么跑、有什么约定。但概念归概念真让你写你可能还是不知道从哪里下笔。这篇我们用一个真实的前端项目为例从空白开始一步步写出一份高质量的 CLAUDE.md。2.1 先认识我们的项目假设你有一个电商后台管理系统技术栈是框架React 18 Next.js 14 (App Router) 语言TypeScript (strict mode) 样式Tailwind CSS 状态管理Zustand API 请求React Query axios 测试Vitest Testing Library 包管理pnpm 目录src/ 下的标准 Next.js 结构这是一个很常见的项目结构。没有 CLAUDE.md 的时候你让 Claude “帮我加一个用户列表页面”它生成的代码可能用的是 class component、CSS 文件放在 styles/ 下、API 请求直接写在组件里——完全不匹配你的项目风格。每次你都得纠正它“我们用函数组件”“API 放 services/ 下”“不要用 CSS 文件用 Tailwind”。有了 CLAUDE.md这些只需要写一次。2.2 第一步项目概览先把项目的基本信息告诉 AI。不用长篇大论几句话说清楚就行。# 电商后台管理系统 面向公司内部运营团队的后台系统管理订单、商品、用户和数据报表。为什么要写面向公司内部因为 AI 可能会默认这是一个公开产品考虑 SEO、SSR、性能优化——这些都是不必要的。让 AI 知道使用场景它的建议会更对路。2.3 第二步技术栈技术栈是 CLAUDE.md 最重要的部分之一。写清楚 AI 就不会推荐错误的技术方案。## 技术栈 ### 核心 - React 18 Next.js 14 (App Router) - TypeScriptstrict modeeslint 配置在项目根目录 - Tailwind CSS ### 状态与数据 - Zustand全局状态 - React Query v5服务端状态和缓存 - axiosHTTP 客户端 - zod运行时类型校验 ### 测试 - Vitest React Testing Library - PlaywrightE2E 测试 ### 工具 - pnpm包管理禁止使用 npm 或 yarn - ESLint Prettier - husky lint-staged这里有一个细节版本号。React Query v4 和 v5 的 API 差别很大写清楚版本号AI 生成的代码就不会用错 API。还有一个更重要的细节禁止事项。“禁止使用 npm 或 yarn”——如果你不写这一句AI 可能哪天就给你跑了个npm install把你的pnpm-lock.yaml搞乱。2.4 第三步开发命令把日常命令都列出来AI 就不用猜了。特别是那些不常用的命令——AI 记不住pnpm vitest --coverage但你写在 CLAUDE.md 里它就知道了。## 开发命令 # 安装 pnpm install # 安装依赖新增依赖也要用 pnpm add pnpm update # 更新依赖 # 开发 pnpm dev # 启动开发服务器 → http://localhost:3000 pnpm build # 生产构建 pnpm start # 启动生产服务器 # 代码质量 pnpm lint # ESLint 检查 pnpm lint:fix # ESLint 自动修复 pnpm type-check # TypeScript 类型检查 pnpm format # Prettier 格式化 # 测试 pnpm test # 运行单元测试 pnpm test:watch # 监听模式 pnpm test:coverage # 覆盖率报告 pnpm test:e2e # E2E 测试 # 数据库 pnpm db:migrate # 运行数据库迁移 pnpm db:seed # 填充测试数据你可能会觉得这些太基础了AI 应该知道。但真实情况是AI 经常猜错命令。它可能猜npm start但实际上项目用的是pnpm dev。也可能会漏掉type-check这个重要步骤。每一条命令都是给 AI 省一次猜测。2.5 第四步编码规范这是最有价值的部分也是拉开差距的地方。## 编码规范 ### 组件 - 使用函数组件 Hooks禁止使用 class 组件 - 组件文件使用 PascalCaseUserProfile.tsx - 非组件文件使用 kebab-caseuser-api.ts - 每个组件一个文件 - 页面组件放在 app/ 目录下业务组件放在 components/ 下 ### TypeScript - 启用 strict mode - 禁止使用 any优先使用 unknown - API 请求和响应的类型定义在 types/api.ts - 共享类型定义在 types/ 目录下 ### 样式 - 使用 Tailwind CSS 类名禁止编写自定义 CSS 文件 - 复杂的样式使用 apply 指令提取到组件同级文件中 - 颜色使用 Tailwind 的预设色板不要使用十六进制颜色 ### API 请求 - 所有 API 请求放在 services/ 目录下 - 每个模块一个文件services/user.ts、services/order.ts - 使用 React Query 的 useQuery / useMutation - query key 统一管理在 lib/query-keys.ts ### 状态管理 - 全局状态用 Zustandstores/ 目录 - 服务端状态用 React Query - 组件内状态用 useState / useReducer - URL 参数用 useSearchParams ### Git - 使用 Conventional Commits 格式 - 分支命名feature/xxx、fix/xxx、chore/xxx - PR 标题格式type(scope): description看到区别了吗这些不是通用的 JavaScript 规范而是你的项目的专属规范。有些是常识“使用函数组件”但更多的是只有你的团队才知道的约定“query key 统一管理在 lib/query-keys.ts”“禁止使用十六进制颜色”。这些约定新人来了要学一两周写在 CLAUDE.md 里AI 一遍就学会了。2.6 第五步目录结构告诉 AI 代码放在什么地方它就不会把组件乱放了。## 目录结构 src/ ├── app/ # Next.js App Router │ ├── layout.tsx # 根布局 │ ├── page.tsx # 首页/登录页 │ ├── dashboard/ # 仪表盘页面 │ ├── orders/ # 订单管理 │ ├── products/ # 商品管理 │ └── users/ # 用户管理 ├── components/ # 共享组件 │ ├── ui/ # 基础 UI 组件Button、Modal、Table 等 │ ├── layout/ # 布局组件Sidebar、Header 等 │ └── shared/ # 业务共享组件 ├── services/ # API 请求 │ ├── http.ts # axios 实例和拦截器 │ ├── user.ts # 用户相关 API │ ├── order.ts # 订单相关 API │ └── product.ts # 商品相关 API ├── stores/ # Zustand stores ├── types/ # TypeScript 类型定义 ├── lib/ # 工具函数和配置 │ ├── query-keys.ts # React Query key 管理 │ └── utils.ts # 通用工具函数 ├── hooks/ # 自定义 Hooks └── styles/ # 全局样式Tailwind 配置目录结构写清楚之后你让 Claude “在订单管理页面加一个搜索功能”它会直接去src/app/orders/下找对应的文件而不是在pages/或者containers/下面新建文件。2.7 第六步边界与约束这一步很多人会忽略但它往往是 CLAUDE.md 里最有价值的部分。## 重要的约束 1. 不要修改 src/lib/ 下的文件除非有明确说明 2. lib/utils.ts 中的工具函数必须有单元测试覆盖 3. 数据库 schema 的修改必须同时更新 types/ 下的类型定义 4. 不要引入新的 npm 包除非经过技术评审 5. API 接口的字段命名使用 snake_case前端代码使用 camelCase 6. 所有新增文件必须包含 TypeScript 类型定义约束告诉 AI什么不能做这比告诉它能做什么更能避免问题。2.8 完整的 CLAUDE.md把前面六步拼起来就是一份高质量的 CLAUDE.md# 电商后台管理系统 面向公司内部运营团队的后台系统管理订单、商品、用户和数据报表。 ## 技术栈 ### 核心 - React 18 Next.js 14 (App Router) - TypeScriptstrict mode - Tailwind CSS ### 状态与数据 - Zustand全局状态 - React Query v5服务端状态 - axiosHTTP 客户端 - zod运行时类型校验 ### 工具 - pnpm包管理禁止使用 npm 或 yarn - Vitest React Testing Library - PlaywrightE2E 测试 - ESLint Prettier husky ## 开发命令 - pnpm dev — 启动开发端口 3000 - pnpm build — 生产构建 - pnpm test — 运行单元测试 - pnpm test:e2e — E2E 测试 - pnpm lint — ESLint 检查 - pnpm type-check — 类型检查 ## 编码规范 - 函数组件 Hooks禁止 class 组件 - 文件命名组件 PascalCase其他 kebab-case - 禁止使用 any优先 unknown - 使用 Tailwind禁止自定义 CSS 文件 - API 请求放 services/React Query key 管理在 lib/query-keys.ts - 全局状态用 Zustand服务端状态用 React Query ## 目录结构 src/ ├── app/ # 页面App Router ├── components/ # 共享组件 ├── services/ # API 请求 ├── stores/ # Zustand stores ├── types/ # 类型定义 ├── lib/ # 工具函数 ├── hooks/ # 自定义 Hooks └── styles/ # 全局样式 ## 约束 - 不要直接修改 lib/ 下的文件 - 新增依赖需经评审 - API 字段 snake_case前端代码 camelCase - 所有新增文件必须有类型定义这份 CLAUDE.md 大概 500 字。占用上下文不多但它能让 AI 生成的代码从一开始就符合你的项目标准。2.9 这些内容分别放在哪个层级你可能注意到了前面的六步都是在项目级 CLAUDE.md的视角下写的。但根据第 1 篇CLAUDE.md 有三个层级。那六步的内容是不是都应该放项目级不是。区分清楚什么放哪才能发挥分层管理的优势。放用户级~/.claude/CLAUDE.md跟个人习惯相关、跟项目无关的内容。# 我的个人偏好 - 代码使用双引号 - 注释用中文写 - Git commit 使用英文写 - 默认用 pnpm没有再用 npm什么时候用你有自己的一套写法习惯但不想强迫整个团队。比如团队规范用单引号但你个人偏好双引号——放用户级你自己的项目生效不影响团队。放项目级项目根目录/CLAUDE.md跟具体项目绑定的、所有团队成员都应该遵守的内容。步骤内容放项目级第一步项目概览项目用途和技术栈✅ 必须第二步技术栈框架、版本、工具✅ 必须第三步开发命令启动、测试、构建✅ 必须第四步编码规范团队规范✅ 必须第五步目录结构代码组织方式✅ 必须第六步边界约束什么不能做✅ 必须这些都应该放项目级。因为它们是项目本身的属性不随人变。放子目录级子目录/CLAUDE.md项目内特定模块或子包专用的信息。比如你的项目根目录的 CLAUDE.md 已经写了通用规范但apps/admin/目录下的后台管理有额外的规范# apps/admin/CLAUDE.md 本目录是后台管理系统跟前台应用不同 - 使用 Ant Design 组件库前台用 Tailwind - 所有页面都需要权限校验 - API 路径前缀是 /api/admin/ - 不需要考虑 SEO什么时候用monorepo 中的子包、大型项目中某个有特殊规范的模块。一张表看懂内容放哪原因个人代码风格偏好用户级跟项目无关项目技术栈和命令项目级所有人都要用团队编码规范项目级统一标准子模块特有规范子目录级不污染其他模块个人工作流偏好用户级不影响团队一个反例有人把个人偏好写进项目级的 CLAUDE.md# 项目 CLAUDE.md ## 技术栈 - React 18 - TypeScript ## 编码规范 - 使用双引号注这是张三的个人偏好其他人可以不遵守这就违背了 CLAUDE.md 的初衷——项目级应该写项目规范而不是个人偏好。如果张三离职了这条注释要不要删如果李四也用这个项目她看到可以不遵守会不会困惑正确的做法张三把使用双引号放自己的用户级 CLAUDE.md项目级只写团队统一认可的规范。2.10 写完怎么测试CLAUDE.md 写完了怎么知道它有没有效果几个简单的测试方法测试 1问项目信息这个项目用什么技术栈 怎么启动 测试怎么跑AI 应该能直接从 CLAUDE.md 中找到答案而不是猜测。测试 2让它生成代码帮我新建一个用户管理页面列出所有用户生成的代码应该文件放在src/app/users/下使用函数组件API 请求写在services/user.ts中使用 React Query 管理请求状态用 Tailwind 样式如果生成的代码在这些方面有偏差说明 CLAUDE.md 还需要补充或调整。测试 3检查约束帮我安装 react-selectAI 应该提醒你这个项目需要经过技术评审才能引入新依赖——因为 CLAUDE.md 里写了约束。2.10 小结写一份好的 CLAUDE.md 只需要六步项目概览这个项目是干什么的技术栈用什么技术、什么版本、什么禁止用开发命令所有常用命令包括不常用的编码规范你们团队独有的约定最有价值的部分目录结构代码放在哪约束什么不能做但写在哪同样重要项目规范技术栈、命令、编码规范→项目级模块特有规范子项目特殊规则→子目录级个人偏好代码风格、语言习惯→用户级 ~/.claude/CLAUDE.md每部分放对层级个人偏好不干扰项目规范项目规范不被个人偏好覆盖。CLAUDE.md 的价值在于——你写一次AI 每次都用。不像你口头交代说完了 AI 可能转头就忘。上一篇CLAUDE.md 是什么——AI 协作的项目手册
