社区里有人把项目里的协作规则，直接写成了 Claude 的“八荣八耻”。 开头不是项目介绍，也不是技术栈，而是一整组行为约束。原网页里有这样两条： 这当然不是官方模板，但它一下子把一件事说透了。 命令会用了，项目也能跑起来了，接下来真正拉开差距的，往往就是这一步。 它适合放三类信息： 这类信息有一个共同点：每次开新会话都应该知道。 官方文档里也把 名字不同，作用其实很像： 这里要分清三点： 所以更准确的说法是：不同 agent 生态里，大家都在用类似的办法解决同一个问题，也就是“让工具先理解项目规则，再开始干活”。 如果只写“项目介绍”“启动命令”“代码规范”，其实还不够。 真正好用的 先让 Claude 知道这个项目是什么。 例如： 这部分不要写成长篇背景介绍，只写 Claude 立刻需要知道的事实。 如果项目有明确范围，也应该写在这里，例如： 很多错误不是代码写错，而是环境没说清。 例如： 这类东西 Claude 不一定能稳定猜出来，最好直接写死。 这部分很值钱，因为很多命令 Claude 无法只靠读代码猜出来。 例如： 如果项目里有“先起本地 Redis 再跑测试”这种要求，也应该写在这里。 这一类经常被漏掉，但其实很关键。 例如： Claude Code 的官方最佳实践一直在强调一件事：要给 Claude 一种验证自己工作的方式。 例如： 这类信息特别适合写进 可以把它理解成“希望 Claude 优先怎么做”。 例如： 这类内容不是在限制 Claude，而是在给它一个更符合团队习惯的默认动作。 有些要求不说清，Claude 很容易踩。 例如： 这部分其实就很像“反向提示词”。 它的作用不是解释项目，而是提前告诉 Claude：哪些路不要走，哪些动作不能做。 如果希望 Claude 每次都按同一种方式汇报改动，也可以提前写清楚。 例如： 很多 下面这些内容通常不适合直接写进去： 官方最佳实践里有一个判断标准很好用： 删掉这一行，Claude 会不会更容易犯错？ 如果不会，通常就不必写进去。 还有一个很实用的判断方法： 官方文档一直在强调两个词：具体 和 简短。 一份好用的 先看一个不太好的写法： 这种写法的问题不是态度不对，而是太空。Claude 读完之后并不知道该怎么做。 再看一个更好的写法： 这类规则读完之后，Claude 才知道“应该怎么做”“不应该怎么做”。 下面这份模板不是最短版，而是更接近真实项目里能长期用的版本。 这类模板的重点，不是栏目看起来全，而是把真正影响表现的东西拆清楚了： 如果想再往前走一步，可以把这份模板理解成四层： 项目是什么，用什么工具，命令怎么跑，目录怎么分。 优先复用什么，先做什么，怎样验证更合适。 哪些目录不能动，哪些做法不要碰，哪些偷懒方式不能接受。 改之前怎么说，改完之后怎么汇报，没把握时怎么说明。 这四层同时写清楚， 我们用一个很小的任务来看： 给登录页补一个空值校验，并在提交前跑相关测试。 如果项目里没有 如果项目里提前写了这些规则，Claude 的表现通常会稳定很多： 适合放个人习惯，比如： 不适合放某个具体项目的规则。 适合放团队共享规则，比如： 适合放某个目录独有的要求。 例如： 越通用的规则放越上面，越具体的规则放越下面。 项目变大之后，继续把所有规则都塞进一个文件里，很快就会乱。 这时候更合适的做法，是把规则拆到 例如： 如果规则只针对某一类文件，还可以加 这种写法的好处很直接： 小项目时，一个 自动记忆和 自动记忆更适合记住这些内容： 但自动记忆不适合替代这些内容： 更简单地说： 把官方建议和实际使用放在一起看，最重要的就是这几条： 每份 不要写“注意代码质量”。 临时任务放在当前对话里，不要塞进 同一个要求如果在多个文件里互相打架，Claude 很容易左右摇摆。 文件一长，就拆到 规则过时了就删，写得不清楚就改，看到 Claude 总犯同一种错，就回来看规则有没有写清楚。 社区里那份“Claude 八荣八耻”之所以让人一眼记住，不是因为它搞笑，而是因为它把规则写成了能执行、能判断的句子。 最推荐的起步方式不是从空白开始硬写，而是这样做： 比如： 做完这一步之后，再看哪些规则开始变多，再决定要不要拆 命令解决的是“怎么用 Claude Code”。 把这三件事分清楚之后，Claude 的表现会稳定很多。 如果今天就要开始动手，最有价值的动作不是再背几个命令，而是去项目里补一份最小可用的 先把这几类内容写清楚，很多“为什么每次都要重新解释”的问题，马上就会少很多。
1. 以暗猜接口为耻， 以认真查阅为荣。
2. 以模糊执行为耻， 以寻求确认为荣。CLAUDE.md 不是装饰文件，也不是项目 README 的另一份副本。它真正的作用，是把 Claude 每次进入项目就该知道的规则提前写清楚。
有的项目里，Claude 一开工就知道该怎么找文件、该跑什么命令、哪些目录不能碰；有的项目里，Claude 每次都像第一次进仓库。差别往往不在模型，而在项目规则有没有提前写清楚。
1. CLAUDE.md 到底是什么
CLAUDE.md 是一个 Markdown 文件。Claude Code 会在会话开始时读取它，把里面的内容当成长期上下文。
如果每次都要重新说一遍，或者只靠聊天历史来维持，Claude 的表现就会忽好忽坏。CLAUDE.md 定义成“项目特定说明、约定和上下文”的入口。它不是强制配置文件，而是高优先级上下文，所以写法越具体、越短、越清楚，Claude 遵守得越稳定。
2. CLAUDE.md、AGENTS.md、GEMINI.md，名字不同，作用类似
CLAUDE.md 不是一个孤例。很多 agent 工具都会给自己留一个“项目规则文件”的位置。
CLAUDE.mdAGENTS.mdGEMINI.md
都是把“这个项目里的固定规则、做事方式、禁止事项、常用命令”提前写下来，让 agent 进入项目时先读到。
3. CLAUDE.md 里到底该写什么
CLAUDE.md，通常要把下面 8 类信息写清楚：1. 项目说明和范围
# Project Overview
- 这是一个基于 Next.js 的后台系统
- 主要目录是 `apps/web` 和 `packages/api-client`
- 默认包管理器是 `pnpm`
apps/admin，不动 apps/landing2. 环境和依赖前提
# Environment
- 默认使用 `pnpm`
- Node 版本是 `20.x`
- 本地测试依赖 Redis
- 需要先复制 `.env.example` 到 `.env.local`3. 常用命令
# Common Commands
- 开发启动：`pnpm dev`
- 单测：`pnpm test`
- Lint：`pnpm lint`
- 构建：`pnpm build`4. 验证和交付要求
# Verification
- 改完后先跑相关单测
- 前端改动至少跑 `pnpm lint`
- 如果改了接口，补一条最小测试
- 交付前列出实际跑过的命令
测试、lint、截图、预期输出，这些都属于高价值信息。5. 目录和代码约定
# Conventions
- 页面组件放在 `apps/web/app`
- API 请求统一走 `packages/api-client`
- 生成文件在 `packages/api-client/generated`，默认不要手改CLAUDE.md，因为它们是项目自己的规则，不是语言本身的常识。6. 正向提示
# Preferred Workflow
- 先读相关文件，再给修改方案
- 优先复用现有组件和工具函数
- 先跑单个相关测试，再决定要不要跑整套
- 如果规则不清楚，先提问确认7. 反向约束
# Do Not
- 不要引入新的 UI 库
- 不要修改 `generated` 目录
- 不要跳过现有测试直接交付8. 输出要求
# Response Style
- 先说明改动方案，再开始修改
- 改完后列出变更文件和验证结果
- 如果没有把握，先说明不确定点
4. 什么不该写进 CLAUDE.md
CLAUDE.md 不好用，不是因为写得不够多，而是因为塞进去的东西太杂。
5. 一份好用的 CLAUDE.md，通常长什么样
CLAUDE.md，通常有这几个特点：
# 项目说明
这个项目历史比较复杂，前后端都很多年了，大家平时开发时要注意代码质量、保持清晰、减少重复、提高可读性、注意命名、关注架构、不要写脏代码……# Code Style
- 使用 TypeScript
- 默认保留现有 ESLint 规则
- 表单校验沿用现有 `zod` 模式
# Workflow
- 改完接口后先跑相关单测
- 改完页面后先看 `pnpm lint`
- 如果只改一个模块，优先跑单个测试，不跑整套测试
# Do Not
- 不要改 `generated` 目录
- 不要直接改数据库迁移文件
6. 一个更接近真实项目的最佳实践模板
# Project Overview
- 这是一个基于 Next.js 的内部后台系统
- 主目录有 `apps/web`、`packages/api-client`
- 默认包管理器是 `pnpm`
- 当前主要维护后台管理端，不处理营销官网
# Environment
- Node 版本使用 `20.x`
- 本地开发使用 `pnpm`
- 测试依赖本地 Redis
- 环境变量模板在 `.env.example`
# Common Commands
- 开发启动：`pnpm dev`
- Lint：`pnpm lint`
- 单测：`pnpm test`
- 构建：`pnpm build`
- 后台单测：`pnpm test --filter admin`
# Verification
- 改完页面后至少运行 `pnpm lint`
- 改完接口后补一个最小测试
- 不要只汇报“理论上可以”，要写实际执行过的命令
- 如果没跑测试，要明确说明原因
# Conventions
- 页面组件放在 `apps/web/app`
- API 请求统一走 `packages/api-client`
- 表单校验沿用现有 `zod` schema
- 新逻辑优先复用现有 hooks 和 util
# Preferred Workflow
- 先读相关文件，再给方案
- 优先沿用现有实现方式
- 先跑单个相关测试，不默认跑整套
- 如果规则不明确，先提问确认
# Do Not
- 不要修改 `packages/api-client/generated`
- 不要引入新的 UI 库
- 不要跳过测试直接交付
- 不要为了通过构建删除已有校验
- 不要凭空新增不存在的接口和字段
# Response Style
- 先说明改动思路，再开始修改
- 改完后列出变更文件和验证结果
- 有不确定点时先说明
# References
- 项目概览：@README.md
- 可用命令：@package.json
- Git 约定：@docs/git-workflow.md
@path 引入额外文件第一层：事实
第二层：偏好
第三层：禁区
第四层：交付格式
CLAUDE.md 才更像一份真正能工作的项目规则文件，而不是一份空泛的项目说明。
7. 没有 CLAUDE.md 和有 CLAUDE.md，差别到底在哪
CLAUDE.md，Claude 常见的问题是：
CLAUDE.md 真正带来的变化，不是让模型突然更聪明，而是让 Claude 更像一个已经进组的人。
8. 三个位置怎么分：用户级、项目级、子目录级
CLAUDE.md 可以放在多个位置，不同位置负责的事情不一样。1. ~/.claude/CLAUDE.md
2. 项目根目录 CLAUDE.md
3. 子目录里的 CLAUDE.md
apps/web/CLAUDE.md 放前端约定packages/api/CLAUDE.md 放接口约定
9. .claude/rules/ 什么时候该上
.claude/rules/ 目录里。your-project/
├── .claude/
│ ├── CLAUDE.md
│ └── rules/
│ ├── testing.md
│ ├── frontend.md
│ └── backend.mdpaths：---
paths:
- "src/api/**/*.ts"
---
# API 开发规则
- 所有 API 端点必须包含输入校验
- 统一返回标准错误格式
- 包含 OpenAPI 注释
CLAUDE.md 往往就够了。
项目变大、目录变多、规则变复杂时，再拆到 .claude/rules/ 会更合适。
10. 自动记忆会记什么，不会记什么
CLAUDE.md 不是一回事。CLAUDE.md 更像我们手动写好的固定规则。
自动记忆更像 Claude 在反复协作里慢慢积累的笔记。
pnpm
CLAUDE.md
11. 最实用的几个最佳实践
1. 保持短
CLAUDE.md 尽量控制在 200 行以内。
太长，Claude 容易忽略重点。2. 保持具体
要写“提交前运行 pnpm test”。3. 只写长期有效的东西
CLAUDE.md。4. 冲突规则只保留一份
5. 大项目要拆
.claude/rules/，不要继续往一个文件里塞。6. 像维护代码一样维护它
这才是项目规则文件真正有用的地方。
12. 先做哪一步最有效
/initCLAUDE.md
.claude/rules/。
13. 真正让 Claude 懂项目的，不是多说，而是提前写清楚
CLAUDE.md 解决的是“Claude 进来之后该按什么规矩做事”。
自动记忆解决的是“合作久了之后，Claude 会慢慢记住什么”。CLAUDE.md：
参考资料
CLAUDE：https://dbinary.github.io/CLAUDE/
本文来自转载微信公众号-凌小添 ，不代表发现AI立场，如若转载，请联系原作者；如有侵权，请联系编辑删除。
