项目记忆（Project Memory）是 MiMo Code 实现上下文感知代码审查的核心能力——它远非简单的存档工具，而是让代码审查真正“带着项目心智高效运作”。MiMo Code 自动将项目架构、技术选型、编码规范、历史决策等关键信息沉淀至 MEMORY.md 文件，后续每一次审查都基于这份持续更新的“项目心智模型”展开，而非孤立地分析某几行代码。换言之，审查的核心不是比对语法是否合规，而是判断新代码是否契合项目整体的逻辑流向与架构意图。

项目记忆如何支撑自动化审查

代码审查并非枯燥的语法校验，而是评估新代码能否与项目既有逻辑自然“融合生长”。项目记忆为此提供了三个层次的有力依据，层层递进支撑审查决策：

• 架构约束——例如 MEMORY.md 中记录了“所有 API 响应必须采用统一 error wrapper”，审查时系统自动检查新增接口是否遗漏该包装，若缺失则予以标记提醒。
• 规则锚点——像“禁止直接使用 localStorage”这类硬性规则，一旦新代码调用了 localStorage，审查工具会立刻触发告警，并关联当初写入该规则的会话编号，明确提示“此项约束源自某次团队讨论的共识”。
• 决策延续性——如果团队此前已确定“表单校验使用 Zod 而非 Yup”，当新增校验逻辑误用了 Yup 时，审查系统直接提示冲突，并引用原始决策记录，帮助团队避免反复争论与分歧。

MEMORY.md 是活的，不是快照

这份文件绝非静态文档，而是持续演化的项目认知中枢，始终跟随团队实践同步更新：

• 每次审查发现新问题时，可一键追加内容至 MEMORY.md（例如：“2026-06-20 补充：日期格式化统一使用 dayjs().format('YYYY-MM-DD')”），确保团队共识能够实时沉淀与传承。
• /dream 指令每 7 天自动执行一次，合并重复规则、剔除已废弃的约定（例如旧版“支持 IE11”这类过时条目会被标记为 obsolete），避免记忆库越积越乱、影响审查效率。
• 审查报告中会清晰标注所依据的记忆条目来源（比如“依据 MEMORY.md 第 42 行｜2026-06-15 决策”），每一条审查结论均可追溯、可验证，杜绝拍脑袋式的随意判断。

和传统审查工具的关键区别

普通 linter 工具只识别规则文本，遇到语法违规便直接报错；但 MiMo Code 的审查逻辑是“先理解项目背景，再做出判断”，智能程度显著不同：

• 遇到非常规写法（例如绕过标准 hook 自定义状态管理），系统不会盲目报错，而是首先查询 MEMORY.md 中是否存在授权例外记录——如果项目此前已明确允许该写法，则直接放行通过。
• 同一段代码在不同项目中审查结果可能截然不同——因为背后加载的是各自专属的 MEMORY.md 文件，项目间的心智模型与规则体系各有差异。
• 新成员提交 PR 时，系统还能自动生成《本次变更与项目记忆一致性说明》，相当于为人工评审提前完成一轮认知对齐，显著降低沟通成本与理解偏差。

实际用起来要注意什么

项目记忆的实际价值高度依赖其“真实感”与“可用性”，以下几个关键点值得特别留意：

• 首次初始化 MEMORY.md 时，建议由人工梳理核心架构图并确定 3 条最高优先级规则，避免系统空转——毕竟可靠的记忆需要从靠谱的“种子”开始培育。
• 审查前可以手动触发 /refresh-memory 指令，强制子 Agent 重新加载最新记忆状态，尤其在多人协作频繁更新后，确保每次审查都能基于最新版本的项目心智模型。
• MEMORY.md 不建议直接手动编辑结构调整内容，所有增删改操作请通过 /mem add、/mem rm 等标准化指令执行，这样才能保证索引与版本可追踪，避免出现记忆断层或信息丢失。