zcf 評測：用 npx 把 Claude Code 與 Codex 的設定一次寫完

zcf 要解的是設定工序，不是模型能力

Claude Code 與 Codex 這類命令列代理，第一次上手要處理的事情相當零碎：安裝本體、選一個 API 供應商、把 key 寫進正確的位置、設定 workflow、如果要接 MCP 還得再補一份設定。每一項都不難，合起來就是一段反覆出現的工序，換一台機器或換一個供應商就要再走一次。zcf 把自己定位成這段工序的自動化：README 的敘述是 zero-config、one-click setup for Claude Code & Codex，並附上雙語介面與所謂的 intelligent agent system。從 repo 的 topic 清單看，它同時觸及 agent、workflow、ccr、mcp 這幾個關鍵字，其中 ccr 對應的是 Claude Code Router 這類代理層設定，說明它處理的範圍比單純安裝更廣。目標讀者因此很清楚：已經在用這兩套工具、每週要碰一次設定檔、而且不想自己維護腳本的人。如果你只用其中一套、或從來沒改過預設值，這支工具的邊際效益會很低。

互動選單是主線，非互動模式是給腳本用的

README 的 Quick Start 把 npx zcf 列為建議入口，執行後會開啟互動式選單，由使用者挑選要做的事。真正的動作指令是 npx zcf i，README 對它的描述是 full initialization，涵蓋 install、workflows、API 或 CCR、以及 MCP 四個環節；npx zcf u 則只更新 workflows，不動其他部分。這種切分方式透露了設計者的假設：安裝與供應商設定是低頻動作，workflow 才是會隨版本更新的部分，所以單獨拉出一條更新路徑。介面語言可以切換，README 給的例子是 npx zcf --lang zh-CN。非互動模式則以 provider preset 呈現，範例是 npx zcf i -s -p 302ai -k "sk-xxx"，其中 -s 對應靜默或跳過互動，-p 指定供應商代號，-k 直接帶入 key。這個組合的用途是 CI 或新機器初始化，但同時也意味著 key 會出現在 shell history 與 process list 裡，這是使用 -k 時必須自己承擔的副作用，README 並沒有針對這點提供替代方案。

從 repo 佈局看它實際碰了哪些東西

README 沒有完整列出安裝後會寫入的檔案路徑，這是最需要讀者自行驗證的一段。可以確認的是：專案以 TypeScript 撰寫，主線語言為 TypeScript，透過 npm 發佈，因為 Quick Start 用的是 npx zcf 而非本地安裝。repo 內有 src/assets 目錄存放 banner 與贊助商圖片，也有 CHANGELOG.md 與多語 README（README_zh-CN.md、README_ja-JP.md），以及指向 codecov 與 JSDocs 的徽章，說明它有測試覆蓋率與 API 文件這兩個對外承諾。既然指令名稱包含 CCR 與 MCP，合理的推論是它會產生或修改對應的設定檔，但具體檔名與格式在提供的材料中並未出現，任何斷言都會是臆測。實務上，第一次執行前先確認家目錄與專案目錄的 git 狀態，跑完後用 diff 檢視變更，是唯一能確定它動了什麼的方法。這一點比 README 裡任何一句宣傳都重要。

贊助商密度是這份 README 最顯眼的事實

README 在 Quick Start 之後幾乎整段都是贊助商內容，包含 AICodeMirror、Z.ai 的 GLM CODING PLAN、code0.ai、Claude API、PatewayAI、302.AI、PackyCode、APIKEY.FUN 等，多數帶有註冊連結與折扣碼，部分直接標明是給 ZCF 使用者的專屬優惠。這本身不是問題，開源專案找贊助很正常，但它對讀者有三個具體影響。第一，這些供應商多半是 API relay 服務，README 自己用 official relay、official-channel、100% official source 這類措辭描述，而這類服務的品質與合規性差異很大，專案並未對它們做任何技術評比。第二，這些連結是專案方收入來源，會影響預設選單裡出現哪些 provider preset，使用時值得確認 -p 後面的代號清單是否只涵蓋贊助方。第三，README 的資訊密度被行銷文字排擠，導致安裝後實際寫入哪些檔案這種關鍵資訊反而缺失。把贊助段落當成 provider 目錄來讀，會比當成推薦來讀安全得多。

什麼情況下不該用 zcf

最明確的反例是已有共用 dotfiles 或內部設定管理流程的團隊。zcf 的價值來自它替你決定設定佈局，而這正好與既有流程衝突：兩套機制都宣稱自己是唯一寫入者時，後執行的會覆蓋前一個，而覆蓋是靜默的。第二個情境是只需要單一工具的人。如果你只用 Claude Code 且從不更換供應商，初始設定是一次性成本，之後 npx zcf u 帶來的 workflow 更新反而可能改動你已經調校過的內容。第三是對憑證路徑有硬性規定的環境，例如 key 必須由 secret manager 注入、不得落地成檔案，此時 zcf 的 API 設定環節會與規範直接牴觸。還有一個較少被提及的失敗模式：這類工具通常假設上游 CLI 的設定格式穩定，而 Claude Code 與 Codex 都還在快速迭代，一旦格式變動，zcf 需要跟著發版才能修正，中間的空窗期使用者會拿到寫壞的設定。從 release 節奏看，3.7.1 到 3.7.3 分別落在 2026 年 7 月、8 月初與 8 月底，更新算頻繁，但也說明它必須持續追趕上游。

與自己寫設定腳本的實際差異

最直接的替代方案不是另一支 CLI，而是自己維護一份 shell 腳本或 dotfiles 倉庫。兩者的差異在於控制權與維護責任的分配。自寫腳本的好處是每一行都可讀、可審計，你能精確知道哪個檔案被寫入什麼內容，出錯時直接讀腳本即可；代價是你得自己追蹤 Claude Code 與 Codex 的設定格式變更，而這正是 zcf 想替你吸收的成本。zcf 走的是另一條路：把供應商清單、workflow 範本、CCR 與 MCP 設定都收進套件內部，用版本號統一發布，使用者只要更新套件就取得最新格式。這在供應商與工具鏈變動頻繁時是優勢，在你只需要固定一種配置時則是多餘的抽象層。如果偏好自寫腳本但想省掉供應商設定的部分，可以只用 npx zcf i 跑一次產生基準設定，再把結果抄進自己的 dotfiles，之後就不再執行 zcf，這是一種折衷，但要注意這等於放棄了 workflow 的後續更新。

授權與後續維護成本

專案採用 MIT 授權，這是寬鬆授權，允許修改、再散布與商業使用，條件是保留著作權聲明與授權條款。對企業內部使用而言，這通常是最容易通過審查的一類授權，但仍需自行確認你們的合規流程是否接受透過 npx 直接執行未經內部審核的第三方套件，因為 npx 每次可能拉取最新版本，而不是鎖定在你們驗證過的版本。若要控制這一點，實務上應該改成本地安裝並鎖定版本，而非依賴 npx 的即時解析。維護成本方面，材料顯示專案在 2026 年 7 月至 8 月間有三次發版，節奏穩定，但這也意味著上游 CLI 的變動會持續傳導過來；採用者需要接受定期更新套件這個動作，否則可能遇到設定格式過期的情況。README 未說明是否有長期支援版本或破壞性變更政策，這點在正式導入前應該向專案確認。

編輯結論

如果你同時用 Claude Code 與 Codex，而且不想每次換機器都重抄一遍設定，zcf 的 npx zcf i 值得先在一個乾淨的環境跑一次，看它實際寫入哪些檔案。如果你把 API key 的存放位置當成不可協商的邊界，或者你的團隊已經有共用的 dotfiles 與內部供應商設定，這支工具會多出一個要維護的抽象層，先不要裝。動手前請確認三件事：你打算用哪個 provider 與它的 key 格式、npx zcf i 在你的家目錄下新增與覆寫了哪些檔案、以及 CCR 與 MCP 這兩個環節你是否真的需要。README 把贊助商放在比使用說明更顯眼的位置，這件事本身就值得在按下 Enter 前多想一秒。

官方來源

1. License: MIT
2. Project website
3. README
4. Releases
5. UfoMiao/zcf on GitHub