mimo code 是终端原生编程 agent，不集成 ide 插件，而是与 vs code/jetbrains 协作：ide 负责编辑与调试，mimo code 专注跨文件理解、任务规划与批量执行，依托终端中枢能力、本地 sqlite 记忆及双屏工作流实现高效分工。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
MiMo Code 并不追求“深度集成到传统 IDE”——它刻意避开 IDE 插件路径，选择在终端中构建独立、自治的编程 Agent。所谓“集成”，不是把它塞进 VS Code 或 JetBrains 的侧边栏，而是让它与 IDE 形成互补协作关系：IDE 负责精细编辑与即时反馈，MiMo Code 负责跨文件理解、任务规划与批量执行。
为什么不在 IDE 里装 MiMo Code？
官方明确将 MiMo Code 定位为 terminal-native 工具，核心逻辑很直接：
- 终端是开发流程的“中枢神经”：Git、npm、make、docker、测试命令全在此运行，AI 若能原生操作，就无需反复切出 IDE 复制粘贴
- 避免上下文割裂：IDE 插件每次聚焦单个文件，而 MiMo Code 需要扫描整个仓库结构（.git、tsconfig.json、package.json 等）来建立项目记忆
- 权限与安全更可控：命令行环境下可精确限制工作目录、禁止 root 权限、启用沙箱模式，比插件调用系统命令的风险更低
- 持久记忆依赖本地 SQLite：会话检查点、任务进度快照都存于项目根目录下的 .mimo/ 目录，IDE 插件难以可靠挂载和同步该状态
与 VS Code / JetBrains 的实用协同方式
不必二选一，真正提效的是分工配合：
-
用 IDE 打开文件，用 MiMo Code 理解项目：在 VS Code 中打开一个陌生仓库后，终端 cd 进入同一目录，运行
mimo plan，它会自动读取依赖图、识别主入口、标注高频修改模块，生成可点击的结构简报 -
让 MiMo Code 改代码，用 IDE 审阅 Diff：执行
mimo compose "添加登录失败重试机制"后，它会生成完整改动并暂存 Git Stash；此时在 VS Code 中打开 Source Control 面板，即可逐行查看、编辑、选择性提交 -
复用 IDE 的调试能力，交由 MiMo Code 触发流程：配置 launch.json 后，可在 MiMo Code 中直接运行
run npm test -- --watch或debug ./src/main.ts，终端输出实时同步到 IDE Debug Console - 共享配置，不共享进程：MiMo Code 会自动识别 .editorconfig、eslint.config.js、prettier.config.cjs，并在生成代码时遵守；你改 IDE 格式化设置，它下次生成时自动适配
终端 + IDE 双屏工作流建议
推荐物理或虚拟双屏布局，提升协作自然度：
- 左屏（宽屏主力）：VS Code 全屏，专注阅读、编辑、调试
- 右屏（窄屏终端）：iTerm2 / Windows Terminal 固定宽度 80 列，运行 MiMo Code；开启
mimo watch后，它会监听文件变更，自动提示“检测到 src/api/ 新增了 useAuth hook，是否更新所有调用处？” - 关键快捷键联动：VS Code 中按
Ctrl+Shift+P→ “Terminal: Focus Terminal”，瞬间切到 MiMo Code 会话；反之，在终端中按Cmd+Click（Mac）或Ctrl+Click（Win/Linux）可跳转到对应文件的指定行
避坑提醒：别强行“嵌入”
目前社区已有尝试把 MiMo Code 封装为 VS Code Extension 的实验项目，但存在明显短板：
- 无法触发语音指令（
/voice）、图片上传（/image）等多模态能力 - 会话检查点丢失：插件重启即清空内存，SQLite 记忆虽保留，但上下文重建成功率下降约 40%
- Compose 模式中断风险高：IDE 插件生命周期受编辑器管理，长时间运行的自动化流程易被回收
- 官方不提供兼容性保障：README 明确标注 “仅支持原生命令行启动”，插件行为不在 Issue 支持范围内
