1. 从“AI乱写”到“精准输出”为什么你需要 CLAUDE.md如果你最近在 VSCode 里用上了 Claude Code 或者 Cursor 这类 AI 编程助手大概率经历过这样的场景你满怀期待地让 AI 帮你写一个函数结果它给你生成了一堆看似正确、实则完全不符合你项目编码规范的代码。或者你让它重构一个模块它却自作主张地引入了你项目里根本不用的第三方库。更让人头疼的是每次开启一个新的对话你都得像教新人一样把“用 TypeScript”、“不要用any类型”、“遵循 Airbnb 代码规范”这些要求重复一遍。问题出在哪不是 AI 不够聪明而是它缺乏一个稳定、持久的“上下文记忆”。每次对话它都像一张白纸需要你重新描绘规则。而CLAUDE.md文件就是解决这个问题的“项目宪法”。它不是一个官方强制文件而是一个被社区广泛采纳的最佳实践一个放在项目根目录下的 Markdown 文件专门用来告诉 Claude Code以及兼容此约定的其他 AI 助手如 Cursor关于这个项目的一切规则、偏好和上下文。简单来说CLAUDE.md 是你的 AI 结对编程伙伴的“入职手册”和“工作指南”。有了它AI 的输出将变得高度可预测、高度符合项目要求从而将你的开发效率从“不断纠偏”提升到“心领神会”的层次。它解决的正是 AI 编程中“不稳定”和“需要反复调教”的核心痛点。2. CLAUDE.md 的核心价值不止于代码规范很多人把 CLAUDE.md 简单理解成一份代码风格说明书这大大低估了它的潜力。一个设计良好的 CLAUDE.md至少能在四个维度上显著提升你的 AI 编程体验2.1 建立稳定的上下文基线告别重复沟通这是最直接的价值。想象一下你团队里来了一个能力超强但记性不好的实习生每次给他派活你都得重新交代“我们公司用 GitLab代码提交流程是…”、“这个项目用 pnpm 包管理器别用 npm”、“接口响应格式统一是{ code, data, message }”。CLAUDE.md 就是一次性把这些信息写下来钉在墙上。AI 在分析你的项目、响应你的请求时会优先参考这份文件确保每次交互都基于同一套前提省去了你 80% 的重复性提示词输入。2.2 约束 AI 行为防止“自由发挥”带来的坑AI 模型基于海量数据训练它知道的“最佳实践”可能和你的项目现状冲突。比如你的老旧项目还在用 Vue 2 和 Options API但 AI 很可能倾向于生成 Vue 3 的 Composition API 代码。又或者你的后端 API 有特定的错误处理中间件但 AI 生成的请求代码可能用了它自己认为更“通用”的错误处理方式。通过在 CLAUDE.md 中明确声明技术栈版本、禁止使用的模式、必须遵循的架构你可以给 AI 划出明确的“行动边界”让它所有的生成和修改都在安全区内进行极大减少了引入技术债务或兼容性问题的风险。2.3 注入项目专属知识让 AI 成为“领域专家”每个项目都有独特的业务逻辑、领域术语和隐藏规则。比如你的电商项目里“SKU”和“SPU”有特定的数据结构和关联关系你的 CMS 里“文章”有一个特殊的“预发布”状态。这些知识通常散落在代码注释、文档或老员工的脑子里。CLAUDE.md 提供了一个集中的地方将这些领域知识Domain Knowledge以结构化的方式喂给 AI。当你对 AI 说“给这个商品 SKU 加个库存预警功能”它因为读过 CLAUDE.md 里对 SKU 模型的描述就能更准确地理解“商品 SKU”所指何物并生成贴合业务的代码。2.4 统一团队协作降低 AI 使用门槛在团队中如果每个成员都用自己的一套提示词和 AI 交互会导致代码风格、工具选择、甚至解决方案的碎片化。CLAUDE.md 作为一个版本控制的文件可以确保团队所有成员使用的 AI 助手都遵循同一套标准。新成员加入项目只要配置好 AI 插件并指向这个文件就能立刻获得与老成员一致的、高质量的 AI 辅助体验极大降低了团队整体的学习和协作成本。3. 手把手构建你的第一份 CLAUDE.md一份有效的 CLAUDE.md 不应该是一份冗长的“百科全书”而应该是一份精炼的“行动指南”。下面我将以一个虚构的全栈项目Node.js 后端 React 前端为例拆解 CLAUDE.md 的核心模块和编写要点。你可以以此为骨架填充自己项目的具体内容。3.1 项目概览与核心指令文件开头应该用最简洁的语言告诉 AI“我们是谁”和“最重要的规矩是什么”。这部分信息会被 AI 最高优先级地采纳。# 项目 AI 助手指南 (CLAUDE.md) **项目名称**Nexus 电商平台 **核心指令**在为本项目生成或修改任何代码、文档时必须严格遵守本文件的所有约定。任何与本文件冲突的建议都应被忽略并优先采用本文件的规定。 **首要原则** 1. **安全与稳定优先**禁止建议或使用任何已知存在安全隐患的包、模式或 API。所有代码变更需考虑向后兼容性。 2. **一致性至上**严格遵循项目中已存在的代码风格、目录结构和命名约定。不要引入不一致的新模式。 3. **询问澄清**如果需求模糊或存在多种实现可能应主动提问以澄清意图而不是自行选择一种可能不合适的方案。为什么这样写“核心指令”和“首要原则”用强语气设定了基调确保 AI 将本文件视为权威。“安全与稳定优先”是针对 AI 有时会推荐最新但不稳定库的倾向“一致性至上”是针对 AI 容易在每次对话中“创新”的问题“询问澄清”则是引导 AI 在不确定时与用户交互而不是瞎猜。3.2 技术栈与版本锁定这是避免兼容性问题的关键。必须明确到具体的主版本号。## 技术栈与版本 **后端 (Node.js)**: - Runtime: Node.js 18.x (LTS) - Framework: Express.js 4.x - ORM: Prisma 5.x - 语言: TypeScript (严格模式) - 包管理器: pnpm **前端 (Web)**: - Framework: React 18.x (仅限函数组件 Hooks) - 状态管理: Zustand - 构建工具: Vite 5.x - CSS 方案: Tailwind CSS 3.x clsx 组合类名 - 请求库: axios且必须使用项目封装的 /src/libs/request.ts 实例 **数据库**: PostgreSQL 15 **缓存**: Redis 7 (作为会话存储和热点数据缓存) **禁止使用的技术/模式** - 类组件 (Class Components) - any 类型 (TypeScript) - var 关键字 - eval() 或 Function 构造函数 - MongoDB (本项目关系型数据模型明确)经验之谈列出“禁止使用的技术/模式”比只列出“推荐使用的”更重要。AI 在训练时接触过各种方案明确禁止项可以防止它“灵机一动”引入不和谐的技术元素。例如明确禁止any类型能迫使 AI 在生成 TypeScript 代码时思考并明确定义类型提升代码质量。3.3 代码风格与规范这部分需要具体、可操作。直接引用你的 linter 和 formatter 配置是最佳实践。## 代码规范 **通用风格** - 缩进2 个空格。 - 字符串使用单引号 () 模板字符串除外。 - 行尾LF (\n)。 - 文件末尾保留一个空行。 **JavaScript/TypeScript** - 遵循项目根目录下的 .eslintrc.js 和 .prettierrc 配置。 - 导出优先使用命名导出 (export const func)而非默认导出。 - 类型必须显式定义函数参数、返回值及接口。使用 interface 而非 type 定义对象形状项目约定。 - 错误处理异步操作使用 try/catch同步错误使用 Result 模式参考 /src/utils/result.ts。 **命名约定** - 变量/函数camelCase - 类/类型/接口PascalCase - 常量UPPER_SNAKE_CASE - 私有类成员前缀 _ (如 _internalMethod) - 组件文件PascalCase (如 UserProfile.tsx) - 非组件工具文件kebab-case (如 format-date.ts) **CSS/Tailwind** - 优先使用 Tailwind 工具类。仅在需要复杂动态样式或复用性极高时才在 *.module.css 中编写自定义 CSS。 - 避免在 JSX 中使用 style 内联样式对象。实操技巧与其在 CLAUDE.md 里详细描述每一条规则不如直接告诉 AI“遵循某某配置文件”。这样当团队更新 ESLint 或 Prettier 规则时AI 的行为会自动同步更新无需修改 CLAUDE.md。同时像“使用interface而非type”这类项目特有的、无法通过工具强制执行的约定必须在这里明确写出。3.4 项目结构与关键路径帮助 AI 理解你的项目脉络知道代码应该放在哪里从哪里引用资源。## 项目结构说明nexus-platform/ ├── backend/ # Node.js 后端服务 │ ├── src/ │ │ ├── modules/ # 业务模块 (user, product, order) │ │ ├── libs/ # 通用库 (数据库客户端、工具函数) │ │ └── middleware/ # Express 中间件 │ └── prisma/ # Prisma schema 和迁移文件 ├── frontend/ # React 前端应用 │ ├── src/ │ │ ├── components/ # 通用 UI 组件 │ │ ├── features/ # 功能模块组件 (与路由相关) │ │ ├── hooks/ # 自定义 React Hooks │ │ ├── libs/ # 第三方库实例和适配器 │ │ ├── stores/ # Zustand 状态切片 │ │ └── types/ # 全局 TypeScript 类型定义 │ └── public/ # 静态资源 └── shared/ # 前后端共享代码 (如类型定义)**关键路径与别名** - / - 指向 frontend/src (在 Vite tsconfig.json 中配置) - #/ - 指向 backend/src (类似配置) - API 请求函数必须定义在对应功能模块的 api.ts 文件中例如 frontend/src/features/user/api.ts。 - 新增页面组件必须放置在 frontend/src/features/ 下对应的文件夹内并使用 lazy 加载。为什么有效明确的目录结构和路径别名能指导 AI 将新生成的代码文件放到正确的位置并正确引用其他模块。这避免了它随意创建文件或使用相对路径../../../这种难以维护的引用方式。3.5 领域模型与业务逻辑这是让你的 AI 助手从“通用程序员”变为“项目专家”的灵魂所在。## 核心领域概念 **用户系统** - 用户 (User) 有 id, email, hashedPassword, role 字段。 - role 枚举值为CUSTOMER, ADMIN, EDITOR。 - 用户身份验证使用 JWT (JSON Web Token)令牌存储在 HTTP-only Cookie 中。 **商品与库存** - 商品 (Product) 是抽象概念ProductVariant 才是可售卖的 SKU。 - 一个 Product 包含多个 ProductVariant (如不同颜色、尺寸)。 - 库存 (Inventory) 记录在 ProductVariant 级别。 - **重要业务规则**当库存低于 safetyStock (安全库存) 字段值时系统应记录日志并触发内部通知但前台仍可销售。 **订单流程** - 订单 (Order) 状态流PENDING - PAID - PROCESSING - SHIPPED - DELIVERED / CANCELLED。 - 状态只能向前推进或变为 CANCELLED不可回退。 - 支付成功后必须异步调用库存扣减服务 (InventoryService.deduct)。编写心得这部分内容来源于你的产品需求文档、数据库 Schema 和核心业务代码。不需要事无巨细只提炼最关键、最容易让 AI 产生误解的概念和规则。用简单的术语和伪代码描述业务规则比大段文字更有效。当 AI 理解了这些领域知识它生成的代码比如一个“创建订单”的函数就会自动包含库存检查、状态初始化等正确逻辑。3.6 AI 交互指令与提示词模板直接教 AI 如何与你合作定义一些常用的交互模式。## 与 AI 协作指南 **当接到任务时请按此流程思考** 1. **澄清需求**如果需求描述简短少于两句话请主动询问目标、输入、输出和边界条件。 2. **分析现状**检查相关模块的现有代码理解当前模式和数据结构。 3. **提供方案**给出 1-2 个实现方案并简要说明其优缺点。优先选择与现有架构一致的方案。 4. **生成代码**根据确定的方案生成完整、可运行的代码块。如果是修改现有文件请明确标出更改范围如使用 diff 格式。 **代码审查模式** 当我要求“审查这段代码”时请按以下顺序提供反馈 1. **安全性**有无潜在的安全漏洞如 SQL 注入、XSS、敏感信息泄露 2. **性能**有无明显的性能瓶颈如循环内重复计算、未优化的数据库查询 3. **是否符合本指南**检查代码风格、技术栈使用、项目结构是否符合上文规定。 4. **可读性与维护性**命名是否清晰函数是否过长逻辑是否过于复杂 5. **改进建议**提供具体的、可操作的改进代码片段。 **常用提示词模板** - **新增功能**“在 features/cart/ 目录下创建一个新的 React 组件 DiscountBanner.tsx用于展示购物车内的促销信息。它需要接收 cartTotal 作为 prop并根据总额决定显示哪条促销语。请使用 Tailwind 设计一个醒目的横幅样式。” - **修复 Bug**“用户报告在 UserProfile.tsx 页面提交表单时如果网络慢会重复提交。请分析 features/user/components/UserProfile.tsx 和相关的 api.ts找出问题并提供修复方案。” - **重构代码**“libs/utils/dateFormatter.js 这个文件混合了日期格式化和时区转换且是纯 JavaScript。请将其重构为 TypeScript拆分为 formatDate.ts 和 timezoneUtils.ts 两个文件并添加单元测试。”核心价值这部分将你平时需要反复输入的高质量提示词固化下来标准化了与 AI 的协作流程。尤其是“代码审查模式”给了 AI 一个清晰的检查清单使其反馈变得结构化、有重点极大提升了审查的价值和效率。4. 高级技巧让 CLAUDE.md 更智能、更强大基础版的 CLAUDE.md 已经能解决大部分问题。但如果你想榨干 AI 助手的潜力下面这些进阶技巧值得一试。4.1 分层与模块化为大型项目设计对于一个庞大的单体应用或微服务群一个巨大的 CLAUDE.md 文件可能难以维护。此时可以考虑分层结构根目录 CLAUDE.md存放全项目通用的规则如 Git 工作流、Docker 规范、公司级编码标准、通用领域词汇表。模块级.claudedir/目录在每个子项目或微服务目录下可以放置一个更具体的配置文件或者直接在该目录的README.md中开辟“AI 助手说明”章节覆盖该模块特有的技术栈和业务规则。AI 助手如 Claude Code通常会从当前打开文件所在目录向上查找 CLAUDE.md。利用这个特性你可以实现配置的继承和覆盖。例如后端服务目录下的规则可以继承根目录的通用规则同时定义自己必须使用Prisma而非Sequelize。4.2 动态上下文与agents.md或.cursorrules的配合CLAUDE.md定义的是静态的、项目级的上下文。而像.cursorrulesCursor 编辑器或agents.md一些高级 AI 工作流工具这类文件则用于定义动态的、任务级的指令。你可以这样区分和使用它们CLAUDE.md“我们这个项目用什么技术栈、怎么写规范、是什么业务。” ——长期记忆项目宪法。.cursorrules/agents.md“我现在要你专门做一件具体的事比如‘以测试驱动开发的方式为这个用户注册函数写测试’或者‘用简洁的英语为这个复杂函数写文档’。” ——短期指令任务模式。一个常见的实践是在CLAUDE.md的最后部分引用或建议几种常用的.cursorrules配置。例如## 附推荐的任务指令模板 当你需要进行特定类型工作时可以激活以下模式通过单独的指令或 .cursorrules 文件 **TDD 模式**优先编写失败的测试用例使用 Jest 和 React Testing Library然后实现最小化代码使其通过最后重构。 测试应覆盖正常流程和关键边界条件。**代码审查专家模式**专注于发现潜在 bug 和性能问题其次才是风格问题。 对每个问题提供严重等级高/中/低和具体的代码修复建议。**文档生成模式**为给定的代码生成 JSDoc 风格的注释。 为公开的 API 函数生成 Markdown 格式的使用说明。4.3 调试与验证如何知道 AI 真的“读”懂了你写好了 CLAUDE.md怎么验证它起作用了一个简单的方法是进行“一致性测试”。基础测试在一个新对话中直接问“根据本项目的规范我们应该使用哪种包管理器” AI 应该能准确回答pnpm。代码生成测试给出一个模糊指令如“帮我创建一个新的工具函数”。观察生成的代码是否用了TypeScript是否避免了any函数是命名导出吗这能检验基础规范是否被应用。业务逻辑测试提出一个涉及核心领域的问题如“用户下单后库存该如何扣减” AI 的回答应该提及“在ProductVariant级别扣减”以及“异步调用InventoryService.deduct”这证明它读懂了领域模型部分。错误预防测试要求它“用 MongoDB 语法写一个查询”它应该拒绝并提醒你本项目使用PostgreSQL和Prisma。如果测试失败检查 CLAUDE.md 的表述是否清晰无歧义并将其放在更靠前的位置。有时将最重要的规则用**加粗**或 引用块强调也能提升 AI 的注意力。5. 实战避坑CLAUDE.md 编写与使用中的常见问题即使概念懂了在实战中还是会踩一些坑。下面是我和团队在多个项目中总结出的血泪教训。5.1 规则冲突与优先级模糊问题场景你在 CLAUDE.md 里写了“优先使用函数组件”但在具体的组件文件里因为历史原因存在一些类组件。当你让 AI 修改这个文件时它可能陷入困惑是遵循文件现状类组件还是遵循总纲函数组件解决方案在 CLAUDE.md 中明确规则的优先级和例外情况。**组件规范** - **总则**所有新组件必须使用 React 函数组件和 Hooks。 - **例外处理**当修改或重构现有文件时如果该文件内主要使用类组件则**优先保持原有风格的一致性**除非本次修改的主要目的是将其重构为函数组件。 - **迁移策略**对于大型类组件建议先将其拆分为更小的函数组件而非一次性重写。同时给你的指令加上上下文。例如不要说“修改这个组件”而应该说“在保持当前类组件风格的前提下为这个UserList组件添加一个分页功能”。5.2 过度约束扼杀了 AI 的创造力问题场景你把所有细节都规定死了包括每个工具函数必须如何命名、每个 React Hook 必须如何组织。结果 AI 生成的代码虽然规范但僵化死板甚至可能因为规则过于复杂而无法生成有效代码。解决方案遵循“二八定律”。用 CLAUDE.md 约束那 20% 会导致严重问题的关键事项如安全、架构一致性、核心业务规则而剩下 80% 的代码风格细节交给ESLint和Prettier自动处理。给 AI 留出一定的灵活度让它能在规范内提供最优解决方案。CLAUDE.md 应该是“护栏”而不是“镣铐”。5.3 文件失效AI 似乎“看不见”CLAUDE.md问题场景你确认文件在根目录命名正确但 AI 的回答完全无视里面的规则。排查步骤检查文件位置与命名确保文件名为CLAUDE.md全大写且位于项目的根目录通常是.git所在目录。有些 AI 插件可能也支持.claude.md有点开头但CLAUDE.md是社区最通用的约定。检查编辑器插件确认你使用的 AI 插件如 Claude Code、Cursor支持并已启用读取 CLAUDE.md 的功能。通常这是默认开启的。检查对话上下文某些 AI 助手仅在新对话开始时才会完整读取 CLAUDE.md。如果你在一个很长的旧对话中突然发现 AI 不守规矩尝试开启一个新的聊天会话New Chat。简化测试在 CLAUDE.md 开头写一句非常独特的话比如“本项目密码是香蕉菠萝披萨”。然后在 AI 对话中问“我们项目的密码是什么” 如果它答不上来说明文件根本没被读取。查看插件日志一些高级插件可能有调试日志可以查看它加载了哪些上下文文件。5.4 维护成本如何保持 CLAUDE.md 的活力问题场景项目初期兴冲冲写了 CLAUDE.md但项目技术栈更新、业务规则变化后文件却没人更新逐渐过时甚至误导 AI。解决方案将 CLAUDE.md 纳入开发流程。版本控制像对待代码一样对待 CLAUDE.md任何修改都需要提交 Pull Request 并经过 Review。关联更新当package.json中主要依赖升级时或当数据库 Schema 有重大变更时更新相应的 CLAUDE.md 章节应成为提交清单中的一项。定期审查在每个季度或重要版本迭代前花 15 分钟快速过一遍 CLAUDE.md删除过时的内容补充新的最佳实践。设为必读在新成员入职清单中加入“阅读并理解项目根目录的 CLAUDE.md 文件”这一项。6. 超越 CLAUDE.md构建你的 AI 增强工作流CLAUDE.md 是基石但真正的生产力飞跃来自于将它融入一个完整的、由 AI 驱动的开发工作流中。6.1 与 Cursor、Claude Code 等工具的深度集成Cursor 的.cursorrules你可以创建多个.cursorrules文件来应对不同场景。例如一个refactor.rules专门指导 AI 如何安全重构一个docs.rules定义文档生成风格。在 CLAUDE.md 中引用这些规则文件形成“总纲专项细则”的体系。Claude Code 的“技能”Skills一些 AI 助手允许你创建可复用的“技能”或“代理”。你可以将 CLAUDE.md 中的核心指令如“代码审查清单”、“TDD 流程”封装成技能一键激活无需每次输入长提示词。VSCode 任务与 Snippets结合 VSCode 的用户任务和代码片段你可以创建一些快捷命令。例如一个任务能自动打开 CLAUDE.md 中指定的“代码审查模式”提示词模板并粘贴到 AI 聊天框。6.2 度量与迭代如何评估 AI 辅助的有效性引入 CLAUDE.md 后如何知道它是否真的提升了效率可以关注几个软性指标提示词长度你是否需要为同一个问题输入更短的提示词了首次通过率AI 生成的代码或方案不需要你反复纠正就能直接使用的比例是否提高了上下文切换成本当你从项目 A 切换到项目 B 时是否需要花大量时间重新“调教” AI如果每个项目都有良好的 CLAUDE.md这个成本应趋近于零。团队新人上手速度新成员使用 AI 生成符合规范的代码所需的时间是否缩短了这些指标不需要精确量化但团队应该有感知。定期收集这些反馈用于迭代优化你的 CLAUDE.md 内容。说到底CLAUDE.md 不仅仅是一个配置文件它代表了一种思维转变从把 AI 当作一个需要你不停下达精确指令的“神秘黑盒”转变为将其视为一个可以通过系统化知识注入来稳定合作的“智能伙伴”。编写和维护它的过程本身也是对你项目架构、规范和领域知识的一次梳理和巩固。当你和你的团队习惯了这种有“宪法”可依的 AI 协作模式后你会发现那些曾经令人头疼的“AI 乱写”、“风格不一”、“业务理解偏差”问题将逐渐成为过去式。
1. 从“AI乱写”到“精准输出”为什么你需要 CLAUDE.md如果你最近在 VSCode 里用上了 Claude Code 或者 Cursor 这类 AI 编程助手大概率经历过这样的场景你满怀期待地让 AI 帮你写一个函数结果它给你生成了一堆看似正确、实则完全不符合你项目编码规范的代码。或者你让它重构一个模块它却自作主张地引入了你项目里根本不用的第三方库。更让人头疼的是每次开启一个新的对话你都得像教新人一样把“用 TypeScript”、“不要用any类型”、“遵循 Airbnb 代码规范”这些要求重复一遍。问题出在哪不是 AI 不够聪明而是它缺乏一个稳定、持久的“上下文记忆”。每次对话它都像一张白纸需要你重新描绘规则。而CLAUDE.md文件就是解决这个问题的“项目宪法”。它不是一个官方强制文件而是一个被社区广泛采纳的最佳实践一个放在项目根目录下的 Markdown 文件专门用来告诉 Claude Code以及兼容此约定的其他 AI 助手如 Cursor关于这个项目的一切规则、偏好和上下文。简单来说CLAUDE.md 是你的 AI 结对编程伙伴的“入职手册”和“工作指南”。有了它AI 的输出将变得高度可预测、高度符合项目要求从而将你的开发效率从“不断纠偏”提升到“心领神会”的层次。它解决的正是 AI 编程中“不稳定”和“需要反复调教”的核心痛点。2. CLAUDE.md 的核心价值不止于代码规范很多人把 CLAUDE.md 简单理解成一份代码风格说明书这大大低估了它的潜力。一个设计良好的 CLAUDE.md至少能在四个维度上显著提升你的 AI 编程体验2.1 建立稳定的上下文基线告别重复沟通这是最直接的价值。想象一下你团队里来了一个能力超强但记性不好的实习生每次给他派活你都得重新交代“我们公司用 GitLab代码提交流程是…”、“这个项目用 pnpm 包管理器别用 npm”、“接口响应格式统一是{ code, data, message }”。CLAUDE.md 就是一次性把这些信息写下来钉在墙上。AI 在分析你的项目、响应你的请求时会优先参考这份文件确保每次交互都基于同一套前提省去了你 80% 的重复性提示词输入。2.2 约束 AI 行为防止“自由发挥”带来的坑AI 模型基于海量数据训练它知道的“最佳实践”可能和你的项目现状冲突。比如你的老旧项目还在用 Vue 2 和 Options API但 AI 很可能倾向于生成 Vue 3 的 Composition API 代码。又或者你的后端 API 有特定的错误处理中间件但 AI 生成的请求代码可能用了它自己认为更“通用”的错误处理方式。通过在 CLAUDE.md 中明确声明技术栈版本、禁止使用的模式、必须遵循的架构你可以给 AI 划出明确的“行动边界”让它所有的生成和修改都在安全区内进行极大减少了引入技术债务或兼容性问题的风险。2.3 注入项目专属知识让 AI 成为“领域专家”每个项目都有独特的业务逻辑、领域术语和隐藏规则。比如你的电商项目里“SKU”和“SPU”有特定的数据结构和关联关系你的 CMS 里“文章”有一个特殊的“预发布”状态。这些知识通常散落在代码注释、文档或老员工的脑子里。CLAUDE.md 提供了一个集中的地方将这些领域知识Domain Knowledge以结构化的方式喂给 AI。当你对 AI 说“给这个商品 SKU 加个库存预警功能”它因为读过 CLAUDE.md 里对 SKU 模型的描述就能更准确地理解“商品 SKU”所指何物并生成贴合业务的代码。2.4 统一团队协作降低 AI 使用门槛在团队中如果每个成员都用自己的一套提示词和 AI 交互会导致代码风格、工具选择、甚至解决方案的碎片化。CLAUDE.md 作为一个版本控制的文件可以确保团队所有成员使用的 AI 助手都遵循同一套标准。新成员加入项目只要配置好 AI 插件并指向这个文件就能立刻获得与老成员一致的、高质量的 AI 辅助体验极大降低了团队整体的学习和协作成本。3. 手把手构建你的第一份 CLAUDE.md一份有效的 CLAUDE.md 不应该是一份冗长的“百科全书”而应该是一份精炼的“行动指南”。下面我将以一个虚构的全栈项目Node.js 后端 React 前端为例拆解 CLAUDE.md 的核心模块和编写要点。你可以以此为骨架填充自己项目的具体内容。3.1 项目概览与核心指令文件开头应该用最简洁的语言告诉 AI“我们是谁”和“最重要的规矩是什么”。这部分信息会被 AI 最高优先级地采纳。# 项目 AI 助手指南 (CLAUDE.md) **项目名称**Nexus 电商平台 **核心指令**在为本项目生成或修改任何代码、文档时必须严格遵守本文件的所有约定。任何与本文件冲突的建议都应被忽略并优先采用本文件的规定。 **首要原则** 1. **安全与稳定优先**禁止建议或使用任何已知存在安全隐患的包、模式或 API。所有代码变更需考虑向后兼容性。 2. **一致性至上**严格遵循项目中已存在的代码风格、目录结构和命名约定。不要引入不一致的新模式。 3. **询问澄清**如果需求模糊或存在多种实现可能应主动提问以澄清意图而不是自行选择一种可能不合适的方案。为什么这样写“核心指令”和“首要原则”用强语气设定了基调确保 AI 将本文件视为权威。“安全与稳定优先”是针对 AI 有时会推荐最新但不稳定库的倾向“一致性至上”是针对 AI 容易在每次对话中“创新”的问题“询问澄清”则是引导 AI 在不确定时与用户交互而不是瞎猜。3.2 技术栈与版本锁定这是避免兼容性问题的关键。必须明确到具体的主版本号。## 技术栈与版本 **后端 (Node.js)**: - Runtime: Node.js 18.x (LTS) - Framework: Express.js 4.x - ORM: Prisma 5.x - 语言: TypeScript (严格模式) - 包管理器: pnpm **前端 (Web)**: - Framework: React 18.x (仅限函数组件 Hooks) - 状态管理: Zustand - 构建工具: Vite 5.x - CSS 方案: Tailwind CSS 3.x clsx 组合类名 - 请求库: axios且必须使用项目封装的 /src/libs/request.ts 实例 **数据库**: PostgreSQL 15 **缓存**: Redis 7 (作为会话存储和热点数据缓存) **禁止使用的技术/模式** - 类组件 (Class Components) - any 类型 (TypeScript) - var 关键字 - eval() 或 Function 构造函数 - MongoDB (本项目关系型数据模型明确)经验之谈列出“禁止使用的技术/模式”比只列出“推荐使用的”更重要。AI 在训练时接触过各种方案明确禁止项可以防止它“灵机一动”引入不和谐的技术元素。例如明确禁止any类型能迫使 AI 在生成 TypeScript 代码时思考并明确定义类型提升代码质量。3.3 代码风格与规范这部分需要具体、可操作。直接引用你的 linter 和 formatter 配置是最佳实践。## 代码规范 **通用风格** - 缩进2 个空格。 - 字符串使用单引号 () 模板字符串除外。 - 行尾LF (\n)。 - 文件末尾保留一个空行。 **JavaScript/TypeScript** - 遵循项目根目录下的 .eslintrc.js 和 .prettierrc 配置。 - 导出优先使用命名导出 (export const func)而非默认导出。 - 类型必须显式定义函数参数、返回值及接口。使用 interface 而非 type 定义对象形状项目约定。 - 错误处理异步操作使用 try/catch同步错误使用 Result 模式参考 /src/utils/result.ts。 **命名约定** - 变量/函数camelCase - 类/类型/接口PascalCase - 常量UPPER_SNAKE_CASE - 私有类成员前缀 _ (如 _internalMethod) - 组件文件PascalCase (如 UserProfile.tsx) - 非组件工具文件kebab-case (如 format-date.ts) **CSS/Tailwind** - 优先使用 Tailwind 工具类。仅在需要复杂动态样式或复用性极高时才在 *.module.css 中编写自定义 CSS。 - 避免在 JSX 中使用 style 内联样式对象。实操技巧与其在 CLAUDE.md 里详细描述每一条规则不如直接告诉 AI“遵循某某配置文件”。这样当团队更新 ESLint 或 Prettier 规则时AI 的行为会自动同步更新无需修改 CLAUDE.md。同时像“使用interface而非type”这类项目特有的、无法通过工具强制执行的约定必须在这里明确写出。3.4 项目结构与关键路径帮助 AI 理解你的项目脉络知道代码应该放在哪里从哪里引用资源。## 项目结构说明nexus-platform/ ├── backend/ # Node.js 后端服务 │ ├── src/ │ │ ├── modules/ # 业务模块 (user, product, order) │ │ ├── libs/ # 通用库 (数据库客户端、工具函数) │ │ └── middleware/ # Express 中间件 │ └── prisma/ # Prisma schema 和迁移文件 ├── frontend/ # React 前端应用 │ ├── src/ │ │ ├── components/ # 通用 UI 组件 │ │ ├── features/ # 功能模块组件 (与路由相关) │ │ ├── hooks/ # 自定义 React Hooks │ │ ├── libs/ # 第三方库实例和适配器 │ │ ├── stores/ # Zustand 状态切片 │ │ └── types/ # 全局 TypeScript 类型定义 │ └── public/ # 静态资源 └── shared/ # 前后端共享代码 (如类型定义)**关键路径与别名** - / - 指向 frontend/src (在 Vite tsconfig.json 中配置) - #/ - 指向 backend/src (类似配置) - API 请求函数必须定义在对应功能模块的 api.ts 文件中例如 frontend/src/features/user/api.ts。 - 新增页面组件必须放置在 frontend/src/features/ 下对应的文件夹内并使用 lazy 加载。为什么有效明确的目录结构和路径别名能指导 AI 将新生成的代码文件放到正确的位置并正确引用其他模块。这避免了它随意创建文件或使用相对路径../../../这种难以维护的引用方式。3.5 领域模型与业务逻辑这是让你的 AI 助手从“通用程序员”变为“项目专家”的灵魂所在。## 核心领域概念 **用户系统** - 用户 (User) 有 id, email, hashedPassword, role 字段。 - role 枚举值为CUSTOMER, ADMIN, EDITOR。 - 用户身份验证使用 JWT (JSON Web Token)令牌存储在 HTTP-only Cookie 中。 **商品与库存** - 商品 (Product) 是抽象概念ProductVariant 才是可售卖的 SKU。 - 一个 Product 包含多个 ProductVariant (如不同颜色、尺寸)。 - 库存 (Inventory) 记录在 ProductVariant 级别。 - **重要业务规则**当库存低于 safetyStock (安全库存) 字段值时系统应记录日志并触发内部通知但前台仍可销售。 **订单流程** - 订单 (Order) 状态流PENDING - PAID - PROCESSING - SHIPPED - DELIVERED / CANCELLED。 - 状态只能向前推进或变为 CANCELLED不可回退。 - 支付成功后必须异步调用库存扣减服务 (InventoryService.deduct)。编写心得这部分内容来源于你的产品需求文档、数据库 Schema 和核心业务代码。不需要事无巨细只提炼最关键、最容易让 AI 产生误解的概念和规则。用简单的术语和伪代码描述业务规则比大段文字更有效。当 AI 理解了这些领域知识它生成的代码比如一个“创建订单”的函数就会自动包含库存检查、状态初始化等正确逻辑。3.6 AI 交互指令与提示词模板直接教 AI 如何与你合作定义一些常用的交互模式。## 与 AI 协作指南 **当接到任务时请按此流程思考** 1. **澄清需求**如果需求描述简短少于两句话请主动询问目标、输入、输出和边界条件。 2. **分析现状**检查相关模块的现有代码理解当前模式和数据结构。 3. **提供方案**给出 1-2 个实现方案并简要说明其优缺点。优先选择与现有架构一致的方案。 4. **生成代码**根据确定的方案生成完整、可运行的代码块。如果是修改现有文件请明确标出更改范围如使用 diff 格式。 **代码审查模式** 当我要求“审查这段代码”时请按以下顺序提供反馈 1. **安全性**有无潜在的安全漏洞如 SQL 注入、XSS、敏感信息泄露 2. **性能**有无明显的性能瓶颈如循环内重复计算、未优化的数据库查询 3. **是否符合本指南**检查代码风格、技术栈使用、项目结构是否符合上文规定。 4. **可读性与维护性**命名是否清晰函数是否过长逻辑是否过于复杂 5. **改进建议**提供具体的、可操作的改进代码片段。 **常用提示词模板** - **新增功能**“在 features/cart/ 目录下创建一个新的 React 组件 DiscountBanner.tsx用于展示购物车内的促销信息。它需要接收 cartTotal 作为 prop并根据总额决定显示哪条促销语。请使用 Tailwind 设计一个醒目的横幅样式。” - **修复 Bug**“用户报告在 UserProfile.tsx 页面提交表单时如果网络慢会重复提交。请分析 features/user/components/UserProfile.tsx 和相关的 api.ts找出问题并提供修复方案。” - **重构代码**“libs/utils/dateFormatter.js 这个文件混合了日期格式化和时区转换且是纯 JavaScript。请将其重构为 TypeScript拆分为 formatDate.ts 和 timezoneUtils.ts 两个文件并添加单元测试。”核心价值这部分将你平时需要反复输入的高质量提示词固化下来标准化了与 AI 的协作流程。尤其是“代码审查模式”给了 AI 一个清晰的检查清单使其反馈变得结构化、有重点极大提升了审查的价值和效率。4. 高级技巧让 CLAUDE.md 更智能、更强大基础版的 CLAUDE.md 已经能解决大部分问题。但如果你想榨干 AI 助手的潜力下面这些进阶技巧值得一试。4.1 分层与模块化为大型项目设计对于一个庞大的单体应用或微服务群一个巨大的 CLAUDE.md 文件可能难以维护。此时可以考虑分层结构根目录 CLAUDE.md存放全项目通用的规则如 Git 工作流、Docker 规范、公司级编码标准、通用领域词汇表。模块级.claudedir/目录在每个子项目或微服务目录下可以放置一个更具体的配置文件或者直接在该目录的README.md中开辟“AI 助手说明”章节覆盖该模块特有的技术栈和业务规则。AI 助手如 Claude Code通常会从当前打开文件所在目录向上查找 CLAUDE.md。利用这个特性你可以实现配置的继承和覆盖。例如后端服务目录下的规则可以继承根目录的通用规则同时定义自己必须使用Prisma而非Sequelize。4.2 动态上下文与agents.md或.cursorrules的配合CLAUDE.md定义的是静态的、项目级的上下文。而像.cursorrulesCursor 编辑器或agents.md一些高级 AI 工作流工具这类文件则用于定义动态的、任务级的指令。你可以这样区分和使用它们CLAUDE.md“我们这个项目用什么技术栈、怎么写规范、是什么业务。” ——长期记忆项目宪法。.cursorrules/agents.md“我现在要你专门做一件具体的事比如‘以测试驱动开发的方式为这个用户注册函数写测试’或者‘用简洁的英语为这个复杂函数写文档’。” ——短期指令任务模式。一个常见的实践是在CLAUDE.md的最后部分引用或建议几种常用的.cursorrules配置。例如## 附推荐的任务指令模板 当你需要进行特定类型工作时可以激活以下模式通过单独的指令或 .cursorrules 文件 **TDD 模式**优先编写失败的测试用例使用 Jest 和 React Testing Library然后实现最小化代码使其通过最后重构。 测试应覆盖正常流程和关键边界条件。**代码审查专家模式**专注于发现潜在 bug 和性能问题其次才是风格问题。 对每个问题提供严重等级高/中/低和具体的代码修复建议。**文档生成模式**为给定的代码生成 JSDoc 风格的注释。 为公开的 API 函数生成 Markdown 格式的使用说明。4.3 调试与验证如何知道 AI 真的“读”懂了你写好了 CLAUDE.md怎么验证它起作用了一个简单的方法是进行“一致性测试”。基础测试在一个新对话中直接问“根据本项目的规范我们应该使用哪种包管理器” AI 应该能准确回答pnpm。代码生成测试给出一个模糊指令如“帮我创建一个新的工具函数”。观察生成的代码是否用了TypeScript是否避免了any函数是命名导出吗这能检验基础规范是否被应用。业务逻辑测试提出一个涉及核心领域的问题如“用户下单后库存该如何扣减” AI 的回答应该提及“在ProductVariant级别扣减”以及“异步调用InventoryService.deduct”这证明它读懂了领域模型部分。错误预防测试要求它“用 MongoDB 语法写一个查询”它应该拒绝并提醒你本项目使用PostgreSQL和Prisma。如果测试失败检查 CLAUDE.md 的表述是否清晰无歧义并将其放在更靠前的位置。有时将最重要的规则用**加粗**或 引用块强调也能提升 AI 的注意力。5. 实战避坑CLAUDE.md 编写与使用中的常见问题即使概念懂了在实战中还是会踩一些坑。下面是我和团队在多个项目中总结出的血泪教训。5.1 规则冲突与优先级模糊问题场景你在 CLAUDE.md 里写了“优先使用函数组件”但在具体的组件文件里因为历史原因存在一些类组件。当你让 AI 修改这个文件时它可能陷入困惑是遵循文件现状类组件还是遵循总纲函数组件解决方案在 CLAUDE.md 中明确规则的优先级和例外情况。**组件规范** - **总则**所有新组件必须使用 React 函数组件和 Hooks。 - **例外处理**当修改或重构现有文件时如果该文件内主要使用类组件则**优先保持原有风格的一致性**除非本次修改的主要目的是将其重构为函数组件。 - **迁移策略**对于大型类组件建议先将其拆分为更小的函数组件而非一次性重写。同时给你的指令加上上下文。例如不要说“修改这个组件”而应该说“在保持当前类组件风格的前提下为这个UserList组件添加一个分页功能”。5.2 过度约束扼杀了 AI 的创造力问题场景你把所有细节都规定死了包括每个工具函数必须如何命名、每个 React Hook 必须如何组织。结果 AI 生成的代码虽然规范但僵化死板甚至可能因为规则过于复杂而无法生成有效代码。解决方案遵循“二八定律”。用 CLAUDE.md 约束那 20% 会导致严重问题的关键事项如安全、架构一致性、核心业务规则而剩下 80% 的代码风格细节交给ESLint和Prettier自动处理。给 AI 留出一定的灵活度让它能在规范内提供最优解决方案。CLAUDE.md 应该是“护栏”而不是“镣铐”。5.3 文件失效AI 似乎“看不见”CLAUDE.md问题场景你确认文件在根目录命名正确但 AI 的回答完全无视里面的规则。排查步骤检查文件位置与命名确保文件名为CLAUDE.md全大写且位于项目的根目录通常是.git所在目录。有些 AI 插件可能也支持.claude.md有点开头但CLAUDE.md是社区最通用的约定。检查编辑器插件确认你使用的 AI 插件如 Claude Code、Cursor支持并已启用读取 CLAUDE.md 的功能。通常这是默认开启的。检查对话上下文某些 AI 助手仅在新对话开始时才会完整读取 CLAUDE.md。如果你在一个很长的旧对话中突然发现 AI 不守规矩尝试开启一个新的聊天会话New Chat。简化测试在 CLAUDE.md 开头写一句非常独特的话比如“本项目密码是香蕉菠萝披萨”。然后在 AI 对话中问“我们项目的密码是什么” 如果它答不上来说明文件根本没被读取。查看插件日志一些高级插件可能有调试日志可以查看它加载了哪些上下文文件。5.4 维护成本如何保持 CLAUDE.md 的活力问题场景项目初期兴冲冲写了 CLAUDE.md但项目技术栈更新、业务规则变化后文件却没人更新逐渐过时甚至误导 AI。解决方案将 CLAUDE.md 纳入开发流程。版本控制像对待代码一样对待 CLAUDE.md任何修改都需要提交 Pull Request 并经过 Review。关联更新当package.json中主要依赖升级时或当数据库 Schema 有重大变更时更新相应的 CLAUDE.md 章节应成为提交清单中的一项。定期审查在每个季度或重要版本迭代前花 15 分钟快速过一遍 CLAUDE.md删除过时的内容补充新的最佳实践。设为必读在新成员入职清单中加入“阅读并理解项目根目录的 CLAUDE.md 文件”这一项。6. 超越 CLAUDE.md构建你的 AI 增强工作流CLAUDE.md 是基石但真正的生产力飞跃来自于将它融入一个完整的、由 AI 驱动的开发工作流中。6.1 与 Cursor、Claude Code 等工具的深度集成Cursor 的.cursorrules你可以创建多个.cursorrules文件来应对不同场景。例如一个refactor.rules专门指导 AI 如何安全重构一个docs.rules定义文档生成风格。在 CLAUDE.md 中引用这些规则文件形成“总纲专项细则”的体系。Claude Code 的“技能”Skills一些 AI 助手允许你创建可复用的“技能”或“代理”。你可以将 CLAUDE.md 中的核心指令如“代码审查清单”、“TDD 流程”封装成技能一键激活无需每次输入长提示词。VSCode 任务与 Snippets结合 VSCode 的用户任务和代码片段你可以创建一些快捷命令。例如一个任务能自动打开 CLAUDE.md 中指定的“代码审查模式”提示词模板并粘贴到 AI 聊天框。6.2 度量与迭代如何评估 AI 辅助的有效性引入 CLAUDE.md 后如何知道它是否真的提升了效率可以关注几个软性指标提示词长度你是否需要为同一个问题输入更短的提示词了首次通过率AI 生成的代码或方案不需要你反复纠正就能直接使用的比例是否提高了上下文切换成本当你从项目 A 切换到项目 B 时是否需要花大量时间重新“调教” AI如果每个项目都有良好的 CLAUDE.md这个成本应趋近于零。团队新人上手速度新成员使用 AI 生成符合规范的代码所需的时间是否缩短了这些指标不需要精确量化但团队应该有感知。定期收集这些反馈用于迭代优化你的 CLAUDE.md 内容。说到底CLAUDE.md 不仅仅是一个配置文件它代表了一种思维转变从把 AI 当作一个需要你不停下达精确指令的“神秘黑盒”转变为将其视为一个可以通过系统化知识注入来稳定合作的“智能伙伴”。编写和维护它的过程本身也是对你项目架构、规范和领域知识的一次梳理和巩固。当你和你的团队习惯了这种有“宪法”可依的 AI 协作模式后你会发现那些曾经令人头疼的“AI 乱写”、“风格不一”、“业务理解偏差”问题将逐渐成为过去式。
)
