判断 MemoraX Code 该记哪一层，标准不是信息重不重要，而是这条约定在多少个会话、多少个目录、多少个任务上仍然成立。包管理器、构建命令、目录结构、代码风格这类跨会话稳定成立的信息，通常写进仓库级记忆；只在某个子目录里成立的信息写进模块级；本次改动意图、临时规则、正在排查的报错，只留在任务级或干脆不写。写入之后还要确认读取时机：换会话、切目录、执行命令三个时点各做一次对比记录，才能判断记忆有没有真正被命中，而不是被 Agent 现场重新扫描仓库覆盖掉。
建议先把会话里反复出现的约定按包管理器、构建命令、目录结构、代码风格归类，再按“换会话是否仍成立、换目录是否仍成立、换任务是否仍成立”切成三层。仓库级写入项目记忆，模块级绑定目录，任务级不写长期记忆。验证方式是换会话、切目录、执行命令三个时点各记录一次命中结果，再数同一问题的重复提问次数。边界是：写入前先排除“这次先这样”的临时妥协，否则记忆会被过期约定污染。
列出会话里反复出现的项目约定
不要凭印象写记忆，先收集候选。翻最近几次会话记录（会话日志的存放位置按你的实际环境替换），按四类关键词粗筛原话，保留 Agent 当时的原句，不要提前改写成结论。
# 会话日志粗筛骨架，路径和文件名按实际存放位置替换
# 包管理器
grep -nEi "(npm|pnpm|yarn|bun|poetry|pip|uv|cargo)" ./sessions/*.log
# 构建与测试命令
grep -nEi "(make|just|task|build|test|lint|format|tsc|eslint)" ./sessions/*.log
# 目录结构
grep -nEi "(monorepo|packages/|apps/|src/|dist/|workspace)" ./sessions/*.log
# 代码风格
grep -nEi "(tab|space|quote|semicolon|prettier|ruff|gofmt|import order)" ./sessions/*.log把命中的句子填进下面的表，只填原话，判断留到下一节做。
- 分类一（包管理器）：原话、出现时机、首次出现在第几次会话
- 分类二（构建命令）：原话、是安装还是测试还是发布、在哪一层目录执行
- 分类三（目录结构）：原话、指的是整个仓库还是某个子包
- 分类四（代码风格）：原话、是仓库统一要求还是某个目录的例外
同一句原话在多个会话里重复出现，说明它至少是候选；只出现过一次且带“先这样”“暂时”“这次”字样的，先在旁边标一个问号。
判断哪些约定属于仓库级、哪些只属于当前任务
分层的判断标准可以统一成三个问题：换会话是否仍成立、换目录是否仍成立、换任务是否仍成立。三个都成立是仓库级，只有前两个成立是模块级，只在当前任务成立的是任务级。
| 层级 | 判断标准 | 典型内容 | 反例 |
|---|---|---|---|
| 仓库级 | 换会话、换目录、换任务都成立，且能在仓库文件里核对 | 包管理器与锁文件类型、统一的测试与 lint 入口、提交前必须跑的检查、仓库级目录约定 | 把“我先用 npm 临时装个包看看”当成仓库级包管理器约定 |
| 模块级 | 换会话、换任务成立，但只在某个子目录或子包内成立 | 某子包用不同测试框架、某目录禁用某条风格规则、某目录有独立构建命令 | 把某个子包的构建命令写成仓库级，导致在根目录执行失败 |
| 任务级 | 只和本次改动绑定，任务结束即失效 | 本次要重构的目标、临时关闭的规则、正在复现的报错、临时分支名 | 把“暂时注释掉这个测试”写进长期记忆 |
反例的价值在于排错。如果换会话后 Agent 仍然给出错误答案，先回头查是不是把某个模块级或任务级的约定写成了仓库级，而不是急着加更多记忆。
观察 MemoraX Code 在什么时候读取记忆
读取时机决定了记忆有没有用。下面三个时点各做一次对比，每次操作前先想清楚“如果命中，我期望看到什么”，再记录实际结果。每个时点建议重复两三次，用来区分偶发和稳定行为。
- 时点一，新会话：开一个全新会话，不贴任何上下文，直接问“这个项目用什么包管理器、测试怎么跑”。看回答里是否直接给出约定，还是先读锁文件、package.json、Makefile 再回答。
- 时点二，切换目录：在同一会话里进入子包目录后重复同一个问题，看答案是否随目录变化。若答案不变，说明模块级记忆没被区分出来。
- 时点三，执行命令：让 Agent 真正跑一次测试或构建命令，看它选用的命令来自记忆，还是现场读配置文件推导出来。
记录模板可以用下面这几列，证据列填聊天回显或日志行，不要只写“感觉命中了”。
时点 | 操作 | 提问或命令 | 是否命中记忆 | 命中内容 | 证据（回显/日志行）| 备注
新会话 | 新建会话 | 项目用什么包管理器 | | | |
切换目录 | cd 到子包 | 同上 | | | |
执行命令 | 运行测试命令 | pnpm test:unit | | | |用一份清单决定写入与不写入
写入前过一遍条件，写入后定好保留周期和删除条件，避免记忆库变成一份没人维护的笔记。
写入条件（全部满足才写）
- 在多次会话里重复出现，且换会话后仍然成立
- 能在仓库文件里核对，例如锁文件、package.json、Makefile、配置文件
- 表述里不含“这次/暂时/先这样/回头再改”这类时间限定词
- 能明确归属层级：仓库级、模块级或任务级
保留周期
- 仓库级：跟随仓库生命周期，锁文件或构建入口变更时同步更新
- 模块级：跟随该目录是否存在，目录迁移时一起搬走
- 任务级：默认不写入长期记忆，最多保留到该任务合并或关闭
删除条件
- 仓库文件已与记忆内容冲突
- 对应目录被删除或迁移
- 连续多次会话不再被触发，可以先标记待观察，确认无用后再删冲突处理优先级建议是：仓库文件为准，记忆跟随。发现冲突时先改记忆，不要改仓库文件去迁就记忆。
复测换会话后的提问次数
验证方式不是看单次回答像不像对的，而是数同一问题在新会话里被重复问到的次数。统计口径要固定：同一仓库、同一批问题、相近的会话长度，否则次数变化说明不了什么。
| 问题 | 接入前重复提问次数 | 接入后重复提问次数 | 是否仍需人工纠正 |
|---|---|---|---|
| 项目用什么包管理器 | |||
| 测试命令怎么跑 | |||
| 提交前要跑哪些检查 |
次数变化取决于问题类型和记忆覆盖程度，不要预设一个具体数字。如果某条问题接入后次数没降，按顺序排查三件事：这条约定是否真的写入了、写入的层级是否正确、读取时机是否覆盖了出现该问题的场景。三者都确认后再考虑调整表述，而不是直接加更多条目。