小米 MiMo 团队推出的 MiMo Code 是一款主打“无限上下文”的终端 AI 编码工具，最近在开发者社区引发了较多讨论。本文将从实际落地表现出发，带您全面了解这款工具的使用体验。
如何安装 MiMo Code
安装方式非常简单：Mac 与 Linux 用户可直接通过以下一键安装脚本来完成部署：
curl -fsSL https://mimo.xiaomi.com/install | bashWindows 用户则可以选择 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
