MiMo Code 的 Compose 模式，本质上是一套“设计闭环”驱动的端到端自动化开发工具。它并非简单生成几行代码，而是从业务需求出发，自动理解项目上下文，遵循单一职责、开闭原则、依赖倒置等经典设计原则，最终输出结构清晰、易于维护的类与模块。关键在于，它将所有设计决策显性化、可追溯，而非黑箱式地直接输出一段代码。

你或许会好奇，它具体是如何实现的？下面逐一拆解分析。

自动识别项目架构与设计约束

首次进入项目时，MiMo Code 会自动扫描目录结构、package.json / tsconfig.json、已有类的命名规范、接口定义以及 README，并生成一份 MEMORY.md。这份记忆文档会清晰记录当前项目的分层方式（如 domain / service / infra）、常用设计模式（如 Repository、Factory）以及团队约定（例如“所有 DTO 必须以 DTO 结尾”）。后续生成类时，系统会自动对齐这些约束，而非凭空创造。

• 例如，当你输入“添加一个用户登录失败次数限制功能”，它不会直接写一个 LoginService 了事。而是先判断：当前项目是否已有 RateLimiter 抽象？Auth 模块是否已存在？若存在，则扩展现有类；若不存在，再新建一个符合目录层级的类。
• 它能自动识别常见框架结构（Express、NestJS、Spring Boot 等），并匹配对应的装饰器、注解或依赖注入风格。

Compose 模式下的四阶段设计闭环

启用 Compose 模式（按 Tab 键切换）后，一句自然语言指令便会触发四个阶段的流程：Design → Plan → Build → Review。其中 Design 阶段由独立子 Agent 完成，会输出 UML 类图草稿、职责划分说明以及接口契约草案，然后等待你确认或微调。

• Design 阶段输出示例：
  • 核心实体：User、LoginAttempt
  • 新增接口：IRateLimitService（含 tryAcquire、resetForUser）
  • 新增类：LoginAttemptTracker（domain）、RedisRateLimitRepository（infra）
  • 违反原则检查：无 —— 所有新类职责单一，infra 层不引用 domain 外部类型
• Plan 阶段会列出具体文件变更路径（如 src/domain/user/LoginAttempt.ts、src/infra/rate-limit/RedisRateLimitRepository.ts），并标注是否需要修改现有文件（例如 UserEntity 增加 failedLoginCount 字段）。

记忆驱动的持续一致性保障

每次生成类后，Writer 子 Agent 会将设计决策写入项目记忆，包括“为什么选用组合而非继承”“为何将校验逻辑放在 domain 层”。后续遇到同类需求（例如“添加邮箱验证次数限制”）时，系统会复用该模式，保持风格统一。你也可以通过 /dream 命令定期压缩记忆，让系统提炼出通用规则（例如：“所有限流功能必须实现 IRateLimitService，且 infra 实现不可暴露 RedisClient”）。

• 跨会话依然有效：即便关闭终端再重新打开，只要在同个项目目录下启动 MiMo Code，它仍记得上次你否决过“用全局单例管理计数器”的方案，并自动避开类似设计。
• 当检测到新类与已有 MEMORY.md 冲突（例如命名不符合规范），它会暂停执行并提示：“检测到新类名 EmailValidator 未遵循 ‘*Validator’ 接口命名约定，是否更新 MEMORY.md 或调整命名？”

可干预、可审查、可回溯

它并非追求“全自动即完成”，而是将每一步设计选择都充分暴露出来。生成代码前，你会看到 diff 预览；提交前，内置审查 Agent 会运行 ESLint/TSLint 规则以及自定义设计检查（例如“domain 层不得 import infra”）。所有中间产物（UML 草稿、接口契约、变更计划）都保留在 .mimo/cache 目录下，随时可供查阅。

• 如果某次生成违反了 SOLID 原则，你可以通过 /distill 命令手动标记该案例，系统下次会主动规避同类错误。
• 支持语音指令干预：“撤回上一步设计”“把 Repository 换成内存实现”“导出当前类图到 docs/”。