目前至少有十几份流行的 CLAUDE.md 指南在流传。Builder.io 发布了一份。ClaudeFast 提供了完整套件。Dometrain、Gradually AI、scotthavird、Claude for Designers——每个人都有模板。
它们都很好。而且它们都针对的是独立开发者和初创公司。
如果您正在企业团队中运行 Claude Code——多个仓库、合规要求、Azure 基础设施、共享 MCP 服务器，以及并非都读过同一篇博文的开发者——那些模板是起点，而非终点。
以下是它们遗漏的内容，以及您的团队真正需要的内容。
概览
CLAUDE.md 是 Claude Code 的项目配置文件——它在每次会话中最先读取的内容。社区已就扎实的基础达成共识（保持简洁、以身份开头、记录命令和陷阱）。但企业团队需要更多：敏感模块的安全边界、多仓库规则分发、MCP 服务器声明、合规护栏，以及不依赖模型记忆的基于钩子的强制执行。本指南涵盖流行模板正确之处、遗漏之处，并提供一个可立即放入您仓库的生产级企业模板。
CLAUDE.md 到底是什么
如果您是 Claude Code 新手，简短版是：CLAUDE.md 是位于仓库根目录的 markdown 文件，Claude 在每次会话开始时读取它。它告诉 Claude 项目是什么、文件在哪里、要运行什么命令以及要遵循什么规则。
我在 The Anatomy of a Claude Code Project 中完整介绍了项目结构——CLAUDE.md、技能、钩子、文档和本地覆盖。如果您需要基础，请先阅读那篇。
需要理解的重要一点：CLAUDE.md 不是提示词。它是配置文件。区别很重要。提示词是一次性的。配置在每次交互、每次会话、团队中每个开发者之间持久存在。
大家公认的标准结构
在审视了所有主要模板——Builder.io 的模块化方法、ClaudeFast 的全副武装套件、scotthavird 的 GitHub 入门、Dometrain 的 .NET 专注指南、Gradually AI 的 token 意识方法——社区已就几项通用原则达成共识：
- 保持在 500 行以内。 上下文 token 有限。臃肿的文件会降低性能。
- 以项目身份开头。 一句话：这个系统做什么？
- 记录确切命令。 构建、测试、lint、部署。Claude 逐字使用它们。
- 捕获陷阱。 那些奇怪的东西——身份验证怪癖、禁用文件、变通模式。
- 分离关注点。 重型文档放入
.claude/rules/或@imported文件，而非主文件。 - 有机增长。 当您发现自己重复指令时才添加规则，而非预先添加。
目录结构同样已定型：
project/
├── CLAUDE.md # 身份、命令、规则（简洁）
├── .claude/
│ ├── settings.json # 钩子、权限
│ ├── commands/ # 斜杠命令
│ └── rules/ # 自动加载的规则文件
└── docs/ # 按需 @imported
这很扎实。Builder.io 的 Steve Sewell 推广了 @imports 模式以保持 CLAUDE.md 精简。Boris Cherny 展示了如何在 PR 评论中标记 @claude 以将规则更新作为审查工作流的一部分。ClaudeFast 更进一步，提供了 18 个预配置代理定义和 20+ 技能模块。
都是好工作。没有一个涉及当您有 15 名开发者跨四个仓库、带 Azure 登陆区域和合规团队紧盯时会怎样。
企业团队的不同需求
安全边界
独立开发者模板不考虑访问控制，因为对自己没什么需要保护的。企业仓库有身份验证模块、计费逻辑、基础设施即代码和密钥管理——Claude 应当极其谨慎地对待，或根本不碰。
您需要在锋利边缘处放置本地 CLAUDE.md 文件：
src/auth/CLAUDE.md
src/billing/CLAUDE.md
infra/terraform/CLAUDE.md
每个都包含模块特定的约束：不更新迁移就不要修改令牌轮换、绝不硬编码连接字符串、提交 Terraform 变更前始终运行合规检查。Claude 在这些目录中工作时自动加载它们。
多仓库规则分发
CLAUDE.md 层级——用户级（~/.claude/CLAUDE.md）、项目级、子目录级——很强大，但没人讨论如何跨组织管理它。当您有 30 个仓库时，您需要不需要复制粘贴到每个项目的共享标准。
行之有效的模式：维护一个中央 claude-standards 仓库，存放您组织的基础规则。通过 CI/CD 分发——一个将共享 .claude/rules/ 文件同步到每个仓库的流水线步骤。或者如果您偏好，使用 Git 子模块。关键是您的 Azure 命名约定、安全基线和合规规则应一次编写、到处继承。
MCP 服务器配置
Model Context Protocol 服务器赋予 Claude 访问外部工具的能力——您的组件库、文档搜索、部署 API、Jira。Dometrain 以 Shadcn 为例触及了这一点，但企业团队运行多个 MCP 服务器：内部包注册表、Azure 资源 API、策略引擎。
您的 CLAUDE.md 应声明哪些 MCP 服务器可用以及它们的用途，这样 Claude 就知道何时应寻求外部上下文而非本地文件。
用于强制执行的钩子
这是大事。每个模板都告诉 Claude “遵循这些规则”。企业团队不能依赖模型记忆。您需要确定性强制执行。
Claude Code 钩子（.claude/settings.json）自动触发——在特定操作之前或之后。将它们用于每次都必须发生的事情：
- 每次文件编辑后格式化代码
- 对基础设施变更运行安全 lint
- 阻止向受保护目录写入
- 提交前执行合规检查
提示是建议。钩子是保证。“Claude 通常遵循我们的标准"与"Claude 总是遵循我们的标准"之间的差别就是钩子。
合规规则即代码
如果您处于受监管行业，您的 CLAUDE.md 规则文件应直接编码合规要求。日志语句中不得有 PII。没有身份验证不得有公共端点。不得在批准的 Azure 区域之外配置资源。这些不是风格偏好——它们是审计要求，应放在 .claude/rules/compliance.md 中，每次会话自动加载。
企业 CLAUDE.md 模板
以下是一个适用于运行 Azure 基础设施、Terraform、.NET 或 Node.js 应用层和 Intune 管理端点的企业团队的生产就绪模板：
# Project: ContosoCloud Platform
Enterprise SaaS platform — .NET 8 APIs, React frontend, Azure landing zone.
Managed by the Platform Engineering team at Contoso.
## Commands
- Build: `dotnet build src/ContosoCloud.sln`
- Test: `dotnet test --no-build --verbosity normal`
- Lint: `dotnet format --verify-no-changes && npx eslint src/web/`
- Deploy (staging): `az deployment group create -g rg-contoso-staging -f infra/main.bicep`
- Terraform plan: `cd infra/terraform && terraform plan -var-file=env/staging.tfvars`
## Architecture
- `src/api/` — .NET 8 Web API (Clean Architecture)
- `src/web/` — React 18 + TypeScript frontend
- `infra/bicep/` — Azure Bicep templates (landing zone)
- `infra/terraform/` — Terraform modules (networking, DNS)
- `scripts/` — CI/CD pipeline scripts
- `.claude/rules/` — Auto-loaded team standards
## Rules
- Never hardcode secrets. Use Azure Key Vault references.
- All API endpoints require authentication. No anonymous access.
- Follow Azure naming convention: `{resource}-{project}-{env}-{region}`
- Terraform changes require `terraform plan` output in PR description.
- No `any` types in TypeScript. No `dynamic` in C# unless justified.
## MCP Servers
- `azure-docs` — Search Azure documentation (use for service limits, SKU details)
- `component-lib` — Internal React component library (check before building new UI)
- `jira` — Project tracking (reference ticket numbers in commits)
## Gotchas
- Auth uses MSAL with custom token cache — see `src/api/Auth/CLAUDE.md`
- Database migrations are EF Core — never modify generated migration files
- The staging Key Vault has a different access policy than prod — check before assuming
- Bicep modules in `infra/bicep/modules/` are shared across 3 teams — coordinate changes
@docs/architecture.md
@docs/adr/
@docs/runbooks/incident-response.md
将此与 .claude/rules/ 文件配套使用，用于代码风格、安全策略和合规：
.claude/rules/
├── code-style.md # 格式化、命名、模式
├── security.md # 身份验证要求、密钥处理、输入验证
├── compliance.md # 数据驻留、PII 处理、审计日志
├── azure-conventions.md # 命名、标记、资源组结构
└── terraform.md # 模块模式、状态管理、plan 要求
并用 .claude/settings.json 中的钩子强制执行不可协商的规则：
{
"hooks": {
"postFileEdit": [
{ "command": "dotnet format src/ContosoCloud.sln --include ${file}" },
{ "command": "npx eslint --fix ${file}" }
],
"preCommit": [
{ "command": "dotnet test --no-build" },
{ "command": "scripts/compliance-check.sh" }
]
}
}
常见错误
将所有内容塞进一个文件。 您的根 CLAUDE.md 应是目录，而非百科全书。如果超过 500 行，您就在浪费上下文 token，Claude 会开始遗漏指令。
只有提示，没有钩子。 如果一条规则重要到值得写下，就重要到值得强制执行。钩子配置成本低且不会被遗忘。
忽视层级。 每个模板都展示根级 CLAUDE.md。很少讨论子目录覆盖或用户级默认值。企业团队需要三层协同工作。
复制粘贴模板而不裁剪。 Builder.io ShopFront 示例很好——对于一个 Next.js 电商应用。您的 Azure 登陆区域仓库需要不同的指令。从 /init 开始，然后大幅删减。
没有团队所有权。 如果一个人写 CLAUDE.md 而无人维护，它就会腐烂。将规则文件的所有权分配给关心它们的团队。安全团队拥有 security.md。平台团队拥有 azure-conventions.md。像对待代码一样对待它们——它们经过拉取请求。
FAQ
请参阅下方的 FAQ 部分——它涵盖了我们从企业团队那里收到的关于 CLAUDE.md 的最常见问题。
让您的团队跟上节奏
“使用 Claude Code 的开发者"与"大规模部署 Claude Code 的团队"之间的差距是结构。模板让您入门。企业模式——安全边界、分布式规则、钩子强制执行、合规集成——让您达到生产级。
Big Hat Group 帮助企业团队构建此类基础设施。我们为 IT 团队提供 Claude Code 和 AI 代理培训，我们的咨询业务专门从事此处描述的精确模式：多仓库 CLAUDE.md 策略、MCP 服务器集成、OpenClaw 部署，以及让合规团队对 AI 辅助开发放心的治理框架。
如果您的团队已度过实验阶段，准备好将 Claude Code 运营化，请联系我们。
Kevin Kaminski 是一名 Microsoft MVP，也是 Big Hat Group 的 Principal，在那里他帮助企业团队部署 AI 代理、Windows 365 和现代管理解决方案。