Kimi Code CLI 台灣實用指南：先驗證登入，再跑第一個 AI coding 任務

Kimi Code CLI 裝起來不難，真正容易卡住的是下一步：台灣帳號能不能登入、付款路徑是否可用、API key 到底該放哪裡，以及你敢不敢讓它碰真實 repo。這篇會把已由官方文件確認的功能，和仍須台灣帳號親自驗證的部分分開。我目前沒有用台灣帳號完成 OAuth、checkout 與付費實測，所以不會假裝知道即時價格或額度。

這篇的目標讀者是已經會用 Git、能看懂 diff 並執行專案 tests 的開發者。若這些名詞還陌生，先別急著安裝，你可以先把本文當成風險清單，找熟悉 Git 的同事陪同完成第一次試跑。

適用範圍：本文針對台灣使用者的帳號與付款疑問撰寫。CLI 的安裝、provider 與權限行為來自官方文件；地區可用性仍要以你的帳號實際畫面為準。

TL;DR

• 安裝前先確認 Kimi OAuth、官方 checkout 或你現有的 API credential 至少有一條能走通。
• 一般 provider 的 API key 要放進 config.toml，單純 export KIMI_API_KEY=... 不會自動生效。
• 第一次只用 toy repo、獨立 branch、最少 secrets，保留人工 approval，先別開 --yolo。
• Kimi Code CLI 支援多種 provider protocol。值不值得換，要比較同一任務的完成率、修正次數與復原成本，不是只看月費。

Kimi Code CLI 適合誰，哪些人先不要換

Kimi Code CLI 適合能看懂 git diff、會跑 tests，也知道怎麼把變更回滾的開發者或 indie maker。 它可以讀寫 code、搜尋檔案、執行 shell command，還會規劃後續步驟。這些能力很方便，但也代表你必須有能力判斷它改得對不對。

如果你不太會寫程式，可以先拿它讀一個小專案、解釋資料流，或替有 tests 的小 bug 擬計畫。不要一開始就把「幫我重構整個專案」丟進 production repo。看不懂 diff、沒有 tests、也不知道怎麼回上一個 commit 時，agent 做得越快，通常只會讓你更晚發現問題。

開始前先問自己三題：

1. 我能判斷這次 diff 有沒有碰到不該碰的檔案嗎？
2. 任務失敗時，我能用 branch 或 commit 回滾嗎？
3. repo 裡的 production secrets、客戶資料與未知 MCP 設定是否已隔離？

三題只要有一題答不出來，就先留在 sandbox。若你需要企業級資料保留、加密或合規保證，也應先向供應商取得正式文件，因為本次查到的 CLI 文件不足以回答這些企業政策問題。

安裝前先跑台灣帳號與計費 preflight

官方 getting-started 說，使用者需要有效的 Kimi membership，或一把可呼叫的 API key。首次啟動可用 /login 選 Kimi Code OAuth，也能輸入 Kimi Platform API key。不過，官方頁面沒有列出「台灣可購買哪些方案」的地區表格。

台灣能不能使用 Kimi Code CLI？ CLI 可在支援的作業系統安裝，但 membership、付款方式與額度不能從「安裝成功」推論。最可靠的做法，是用自己的帳號完成登入與 checkout 檢查，或先準備已能呼叫的 provider API key。

我會在安裝前跑這個快速檢查，每一步都要有明確的通過訊號：

1. 開啟 Kimi 官方登入頁，能完成帳號驗證或 device-code flow 才算通過。
2. 進入官方 checkout，帳號實際顯示可選方案、幣別與付款方式才算通過。不要拿第三方截圖當現況。
3. 若走 API，先在 Kimi Platform 建立 credential，確認 key 與 direct API 的 base URL 配對。
4. 啟動 CLI 後完成一次最小請求，確定沒有 authentication 或 billing 錯誤，再投入 AGENTS.md、MCP 與專案規則的遷移。

官方目前把兩條連線路徑分開：用 /login 的 Kimi Code managed service 由 CLI 自動設定 https://api.kimi.com/coding/v1 與 OAuth credential。direct API key 的 endpoint 則出現官方文件差異，Help Center 列出 https://api.moonshot.cn/v1，新版 provider 文件把 kimi provider 預設值列為 https://api.moonshot.ai/v1。因此不要跨區照抄 endpoint，應以你建立 key 的 Kimi Platform console 與當下 provider 設定頁為準。遇到 authentication failed，先確認自己走的是 OAuth managed service 還是 direct API key，再核對 key、base URL 與 billing account，別急著重裝 CLI。

macOS、Linux、Windows 的安裝與 PATH 排錯

官方目前推薦 install script，這條路不要求你預先安裝 Node.js。macOS 或 Linux 可執行：

curl -fsSL https://code.kimi.com/kimi-code/install.sh | bash

Windows PowerShell 使用：

irm https://code.kimi.com/kimi-code/install.ps1 | iex

如果你習慣 npm，官方要求 Node.js 22.19.0 以上：

npm install -g @moonshot-ai/kimi-code
kimi --version

Windows 第一次啟動前還要安裝 Git for Windows，因為 CLI 會使用隨附的 Git Bash。若 Git Bash 不在預設位置，需把 KIMI_SHELL_PATH 指到 bash.exe 的完整路徑。

看到 kimi: command not found 時，先重開 terminal，接著依你使用的 shell 執行 source ~/.bashrc 或 source ~/.zshrc。仍失敗再檢查 ~/.local/bin 是否存在於 PATH。這比一直重跑 installer 更容易找到真正的斷點。

安裝完成後先跑 kimi --version，再進 toy repo 執行 kimi。先確認 executable 與 PATH 正常，才處理 OAuth 或 provider，排錯時才不會把兩個問題混在一起。

先選登入方式與 provider，再處理 API key

現行 Kimi Code CLI 已不只是綁定單一模型的終端。官方 provider 文件列出的 protocol 類型包含 kimi、anthropic、openai、openai_responses、google-genai 與 vertexai。這代表你可以把它當成可替換 provider 的 agent shell，但不代表每一個模型、功能或價格都完全相同。

你的情況	建議起點	先確認什麼
已有可用的 Kimi Code membership	用 /login 走 OAuth	台灣帳號 checkout 與 credits 是否實際顯示
已有 Kimi Platform API key	用 /login 選 Platform API key	key 與 base URL 是否屬於同一平台
已在用 Anthropic、OpenAI 或 Google API	設定對應 provider	protocol、base URL、模型名稱與 billing account
沒有任何可用 credential	先不要遷移工作流	先完成帳號與付款 preflight

最常見的誤會，是以為這樣就夠了：

export KIMI_API_KEY="your-real-key"

官方文件目前明寫，一般 credential 不會自動從 shell environment variables fallback。你要在 ~/.kimi-code/config.toml 的 provider 設定加入 api_key，或使用對應 provider 的 env 子表。以下只示範結構，請勿把真 key 貼進 issue、聊天紀錄或公開 repo：

[providers.kimi]
type = "kimi"
base_url = "https://api.moonshot.ai/v1"
api_key = "YOUR_API_KEY"

上面範例採用新版 provider 文件列出的 .ai endpoint。若你的 key 來自列出 .cn endpoint 的平台，請使用該 console 對應的 base URL，不要把不同區域的 key 與 endpoint 混在一起。

credential 的優先序是 provider 的 api_key，其次為該 provider 的 env 子表；兩者都沒有時，CLI 會在啟動時報錯。OAuth managed account 則用 /login、/logout 管理，不會顯示在 /provider 清單裡。

改完設定後，重新啟動 kimi，輸入 /provider 檢查 direct API provider 是否已列出，再確認預設模型屬於預期的 provider。若你走的是 /login OAuth，帳號不會出現在 /provider，這是官方設計，不代表登入失敗。

用 Plan mode 跑完第一個可驗證任務

我不會把沒跑過的流程寫成「實測成功」。目前可確認的是，官方說明 read-only 操作預設能自動執行，修改檔案與執行 shell command 通常會要求確認；--plan 會優先使用 read-only tools 做探索與規劃。

第一次試跑，我會選一個有 tests、人工可在 15 分鐘內驗證的小 bug。這裡的 toy repo 指專門拿來測試、不含 production secrets，也能隨時丟棄的練習專案：

git switch -c test/kimi-first-run
kimi --plan

進入後先給它一個窄任務，例如：「只讀取相關檔案，找出這個測試失敗的原因，先提出修改計畫，不要更動檔案。」確認它理解範圍後，再讓它離開 Plan mode，批准一個小修改。

接著自己過五關：

1. Plan：它指出的 root cause 是否對得上 code？
2. Edit：diff 是否只碰預期檔案？
3. Test：測試真的有跑，還是只口頭說會通過？
4. Review：是否新增依賴、改設定或碰 secrets？
5. Rollback：若結果不對，能否乾淨丟掉 branch？

如果你想先理解 coding agent 的共同比較方式，可以搭配三款 CLI agent 的決策指南看評估維度。這裡的重點仍是同一個：模型答得漂亮，不等於變更可以直接 merge。

Production Mine Map：權限、YOLO 與 MCP 的三層地雷

第一層是檔案修改，第二層是 shell command，第三層是 MCP 把外部工具接進 agent。這三層疊起來後，一個看似單純的 prompt 可能觸及 repo、terminal、遠端服務與 credential。

--yolo 會跳過一般 tool calls 的人工 approval，包含寫檔與 shell command。官方 command reference 也說明，Plan mode 的離開確認不會被 YOLO 略過，但這不表示其他操作都安全。更容易忽略的是，MCP tool calls 在 YOLO mode 也會自動核准。

project-level MCP 設定放在 .kimi-code/mcp.json。其中 stdio server 的 command 會在 session 啟動時執行本機命令，官方要求只在信任的 repo 啟用。若你 clone 了一個陌生專案，還沒讀這個檔案就直接啟動 agent，風險比「AI 可能改錯一行 code」大得多。

第一次試跑請保留這些護欄：

• 不在含 production secrets 的 repo 啟動。
• 先讀 .kimi-code/mcp.json，未知 server 一律停用。
• 高風險的寫檔、shell、遠端操作保留人工 approval。
• 不使用 mcp__* 這類全開 wildcard。
• 用獨立 branch，跑 tests 後人工 review diff。

安全邊界怎麼抓？ 只有在 repo、MCP server、command 與 rollback 都已知時，才考慮提高自動核准程度。陌生 repo 或客戶案維持手動 approval，通常比省掉幾次按鍵划算。

Sessions、credentials 與 logs 放哪裡

Kimi Code CLI 預設把 config、session history、OAuth credentials、logs 與 update cache 放在 ~/.kimi-code/。session 會依 working directory 分組存到 sessions/，因此關掉 terminal 後仍可續接。

常用操作包括：

kimi --continue
kimi --session
kimi export <sessionId>

--continue 續接目前目錄最近的 session，--session 可選歷史 session 或指定 ID。兩者不能同時用。TUI 裡也能用 /fork 分出獨立 session。官方警告不要手動修改 sessions/ 內部檔案，否則可能無法恢復。

需要隔離個人 side project 與客戶案時，可在啟動前改資料根目錄：

export KIMI_CODE_HOME="$HOME/.config/kimi-code-client-a"
kimi

這會讓 config、sessions、logs 與 OAuth credentials 一起移到新位置。注意，多個 instance 若共用同一個 KIMI_CODE_HOME，也會共用 credential 與 config。

session export 可能包含 code、command output、檔案路徑與 diagnostic logs。分享給同事或客服前先解壓檢查；官方也提供 --no-include-global-log，可在不需要時排除 global diagnostic log。

從舊 kimi-cli 遷移，先備份再升級

GitHub 上的 MoonshotAI/kimi-cli 仍存在，但官方 README 已說明它正在演進為 Kimi Code CLI，安裝新版會自動遷移設定與 sessions，舊專案將逐步退場。官方沒有公布完整退場日期，所以別自行猜一個 deadline。

舊使用者先盤點這四類資料：config、sessions、MCP servers、自訂規則。備份完成後依官方 migration 文件操作，再跑 smoke test：確認登入、provider、模型、MCP 與舊 session 是否能正常讀取。

這裡有個很實際的判斷。搜尋到舊 kimi-cli 教學時，可以拿來理解歷史脈絡；涉及安裝 package、config 路徑、flags 與 provider 的操作，應回到現行 Kimi Code docs 核對。CLI 變動很快，一條過期指令就足以讓後面的排錯全部走偏。

用 30 到 60 分鐘 scorecard 比較其他 coding agents

這篇沒有拿 Kimi Code CLI、Claude Code、Codex 與 OpenCode 跑同條件 benchmark，也沒有可驗證的台灣即時價格，所以我不會硬排冠軍。你可以用同一個小 repo、同一個 bug 與同一組 tests，自己留下可重現紀錄。

評估項目	怎麼記錄	為什麼有用
首次完成	第一次輸出是否通過 tests	避免只看 demo 的漂亮片段
總耗時	從 prompt 到可 review diff	包含等待與排錯，不只模型速度
人工修正	改了幾次、哪裡需要接手	看真實審核成本
權限控制	哪些操作會詢問 approval	判斷能否放進日常 repo
復原成本	失敗後多久回到乾淨狀態	production 工作流很在乎這點
session 追溯	能否找到歷史、匯出與 fork	長任務比一次問答更需要
provider 切換	設定是否清楚、結果是否穩定	避免被單一帳號或模型綁死

每個工具各跑一次通常不夠，因為偶發成功很容易誤導。至少記錄同一類任務的多次結果，再看哪個工具讓你最少接手、最容易知道它做過什麼。月費最後再填，因為便宜但需要你花更多時間救火，CP 值未必比較高。

什麼情況下不要放進 production repo

有四道 gate。帳號與資料路徑不清楚、repo 或 MCP 不可信、沒有 tests 與 rollback、人工 review 無法落實，任一道沒過，就留在 sandbox。

私人或客戶專案還要多問一層：哪些 code、prompt、tool schema、command output 與 log 可能進入 session 或 export？官方 session 文件確認 event stream 會保存請求 trace，也提醒 export 可能包含敏感內容；至於遠端服務的 retention、訓練使用與企業 SLA，必須再看你選用 provider 的正式政策，不能用 CLI 本機資料位置代替答案。

Kimi Code CLI 值得試，但先別急著整套搬家。如果你已經有可用 credential，也能 review diff、跑 tests 與回滾，就用 toy repo 完成 preflight 和 scorecard；如果台灣 checkout 還不確定，或客戶案的資料政策尚未核准，先把它留在測試環境。等這些 gate 都過了，再讓 agent 靠近真正重要的 code。