將外部模型連接到 Codex 是一個複雜的過程。本指南以 Kimi API 作為實作範例，帶你完成在 macOS 和 Windows 上完整的 Codex API 設定。
什麼是 Codex？
Codex 是 OpenAI 針對程式庫與終端機作業所打造的程式編寫 agent。它可以：
撰寫程式碼： 建立函式、測試與針對性的功能。
理解陌生的程式碼庫： 搜尋檔案、追蹤呼叫關係並說明各個元件。
檢查程式碼： 找出可能的缺陷、有風險的假設、缺漏的測試以及安全疑慮。
除錯與修正問題： 重現錯誤、提出修改方案並執行檢查。
自動化例行工作： 在你的核准下更新檔案並執行既定的工作流程。
安裝並登入 Codex
第一部分：安裝 Codex CLI
在 macOS 上開啟終端機，或在 Windows 上開啟 PowerShell。
依你的作業系統執行對應指令：
macOS：
curl -fsSL https://chatgpt.com/codex/install.sh | shWindows：
powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"等待安裝完成，然後關閉並重新開啟終端機或 PowerShell。
執行：
codex選擇「使用 ChatGPT 登入」，完成瀏覽器登入流程，然後回到終端機或 PowerShell。
第二部分：安裝 Codex 桌面應用程式
前往 Codex 桌面應用程式官方頁面。
下載 macOS 或 Windows 版的 ChatGPT 桌面應用程式。
安裝並開啟應用程式，然後使用你的 ChatGPT 帳號登入。
建立一項工作或開啟一個專案，並選擇 Codex 作為工作模式。
輸入「Say hello in one sentence.」並傳送訊息。
內建 AI 模型 vs. 外部 LLM API
安裝 Codex 後，你可以使用它內建的 AI 模型，也可以連接相容的外部 LLM API。哪個選項最合適，取決於你願意投入多少設定工作、想要多大的彈性，以及願意管理多少帳號。
使用 Codex 內建模型
內建模型提供最簡單的使用體驗。你可以選擇一個可用的模型，不需要另外執行其他服務或設定獨立的 API 金鑰，就能直接開始編寫程式碼。
優點：
設定快速，不需要額外的配置步驟。
直接整合 Codex 的工具與功能
需要管理的服務與憑證較少
限制：
只能從帳戶可用的模型中選擇
若想使用其他供應商的模型，彈性較低
需要 GPT 訂閱，且使用成本相對較高。
使用外部 LLM API
外部 API 讓你有更多模型選擇，並可使用其他供應商既有的帳戶。不過，部分模型在 Codex 使用前需要額外配置或本機相容工具。
優點：
可使用其他供應商的模型
應付不同編碼任務時更有彈性
可獨立控管外部 API 帳戶與使用量
不需要 GPT 訂閱，適合注重成本的情境。
限制：
需要 API 金鑰與額外配置
可能需要本機路由器，且必須持續運作
計費、相容性、隱私與疑難排解都取決於外部供應商
如果你想要最快完成設定，就從內建模型開始。如果你已經有外部 API 帳戶，或想要更多模型選擇，可繼續參考以下步驟說明。這裡以 Kimi API 為實例，示範如何將外部模型連接到 Codex。
如何將外部 LLM API 連接到 Codex：以 Kimi 為例
macOS 設定
步驟 1：開啟終端機 A，確認 Node.js 與 npm
位置： 按下 Command+Space，輸入 Terminal，再按下 Enter。將這個第一個視窗當作終端機 A。
執行：
node --version
npm --version預期結果： 每個指令都會印出版本號。像 Node.js 的 v22.x.x 與 npm 的 10.x.x 這類輸出僅為範例，並非最低版本需求。
若找不到指令： 開啟瀏覽器，前往 https://nodejs.org/en/download，下載 macOS 版的 LTS .pkg 安裝檔，在 Finder 中開啟下載項目，雙擊該安裝包，並依照安裝程式的預設選項完成安裝。以 Command+Q 關閉終端機，重新開啟終端機 A，再次執行兩個版本查詢指令。在兩個指令都能回傳版本號之前，請勿繼續下一步。
步驟 2：建立 Kimi API 金鑰
開啟 Kimi API 平台。 在控制台中建立一組 API 金鑰，然後將其儲存到密碼管理工具或密鑰管理工具中。如果控制台只顯示完整金鑰一次，請在離開頁面前先複製下來。
步驟 3：在終端機 A 中設定 MOONSHOT_API_KEY
位置： 回到終端機 A。
執行：
export MOONSHOT_API_KEY="YOUR_KIMI_API_KEY"只需將 YOUR_KIMI_API_KEY 替換成實際的 Kimi 金鑰。請保留引號與變數名稱 MOONSHOT_API_KEY 不變。
預期結果： export 指令不會印出任何內容。可以用以下方式確認值是否已設定，而不會顯示其內容：
test -n "$MOONSHOT_API_KEY" && echo "Kimi key is set"終端機應會印出 Kimi key is set。
步驟 4：直接在終端機 A 中測試 Kimi
位置： 繼續使用已設定 MOONSHOT_API_KEY 的終端機 A。
執行：
curl --silent --show-error https://api.moonshot.ai/v1/chat/completions \
-H "Authorization: Bearer $MOONSHOT_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"kimi-k2.7-code","messages":[{"role":"user","content":"Say hello in one sentence."}],"stream":false}'預期結果： 會出現一段 JSON 回應，其中 choices[0].message.content 底下包含生成的文字內容。
步驟 5：開啟終端機 B，並在終端機 A 中啟動路由器
位置：啟動終端機 A 後,按下 Command+N 開啟第二個視窗,將新視窗命名為終端機 B。執行路由器指令前,請切回終端機 A。
在終端機 A 中執行：
npx @codeproxy/cli --base-url https://api.moonshot.ai/v1 --model kimi-k2.7-code --apikey "$MOONSHOT_API_KEY"請勿替換基礎 URL 或模型。$MOONSHOT_API_KEY 必須保持為變數參照,不能貼上第二份重複的金鑰。
首次執行可能出現的提示：npx 可能會顯示「Need to install ... Ok to proceed? (y)」。請先檢視套件名稱及其連結的第三方來源。只有在你接受該套件的情況下,才輸入 y 並按下 Enter。這裡並未聲明已測試過某個確切的套件版本。
**預期結果：**該行程會持續執行,並回報正在監聽 127.0.0.1:8787。請保持終端機 A 開啟。
**若失敗：**如果 npm 無法下載套件,請確認網路連線,並重新執行 node --version 與 npm --version。如果連接埠 8787 已被占用,請停止使用該連接埠的其他本機行程,或切回其終端機並按下 Ctrl+C,然後重新執行路由器指令。
步驟 6：在終端機 B 中測試 localhost
**位置：**點選終端機 B。
執行：
curl --no-buffer --show-error http://127.0.0.1:8787/v1/responses \
-H "Content-Type: application/json" \
-d '{"model":"kimi-k2.7-code","input":"Say hello in one sentence.","stream":true}'**預期結果：**終端機 B 會印出類似 Responses 的串流事件,或包含一句話問候語的輸出。確切的事件順序可能因路由器版本而異。
若看到 Connection refused**：**請檢查終端機 A。如果路由器已停止,請重新執行步驟 5 的指令並保持開啟。如果終端機 A 顯示上游 401 錯誤,請在該處重設 MOONSHOT_API_KEY 並重新啟動路由器。
步驟 7：建立並編輯 macOS 的 Codex 設定檔
**位置：**繼續使用終端機 B。
執行：
mkdir -p "$HOME/.codex"
if [ -f "$HOME/.codex/config.toml" ]; then cp "$HOME/.codex/config.toml" "$HOME/.codex/config.toml.backup-$(date +%Y%m%d-%H%M%S)"; fi
touch "$HOME/.codex/config.toml"
open -e "$HOME/.codex/config.toml"這些指令會在必要時建立使用者層級的設定檔,備份既有檔案,並在 TextEdit 中開啟 ~/.codex/config.toml。
若檔案是空的
貼上以下完整設定：
model = "kimi-k2.7-code"
model_provider = "kimi-proxy"
model_context_window = 256000
model_supports_reasoning_summaries = false
[model_providers.kimi-proxy]
name = "Kimi via local proxy"
base_url = "http://127.0.0.1:8787/v1"
wire_api = "responses"
stream_idle_timeout_ms = 600000若檔案中已有設定
請勿用完整設定覆蓋既有檔案內容。保留無關的設定,並逐行更新所需的內容。
找到以
model =開頭的那一行,將整行替換為：
model = "kimi-k2.7-code"找到以
model_provider =開頭的那一行,將整行替換為：
model_provider = "kimi-proxy"找到以
model_context_window =開頭的那一行,將整行替換為：
model_context_window = 256000找到以
model_supports_reasoning_summaries =開頭的那一行,將整行替換為：
model_supports_reasoning_summaries = false如果這四項設定中有任何一項尚未存在,請在檔案開頭附近加入缺少的那一行。
找到並刪除以下開頭的整行：
model_catalog_json =同樣找到並刪除以下開頭的整行：
service_tier =加入以下區段：
[model_providers.kimi-proxy]
name = "Kimi via local proxy"
base_url = "http://127.0.0.1:8787/v1"
wire_api = "responses"
stream_idle_timeout_ms = 600000請勿移除其他提供者區段,例如 [model_providers.openai]。
保留其他無關的既有設定,包括 notify、核准、沙盒、專案及介面偏好設定。請勿複製其他使用者的 notify 那一行,因為其中可能包含特定電腦的絕對路徑。
按下 Command+S 儲存檔案,然後關閉 TextEdit。
步驟 8：重新啟動 Codex 並執行完整的 macOS 測試
**位置：**讓路由器繼續在終端機 A 中執行。在終端機 B 中,用 Ctrl+C 關閉任何現有的 Codex 工作階段,然後準備一個可捨棄的資料夾。
在終端機 B 中執行：
mkdir -p "$HOME/codex-kimi-test"
cd "$HOME/codex-kimi-test"
codex**測試：**輸入 hello. 並按下 Enter。收到一句話回覆即可確認基本的請求路徑正常運作。
Windows 設定
使用兩個獨立的 PowerShell 視窗。PowerShell A 儲存目前工作階段的 Kimi 金鑰並執行路由器。PowerShell B 用來測試 localhost、編輯設定並啟動 Codex。持久性的使用者變數可供未來的視窗使用;而目前工作階段的賦值則讓金鑰立即可在 PowerShell A 中使用。
步驟 1：開啟 PowerShell A 並確認 Node.js 與 npm
位置： 按下 Windows 鍵，輸入 PowerShell，開啟 Windows PowerShell。此視窗稱為 PowerShell A。
執行：
node --version
npm --version預期結果： 兩個指令都會印出版本號。像 v22.x.x 和 10.x.x 這類數值僅為範例，並非最低需求。
若指令無法識別： 開啟瀏覽器並前往 https://nodejs.org/en/download。下載 LTS 版 Windows .msi 安裝檔，在檔案總管中開啟 Downloads，雙擊安裝程式，接受預設設定，並確認安裝程式保留了將 Node.js 加入 PATH 的選項。關閉所有 PowerShell 視窗，重新開啟 PowerShell A，再次執行這兩個指令。
步驟 2：建立 Kimi API 金鑰
開啟 Kimi API 平台。 在主控台中建立一組 API 金鑰，然後將其存放於密碼管理工具或密鑰管理工具中。若主控台只會顯示完整金鑰一次，請在離開頁面前先複製起來。
步驟 3：在 PowerShell A 中設定永久變數與目前工作階段變數
位置： 回到 PowerShell A。
執行：
[Environment]::SetEnvironmentVariable("MOONSHOT_API_KEY", "YOUR_KIMI_API_KEY", "User")
$env:MOONSHOT_API_KEY = "YOUR_KIMI_API_KEY"只需將兩行中的 YOUR_KIMI_API_KEY 替換為同一組 Kimi 金鑰即可。MOONSHOT_API_KEY、User、引號與標點符號請保持不變。第一行會將該值儲存供日後的行程使用。第二行則讓其在 PowerShell A 中立即生效。
預期結果： 兩個指令都不會有輸出。可透過以下方式確認金鑰已存在，而不會印出金鑰內容：
$null -ne $env:MOONSHOT_API_KEYPowerShell 應會印出 True。
若印出的是 False： 請使用直引號重新執行目前工作階段的賦值指令。若 User 層級的寫入被政策封鎖，可先在本教學中使用目前工作階段的值繼續操作，並詢問您的系統管理員應如何儲存使用者環境變數。若金鑰曾出現在日誌或分享的文字中，請將其撤銷。
步驟 4：直接從 PowerShell A 測試 Kimi
API 參考文件可能會顯示 POST URL，但請勿單獨在 PowerShell 中輸入 POST https://...。請如下使用 Invoke-RestMethod -Method Post。
位置： 留在已設定 $env:MOONSHOT_API_KEY 的 PowerShell A 中。
執行：
$headers = @{ Authorization = "Bearer $env:MOONSHOT_API_KEY" }
$body = @{ model = "kimi-k2.7-code"; messages = @(@{ role = "user"; content = "Say hello in one sentence." }); stream = $false } | ConvertTo-Json -Depth 5
$response = Invoke-RestMethod -Method Post -Uri "https://api.moonshot.ai/v1/chat/completions" -Headers $headers -ContentType "application/json" -Body $body
$response.choices[0].message.content請勿更改端點、模型或變數名稱。PowerShell 會從 $env:MOONSHOT_API_KEY 讀取金鑰。
預期結果： 最後一行會印出來自 choices[0].message.content 的一句問候語。
若收到 401： 確認該金鑰來自全域 .ai 主控台，如有需要請撤銷並重新建立金鑰，重新執行步驟 3 中的兩個賦值指令，再試一次。若模型遭拒，請確認識別碼確實是 kimi-k2.7-code，並在 Kimi 主控台中確認模型存取權限。
步驟 5：開啟 PowerShell B 並在 PowerShell A 中啟動路由器
位置： 再次按下 Windows 鍵，輸入 PowerShell，開啟第二個 Windows PowerShell 視窗，稱之為 PowerShell B。接著回到 PowerShell A 執行路由器指令。
在 PowerShell A 中執行：
npx @codeproxy/cli --base-url https://api.moonshot.ai/v1 --model kimi-k2.7-code --apikey $env:MOONSHOT_API_KEY請保持 $env:MOONSHOT_API_KEY 不變，不要將金鑰直接貼入指令中。
首次執行可能出現的提示： npx 可能會顯示「Need to install ... Ok to proceed? (y)」。請先查看該套件與第三方來源，確認接受後再輸入 y 並按下 Enter。此處並未聲明已測試的確切套件版本。
預期結果： 該行程會持續開啟，並回報正在 127.0.0.1:8787 上監聽。請保持 PowerShell A 開啟。
若失敗： 在 PowerShell A 中執行 node --version 與 npm --version。若任一指令失敗，請重複步驟 1。若連接埠 8787 已被佔用，請在該視窗中按下 Ctrl+C 停止另一個路由器，再重新執行指令。
步驟 6：從 PowerShell B 測試本機連線
位置： 點選 PowerShell B。請勿停止 PowerShell A 中的路由器。
執行：
$localBody = @{ model = "kimi-k2.7-code"; input = "Say hello in one sentence."; stream = $false } | ConvertTo-Json
Invoke-RestMethod -Method Post -Uri "http://127.0.0.1:8787/v1/responses" -ContentType "application/json" -Body $localBody請勿更改 localhost 網址，它指向 PowerShell A 中的路由器。
預期結果： PowerShell 會回傳一個類似 Responses 的物件，或包含問候語的輸出內容。實際欄位可能因路由器版本而異。
若連線遭拒： 請查看 PowerShell A，若路由器已結束，請重新執行步驟 5 的指令。若 PowerShell A 顯示上游驗證錯誤，請按下 Ctrl+C，重設 $env:MOONSHOT_API_KEY，再重新啟動路由器。針對預設的 @codeproxy/cli 快速上手流程，請勿額外加入本機授權標頭。
步驟 7：建立並編輯 Windows 的 Codex 設定檔
位置： 繼續使用 PowerShell B。供應商設定檔應位於 $HOME\.codex\config.toml，而非專案資料夾內。
執行：
New-Item -ItemType Directory -Force -Path "$HOME\.codex" | Out-Null
$configPath = "$HOME\.codex\config.toml"
if (Test-Path $configPath) { Copy-Item $configPath "$configPath.backup-$(Get-Date -Format 'yyyyMMdd-HHmmss')" }
if (-not (Test-Path $configPath)) { New-Item -ItemType File -Path $configPath | Out-Null }
notepad "$HOME\.codex\config.toml"這些指令會建立使用者目錄、備份現有的設定檔、在檔案不存在時建立新檔，並以記事本開啟它。
在記事本中： 貼上以下完整的預設設定內容；若檔案中已存在衝突的重複 model 或 provider 鍵值，請將其移除：
model_provider = "kimi-proxy"
model = "kimi-k2.7-code"
model_context_window = 256000
model_supports_reasoning_summaries = false
[model_providers.kimi-proxy]
name = "Kimi via local proxy"
base_url = "http://127.0.0.1:8787/v1"
wire_api = "responses"
stream_idle_timeout_ms = 600000不要替換 kimi-proxy、localhost URL 或 responses。按下 Ctrl+S 並關閉記事本。
確認檔名： 執行：
Get-Item "$HOME\.codex\config.toml" | Select-Object FullName, Name, Length預期結果： Name 必須完全是 config.toml，而不是 config.toml.txt，且 Length 大於零。
如果記事本加上了 .txt： 在記事本中選擇 檔案 → 另存新檔，將 存檔類型 設為 所有檔案，輸入 config.toml，並儲存到 $HOME\.codex 中。重新執行 Get-Item。如果 Codex 仍忽略該供應商，請確認你編輯的是使用者層級的路徑，並移除重複的 TOML 鍵。
步驟 8：重新啟動 Codex 並執行完整的 Windows 測試
位置： 讓 PowerShell A 及其路由器保持運行。完全關閉任何 Codex 應用程式或工作階段。關閉 PowerShell B，按下 Windows 鍵並輸入 PowerShell 後重新開啟 Windows PowerShell，並建立一個可拋棄的資料夾。
在重新開啟的 PowerShell B 中執行：
New-Item -ItemType Directory -Force -Path "$HOME\codex-kimi-test" | Out-Null
Set-Location "$HOME\codex-kimi-test"
codex測試： 輸入 hello. 並按下 Enter。收到一句話的回覆即可確認基本請求路徑正常。
在 Codex 桌面應用程式中使用 Kimi
在繼續之前，請先完成 macOS 或 Windows 設定中步驟 1–7，設定本機路由器與 config.toml。你不需要先完成 CLI 測試，但在桌面應用程式中使用 Kimi 時，路由器必須保持運行。
步驟 1：保持本機路由器運行
讓終端機 A 或 PowerShell A 保持開啟，並確保 @codeproxy/cli 正在以下位址運行：
http://127.0.0.1:8787步驟 2：確認供應商設定
開啟使用者層級的 Codex 設定檔。
在 macOS 上，執行：
open -e "$HOME/.codex/config.toml"在 Windows 上，執行：
notepad "$HOME\.codex\config.toml"確認該檔案包含以下頂層設定：
model = "kimi-k2.7-code"
model_provider = "kimi-proxy"
model_context_window = 256000
model_supports_reasoning_summaries = false
[model_providers.kimi-proxy]
name = "Kimi via local proxy"
base_url = "http://127.0.0.1:8787/v1"
wire_api = "responses"
stream_idle_timeout_ms = 600000步驟 3：完全重新啟動桌面應用程式
在 macOS 上，按下 Command+Q 以完全結束桌面應用程式。只關閉視窗是不夠的。
在 Windows 上，關閉所有桌面應用程式視窗，並確認該應用程式已不在系統匣中運行。
重新開啟桌面應用程式並開啟一個專案資料夾。
步驟 4：保持選取 Custom 模型
桌面版模型選擇器可能會顯示 Custom，而不是 Kimi K2.7 Code。這是正常現象。
在 config.toml 中定義的自訂供應商，並不一定會以名稱形式顯示在桌面版模型清單中。當你想使用 Kimi 供應商時，不要選擇 GPT-5.6 Sol 之類的 OpenAI 模型。請保持選取 Custom。
你可能還會看到這個警告：
Model metadata for `kimi-k2.7-code` not found.
Defaulting to fallback metadata.這只是一則警告，並非連線失敗。以下設定已經提供了正常使用所需的重要模型資訊：
model_context_window = 256000
model_supports_reasoning_summaries = false步驟 5：驗證桌面版的請求路徑
在桌面應用程式中傳送這個提示詞：
在桌面應用程式回應時，觀察終端機 A 或 PowerShell A。如果終端機 A 視窗收到新的請求，且桌面應用程式回傳了答案，就代表桌面應用程式正在使用本機的 Kimi 路由。
排解常見整合錯誤
zsh: command not found: POST
POST URL 是 API 文件的標示方式，並非一個指令。在 macOS 上，請複製完整的 curl 範例。在 Windows 上，請複製完整的 Invoke-RestMethod -Method Post 範例。
8787 埠連線被拒
回到終端機 A 或 PowerShell A。如果沒有路由器程序在運行，請設定目前工作階段的 Kimi 變數，並重新執行文件中的 npx @codeproxy/cli ... 指令。保持該視窗開啟，然後在視窗 B 中重複 localhost 測試。
401 回應
查看路由器視窗以找出失敗的環節。上游 Kimi 回傳 401 通常代表 MOONSHOT_API_KEY 無效、已被撤銷，或來自錯誤的地區帳號。請在全域的 .ai 主控台撤銷該金鑰、建立新金鑰、重設目前工作階段的變數，並重新啟動路由器。預設的路由器路徑沒有傳入的持有者驗證檢查。若其他轉接器出現本機 401，可能代表其選用的 CODEX_KIMI_PROXY_KEY 缺失或無效。
不支援的參數或工具錯誤
路由器可能正在轉發一個 Kimi 不接受的欄位。抽樣相關欄位應保持未設定；若有傳送，則必須使用可接受的固定值。請確認 tool_choice 為 auto 或 none，且轉接器有保留 reasoning_content。如果多步驟測試仍然失敗，請停止使用該版本的路由器，改選或更新一個明確支援 Kimi 的版本。
Codex 忽略了供應商設定
直接開啟使用者設定檔:在 macOS 上執行 open -e "$HOME/.codex/config.toml",或在 Windows 上執行 notepad "$HOME\.codex\config.toml"。確認其中只有一個頂層的 model_provider = "kimi-proxy"、一個 provider 表格、localhost 基底網址,以及 wire_api = "responses"。儲存後,完全退出 Codex 再重新啟動。不要只在專案層級的 .codex/config.toml 中設定 provider。
npx 無法啟動 router
在 router 視窗 A 中執行 node --version 與 npm --version。若任一指令失敗,請從 nodejs.org/download 安裝 Node.js LTS 套件,關閉並重新開啟終端機後再試一次。若 npx 要求下載套件的許可,請在輸入 y 之前先檢查套件與來源。
使用 Kimi API 的優點
在 Cursor API 工作流程中使用 Kimi,可以提升編碼、除錯與開發任務的效率。它的進階能力有助於產生準確的回應、處理複雜的指令,並加速問題解決。以下是在 Cursor 工作流程中使用 Kimi 以提升生產力與效率的主要優點。
長情境程式碼理解
Kimi 可以一次處理大量的程式碼與資訊,更有效地辨識不同檔案與專案區塊之間的關聯。因此,處理大型或複雜的程式碼庫會變得容易許多。
更好的文件與儲存庫分析
使用 Kimi 可以快速檢視專案文件、技術筆記與儲存庫,不必逐一翻閱每個檔案就能更容易找到重要細節。開發者能在更短的時間內對整個專案有更清楚的了解。
具成本效益的 AI 開發
Kimi 為許多開發任務提供了實用且經濟的選擇。即使不完全依賴成本較高的模型,也能獲得強大的 AI 支援。團隊可以在提升整體生產力的同時,更妥善地控管支出。
更快的知識檢索
可以在大型程式碼庫、資料集與專案檔案中快速找到有用的資訊,減少花在搜尋答案或參考資料上的時間,把更多注意力放在編碼、測試與專案改進上。
改善工作流程自動化
有了 Kimi,重複性的開發任務會變得更容易管理與完成。它可以協助程式碼生成、內容審查與例行專案作業,讓日常工作流程長期保持有條理、高效且更具生產力。
Codex 如何改善開發工作流程
配置完成的 Codex CLI API 工作流程,能將儲存庫檢視、編輯、指令執行與審查整合在同一個情境中。Codex 可以搭建檔案架構、解釋不熟悉的模組、重現失敗情形、提出測試建議,並執行已核准的檢查。支援外部 provider 增加了模型選擇的彈性,但並不會減少審查的責任。
每項任務都應從明確而具體的目標開始。在編輯前先請 Codex 進行檢視,審查它提出的變更,只核准你理解的指令,執行儲存庫的測試,並檢查最終的差異(diff)。在通過審查與驗證之前,應將產生的程式碼視為未經信任的貢獻內容。
結論
可靠地使用 Codex API,來自於依序測試每一層:驗證 Codex 身分、直接呼叫 Kimi、啟動並測試 localhost、儲存使用者層級的 provider 設定、執行唯讀提示詞,並完成一項牽涉檔案與工具的任務。將真正的 Kimi 金鑰留在 router 那一側,不要把機密資訊放進共用檔案,完成後記得停止 router。