企业官网建设流程全解析

用 project-CLAUDE.md 为 Claude Code 建立团队级项目记忆：完整配置指南与模板拆解

【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto

项目级CLAUDE.md（即本仓库zh/02-memory/project-CLAUDE.md模板所代表的记忆文件）是 Claude Code 在跨会话间保留上下文的核心机制：把团队规范、架构约定、编码标准、Git 工作流写进一个文件，Claude 每次会话启动都会自动加载。本文以该模板为骨架，逐节拆解其字段含义与落地姿势，并结合本仓库真实的CLAUDE.md、目录级与个人级记忆文件，讲清"项目记忆该写什么、怎么写、放在哪、如何验证"，让你 15 分钟内在自己的项目里把 Claude 的默认行为调教成团队标准。

一、为什么需要项目级记忆：从"每次重说"到"自动遵守"

Claude Code 的上下文窗口只在单次会话内有效；一旦关闭终端，你反复强调的"本项目用 2 空格缩进、提交信息必须遵循 conventional commits"就全部丢失。Memory 体系把这类规则固化到文件系统中：

• 跨会话持久：CLAUDE.md文件在每次会话启动时自动加载，规则"始终在场"；
• 团队共享：项目级记忆跟随 git 提交，5 人团队只要各自拉取仓库就获得同一套规范；
• 分层生效：从组织级受管策略、用户级个人偏好，到项目级团队规范、子目录级模块约束，逐层拼接进上下文，实现"全局默认 + 局部覆盖"。

本仓库02-memory/目录提供了三种可复制的模板：project-CLAUDE.md（团队项目规范，复制为./CLAUDE.md）、personal-CLAUDE.md（个人偏好，复制为~/.claude/CLAUDE.md）、directory-api-CLAUDE.md（目录级规范，复制为src/api/CLAUDE.md）。本文聚焦第一种，也就是最常见的落地场景。

二、三分钟上手：把项目记忆装进你的仓库

方法一：/init一键初始化（推荐）

在项目根目录启动 Claude Code，输入：

/init

Claude 会扫描当前项目，生成一个结构完整的CLAUDE.md（通常落在./CLAUDE.md或./.claude/CLAUDE.md），骨架与本仓库模板一致：

# 项目配置 ## 项目概览 ## 开发规范

随后按需增删章节即可。若希望init走多阶段交互式引导（分步询问项目信息），可以这样启动：

CLAUDE_CODE_NEW_INIT=1 claude /init

方法二：直接复制模板（最快）

把本仓库的模板拷到自己的项目根目录，然后逐项改写成你的实际情况：

cp zh/02-memory/project-CLAUDE.md /path/to/your-project/CLAUDE.md

这也是仓库根README.md的"15 分钟快速上手"推荐路径（见 README.md 的 Get Started 一节）：cp 02-memory/project-CLAUDE.md ./CLAUDE.md。

方法三：会话中追加规则

想让 Claude 记住一条新规则，直接口语化提出即可（#前缀快捷写法在新版本中已弃用）：

请记住：这个项目所有新组件都使用 React Hooks 函数组件

Claude 会反问保存到哪个作用域（项目记忆./CLAUDE.md/ 个人记忆~/.claude/CLAUDE.md），确认后写入对应文件并自动重载。

验证是否生效

1. 重新打开一个 Claude Code 会话；
2. 观察会话启动时CLAUDE.md是否被自动加载；
3. 用一条明显受记忆影响的提示词测试（例如"检查这个文件的命名是否符合规范"），确认 Claude 遵循了你写入的规则。

三、逐节拆解 project-CLAUDE.md：每段写什么、为什么

原模板的组织顺序本身就是一份"项目记忆最佳目录结构"。下面逐节说明每个字段的用途与写法要点。

1. 项目概览：给 Claude 的第一印象

## 项目概览 - **名称**：电商平台 - **技术栈**：Node.js、PostgreSQL、React 18、Docker - **团队规模**：5 名开发者 - **截止时间**：2025 年第 4 季度

这段决定了 Claude 对项目语境的基本判断：用什么语言写代码、面向什么环境部署、节奏多紧。技术栈尤其重要——Claude 会据此选择合理的依赖、构建与调试策略。

2. 架构：用@导入替代复制粘贴

## 架构 @docs/architecture.md @docs/api-standards.md @docs/database-schema.md

这是CLAUDE.md最值得掌握的语法：@path/to/file会把外部文档内容在加载时直接并入上下文。要点：

• 支持相对路径与绝对路径（如@~/.claude/my-instructions.md）；
• 递归导入最大深度为 4 层；
• 首次导入外部文件会触发安全确认对话框；
• 代码块或行内代码中的@...不会被当作导入指令，因此可以在文档里安全地讲解该语法。

核心收益是"单点维护"：架构文档更新后，记忆自动跟随最新版，无需手工同步——这正是模板用@而非复制内容的原因。

3. 代码风格：机器可执行的硬约束

### 代码风格 - 使用 Prettier 格式化 - 使用带 airbnb 配置的 ESLint - 最大行长度：100 字符 - 使用 2 空格缩进

这里的原则是具体、可验证：与其写"保持代码整洁"，不如写"最大行长度 100 字符、2 空格缩进"。Claude 写出的代码会逐条对齐这些硬性约束，等效于把 lint 规则前置到生成阶段。

4. 命名规范：一张表统一全队认知

### 命名规范 - **文件**：kebab-case（`user-controller.js`） - **类**：PascalCase（`UserService`） - **函数 / 变量**：camelCase（`getUserById`） - **常量**：UPPER_SNAKE_CASE（`API_BASE_URL`） - **数据库表**：snake_case（`user_accounts`）

命名规范是 Claude 生成新文件、新符号时最常踩坑的地方，用表格写明各作用域的命名范式后，产出的代码风格会自动趋同。

5. Git 工作流：规范提交与合并门槛

### Git 工作流 - 分支命名：`feature/description` 或 `fix/description` - 提交信息：遵循 conventional commits - 合并前必须有 PR - 所有 CI/CD 检查都必须通过 - 至少需要 1 个 approval

写清楚分支前缀、提交信息格式、PR 与 CI 门槛，Claude 生成的提交信息（type(scope): subject）与分支名会自动符合仓库约定。本仓库自身的 CLAUDE.md 就是这样实践的——其 Hard rules 一节规定提交格式type(scope): subject，scope 与模块目录对应（如docs(memory):）。

6. 测试要求：把覆盖率底线写进上下文

### 测试要求 - 最低 80% 代码覆盖率 - 所有关键路径都必须有测试 - 单元测试使用 Jest - E2E 测试使用 Cypress - 测试文件名：`*.test.ts` 或 `*.spec.ts`

明确框架选型与覆盖率底线后，Claude 在"补测试"类任务中会自动对齐测试栈、命名与覆盖目标。

7. API 规范：接口风格的统一契约

### API 规范 - 只允许 RESTful 端点 - 请求 / 响应都使用 JSON - 正确使用 HTTP 状态码 - API 版本路径：`/api/v1/` - 所有端点都要带示例文档

如果项目对 API 有更细的要求（校验、认证、分页、限流、缓存），不要堆进根文件，而是用目录级记忆承载——见本仓库 zh/02-memory/directory-api-CLAUDE.md：它定义了 Zod 请求校验、JWT 认证、统一响应结构、cursor 分页、限流配额、Redis 缓存等完整契约，专门作用于src/api/目录。

8. 数据库与部署：把运维红线写清楚

### 数据库 - schema 变更使用 migrations - 绝不硬编码凭据 - 使用连接池 - 开发环境启用查询日志 - 需要定期备份 ### 部署 - 基于 Docker 的部署 - 使用 Kubernetes 编排 - 蓝绿部署策略 - 失败时自动回滚 - 部署前先执行数据库迁移

这两节属于"防止事故型"规则：迁移先行、凭据不入库、部署顺序等，都是 Claude 参与运维类任务时最容易被纠正的点。

9. 常用命令表：把重复输入交给记忆

项目记忆里放一张"高频命令速查表"，Claude 就不需要每次去翻package.json或追问你。本仓库的 CLAUDE.md 同样维护了 Critical commands 一节（pre-commit run --all-files、pytest scripts/tests/ -v、uv run scripts/build_epub.py等），可作为真实范例参考。

10. 团队联系人：跨会话的人肉路由

## 团队联系人 - 技术负责人：Sarah Chen（@sarah.chen） - 产品经理：Mike Johnson（@mike.j） - 运维：Alex Kim（@alex.k）

让 Claude 知道"哪类问题该找谁"，在处理需要人工介入的事项时能给出准确指向。

11. 已知问题与解决方案：沉淀踩坑经验

## 已知问题与解决方案 - PostgreSQL 连接池在高峰期限制为 20 - 解决方法：实现查询排队 - Safari 14 对 async generator 的兼容性有问题 - 解决方法：使用 Babel 转译器

这是团队最容易忽视却最值钱的一节：把"已知坑 + 解法"固化进记忆，Claude 再遇到同类问题时会直接给出已验证的答案，而不是重新踩一遍。

12. 关联项目：上下文里的项目地图

## 关联项目 - 分析仪表盘：`/projects/analytics` - 移动端 App：`/projects/mobile` - 管理后台：`/projects/admin`

在多仓库或微服务场景下，标明关联项目路径，Claude 就能理解当前仓库在整个系统中的位置。

四、记忆的分层体系：项目、目录、个人如何协作

记忆不是单一文件，而是一个分层拼接的体系。本仓库提供了另外两个模板做对照：

关键机制（详见 zh/02-memory/README.md 的 Memory Hierarchy 一节）：

• 拼接而非覆盖：所有CLAUDE.md文件按"受管策略 → 用户规则 → 用户记忆 → 项目规则 → 项目记忆 → 本地项目记忆"的顺序全部拼进上下文，而不是高层替换低层。目录级文件是对根文件的补充，根规则依然生效；
• 就近加载：从工作目录向上逐层发现CLAUDE.md；工作目录之下的子目录文件在 Claude 实际读取该目录内容时按需加载；
• 本地私货：./CLAUDE.local.md存放仅个人可见的项目内偏好，应加入.gitignore，不进版本库；
• 排除机制：在~/.claude/settings.json或.claude/settings.json中用claudeMdExcludes排除巨型 monorepo 中无关子项目的记忆文件：

{ "claudeMdExcludes": [ "packages/legacy-app/CLAUDE.md", "vendors/**/CLAUDE.md" ] }

另外注意：Claude 还会自动维护一份auto memory（~/.claude/projects/<project>/memory/，入口MEMORY.md，会话启动时加载前 200 行/25KB），用于记录它自己观察到的模式与偏好，与手写的CLAUDE.md是两套互补系统。

五、真实范例：本仓库自己的 CLAUDE.md 是怎么写的

仓库根目录的 CLAUDE.md 就是项目记忆的活教材，它展示了"项目级记忆"还能承载哪些元信息：

• Critical commands：把质量门禁（pre-commit run --all-files）、测试（pytest scripts/tests/ -v）、构建（uv run scripts/build_epub.py）等关键命令写进记忆；
• Architecture map：用目录级别的说明（01-～10-模块按学习顺序编号、scripts/仅用于校验与构建）让 Claude 理解仓库的角色边界——正如模板中"架构"一节的作用；
• Hard rules：不可违背的硬约束（如"未经用户明确要求不得提交或推送"、"代码围栏必须声明语言"），与模板的"Git 工作流/数据库/部署"红线一脉相承；
• Token Efficiency：要求 Claude 不重读刚写过的文件、合并编辑、避免多余确认——这类"如何与 Agent 协作"的元规则同样适合放进项目记忆。

从这个例子可以看到：模板给出的 12 个章节是可裁剪的起点，你的项目记忆完全可以按需增加"质量门禁、硬性红线、协作偏好"等自定义章节。

六、最佳实践：写什么、不写什么

应该做

• 项目记忆存团队标准：架构、编码规范、Git 工作流、测试要求，随 git 共享；
• 目录记忆存局部差异：模块专属规则（如 API 目录的校验/认证/分页契约）放子目录CLAUDE.md；
• 先简洁后扩充：先写几条最关键规则跑起来，再逐步沉淀；
• 用@导入已有文档：优先引用而非复制，保证单点维护；
• 控制篇幅：官方建议每个CLAUDE.md控制在200 行以内——它每个会话都会完整加载，行数越多对无关任务的注意力稀释越严重。内容膨胀时，把多步骤流程迁到 skill、把路径专属规则迁到.claude/rules/*.md（用paths:frontmatter 按 glob 生效）；
• 纳入版本控制：提交CLAUDE.md，让全队共享并留下变更历史。

不应该做

• 不要把 README 整份复制进CLAUDE.md——改用@README.md导入；
• 不要把代码实现细节硬塞进 memory——那是源码该管的事；
• 不要让 memory 变成垃圾桶——只保留真正会改变 Claude 行为的信息；
• 不要写"验证提醒"类规则（如"完成后记得跑测试"）：在 Claude Opus 5 / Fable 5 等新模型上这类提示会引发过度验证，白白消耗轮次与 token；改成陈述目标，让 Claude 自行判断；
• 绝不放密钥与敏感信息：凭据、token、PII 一律不进CLAUDE.md。

维护节奏

1. 新增单条规则：直接用/memory打开记忆编辑器，或口语化让 Claude 写入；
2. 批量调整：用/memory打开./CLAUDE.md统一整理，保存后 Claude 自动重载；
3. 定期审计：随着项目演进清理过期、冲突的规则；当文件明显超出 200 行且adherence下降时，考虑把内容外移到 skill 或rules/目录。

七、小结

project-CLAUDE.md本质上是一份"可版本化、可共享、自动加载"的团队协作契约。把项目概览、架构导入、代码风格、命名规范、Git 工作流、测试要求、API 规范、数据库与部署红线、常用命令、联系人、已知问题与关联项目写进./CLAUDE.md，Claude Code 便能在每个会话中自动遵循这套标准。配合目录级记忆（directory-api-CLAUDE.md）、个人记忆（personal-CLAUDE.md）与@文档导入机制，你可以在不增加上下文负担的前提下，把规则精确作用到每一个层级——这也是本仓库02-memory/模块想传递的核心能力。

【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto