规范维护、漂移治理与版本管理

记忆与规范不是写完即止的静态文档。随代码演进、人员变动与会话压缩，规则会出现过时、重复、冲突与膨胀。本节给出漂移的来源、排查命令与治理节奏，让团队约定长期可信、精简且单一来源。

一、规范漂移的五种来源

漂移类型	典型表现	后果
内容过时	构建方式、目录已变，CLAUDE.md 仍写旧流程	代理给出错误步骤
多层冲突	个人/项目/托管层对同一行为要求不一致	结果不可预期
冗余膨胀	可由代码本身推导的细节被反复抄写	挤占上下文、降低遵循度
临时指令丢失	只在对话里口头约定，压缩后不复存在	新会话又回到旧行为
重复定义	同一规则在多处各写一份、表述不同	改一处漏多处

二、排查命令：先确认规则到底加载了什么

• /context：查看本次启动实际加载的 Memory files 清单；若期望的文件不在其中，说明位置不在加载范围（上级/项目/子目录按需），应先修正存放位置。
• /memory：打开各层文件核对内容，区分项目共享文件与本机个人文件；缺失文件可在此创建。
• /doctor：让工具评估 CLAUDE.md 冗长程度，识别那些可由代码库直接推导、应当删除或精简的内容。
• 子目录规则未生效时，确认是否已进入该子目录读取文件而触发按需加载；必要时把稳定要求上移到项目根文件。

三、压缩会话后的规则存活边界

• 执行 /compact 后，项目根 CLAUDE.md 会重新读取并重新注入；子目录 CLAUDE.md 与按路径匹配的规则在再次接触相关文件时按需重载。
• 仅出现在对话里、未写入文件的约定不会自动保留。需要长期执行的要求，应写入项目 CLAUDE.md、规则文件或由代理保存的自动记忆，避免"这次会话遵守、下次又忘记"。
• 需要回退过程时，可使用检查点/重述能力定位到此前摘要节点；但这只辅助会话整理，不替代对持久规则文件的维护。

四、治理节奏与单一来源原则

1. 随代码变更同步：调整架构、构建、目录或测试策略时，同一变更中更新对应 CLAUDE.md/规则，避免代码先行、规则滞后。
2. 评审时审查规则改动：项目记忆、命令、子代理文件经版本控制评审，确认不夹带本机路径、密钥与个人临时偏好。
3. 定期精简：按 /doctor 建议删除可由代码推导、已废弃的条目；长内容拆到 .claude/rules/ 按需加载。
4. 单一事实来源：一条规则只在一个权威位置定义，其余位置引用它，消除重复与版本差。
5. 明确优先级：托管策略 > 项目 > 本地/个人；确有覆盖关系时写明，避免同层多条互相矛盾。

五、版本管理边界

文件/数据	是否入库共享	说明
项目 ./CLAUDE.md、.claude/commands、.claude/agents、.claude/rules	是	团队一致基线，随仓库评审发布
./CLAUDE.local.md	否（gitignore）	本机个人偏好，勿提交
~/.claude/CLAUDE.md、自动记忆目录	否	个人/本机数据，不跨机、不入仓