目录
-
claude.md文件存放哪些内容；
-
skills.md中如何读取claude.md文件内容
-
一、claude.md介绍
🗂️ 文件层级体系
|
1 2 |
~/.claude/CLAUDE.md # 全局：适用于所有项目 /project-root/CLAUDE.md # 项目级：团队共享，纳入 Git |
📏 核心写作原则
控制体积：每个 CLAUDE.md 目标控制在 200 行以内。超过后上下文消耗增加、指令遵循率下降。若内容增多，可用 @path 导入拆分到 .claude/rules/ 目录的子文件。
指令要具体：避免”遵循最佳实践”这类模糊表述。太多细节会浪费 token 甚至让模型困惑。只写能实质改变 Claude 决策的信息，而非 Claude 读代码就能推断的内容。
避免矛盾：如果根目录 CLAUDE.md 说”用 tab”，子目录说”用 space”，Claude 应用最具体的那条，但根目录文件的结果仍不可预测。
🔥 ✅ 项目级 CLAUDE.md 应包含的内容
把项目 CLAUDE.md 理解为AI 入职文档 + 操作手册，而非知识大杂烩。它应该帮 Claude 回答：项目是什么、如何构建测试运行、代码惯例是什么。如果已有优质 README 或架构文档，直接引用而不是复制。
典型结构
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
# 项目简介 [3-5 句话描述项目] ## 构建 & 测试命令 - 构建：`npm run build` - 测试：`npm test` - Lint：`npm run lint` ## 代码规范 - 使用 TypeScript strict 模式 - 函数优先于类 - 文件命名：kebab-case ## 禁止事项 - 不要生成过多注释 - 不要修改 /legacy 目录下的文件 ## 目录结构 [简要说明核心目录职责] |
🔀 按需加载 vs 常驻内存
对于只在特定场景需要的内容（如某个模块的详细规范），放进 docs/ 文件夹，用时通过 @docs/filename.md 引用，而不是全塞进 CLAUDE.md，避免每次会话都消耗 token。
🛠️ 实用操作技巧
初始化：运行 /init 可自动生成 CLAUDE.md 骨架，Claude 会分析代码库并提取构建命令、测试指令和项目惯例。已有文件时，/init 会给出改进建议而不是覆盖。
定期维护：建议每季度审查一次 CLAUDE.md，就像维护技术文档一样。最佳实践是给每个修改的章节标注日期。定期审计平均可减少 25% 的记忆 token 消耗.
🚫 常见错误
| 错误 | 正确做法 |
|---|---|
| CLAUDE.md 超过 200 行 | 拆分到 .claude/rules/ |
| 复制 README 内容 | 用 @README.md 直接引用 |
| 把所有文档塞进 CLAUDE.md | 按需用 @docs/xxx.md 引用 |
二、OpenClaw vs Claude Code 文件对比
| OpenClaw | Claude Code | 作用 |
|---|---|---|
SOUL.md |
CLAUDE.md（全局 ~/.claude/） |
最接近——定义 Agent 的身份、行为风格、边界 |
USER.md |
CLAUDE.md（全局 ~/.claude/） |
用户个人偏好、环境特定配置，不共享 |
AGENTS.md |
CLAUDE.md（项目级） |
项目/工作区的操作规范和工具能力描述 |
memory/YYYY-MM-DD.md |
Auto Memory（自动写入） | 每日会话记录，短期记忆 |
MEMORY.md |
无直接对应 | 长期记忆摘要，跨月持久化 |
核心差异
SOUL.md ≈ Claude Code 的全局 CLAUDE.md，但有个关键区别：
- SOUL.md 是 Agent 的”灵魂”——每次会话开始时读取，定义身份和行为。如果 Agent 修改了这个文件，必须告知用户，因为它代表 Agent 自身的演化。 Claude
- CLAUDE.md 更偏向”工作手册”——由人类写给 Claude 的指令，Claude 不会主动修改它。
OpenClaw 每次会话开始时会同时将 SOUL.md（身份）和 USER.md（用户理解）一起加载进上下文，这种 Identity Core 架构让 Agent 不只是处理当前消息，而是通过自身身份和对用户的了解来过滤回应
三、skills中读取claude.md的内容，比如部署信息
🔥 最佳建议
当部署信息非常复杂（多区域、多服务、几十行），撑爆了 CLAUDE.md 的 200 行建议上限，才考虑拆出去。否则保持简单，信息都在 CLAUDE.md 里。
比如：
|
1 2 3 4 5 6 7 |
devflow: psm: "xx.xx.xx.xx" # PSM信息 biz_id: 0 # 业务线 ID，0 表示默认 deploy: env: ["ppe"] # 支持的部署环境 region: "cn" # 部署区域，cn=国内 dc_list: ["LF"] # PPE 泳道机房列表 |
保留在 CLAUDE.md 里，不拆文件的理由：
- 内容体积小，不会撑爆 200 行限制
- skill 直接通过
@CLAUDE.md引用即可，无需多一层跳转
如果公司有多个部署平台，用户可以自选一个
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
## 部署信息 ```yaml # 当前使用平台 platform: devflow devflow: psm: "xx.xx.xx.xx" biz_id: 0 deploy: env: ["ppe"] region: "cn" dc_list: ["LF"] bits: app: "aiden_platform" cluster: "cn-ppe" ``` |
方式一：CLAUDE.md 定义数据，skill 用 @ 引用
Skill 的核心设计原则是渐进式披露——SKILL.md 只放核心指令，详细内容通过引用外部文件按需加载。
把部署信息单独抽成一个文件，CLAUDE.md 和 skill 都引用它
|
1 2 3 4 5 6 7 8 |
project/ ├── CLAUDE.md └── .claude/ ├── context/ │ └── deployment.md # 部署信息单独存放 └── skills/ └── deploy/ └── SKILL.md |
CLAUDE.md 引用：
|
1 2 |
## 服务部署信息 @.claude/context/deployment.md |
SKILL.md 也引用同一个文件：
|
1 2 3 4 5 6 7 8 9 10 |
--- name: deploy description: 部署服务到生产/测试环境 --- # 部署 Skill 读取部署配置： @../../context/deployment.md 按照上述配置执行部署步骤... |
这样两者共享同一份数据源，改一处处处生效
方式二：直接读取Claude.md中内容
claude.md内容
|
1 2 3 4 5 6 7 |
# CLAUDE.md ## 部署信息 - 生产环境：api.example.com - 测试环境：staging.example.com - 部署用户：deploy - 服务名：my-service |
skill的内容
|
1 2 3 4 5 6 7 8 |
# SKILL.md --- name: deploy description: 部署服务，从 CLAUDE.md 的「部署信息」章节读取配置 --- # 部署步骤 从 CLAUDE.md 的「部署信息」章节获取目标环境，然后执行： ssh {部署用户}@{目标环境} "systemctl restart {服务名}" |
