小米发布MiMo Code 主打无限上下文能力

小米 MiMo 团队推出的 MiMo Code 是一款主打“无限上下文”的终端 AI 编码工具，最近在开发者社区引发了较多讨论。本文将从实际落地表现出发，带您全面了解这款工具的使用体验。

如何安装 MiMo Code

安装方式非常简单：Mac 与 Linux 用户可直接通过以下一键安装脚本来完成部署：

curl -fsSL https://mimo.xiaomi.com/install | bash

Windows 用户则可以选择 npm 全局安装方式：

npm install -g @mimo-ai/cli

安装完成后，在项目目录中执行 mimo 即可启动工具。首次使用时需要先连接模型，在 TUI 界面中输入 /connect 即可完成连接。值得关注的是，官方文档默认推荐使用 Xiaomi MiMo Token Plan，但它同样兼容其他 LLM 提供商。MiMo Code 底层整合了 AI SDK 与 Models.dev 平台，官方文档声称支持超过 75 种 LLM 提供商，同时也支持接入本地模型。模型连接成功后，通过 /models 命令即可切换到当前任务所需的模型——这种入口设计非常实用，例如在同一个 Android 项目中，阅读代码、修改代码、撰写文档、进行代码审查等不同环节，未必需要依赖同一个模型。

配置文件详解

MiMo Code 的配置文件名为 mimocode.json，常见的配置字段包括 model、small_model、provider、permission、agent、command、skills、mcp、lsp、formatter、instructions 等。最小配置只需写入 schema、模型及 provider 信息即可运行。

API Key 的处理方式值得肯定——官方文档明确建议不要将密钥硬编码在仓库中，支持从环境变量和文件中读取。下面是一个配置示例：

{
  "$schema": "https://mimo.xiaomi.com//config.json",
  "model": "{env:MIMOCODE_MODEL}",
  "provider": {
    "anthropic": {
      "options": {
        "apiKey": "{env:ANTHROPIC_API_KEY}",
        "baseURL": "{file:~/.secrets/anthropic-endpoint}"
      }
    }
  }
}

其中 {env:VAR} 从环境变量读取值，{file:path} 则从指定文件获取内容。对于公司项目而言，这种方案比将 API Key 直接写入配置文件更加安全，也方便在不同开发环境中切换 provider。

如果希望团队仅使用一组固定的 provider，可以通过 enabled_providers 或 disabled_providers 进行限制。需要注意的是，文档明确指出 disabled_providers 的优先级更高——即使某个 provider 已配置环境变量，只要被禁用就不会出现在选择列表中。例如：

{
  "enabled_providers": ["anthropic", "openai"],
  "disabled_providers": ["gemini"]
}

这种配置方式非常适合团队统一管理入口。比如，当公司内网环境仅支持特定 provider 时，就不应该让每个成员在本地随意尝试其他 provider。

权限配置建议：谨慎放行

AI 编码工具最容易被忽视的问题并非“它能不能写代码”，而是“它能否随意执行命令”。MiMo Code 的权限支持 ask、allow、deny 三种模式，同时支持针对不同工具和命令前缀设置独立的规则。一个相对保守的 Android 项目配置可以这样设计：

{
  "permission": {
    "bash": {
      "*": "ask",
      "git status*": "allow",
      "git diff*": "allow",
      "git log*": "allow",
      "./gradlew tasks*": "allow",
      "./gradlew test*": "ask",
      "./gradlew assemble*": "ask",
      "git commit*": "deny",
      "git push*": "deny"
    },
    "edit": "ask",
    "write": "ask"
  }
}

这里并没有开放 git commit 和 git push——AI 可以帮助修改代码，但提交与推送操作最好由开发人员手动确认。Gradle 命令同样不建议全部放行，因为 Android 项目中的构建命令往往需要较长时间的编译、依赖下载或设备测试。

关于 ask 审批机制，官方文档提供了三个选项：once、always、reject。值得注意的是，always 仅在当前 MiMo Code 会话剩余时间内有效，并不会永久写入配置。这种设计适合临时放行一组安全命令，例如在某个具体任务中需要反复执行 git diff 或某个特定的测试命令。

三大核心模式详解

MiMo Code 内置了三种主线模式：build、plan、compose。

build 是默认模式，文件操作与系统命令均可使用，适合实际修改代码的场景。在日常开发中，让该模式修复一个 Compose 页面、补充 ViewModel 测试、调整 Gradle 配置等大部分任务都能胜任。

plan 是受限模式，默认不能写入文件、修改文件、打补丁或执行 shell 命令。该模式适合先阅读代码和拆分任务。例如，在迁移一个老模块到 Koin 4 之前，先让 plan 分析依赖关系、列出风险点并拆解步骤，比直接让模型动手更为稳妥。

compose 更像是一种工作流模式，内置了一套技能组合，包括 compose:tdd、compose:debug、compose:verify、compose:plan、compose:execute、compose:review、compose:worktree 等。它并非替代 build，而是让模型按照技能来组织任务。切换方式也非常直观：按 Tab 键在主模式之间切换，或者在消息中使用 @compose 调用。

在 Android 项目实践中，可以按如下方式分类使用：

• 不确定改动范围时，先使用 plan 读取代码
• 明确需要修改文件时，使用 build 执行
• 当任务涉及计划、执行、验证、审查多个环节时，使用 compose

这些模式的实际效果在很大程度上取决于权限、工具、提示词以及模型的配置。如果 plan 被额外放开了写权限，它就不再是纯粹的只读规划；反过来，如果 build 将所有 bash 命令都设为 deny，很多验证动作也无法顺利执行。

总体来看，MiMo Code 的基础架构已经相当完整：终端入口、模型连接、配置文件、权限控制、主模式、技能系统、MCP、LSP、格式化工具，均有对应的文档支持。开发者可以根据自己的具体需求逐步深入探索。

#Android #AI编程 #MiMoCode #Kotlin #JetpackCompose