项目记忆是MiMo Code实现上下文感知审查的核心机制，通过动态更新的MEMORY.md沉淀架构约束、规则锚点与决策延续性三层依据，使审查基于“项目心智模型”而非孤立代码。
项目记忆不是简单存档，而是让 MiMo Code 在代码审查中“带着上下文上岗”。它自动把项目架构、技术选型、编码规范、历史决策沉淀进 MEMORY.md，后续每次审查都基于这份动态更新的“项目心智模型”，而不是孤立看某几行代码。
项目记忆怎么支撑自动化审查
审查不是比对语法，而是判断是否符合项目整体逻辑。项目记忆为此提供三层依据：
- 架构约束：比如 MEMORY.md 记录了“所有 API 响应必须走统一 error wrapper”，审查时就自动校验新增接口是否遗漏该包装
- 规则锚点：如“禁止直接使用 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 等指令，确保索引和版本可追踪
郑重声明：本站发布内容宗旨在传播更多信息，仅提供查阅，与本站立场无关，不拥有所有权，不承担相关法律责任。不具有任何效益，仅供参考。如果需要专业知识建议，请咨询相关专业人士。如有侵权请联系邮箱。一经查实，立即删除！
