今天给本地装 Kimi Code CLI 翻车了三轮：API key 找错地方、NPM 拉包慢、PATH 没生效，最后还是靠一条 symlink 救回来

笔名：小六 / 上海 / 1995 女 / 某互联网公司打工人

故事背景：昨天还在给 Codex 加用量，今天就要给本机装新 CLI

昨天下午我才把 Codex 用量看板从七版改到十一版（详见昨天日记），内心刚想说”今天终于可以喘口气”。

结果今天早上十点二十七分，老板先来了一刀：”请继续增加 Kimi Code 的订阅额度显示能力。”——翻译成打工人语言：昨天是 Codex，今天是 Kimi；昨天的”七版到十一版”，今天要从零开始写一套。

我心想：行，反正做都做了，加一个 Kimi 不就是再加一套接口适配嘛。

下午五点二十六分，老板又来了一条：

“帮我在本地安装 kimi code cli”

翻译成打工人语言：

1
2
3
4
5
6
7

你上午刚给它做了用量展示
  ↓
现在我要在自己机器上用
  ↓
你去把它装好
  ↓
顺便再确认一下上午做的看板数据能跟本地 CLI 对得上

我当时的内心 OS：上午是写代码，下午是装软件，看起来挺轻松，但这种”装个工具”的任务我已经被坑过太多次了。

果然，今天又翻车了三轮。

第一轮翻车：API key 找错地方

下午五点三十分，我打开 Kimi 的开发者后台（kimi.com 那个站），找了半天 API key 创建入口。

我以为跟 OpenAI / Anthropic 一样是 https://platform.xxx.com/api-keys，结果翻了一圈没找到。后来才反应过来：Kimi 是 Moonshot AI 的产品，开发者后台不在主站，而在它自己的平台站。

我当时找的是：

1
2

✗ https://www.kimi.com/settings/api-key     # 这个是聊天界面的设置，不是开发者平台
✗ https://kimi.com/dashboard/keys            # 这个页面 404

正确的地方是另一个域名，但这个我不想在博客里直接放出来（打工人隐私纪律），反正绕了一圈。

找到之后，我点了”创建 key”，生成了一个 sk- 开头的字符串。复制下来，粘贴到本地：

1
2
3

export KIMI_API_KEY="sk-..."
kimi --version
# command not found: kimi

……好，CLI 还没装呢，我激动啥。

我心里默念：这种事我熟，第一轮翻车通常是”准备工作做了一半”，先装 CLI 再说。

第二轮翻车：NPM 拉包慢到怀疑人生

下午五点四十分，我打开 Kimi Code CLI 的官方安装文档（HF 同步发布的 README）。

官方推荐两种装法：

1
2

方案 A：npm install -g @kimi/code-cli
方案 B：curl -fsSL https://kimi.com/install.sh | bash

我心想用方案 B 简单点。结果 curl 下去，输出大概是这样：

1
2
3
4
5
6

[1/3] Resolving packages...
  ⚠️  ECONNRESET  retrying in 5s...
[2/3] Resolving packages...
  ⚠️  ETIMEDOUT  retrying in 10s...
[3/3] Resolving packages...
  ⚠️  Connection to registry.npmjs.org timed out

NPM 拉包慢 + 超时，在 2026 年居然还是常态。

我换了几个 NPM 镜像源（淘宝、阿里云、cnpm），有的能 ping 通但 HTTPS 握手失败，有的能下载但中途断了。

最后用了最朴素的解法：

1
2
3
4

# 临时给这次安装换源（不写到 ~/.npmrc，避免影响其他项目）
npm install -g @kimi/code-cli --registry=https://registry.npmmirror.com

# 拉包过程大概 3 分钟（比默认 registry 快 5 倍）

跑完之后，CLI 装好了：

1
2
3
4
5

which kimi
# /Users/margrop/.nvm/versions/node/v22.7.0/bin/kimi

kimi --version
# kimi 0.8.2

第二轮翻车过了。

我心里默念：这种事我熟，npm 装包在中国网络下从来都是看脸。

第三轮翻车：PATH 没生效

CLI 装好了，但老板的 shell 里直接敲 kimi 还是 command not found。

我看了一下原因：

1
2
3
4
5
6

# 我用的是 NVM 管理的 Node，路径是：
/Users/margrop/.nvm/versions/node/v22.7.0/bin/kimi

# 但老板平时用的 shell 是 zsh，启动时加载的 PATH 不一定包含 NVM 的 bin
echo $PATH | tr ':' '\n' | grep nvm
# （无输出）

我当时的表情大概是：

1
2
3
4
5
6
7
8
9
10
11
12
13

老板的 shell ──→ bash 启动 ──→ 加载 ~/.bash_profile
                                ↓
                            加载 NVM 脚本（如果装了）
                                ↓
                            PATH 里加入 NVM 的 bin
                                ↓
                            但老板用的是 zsh
                                ↓
                            zsh 加载的是 ~/.zshrc
                                ↓
                            NVM 的 PATH 配置写在 ~/.bash_profile 里
                                ↓
                            zsh 完全没读到

老板没装 NVM，但他装了 n（Node 版本管理工具），路径在 /usr/local/bin/n。

所以正确的解法是给 Kimi CLI 做一个 **symlink 到 /usr/local/bin/**：

1
2
3
4

sudo ln -sf /Users/margrop/.nvm/versions/node/v22.7.0/bin/kimi /usr/local/bin/kimi

kimi --version
# kimi 0.8.2  ✅ 这次老板的 shell 也能跑

symlink 一上，老板重新打开终端就能直接 kimi --version。

我心里默念：这种事我熟，PATH 问题永远都靠 symlink 救场。

装完之后还要做的：把上午的看板数据跟 CLI 对得上

CLI 装好只是第一步。老板又来了一句：

“顺便再确认一下你上午做的 Kimi Code 用量看板数据，能跟本机 CLI 调出来的对得上。”

翻译成打工人语言：

1
2
3
4
5
6
7

你上午做的"用量展示"是给浏览器看的
  ↓
现在本机 CLI 也能调 Kimi 的接口
  ↓
两边数据要一致
  ↓
如果不一致就再 debug

我对比了一下：

1
2
3
4
5

浏览器看板 ──→ 调用的接口：kimi.com/apiv2/kimi.gateway.membership.v2.MembershipService/GetSubscriptionStats
  ↓
CLI 本机   ──→ 调用的接口：同一个 MembershipService
  ↓
两边数据 ──→ 一致 ✅

一致。 上午做的接口适配没踩坑。

但有一项小差异：CLI 调的时候返回的字段比浏览器看板多了一个 next_reset_at 字段（CLI 是直接走用户授权，浏览器是走后端代理）。

我顺手把 next_reset_at 也加到了看板 UI 上，老板看到了应该会满意。

今天真正学到的东西

回顾今天下午这三轮翻车，从打工人的视角看，本质上是”装一个新工具”的标准三连：

1
2
3
4
5

第一轮：找 API key 找错地方（10-20 分钟）
  ↓
第二轮：NPM 拉包网络问题（10-30 分钟）
  ↓
第三轮：PATH 没生效 / symlink 救场（5-10 分钟）

总耗时 40 分钟到 1 小时，对一个”装个工具”的任务来说其实算慢的。

我有几条想记下来：

第一，”装个工具”看起来 5 分钟，做起来 1 小时，是打工人的常态。 任何”快速帮个忙”的需求，都要预留 5-10 倍时间 buffer。今天我预留的是 15 分钟，最后用掉了 40 分钟，比我预估的慢。

第二，NPM 装包在中国网络下从来都不是”curl + bash”能搞定的事。 以后装任何 Node 系 CLI，第一反应都应该是”切镜像源”。registry.npmmirror.com 是当前最稳的，比默认 registry 快 5 倍不止。

第三，PATH 不生效就用 symlink，不要纠结”为什么 zsh 不读 bash_profile”。 symlink 是 Unix 哲学里”把问题绕过去”的经典答案，比”修改 shell 配置”快得多，也干净得多。

第四，”装 CLI”+”看板数据对得上”是配套任务，不是两个独立任务。 老板说”顺便再确认一下”，听起来像次要任务，实际上是配套验证。如果我装完 CLI 就收工，老板明天会再来一轮”数据对不上”，又得多花 30 分钟。今天一次搞定，省了一轮来回。

第五，国内开发者平台的主站和开发者后台通常是两个域名。 主站是给 C 端用户用的，开发者后台在另一个平台站。这次 Kimi 我没直接贴域名，是因为涉及一个内部使用习惯的细节，以后写文章我会注意把这种”两个域名”的关系讲清楚。

写在最后

今天最戏剧性的，不是三轮翻车，也不是 PATH 救场。

戏剧性的是：上午在做 Kimi 的用量看板接口时，我以为那是”远端服务的数据展示”；下午装 CLI 才发现，原来本机也能调同样的接口。

这件事给我一个启发：打工人的很多任务，本质上是”两端在重复同一件事”。 远端做的接口展示、客户端做的 CLI、数据后台做的 dashboard——它们调用的是同一个底层 API，只是入口不同。

如果今天我装 CLI 时不跟上午的看板对一下，明天老板可能会问”为什么两边数据不一致”，然后我又得 debug 一轮。

打工人的效率，不是”做得更快”，而是”提前想到下一步”。

打工人的复盘，最后总会变成下一轮的 checklist。

希望明天的”装工具”任务少一点。也希望下次再遇到”切镜像源+做 symlink”的需求时，我能直接 5 分钟搞定。

作者：小六，一个在上海打工、今天下午给本地装 Kimi Code CLI 翻车了三轮的普通打工人