每次都提醒“改源文件，不要直接改生成的 HTML”，适合沉淀成项目规则；“今天只修改退款说明”只属于本次任务。混在一起，下一次任务就会继承过期限制。
放在哪里，取决于谁要遵守
| 位置 | 适合写什么 | 不适合写什么 |
|---|---|---|
用户目录的 ~/.claude/CLAUDE.md |
你跨项目通用的沟通习惯 | 某个项目独有的构建命令 |
项目根目录 CLAUDE.md |
源码入口、交付方式、团队约定 | 临时任务进度 |
子目录中的 CLAUDE.md |
该模块独有的字段和测试要求 | 与根规则相反却不解释的要求 |
Windows 的 ~ 表示当前用户目录。启动位置及其上层的规则会进入上下文；子目录规则通常在读取对应目录文件时加载。因此，先从项目根目录启动，确认路径，再处理子目录。官方加载说明
一份能直接改成自己项目规则的文件
下面是虚构文档站 docs-demo 的教学示例。只有你的目录和命令确实存在时才能原样采用；不要因为示例写了测试命令，就假定自己的项目也有它。
# docs-demo 项目约定
## 文件职责
- content/articles/*.md 是文章源；标题和摘要来自 frontmatter。
- scripts/build.mjs 读取文章源并生成 dist/。
- dist/ 是生成物。正文问题先改源，再运行构建。
## 修改要求
- 保留已有 slug、内部链接目标和文章发布时间。
- 引用产品价格或版本时附来源和核对日期；无法确认则明确待核对。
- 本次任务未涉及的文章不要顺带统一措辞。
## 验证与交付
- 修改文章后运行 node scripts/check-content.mjs。
- 需要检查输出时运行 node scripts/build.mjs。
- 报告修改文件、命令结果和未验证范围。
- 本地构建与发布是两项工作；本项目任务默认交付本地文件。
如果没有 check-content.mjs，先写清人工检查方式，不能留下一个必然失败的命令。若项目已经有 CLAUDE.md，合并必要条目，不要整份覆盖原有决定。
当 content/legal/ 有独立流程，可以在其下补充：
# 法务说明目录
- 保留原文的生效日期和版本号。
- 本次仅修错别字；涉及权利义务的文字变更列入待审稿。
- 输出逐项差异，交给该文档负责人决定是否采纳。
这段是局部补充。若根规则要求“可以更新全部正文”，而局部规则说“仅修错字”，应先明确当前任务采用哪一项，不期待模型自动解决含糊冲突。
怎样检查规则真的进来了
在项目目录运行 claude，输入 /context，查看 Memory files。/memory 可以帮助找到规则位置，但其列表可能包含尚未创建的候选位置，不能只看到一个路径就判定内容已经加载。
然后输入：
先不改文件。请读取 content/articles/demo.md。
列出你实际读到的项目规则路径，并回答：
1. demo.md与dist的关系是什么？
2. 如果只改文章标题，需要运行哪个现有检查？先确认该脚本存在。
3. 这次任务是否包含发布？
不要只复述我的问题，请用当前文件和规则中的条目说明。
换成真实文件名。检查子目录规则时，明确让它读取该子目录的一份实际文件，并检查加载提示及回答是否包含局部要求。若没读到，先排查工作目录、文件名、规则内容与冲突，别马上把整份规则再粘进对话。
已经有AGENTS.md，还要复制一份吗
截至本次核对，Claude Code v2.1.277 及之后的版本支持直接读取 AGENTS.md，但有加载条件：默认情况下，工作目录或祖先已有项目 CLAUDE.md / CLAUDE.local.md 时会走 CLAUDE 规则体系。可在终端的 /config → Project instructions 调整；旧版本或相关内置插件不可用时，仍需按官方兼容方式处理。当前条件
需要兼容时，可让同目录 CLAUDE.md 只写 @AGENTS.md，随后补充 Claude 专用要求，避免维护两份逐渐分叉的正文。先看现有结构，再决定是否添加；不要无故迁移团队规则。
规则写得再清楚，也不能代替权限配置
“不要部署”会影响工具的行动计划，却不等于在执行层禁用了部署命令。需要限制工具操作时，另看 allow、ask、deny教程。本文核对了当前文档；示例规则未在读者的项目或 Claude 会话里运行，加载与行为仍需按上面的具体任务检查。
资料来源
- Claude Code项目记忆
核对规则位置、按需加载、AGENTS.md支持与加载检查。
- Claude Code权限
规则说明与工具权限是不同机制。
下一步
继续阅读与你当前问题相关的教程：
