Claude Code 接入 MiMo 排障实录：从“16 位应用程序”报错到 Windows 全链路跑通

公众号：码海寻道

适用场景：Windows 64 位环境下，将 Claude Code 接入 Xiaomi MiMo / MiMo Token Plan 时，启动阶段就报错，根本进不了对话界面

最近帮一台 Windows 机器把 Claude Code 切到 MiMo 模型时，遇到了一类很容易误判的问题：表面看像是 MiMo 的 API 配置写错了，实际上根因根本不在模型配置，而在 Claude Code 的 Windows 原生二进制没有正确安装。

最终结果是两条链路都跑通了：

• Claude Code CLI 可以直接启动，并且能通过 MiMo 正常返回结果
• VS Code 里的 Claude Code 插件也同步到了同一套 MiMo 配置

这篇文章把整个排障过程完整记录下来，重点写清楚下面几件事：

• 为什么报错看起来像“系统兼容性问题”，实际上和 MiMo 配置是两层问题
• 如何快速判断是“配置错了”还是“Claude Code 自己没装好”
• Windows 下 Claude Code 的安装链路到底是什么样
• 为什么有时候 npm install -g @anthropic-ai/claude-code 执行成功了，但 claude 还是不能用
• 最终如何修复 CLI 和 VS Code 插件

一、问题现场

用户的目标很明确：把本机的 Claude Code 切到 MiMo 模型，并让它可以正常工作。

已经具备的前提包括：

• Node.js 已安装
• Claude Code 已通过 npm 全局安装
• ~/.claude/settings.json 已经写入 MiMo 兼容配置

但一运行 claude，Windows 直接弹出一个非常迷惑的错误框，大意如下：

不支持的 16 位应用程序
由于与 64 位版本的 Windows 不兼容，C:\Users\xxx\AppData\Roaming\npm\node_modules\@anthropic-ai\claude-code\bin\claude.exe 无法启动或运行。

如果你第一次看到这个错误，很容易走偏。多数人的第一反应会是：

• 是不是 Node 装错位数了
• 是不是 MiMo 的 BASE_URL 写错了
• 是不是 Token Plan 的 key 不对
• 是不是 Windows 不支持 Claude Code

但这几种猜测里，只有第一类和问题接近，后面几类都不是根因。

二、先下结论：这不是 MiMo 参数错误

当时机器上的 Claude Code 配置文件已经存在，而且结构基本正确。

C:\Users\14429\.claude\settings.json 的核心内容是：

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://token-plan-sgp.xiaomimimo.com/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "tp-xxxxx",
    "ANTHROPIC_MODEL": "mimo-v2.5-pro",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "mimo-v2.5-pro",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "mimo-v2.5-pro",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "mimo-v2.5-pro"
  }
}

C:\Users\14429\.claude.json 也已经存在：

{
  "hasCompletedOnboarding": true
}

这里有两个值得强调的点。

第一，如果 claude 在启动阶段就被 Windows 拒绝执行，那么它甚至还没来得及发出任何 API 请求。
也就是说，这时候就算你的 MiMo BASE_URL、API Key、模型名有问题，也不会先表现为“16 位应用程序报错”。

第二，MiMo 的配置问题通常会表现为 HTTP 认证失败、模型不可用、请求参数错误，或者运行期的连接失败，而不是操作系统层面的可执行文件错误。

所以这个案例里，排查方向必须先落在本地安装链路，而不是先怀疑模型接入参数。

三、第一轮排查：确认 claude 到底在执行什么

排障时，第一件事不是改配置，而是先确认系统里的 claude 命令究竟指向哪里。

where.exe claude
node -v
npm -v

实际结果：

C:\Users\14429\AppData\Roaming\npm\claude
C:\Users\14429\AppData\Roaming\npm\claude.cmd

node: v22.14.0
npm: 10.9.2

这说明：

• 全局命令入口在 AppData\Roaming\npm
• Node 和 npm 本身是正常的
• 问题不在“没有安装命令”这一层

继续看 claude.cmd：

@ECHO off
GOTO start
:find_dp0
SET dp0=%~dp0
EXIT /b
:start
SETLOCAL
CALL :find_dp0
"%dp0%\node_modules\@anthropic-ai\claude-code\bin\claude.exe"   %*

这个脚本没有任何复杂逻辑，本质上就是把命令转发给：

C:\Users\14429\AppData\Roaming\npm\node_modules\@anthropic-ai\claude-code\bin\claude.exe

也就是说，只要这个 claude.exe 不是真正可执行的 Windows 二进制，整个命令就必然失败。

四、关键突破：claude.exe 只有 500 字节

接下来检查这个文件本体：

Get-Item "$env:APPDATA\npm\node_modules\@anthropic-ai\claude-code\bin\claude.exe" |
  Select-Object FullName, Length, LastWriteTime

看到结果时，问题基本就坐实了：

Length: 500

一个真正的 Windows CLI 可执行文件，不可能只有 500 字节。
这已经足够说明：当前这个 claude.exe 根本不是正常安装出来的原生二进制。

为了进一步确认，我又看了文件的十六进制头：

Format-Hex -Path "$env:APPDATA\npm\node_modules\@anthropic-ai\claude-code\bin\claude.exe" |
  Select-Object -First 8

结果前几行能直接读出 ASCII 文本，大意如下：

echo "Error: claude native binary not installed."

这说明了非常关键的一点：

当前这个 claude.exe 并不是真正的 .exe，而是 Claude Code 包在安装失败时留下的“占位 stub”。

Windows 把这个文件当作可执行程序去启动，自然就会抛出“不是有效 Win32 应用程序”或者“16 位程序不受支持”之类的错误。

到这里，根因已经不再模糊：

• 不是 MiMo 配置写错
• 不是 Node 版本不够
• 不是命令路径错了
• 而是 Claude Code 依赖的 Windows 原生二进制没有落到位

五、继续深挖：为什么 npm 安装成功了，二进制却没装上

这一步非常值得写，因为很多人会被“安装成功”的假象误导。

我直接查看了 @anthropic-ai/claude-code 包的 package.json，发现它的结构不是“一个纯 Node.js CLI”，而是“一个包装器 + 平台原生包”的设计。

关键字段大致如下：

{
  "name": "@anthropic-ai/claude-code",
  "version": "2.1.121",
  "bin": {
    "claude": "bin/claude.exe"
  },
  "scripts": {
    "postinstall": "node install.cjs"
  },
  "optionalDependencies": {
    "@anthropic-ai/claude-code-win32-x64": "2.1.121",
    "@anthropic-ai/claude-code-win32-arm64": "2.1.121",
    "@anthropic-ai/claude-code-linux-x64": "2.1.121",
    "@anthropic-ai/claude-code-darwin-arm64": "2.1.121"
  }
}

这里的核心机制是：

1. 先安装包装包 @anthropic-ai/claude-code
2. 再根据平台自动下载对应的原生包
3. postinstall 脚本把原生包里的真正二进制复制或硬链接到 bin\claude.exe

也就是说，bin\claude.exe 不是一开始就是真正的程序。
它需要 postinstall 成功拿到平台包之后，才会被替换成真实二进制。

如果这一步失败，就会留下那个 500 字节的占位文件。

六、证据补齐：全局依赖树里只有包装包，没有 Windows 原生包

为了验证这个判断，我继续看全局依赖树：

npm ls -g --depth=1 @anthropic-ai/claude-code @anthropic-ai/claude-code-win32-x64

当时的结果只显示：

`-- @anthropic-ai/claude-code@2.1.121

但没有看到 @anthropic-ai/claude-code-win32-x64。

这就把链条彻底闭合了：

• 包装包装上了
• Windows 原生包没装上
• postinstall 因为找不到平台包，只能保留占位 stub
• claude.cmd 又一股脑去执行这个 stub
• Windows 最终报“不是有效应用程序”

七、修复过程：先装包装包，再补装平台原生包

第一步我先尝试了常规重装：

npm install -g @anthropic-ai/claude-code@latest

这个命令执行成功了，但问题仍然存在。
说明这台机器上，单纯重装包装包不足以把缺失的原生包拉下来。

于是进入第二步，直接安装 Windows x64 对应的平台包：

npm install -g @anthropic-ai/claude-code-win32-x64@2.1.121

装完以后，再看目录结构，就能看到：

• @anthropic-ai/claude-code
• @anthropic-ai/claude-code-win32-x64

这时再检查真正的二进制文件，长度已经是正常量级：

253241504 bytes

也就是大约 253 MB，这才像一个真正的 Windows 原生 CLI。

进一步确认 bin\claude.exe 的链接关系，还能看到它已经和平台包里的真实文件建立了关联。
从工程角度看，这说明 Claude Code 的安装脚本已经不再指向 stub，而是指向实际可执行程序。

八、修复完成后的第一层验证：CLI 能否正常启动

修完可执行文件以后，第一层验证非常直接：

claude --version

返回结果：

2.1.121 (Claude Code)

这一步意义很大，因为它证明的是：

• Windows 已经能够正常启动 claude
• npm 全局入口已经连到了真实程序
• 之前那种“16 位应用程序”错误已经消失

如果这一步还过不了，就不要急着测 API；因为 CLI 自己都还没活过来。

九、第二层验证：MiMo 配置是否真的生效

CLI 能启动，只能说明“程序装好了”；还不能证明“MiMo 配好了”。

所以我又做了第二层验证：

1. 检查当前进程环境里是否存在会覆盖本地配置的 ANTHROPIC_* 变量
2. 直接发一个最小请求，确认它能通过 MiMo 返回结果

实际验证命令：

claude -p "只回复 OK"

返回结果：

OK

这一步说明两件事：

• Claude Code 已经成功读取了 ~/.claude/settings.json
• 配置里的 MiMo endpoint、key 和模型名至少在最小请求链路上是可用的

十、最终生效的 Claude Code 配置

1. CLI 配置

CLI 侧最终使用的是下面这套配置结构。

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://token-plan-sgp.xiaomimimo.com/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "tp-xxxxx",
    "ANTHROPIC_MODEL": "mimo-v2.5-pro",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "mimo-v2.5-pro",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "mimo-v2.5-pro",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "mimo-v2.5-pro"
  }
}

对应文件：

• C:\Users\<用户名>\.claude\settings.json
• C:\Users\<用户名>\.claude.json

其中 C:\Users\<用户名>\.claude.json 最少需要：

{
  "hasCompletedOnboarding": true
}

2. 关于 Base URL 的一个细节

MiMo 文档页里通常会给示例地址，但实际使用时，Token Plan 应该以你控制台或订阅管理页给出的专属 Base URL 为准。

这次机器上真正生效的，是：

https://token-plan-sgp.xiaomimimo.com/anthropic

而不是机械照抄某个文档示例地址。

这件事非常重要，因为很多人会把“文档示例地址”和“自己订阅实际分配的地址”混为一谈。

3. 如果你用的是按量 API

如果你不是 Token Plan，而是按量 API，那么通常应改成：

ANTHROPIC_BASE_URL=https://api.xiaomimimo.com/anthropic
ANTHROPIC_AUTH_TOKEN=sk-xxxxx

模型名仍然需要按 MiMo 当前支持的模型填写。

十一、VS Code 插件同步：不要盲信文档里的旧键名

CLI 修好以后，下一步是把 VS Code 里的 Claude Code 插件也同步到 MiMo。

当时这台机器上已经安装了：

anthropic.claude-code-2.1.121-win32-x64

我进一步检查了扩展自身的 package.json，确认这版扩展真正支持的配置项包括：

• claudeCode.environmentVariables
• claudeCode.disableLoginPrompt
• claudeCode.preferredLocation

但并没有发现一个稳定声明的 claudeCode.selectedModel 配置项。

这意味着一个很实际的问题：

某些文档示例、旧教程、社区文章里出现的键名，不一定和你本机实际安装的扩展版本一致。

所以这次我没有去写一个“看起来很合理、但扩展未必认”的设置项，而是直接按扩展声明里真实支持的方式，把环境变量写进 VS Code 用户设置。

最终写入到：

C:\Users\14429\AppData\Roaming\Code\User\settings.json

内容如下：

{
  "claudeCode.preferredLocation": "panel",
  "claudeCode.disableLoginPrompt": true,
  "claudeCode.environmentVariables": [
    {
      "name": "ANTHROPIC_BASE_URL",
      "value": "https://token-plan-sgp.xiaomimimo.com/anthropic"
    },
    {
      "name": "ANTHROPIC_AUTH_TOKEN",
      "value": "tp-xxxxx"
    },
    {
      "name": "ANTHROPIC_MODEL",
      "value": "mimo-v2.5-pro"
    },
    {
      "name": "ANTHROPIC_DEFAULT_SONNET_MODEL",
      "value": "mimo-v2.5-pro"
    },
    {
      "name": "ANTHROPIC_DEFAULT_OPUS_MODEL",
      "value": "mimo-v2.5-pro"
    },
    {
      "name": "ANTHROPIC_DEFAULT_HAIKU_MODEL",
      "value": "mimo-v2.5-pro"
    }
  ]
}

写完以后，还要做两件事：

1. 执行一次 Developer: Reload Window
2. 如果扩展里残留了旧登录态，执行一次 Claude Code: Logout 再重新打开

十二、这个案例里，最容易踩的五个坑

1. 把系统层错误误判成模型配置错误

只要报错发生在 claude 进程启动之前，优先查本地安装链路，不要先改 BASE_URL。

2. 看到 npm install 成功，就默认程序一定可用

这个案例证明，包装包安装成功，不代表平台原生包一定安装成功。

3. 忽视 optionalDependencies

Claude Code 的 Windows 原生包是通过 optionalDependencies 安装的。
这类依赖一旦缺失，主包本身可能仍然“安装成功”，但功能实际上不可用。

4. 直接照抄文档示例地址

MiMo 的 Token Plan 地址应以实际控制台分配结果为准，不要无脑复制文档页上的示例。

5. 在博客或截图里泄露真实 key

无论是 sk-xxxxx 还是 tp-xxxxx，都不要把真实值发进文章、工单、截图或终端录屏里。
技术分享要详细，但密钥必须脱敏。

十三、给读者一套可复用的排障顺序

如果你也在 Windows 上给 Claude Code 接 MiMo，我建议按下面顺序排：

第一步：先看命令能不能启动

claude --version

如果这里就失败，优先查安装，不要先查 API。

第二步：检查 claude.cmd 指向的真实程序

where.exe claude
Get-Content "$env:APPDATA\npm\claude.cmd"

第三步：看 bin\claude.exe 是否异常小

Get-Item "$env:APPDATA\npm\node_modules\@anthropic-ai\claude-code\bin\claude.exe" |
  Select-Object Length

如果是几百字节，基本就是 stub。

第四步：检查平台原生包是否存在

npm ls -g --depth=1 @anthropic-ai/claude-code @anthropic-ai/claude-code-win32-x64

第五步：补装缺失的平台包

npm install -g @anthropic-ai/claude-code-win32-x64

第六步：确认 MiMo 配置文件

Get-Content "$env:USERPROFILE\.claude\settings.json"
Get-Content "$env:USERPROFILE\.claude.json"

第七步：发一个最小请求验证

claude -p "只回复 OK"

十四、结语：真正的经验，不是“把它配好”，而是“知道为什么会坏”

这次排障如果只看结果，其实就两句话：

• 补上 Claude Code 缺失的 Windows 原生二进制
• 把 CLI 和 VS Code 都指向 MiMo 的 Anthropic 兼容接口

但真正有价值的，不只是“把它修好”，而是搞清楚背后的安装机制：

• @anthropic-ai/claude-code 不是一个纯 JS 命令
• 它依赖平台原生包
• Windows 上看到“16 位程序”之类的错误时，很多时候不是系统真在运行一个 16 位程序，而是你交给它的文件压根不是合法的 PE 可执行文件

从工程视角看，最重要的不是记住某一个命令，而是建立一套排障思路：

1. 先判断错误发生在哪一层
2. 启动层错误先查本地安装链路
3. 网络层错误再查模型和 API 配置
4. IDE 配置要以当前扩展实际声明的设置项为准

如果你后面还要继续把 MiMo 接到 Codex、Cline、Cherry Studio 或其他工具上，建议也沿用同样的思路：先验证 CLI 主链路，再同步 IDE 或上层工具。