反复解释的项目规则，才适合写进文件
每次让 Claude Code 改同一仓库，都要重说构建命令、目录约定和不能随意改变的接口行为，可以考虑把这些稳定事实写入 CLAUDE.md。当前任务里“先处理第二个报错”这样的临时要求，仍适合留在聊天中，完成后就失效，避免未来会话继续照着旧任务执行。
2026年10月17日核对的官方文档说明，CLAUDE.md 提供持续上下文；它与 Claude 自己记录的自动记忆不同。文档也强调，这些文字属于模型上下文，不能用来强制阻断工具行为。不要把“不要访问某文件”只写进说明后，就当作已配置访问控制。
先从一个仓库根文件开始
可以在仓库根目录记录项目用途、经过核实的构建与测试命令、关键目录和约定。命令应来自当前项目的实际配置，而不是让模型根据语言猜测。如果测试尚未运行，就写成待核实；不要记录“已通过”来代替检查。
官方文档还列出用户级、项目级和本地说明位置。对初次维护项目的人，先让根文件保持简短，再按实际需要拆分，比一次建立多层模板更容易查错。团队共同规则可进入版本管理，私人本地信息应按项目约定处理，凭据不应写进说明文件。
虚构仓库：付款模块规则不要塞到每个任务里
假设一个练习仓库有 src/billing 和 docs 两个目录。根 CLAUDE.md 只记录统一格式和通用检查；付款目录自己的说明记录金额单位、重复请求处理与专项验证；当前聊天明确这次只解释一个失败测试，先不改代码。这里的目录和要求是虚构教学设计，不是实际仓库审计。
这种分层能帮助你判断规则是否放对位置。只影响文档目录的排版规则，不必让所有代码任务都反复阅读。另一方面，凡是整个项目都必须知道的事实，也不能只藏在一个偶尔访问的子目录里。
用加载记录核对，不靠文件名猜测
官方说明启动时会读取工作目录及其上层的相关指令文件，子目录中的文件按需要加载。根文件和子目录要求应保持一致，不能假设更深目录一定以程序配置的方式自动覆盖冲突。文档给出的检查入口包括 /context；实际可见内容以所用版本为准。
可在一个不涉及敏感信息的小目录里做练习：从项目根启动，查看已加载信息，再要求读取目标目录中的普通文件，观察相关说明是否出现。没有运行这个检查之前，只能说文件已创建，不能说每条规则已被可靠采用。
维护时删除过期要求，比不断加长更有效
当命令、路径或约定改变，同步修订说明；遇到相互矛盾的条目，先由项目维护者确定有效版本。记录背景与验证标准，避免一大串没有适用条件的绝对句。把复杂、多步骤且偶尔才用的工作流程独立组织，不必全塞进启动上下文。
最后抽查一次输出：是否使用了正确命令，是否遵守本轮改动范围，是否如实报告未运行的验证。需要管理工具执行权限时，请查官方 permissions 文档；项目说明帮助理解任务，权限配置负责决定工具能否执行。