四种类型不是"标签"——它们对应四种本质不同的信息。 记错类型不只是分类乱，会导致 Claude 在错的时机用错的方式调用记忆。 下面是每种类型的定义、写法标准、典型示例和反例。

写法铁律：feedback 与 project 必须带 Why + How

feedback 与 project 是最容易腐烂的两类—— 没有上下文的规则未来无法判断是否还成立。统一写成三段式：

## 主体规则或事实
集成测试必须连真实数据库,不用 mock

**Why**: 2026-Q1 mock 测试通过但 prod 迁移挂了,
        造成 4 小时 outage(INC-2398)

**How to apply**: 看到 test 文件含 vi.mock('../db') 立刻警示;
        集成测试用 testcontainers 起真实 pg

Memory 存在 ~/.claude/projects/<project>/memory/—— 不在项目目录、不进 git。 结构是索引 + 事实文件 + 链接三层。

典型目录结构

# ~/.claude/projects/-Users-minimax-myproject/memory/
memory/
├── MEMORY.md                 # 索引(总览,加载到 context)
├── user_role.md              # type=user
├── user_preferences.md       # type=user
├── feedback_testing.md       # type=feedback
├── feedback_pr_size.md       # type=feedback
├── project_q2_freeze.md      # type=project
├── project_auth_rewrite.md   # type=project
├── reference_oncall.md       # type=reference
└── reference_linear.md       # type=reference

单个 memory 文件结构

# feedback_testing.md
---
name: feedback-testing
description: 集成测试必须连真实数据库,不允许 mock —— 决策点关键
metadata:
  type: feedback
---

集成测试必须连真实数据库,不用 mock。

**Why**: 2026-Q1 mock 测试通过但 prod 迁移挂了,造成 4 小时 outage(INC-2398)。
        Mock 与真实 schema 漂移过大,无法及时发现。

**How to apply**: 看到 vi.mock('../db') / jest.mock('@/db')
        立刻警示;集成测试统一用 testcontainers 起真实 pg。

相关:[[project-migration-strategy]]、[[reference-incident-db]]

MEMORY.md 索引规则

# MEMORY.md 是索引,不是内容容器
# 永远只放一行一条 — 单行 <150 字符
# 不带 frontmatter

## User
- [Role](user_role.md) — Go 10y / 新手 React / 偏好后端类比
- [Preferences](user_preferences.md) — 终端用 ghostty / 编辑器用 vscode

## Feedback
- [Testing](feedback_testing.md) — 集成测试不用 mock(INC-2398)
- [PR Size](feedback_pr_size.md) — 重构 PR 偏好单个 bundled 而非多个小 PR

## Project
- [Q2 Freeze](project_q2_freeze.md) — 2026-03-05 起 mobile release 冻结
- [Auth Rewrite](project_auth_rewrite.md) — 合规驱动 / 不是技术债

## Reference
- [Oncall](reference_oncall.md) — grafana.internal/d/api-latency
- [Linear](reference_linear.md) — pipeline bug 在 INGEST 项目

[[name]] 链接机制

记忆系统的难度不在怎么写——而在何时写、何时读、何时不用。 下面是一套实战可用的判断标准。

何时该自动写入

何时不该写入

读取与陈旧检测

陈旧处理三档

"忽略 memory" 指令处理

# 用户说: "这次先不用 memory" / "暂时忽略你记住的内容"

行为约定:
- ✗ 不要应用任何 memory 中的事实
- ✗ 不要在回答中引用或对比 memory
- ✓ 当前对话视为"零记忆"状态
- ✓ 仍可以读 memory 文件作为研究,但不作为约束

为什么需要:
- 用户在做 prototype / spike,不希望被既有约束限制
- 调试时怀疑 memory 是错误信息源
- 想体验"清洁状态"下 Claude 的表现

Memory 不孤立——它和 CLAUDE.md、Skills、Plan、Task 都涉及"持久化"。 划清边界是 Memory 用对的前提：选错系统比不存还糟。

五个持久化系统的对比

决策树：信息该存哪儿？

边界判断三句话

Memory 不维护就会腐烂——MEMORY.md 越长、重复越多、过期条目越多， 读它的 Claude 行为就越混乱。 下面是维护 Memory 的日常操作与定期保养。

核心命令

定期保养清单

反模式预警

四个递进的动手实验——从写一条标准 memory 到完成季度保养。 预计 40 分钟，全部在你日常使用的项目里完成。

1. 请说出 user / feedback / project / reference 四种类型各自保存什么——并各举一个 good 与 bad 示例。
2. feedback 与 project 类必须包含 Why 和 How to apply——为什么不能只写主规则？
3. MEMORY.md 是什么？为什么不能把 memory 内容直接写进 MEMORY.md？
4. 给定一条信息,如何判断它该进 CLAUDE.md / Memory / Skill / Plan / Task 中的哪个？请描述判断流程。
5. Memory 的"陈旧检测"分三档——FRESH / PARTIAL / DEAD,请说出各自的处理动作。