Cursor 和 Claude Code 用了也有很長的一段時間,我現在的日常大概是:Cursor 占 60%,Claude Code 占 40%。兩個工具各有勝負,但如果只用 Claude 官方模型,可能這個比例會反過來。
之前給 Claude Code 配置的是 Claude Opus 4.5,但國內開發者應該都懂:帳號容易被封,超時更是家常便飯。你剛花了幾千 Token 把上下文喂給它,眼看就要出結果了——啪,一個 timeout,欲哭無淚。
後來我索性把 Claude Code 接上了國產大模型。特別是 Kimi K2.5 和 GLM-4.7 這倆出來後,性價比直接起飛!!!在大多數日常開發場景裡,它們的效率完全不輸 Claude 和 OpenAI。
OpenRouter 的周排行榜和 OpenClaw 調用請求量榜單,Kimi K2.5 長期霸榜第一,大幅領先於 Gemini 3。

Claude Code 接入 Kimi 2.5 和 GLM-4.7 其實就三步:申請 API Key → 配置環境變量 → 啟動。搞定!🎯
# GLM
export ANTHROPIC_BASE_URL=https://open.bigmodel.cn/api/anthropic
export ANTHROPIC_AUTH_TOKEN=你的API密鑰
export ANTHROPIC_MODEL=GLM-4.7
export ANTHROPIC_DEFAULT_HAIKU_MODEL=GLM-4.7
export ANTHROPIC_DEFAULT_SONNET_MODEL=GLM-4.7
export ANTHROPIC_DEFAULT_OPUS_MODEL=GLM-4.7
# Kimi
export ANTHROPIC_BASE_URL=https://api.moonshot.cn/anthropic
export ANTHROPIC_AUTH_TOKEN=你的API密鑰
export ANTHROPIC_MODEL=kimi-k2.5
export ANTHROPIC_DEFAULT_HAIKU_MODEL=kimi-k2.5
export ANTHROPIC_DEFAULT_SONNET_MODEL=kimi-k2.5
export ANTHROPIC_DEFAULT_OPUS_MODEL=kimi-k2.5
💡 小提示:建議把這些配置寫進 .zshrc 或 .bashrc,不然每次重啟終端都要重新 export,真麻煩。
如果你經常 Kimi、GLM、Claude 官方模型切來切去,手動改環境變量確實有點劝退 😅。GLM 接入 Claude Code 官方文檔有提供腳本的方案,提高環境變量配置的效率。
當然也可以考慮使用 claude-code-router 這個神器。
它能讓你用一條命令快速切換模型,不用改配置文件,不用重啟終端。比如:
ccr use kimi # 切換到 Kimi
ccr use glm # 切換到 GLM
ccr use claude # 切回 Claude 官方
🔗 項目地址:github.com/musistudio/…
更多配置細節也可以參考官方文檔:
分享幾個我每天都用的命令,新手可能不知道,老手可能忘了用:
| 命令 | 作用 | 什麼時候用 |
|---|---|---|
/clear |
清空對話但保留代碼改動 | 長任務必備——上下文過長時重置,保留代碼改動 |
/compact |
壓縮成摘要 | 比 /clear 更溫和,保留關鍵資訊同時節省 Token |
/rewind / Esc+Esc |
撤回最近修改 | 撤回最近的代碼修改或對話 |
血淚教訓:長任務做到一半記得定期 /compact,別等報錯才後悔。
| 命令 | 作用 |
|---|---|
/init |
新項目一鍵生成 CLAUDE.md |
/memory |
編輯長期記憶(項目的"祖傳規範"都寫這兒) |
/add-dir |
把其他目錄加進來(Monorepo 神器) |
/context |
可視化看 Token 占用,彩色格子一目了然 🎨 |
| 命令 | 作用 |
|---|---|
/model |
切模型:複雜任務切 Opus,簡單任務切 Sonnet 節省成本 |
/cost |
看帳單:長對話必看——監控消耗,避免超額 |
/usage |
檢查速率限制和剩餘額度 |
省錢小技巧:寫註釋、格式化這種簡單活,切 Sonnet 或 Haiku 就夠了,別用 Opus 燒錢 😂
如果說 Claude Code 只有一個必學功能,我會選 Plan Mode。特別是在處理複雜需求時,它真的能救命。
Plan Mode 是 Claude Code 的一種只讀規劃模式,讓 Claude 在不修改任何代碼的情況下先分析問題、制定詳細計劃,等待你批准後再執行。這相當於"先思考,後行動"的工作流程。
我用 Plan Mode 最多的三個場景:
怎麼進入 Plan Mode:
| 方式 | 操作 | 適用場景 |
|---|---|---|
| 快捷鍵 | Shift + Tab 按兩次,看到 ⏸ plan mode on 就對了 |
最常用,隨時切換 |
| 命令行 | claude --permission-mode plan |
啟動時直接進入 |
| 單次查詢 | claude --permission-mode plan -p "你的問題" |
只問不聊,快速分析 |
我的 Plan Mode 工作流:

當 Claude Code 輸出計劃後,會讓你選擇:
| 選項 | 什麼意思 | 適用場景 |
|---|---|---|
| 1. Yes, clear context and auto-accept edits (shift+tab) | 清空上下文,自動接受所有編輯 | 想重新開始的時候 |
| 2. Yes, auto-accept edits | 自動接受所有編輯(保留上下文) | 信任計劃,直接執行 |
| 3. Yes, manually approve edits | 每改一行都問你 | 想審查每個修改 |
| 4. Type here to tell Claude what to change | 讓 Claude 先改計劃 | 需要調整計劃內容 |
💡 小技巧:我一般會選 4,然後輸入:"先把計劃保存到 plan.md,我們再繼續"。這樣方案留底,後面出問題了還能回溯。等保存完了再選 2 讓 Claude 自動執行。
Claude Code 創始人 Boris Cherny 在 X 上分享過團隊內部的使用心得。挑幾個我覺得特別實用的:
原文鏈接:x.com/bcherny/sta…
前面已經說過 Plan Mode ,創始人也提到了說明 Plan Mode 的重要性。
把精力集中在打磨計劃上,這樣 Claude 在實現代碼時就能一步到位(1-shot)。
團隊裡有個成員的做法是:先讓一個 Claude 寫出計劃,然後啟動第二個 Claude,讓它代入Staff Engineer(資深工程師)的角色來對計劃進行 Review。
還有成員建議:一旦發現進展跑偏(go sideways),立刻切回 Plan Mode重新規劃。千萬別硬推。他們甚至會明確指示 Claude 在驗證步驟中也要進入 Plan Mode,而不僅僅是在構建代碼的時候才用。

幾個我常用的"刁鑽" prompt:
🧪 角色反轉 —— 讓 Claude 考你:
"針對這些改動向我提問,在我通過你的測試之前不要提交 PR"
讓 Claude 充當面試官,幫你查漏補缺。它問的問題往往是你沒想到的 edge case。
🔍 要求自證:
"證明這套方案行得通,對比 main 分支和 feature 分支的差異"
逼 Claude 寫出驗證邏輯,而不是盲目相信它的"我覺得沒問題"。
💡 推倒重來:
"基於你現在掌握的信息,推翻剛才的方案,換一個更優雅的實現"
當 Claude 給出一般般的方案時,用這句話激發它的第二想法。往往第二個方案比第一個好得多。
📝 先寫 Spec 再動手:
交付任務前,先讓 Claude 寫詳細的規格說明。你寫得越具體,它輸出越可靠。 vague 的需求 = vague 的代碼,這個道理對 AI 也一樣。

幾個團隊內部的學習小技巧:
🎓 開啟解釋模式: 在 /config 裡把輸出風格設為 "Explanatory" 或 "Learning",Claude 會在改代碼的同時解釋為什麼這麼改。適合讀新項目代碼時邊改邊學。
📊 生成可視化簡報: 讓 Claude 把陌生代碼庫生成一個 HTML 演示文稿。不必說,它做的幻燈片比很多 PM 做的都好…… 😂
🗺️ ASCII 架構圖:
"給我畫個 ASCII 流程圖,解釋這個模組的調用鏈"
不用開畫圖工具,終端裡直接看清邏輯,程式員友好。
🔄 間隔重複學習: 跟 Claude 玩"費曼學習法":你先解釋自己理解的邏輯,Claude 通過提問填補你的知識盲區,最後把學習記錄保存下來。

Boris 還提到了 CLAUDE.md 和 Skills 的進階玩法,特別是 Skills 系統,最近社區裡討論得很多。等我把實踐總結整理好了,再專門寫一篇分享 👋
每一步都是進步!
我是宅小年,一個寫 Bug 小能手
关注公众号「宅小年」
個人博客 📖 edisonz.cn,閱讀更多分享文章