DeepSeek on KnightLi的博客

讓 Codex 使用 DeepSeek 模型的兩種方法：本機閘道和 OpenRouter BYOK

Sun, 24 May 2026 09:52:55 +0800

想讓 Codex 使用 DeepSeek，第一反應通常是改 ~/.codex/config.toml：

1
2

model = "deepseek-chat"
base_url = "https://api.deepseek.com"

這個思路在一些舊版本或普通 OpenAI SDK 場景裡確實成立，但放到目前的 Codex CLI 上，很容易撞到一個底層問題：Codex 的自訂模型供應商走的是 OpenAI Responses 協議，而 DeepSeek 官方介面主要提供 OpenAI 相容的 Chat Completions 呼叫方式。

我本機目前是 codex-cli 0.111.0。codex --help 裡可以看到它支援 --config、--model、--profile 這些設定入口；OpenAI 官方 Codex 設定參考也寫得很明確：model_providers.<id>.wire_api 目前只支援 responses，省略時也預設是 responses。

DeepSeek 官方文件則給出的呼叫路徑是 https://api.deepseek.com/chat/completions，範例也是 client.chat.completions.create(...)。所以問題不在於 DeepSeek 不能被 OpenAI SDK 呼叫，而在於 Codex 發出的請求語義，和 DeepSeek 原生介面能理解的語義不完全是同一套東西。

這就是為什麼直接把 base_url 改成 https://api.deepseek.com 後，可能出現下面這些現象：

請求路徑不匹配，直接 404 或回傳格式不對。
多輪對話、工具呼叫、補丁產生時解析失敗。
tool_calls 順序、訊息結構、串流事件格式對不上。
看起來模型能回一句話，但一到 Codex 真正幹活就開始報錯。

更穩的辦法，是在 Codex 和 DeepSeek 之間放一個「翻譯層」。常見有兩種路線。

方法一：用本機閘道橋接 DeepSeek

本機閘道的作用不是簡單轉發，而是把 Codex 側的 Responses 風格請求，轉換成 DeepSeek 能處理的 Chat Completions 風格請求，再把 DeepSeek 的結果轉換回 Codex 能吃的格式。

如果你用的是 ccx 這類本機閘道，設定思路大致是這樣：

[profiles.deepseek-ccx]
model = "deepseek-v4-flash"
model_provider = "ccx-bridge"

[model_providers.ccx-bridge]
name = "Local CCX Gateway"
base_url = "http://localhost:3000/v1"
env_key = "DEEPSEEK_API_KEY"

然後在終端機裡設定 DeepSeek Key，再用這個 profile 啟動：

1
2

export DEEPSEEK_API_KEY="your-deepseek-key"
codex --profile deepseek-ccx

PowerShell 裡是：

1
2

$env:DEEPSEEK_API_KEY="your-deepseek-key"
codex --profile deepseek-ccx

這裡有兩個細節要注意。

第一，base_url 要指向閘道暴露給 Codex 的位址，不是 DeepSeek 官方位址。閘道背後再去呼叫 DeepSeek。

第二，env_key 寫什麼取決於閘道怎麼鑑權。有的閘道直接讀取 DeepSeek 官方 Key，有的閘道會要求你給它一個本機代理 Key，再由閘道自己的後台保存 DeepSeek Key。遇到這種情況，env_key 就應該改成閘道要求的環境變數名。

這條路的優點是本機可控，延遲和成本也更容易算清楚。缺點是你必須確認閘道真的支援 Codex 目前使用的 Responses 語義，而不是只做了普通 Chat Completions 代理。

方法二：用 OpenRouter BYOK 做線上橋接

如果不想在本機部署閘道，可以考慮 OpenRouter 的 BYOK。BYOK 的意思是把你自己的上游供應商 Key 綁定到 OpenRouter，由 OpenRouter 負責路由和轉發。

這裡最容易寫錯的是環境變數。Codex 存取的是 OpenRouter，所以 env_key 通常應該是 OPENROUTER_API_KEY，不是 DEEPSEEK_API_KEY。DeepSeek Key 要在 OpenRouter 的 BYOK 或 provider key 設定裡新增。

設定範例：

[profiles.deepseek-openrouter]
model = "deepseek/deepseek-chat"
model_provider = "openrouter"

[model_providers.openrouter]
name = "OpenRouter"
base_url = "https://openrouter.ai/api/v1"
env_key = "OPENROUTER_API_KEY"

啟動方式：

1
2

export OPENROUTER_API_KEY="your-openrouter-key"
codex --profile deepseek-openrouter

PowerShell：

1
2

$env:OPENROUTER_API_KEY="your-openrouter-key"
codex --profile deepseek-openrouter

然後在 OpenRouter 後台把 DeepSeek 的 provider key 加進去。OpenRouter 的 BYOK 文件說明，綁定的 provider key 會被加密保存，並用於路由到對應供應商。

這條路的優點是省掉本機閘道維護成本，設定起來更像普通第三方 API 代理。缺點是中間多了一層線上服務，排障時要同時看 Codex、OpenRouter、DeepSeek 三邊的錯誤訊息。

要不要繼續用 deepseek-chat 這個模型名？

DeepSeek 官方文件在 2026 年 5 月的說明裡，推薦模型名已經出現 deepseek-v4-flash 和 deepseek-v4-pro，並提示 deepseek-chat、deepseek-reasoner 相容別名會在 2026-07-24 之後廢棄。

所以新設定裡更建議優先測試：

`1`	`model = "deepseek-v4-flash"`

如果走 OpenRouter，則要按 OpenRouter 的模型命名來寫，例如：

`1`	`model = "deepseek/deepseek-chat"`

實際可用名稱以你所用閘道或 OpenRouter 模型頁為準。模型名不對時，錯誤通常會表現為 model not found、404，或者 provider 找不到對應 endpoint。

直接改 DeepSeek 官方 base_url 為什麼不推薦

你當然可以試著寫：

[profiles.deepseek-direct]
model = "deepseek-v4-flash"
model_provider = "deepseek"

[model_providers.deepseek]
name = "DeepSeek"
base_url = "https://api.deepseek.com"
env_key = "DEEPSEEK_API_KEY"

但這更像排錯實驗，不適合作為穩定方案。因為 Codex 會按 Responses 協議去和自訂 provider 說話，而 DeepSeek 官方範例走的是 /chat/completions。如果 DeepSeek 或 Codex 未來補齊了相容層，這種直連才可能變得簡單；在此之前，橋接層更可靠。

改完設定後還是走 OpenAI 怎麼辦

先確認設定檔位置。全域設定應該在：

`1`	`~/.codex/config.toml`

專案裡的 .codex/config.toml 不適合放 model_provider、model_providers 這類機器級 provider 設定。OpenAI 官方文件也提醒，專案級設定不會覆蓋這些本機 provider 和認證相關欄位。

如果 Codex 仍然要求網頁登入，或者看起來還在走預設 OpenAI 模型，可以先退出目前登入狀態：

`1`	`codex logout`

有些舊教學會寫成交互介面裡的 /logout。在目前 CLI 裡，更穩的是直接在終端機執行 codex logout。

還可以用臨時參數做一次快速驗證：

`1`	`codex --profile deepseek-ccx`

或者：

`1`	`codex -c model_provider=ccx-bridge -c model=deepseek-v4-flash`

如果這樣能生效，說明設定本身可讀；如果不生效，優先檢查 profile 名稱、TOML 語法、環境變數是否只在目前 shell 裡有效。

排障清單

401：Key 不對，或者 env_key 指向了錯誤的環境變數。
404：base_url 或模型名不對，也可能是把 Responses 請求打到了只支援 Chat Completions 的位址。
tool_calls、patch、串流解析報錯：大機率是協議橋接不完整。
仍然提示登入 OpenAI：執行 codex logout，再確認是否用了正確 profile。
PowerShell 設定環境變數後新開視窗失效：$env:... 只對目前會話生效，需要長期保存就改使用者環境變數。
OpenRouter BYOK 沒走自己的 DeepSeek Key：檢查 OpenRouter 後台 provider key 是否綁定、是否允許目前 OpenRouter API Key 使用，以及是否開啟了 fallback。

結論

讓 Codex 使用 DeepSeek，不是不能改 config.toml，而是不能只改 base_url 就指望一切自動相容。

目前更穩的兩條路是：

用本機閘道做協議橋接，Codex 連本機閘道，閘道再連 DeepSeek。
用 OpenRouter BYOK 做線上轉發，Codex 連 OpenRouter，DeepSeek Key 綁定在 OpenRouter 後台。

如果只是想快速試用，OpenRouter 路線更省事；如果你希望 Key、成本、日誌都盡量掌握在自己手裡，本機閘道更適合長期折騰。

參考資料：

DeepSeek-TUI：把 DeepSeek V4 變成終端裡的編程智能體

Sat, 16 May 2026 22:41:41 +0800

DeepSeek-TUI 是一個把 DeepSeek V4 接入終端開發流程的開源專案。它不是普通聊天外殼，而是更接近 Claude Code、Codex CLI 這類「命令列編程智能體」：能看檔案、改程式碼、執行命令、調用工具，並在終端裡用 TUI 方式持續推進任務。

如果你已經習慣在編輯器和終端之間切換，這類工具的價值很直接：不用把程式碼來回複製到網頁對話框裡，也不用手動描述完整專案結構。你把任務交給它，它可以在目前工作區裡讀取上下文、規劃步驟、執行修改，再把結果交還給你審查。

它解決的是 DeepSeek 的使用入口問題

DeepSeek 模型本身提供了很強的推理和程式能力，但模型能力要落到真實開發流程裡，還需要一層工程化外殼。

網頁聊天適合問問題，不適合長時間改專案。API 適合接入系統，但一般開發者還要自己寫工具調用、上下文管理、檔案讀寫和權限控制。DeepSeek-TUI 想補上的正是這一層：把 DeepSeek V4 包成一個可以在終端裡工作的 Agent。

從專案介紹看，它的重點能力包括：

終端 TUI 介面；
面向 DeepSeek V4 的對話與任務執行；
工具調用和檔案操作；
1M 上下文支援；
Auto 模式；
子智能體；
沙箱執行；
持久化任務佇列。

這些功能組合起來，目標不是「讓模型回答得更像人」，而是讓模型更容易進入開發現場。

TUI 比純命令列更適合長任務

很多 AI CLI 工具一開始都是純文字互動：輸入提示詞，等待輸出，再複製命令或補充上下文。這種方式簡單，但任務一長就容易混亂。

TUI 的好處是能把會話、檔案、執行結果、任務狀態放在一個更穩定的介面裡。對編程 Agent 來說，這很重要。因為一次程式任務往往不是一問一答，而是包含：

理解專案結構；
查找相關檔案；
修改程式碼；
執行測試或命令；
根據錯誤繼續修復；
總結變更。

如果介面只是一串日誌，使用者很難快速判斷 Agent 走到了哪一步。TUI 至少給了一個更適合觀察和接管的入口。

Auto 模式適合明確邊界的任務

DeepSeek-TUI 提到的 Auto 模式，適合用在邊界比較清楚的工作裡。例如修一個小 bug、補一個腳本、改一段配置、整理一組文件、實作一個局部功能。

這類任務的共同點是：目標清楚，檢查方式明確，影響範圍可控。Agent 可以自己查檔案、改檔案、跑命令，然後把結果交給使用者確認。

但 Auto 模式不適合無限放權。尤其是在真實專案裡，刪除檔案、批量重構、資料庫遷移、部署命令都應該有明確確認。編程 Agent 的效率來自自動化，但風險也來自自動化。越是能執行命令的工具，越需要沙箱、權限邊界和人工審查。

子智能體的意義在於拆任務

子智能體不是新概念，但放在程式場景裡很有用。

一個稍複雜的任務，通常會同時需要幾類工作：有人負責讀程式碼，有人負責改實作，有人負責檢查測試，有人負責整理文件。傳統多 Agent 系統經常顯得花俏，是因為它們沒有真實工具和真實工作區，只是在對話裡互相討論。

如果子智能體能結合檔案系統、命令執行和任務佇列，它就更像一種任務拆分機制。比如一個子智能體專門分析依賴關係，另一個負責修改某個模組，主智能體再整合結果。這樣可以減少單一上下文裡堆太多無關資訊的問題。

當然，子智能體也會帶來額外成本：更多 token、更複雜的狀態、更難追蹤的責任邊界。所以它適合中等複雜度以上的任務，不一定適合每一次小修改。

1M 上下文不是萬能，但很適合讀專案

1M 上下文聽起來很誇張，但在編程場景裡並不只是行銷數字。

真實程式庫的上下文很碎：README、設定檔、型別定義、測試、調用鏈、歷史約定、錯誤日誌，都可能影響一次修改。更長上下文能減少「只看局部就動手」的問題，也能讓模型保留更多專案約束。

不過，上下文長不等於判斷一定更準。程式任務仍然需要檢索、篩選和驗證。把整個專案塞進上下文並不一定比精準讀取相關檔案更好。好的編程 Agent 應該把長上下文當作緩衝區，而不是把它當成替代工程判斷的捷徑。

更適合哪些使用者

DeepSeek-TUI 更適合幾類人：

想在終端裡使用 DeepSeek 做程式任務的開發者；
不想自己搭工具調用和檔案操作框架的人；
已經熟悉 Claude Code、Codex CLI，但想嘗試 DeepSeek 模型入口的人；
需要本地專案上下文，而不是只在網頁裡問程式片段的人；
想把 AI 編程流程放進命令列環境的人。

如果你只是偶爾問一個函式怎麼寫，網頁聊天已經夠用。如果你希望模型直接參與專案修改，終端 Agent 才更有意義。

需要關注的風險

這類工具最需要關注三件事。

第一是權限。只要工具能讀寫檔案、執行命令，就要確認它預設能存取哪裡、能不能刪除檔案、能不能連網、危險命令是否需要確認。

第二是可回滾。使用前最好保持 Git 工作區乾淨，讓每次 Agent 修改都能被 git diff 清楚看到。不要在一堆未提交改動裡讓 Agent 自動改專案。

第三是驗證。Agent 寫完程式不代表任務完成。測試、構建、lint、人工 review 仍然要保留。AI 編程工具可以提高推進速度，但不能替代最後的工程確認。

總結

DeepSeek-TUI 的意義不在於又多了一個聊天客戶端，而在於它把 DeepSeek V4 放進了更接近真實開發工作的終端環境裡。

對開發者來說，模型能力只是第一步。真正影響體驗的是：它能不能讀專案、能不能安全改檔案、能不能執行驗證命令、能不能在長任務裡保持狀態、能不能讓使用者隨時接管。

如果你想把 DeepSeek 用在日常程式修改、專案閱讀和自動化開發任務裡，DeepSeek-TUI 值得關注。它代表的方向也很清楚：AI 編程工具正在從「回答程式問題」轉向「參與專案執行」。

本地執行 DeepSeek 4：Antirez ds4 在 Apple Silicon Mac 上的嘗試

Mon, 11 May 2026 08:51:37 +0800

Antirez 開源了一個新專案：ds4。它不是通用 LLM 框架，而是一個面向 DeepSeek V4 Flash 的本地推理引擎，重點放在 Apple Silicon 和 Metal 後端上。

專案地址：https://github.com/antirez/ds4

ds4 是什麼

ds4 的目標很明確：在 Mac 上本地執行 DeepSeek V4 Flash。

它目前提供三種使用方式：

互動式 CLI。
HTTP server。
一個實驗性的 Agent 模式。

從定位看，它更像是一個針對特定模型深度最佳化的推理專案，而不是要取代 llama.cpp、Ollama 或 vLLM 這類通用工具。

為什麼值得關注

這類專案值得看，主要有三個原因。

第一，作者是 Redis 作者 Antirez。他長期關注底層系統、效能和簡單工具，專案風格通常比較直接。

第二，DeepSeek V4 Flash 屬於面向高效推理的模型方向。如果本地執行體驗足夠好，對 Mac 使用者來說會很有吸引力。

第三，ds4 直接面向 Apple Metal。相比「先支援所有平台，再慢慢最佳化」的路線，它更像是先把一個明確場景做深。

適合誰用

ds4 更適合這幾類使用者：

使用 Apple Silicon Mac。
想在本地執行 DeepSeek V4 Flash。
關注 Metal 推理效能。
願意嘗試 alpha 階段專案。
想研究輕量推理引擎和模型執行細節。

如果你的目標是穩定部署、跨平台執行、OpenAI API 相容生態，現階段它未必是首選。它更適合作為實驗工具和技術觀察對象。

使用方式

專案 README 給出的基本流程是先建置，再執行。

1
2
3

git clone https://github.com/antirez/ds4.git
cd ds4
make

互動式執行：

./ds4

啟動 HTTP server：

`1`	`./ds4 --server`

Agent 模式：

`1`	`./ds4 --agent`

具體參數和模型檔案準備方式，建議以倉庫 README 為準，因為專案仍在快速變化。

目前的風險

ds4 還處在早期階段，使用前要有預期：

功能可能不完整。
參數、模型格式和命令列行為可能變化。
相容性主要圍繞 Apple Silicon 和 Metal。
Agent 模式更偏實驗，不適合直接用於生產流程。
遇到問題時，需要自己閱讀 README、issue 或原始碼排查。

也就是說，它現在更像「值得動手試的開源實驗」，還不是面向普通使用者的一鍵工具。

和通用推理工具的區別

通用推理工具通常追求模型格式、平台、後端和 API 的廣泛相容。ds4 的方向更窄：圍繞 DeepSeek V4 Flash 和 Metal 做本地執行。

這種選擇有利有弊。

好處是實作可以更集中，效能和體驗更容易圍繞單一目標最佳化。代價是適用範圍有限，不適合拿來執行各種不同模型，也不適合取代完整的部署平台。

如果你已經在用 llama.cpp 或 Ollama，ds4 可以作為補充測試工具，而不是馬上替換現有工作流。

小結

ds4 的看點不在「又一個本地大模型工具」，而在於它把範圍收得很窄：DeepSeek V4 Flash、Apple Silicon、Metal、本地推理。

如果你手上有合適的 Mac，並且願意折騰早期專案，可以關注它後續的效能表現、模型支援方式和 server/agent 能力演進。對於生產環境，建議繼續觀望，等介面和使用方式穩定後再評估。

參考

GitHub 專案：https://github.com/antirez/ds4

AI 編程工具這一輪，DeepSeek 為何成了省錢關鍵？

Mon, 11 May 2026 04:59:00 +0800

這一輪 AI 編程工具的競爭，表面上是在比模型能力、插件生態和 agent 自動化程度，真正用起來以後，最先撞上的問題卻是成本。

Claude Code、Codex、OpenClaw、Superpowers 這類工具都很好用，但它們有一個共同特點：一旦進入複雜任務，就會非常吃 token。它們要讀項目、建計劃、調用工具、總結上下文、反覆檢查結果，還可能拉起多個子任務。模型越聰明，工作流越自動化，帳單也越容易悄悄變大。

所以 DeepSeek 在這一輪裡變得很關鍵，不只是因為它能寫程式碼，而是因為它在長上下文和快取成本上，剛好打中了 AI 編程工具最燒錢的地方。

Agent 工具為什麼特別費 token

傳統聊天式編程助手，通常是一問一答。你問一個函式怎麼寫，它回答一段程式碼。這個模式消耗不小，但還算可控。

Agent 工具不一樣。它不是只回答問題，而是要像一個臨時工程師一樣進入項目：

先掃描目錄和關鍵檔案；
再理解需求和現有架構；
然後制定計劃；
修改檔案；
執行命令或測試；
根據報錯繼續修；
最後總結改了什麼。

這個過程裡，模型反覆讀取同一批上下文。項目說明、程式碼片段、工具結果、歷史對話、計劃和錯誤日誌都會被塞回上下文。任務稍微複雜一點，幾十萬 token 很快就出去了。

如果再裝一些更激進的插件，成本會更明顯。比如有些 OpenCode 或 Claude Code 增強工具，會預設組織一整套 agent 團隊。你只是想改一個小功能，它也可能啟動規劃、審查、執行、復盤等多個環節。任務當然顯得更「智慧」，但 token 也會一路往上跑。

Superpowers 的好處是按需觸發

Superpowers 這類工具的一個優點，是它不會在所有任務裡都強行拉起完整 agent 流程。

平時你還是可以讓 Claude Code、OpenCode 或 Codex 按原來的方式工作。只有當你明確調用某個 skill，比如頭腦風暴、寫計劃、執行計劃、做復盤時，它才進入更重的自動化流程。

這對成本很重要。

AI 編程不應該所有任務都用重武器。改一行設定、查一個報錯、寫一個小腳本，用普通對話就夠了；只有複雜重構、跨檔案修改、長文件處理、多輪驗證，才值得上完整 agent 流程。

工具越強，越要學會控制觸發條件。否則自動化越多，浪費越多。

DeepSeek 的關鍵優勢是快取便宜

DeepSeek 適合接這類 agent 工具，一個很重要的原因是快取命中成本低。

AI 編程任務裡有大量重複前綴。比如專案背景、系統提示詞、工具說明、檔案內容、前幾輪對話，經常會在後續請求裡反覆出現。如果模型服務支援 prompt cache，這些重複內容命中快取後，成本會明顯下降。

很多模型的快取命中價只是比未命中便宜一些，比如便宜到三分之一左右。DeepSeek 的優勢在於，命中快取後的價格差距可以大很多。對長上下文、多輪調用、重複讀取項目的 agent 工作流來說，這個差距會直接反映到帳單上。

也就是說，DeepSeek 不是每一次回答都一定最強，而是在「長任務、多輪任務、反覆讀上下文」的場景裡，成本結構特別適合 AI 編程。

長上下文讓 Claude Code 更好用

把 Claude Code 或類似工具接到 DeepSeek V4 時，另一個明顯優勢是長上下文。

AI 編程工具最怕上下文不夠。上下文一不夠，就要頻繁壓縮；壓縮一多，前面讀過的細節就可能丟失。模型開始忘記專案結構、忘記約束、忘記某個檔案為什麼這麼改，後續品質就會下降。

DeepSeek V4 系列的長上下文能力，讓它更適合處理程式碼倉庫、文檔批處理、字幕翻譯、站點文章整理這類任務。特別是接入 Claude Code、OpenClaw 這類工具時，如果配置得當，可以讓它盡量晚一點進入上下文壓縮，讓模型保留更多專案細節。

這也是為什麼有些任務用 DeepSeek 會顯得「很耐用」：它不一定每一步都驚艷，但能承受長時間、低成本、反覆調用。

V4 Pro 和 V4 Flash 怎麼分工

DeepSeek V4 Pro 和 V4 Flash 不應該混著用。

簡單任務用 DeepSeek V4 Flash 更合適。它速度快、成本低，用在下面這些場景通常足夠：

翻譯字幕；
整理文檔；
生成普通腳本；
修改小範圍程式碼；
跑 OpenClaw 裡的輕量任務；
做簡單的站點內容處理。

複雜任務再考慮 DeepSeek V4 Pro：

大規模重構；
多模組程式碼理解；
複雜推理；
長鏈路 agent 任務；
高風險程式碼修改；
需要更強規劃能力的工程任務。

很多人一上來就想掛最強模型，這反而不划算。AI 編程工具最現實的玩法，是把任務分層：便宜模型吃掉大量常規工作，貴模型只處理關鍵節點。

MiniMax、豆包和 DeepSeek 的位置不同

國產模型和套餐裡，MiniMax、豆包、Kimi、DeepSeek 各有位置。

MiniMax 的優勢是量大、便宜、功能全。它未必是最聰明的編程模型，但拿來做翻譯、輕量整理、批處理，很划算。比如批量處理字幕、改格式、做簡單校對，MiniMax 這類套餐很耐用。

豆包的優勢是生態工具比較全，圖片、影片、搜尋、TTS、可能的 STT 和 embedding 都能接在一起。它更像綜合型工具箱。

DeepSeek 的位置更明確：文本、程式碼、長上下文、低成本快取。它沒有完整的圖像生成、語音、影片生態，短板很明顯；但在 AI 編程和長文本 agent 工作流裡，它的長板足夠長。

所以不是誰替代誰，而是任務拆開以後各用各的。

省錢的關鍵不是只找便宜模型

AI 編程想省錢，不是簡單把所有請求都換成便宜模型。

真正有效的省錢方式有幾條：

簡單任務不要啟動重 agent。
能用 Flash 的任務不要上 Pro。
長任務盡量利用快取。
重複上下文要穩定，避免無意義改動導致快取失效。
大任務先讓便宜模型做草稿和批處理，再讓強模型做關鍵審查。
明確告訴 agent 不要重複描述事實，不要反覆總結同一件事。

尤其是最後一點很重要。AI 工具很容易囉嗦，囉嗦不只是閱讀體驗問題，也是成本問題。提示詞裡明確要求「事實只描述一次，觀點只表達一次」，能同時改善文章品質和 token 消耗。

DeepSeek 適合哪類 AI 編程工作流

DeepSeek 最適合這些任務：

長程式碼倉庫閱讀；
多檔案輕量修改；
批量文檔整理；
批量字幕翻譯；
Hugo 文章整理；
agent 計劃執行；
大量重複上下文的低成本自動化。

它不一定適合所有任務。如果要做特別強的前端審美、複雜產品判斷、跨模態創作，可能還要搭配 Claude、GPT、Gemini、豆包或其他工具。

但只要任務是「長文本、長上下文、反覆調用、成本敏感」，DeepSeek 就很容易變成首選。

小結

AI 編程工具這一輪，DeepSeek 的價值不只是「國產模型能寫程式碼」，而是它解決了 agent 工具最現實的痛點：長任務太燒錢。

Claude Code、OpenClaw、Superpowers 這類工具會讓開發流程越來越自動化，但自動化的背後是大量上下文讀寫和多輪調用。誰能把這部分成本壓下來，誰就能讓 AI 編程從「偶爾爽一下」變成「天天用得起」。

DeepSeek 的長上下文、低快取成本和 V4 Flash / V4 Pro 分層使用，正好讓它站在這個位置上。

這一輪真正省錢的關鍵，不是不用好模型，而是把好模型、便宜模型、快取和 agent 流程搭配好。能把這套帳算明白，AI 編程工具才真的會變成生產力，而不是一個漂亮但昂貴的玩具。

DeepSeek-TUI：在終端裡執行 DeepSeek 編程 Agent

Fri, 08 May 2026 13:41:15 +0800

DeepSeek-TUI 是一個執行在終端裡的 AI 編程 Agent。它圍繞 DeepSeek V4 模型設計，透過 deepseek 命令啟動，可以在 TUI 介面裡讀寫檔案、執行 shell 命令、搜尋網頁、管理 git、呼叫 MCP server，並支援子 Agent 協作。

它比普通聊天 CLI 更像一個終端工作台。它不只是把問題發給模型，而是把看程式碼、改檔案、跑命令、檢查診斷、保存會話、恢復狀態整合在一起。

專案主要使用 Rust 編寫，授權為 MIT。GitHub 描述是「Coding agent for DeepSeek models that runs in your terminal」。

適合誰

DeepSeek-TUI 適合喜歡終端工作流，並想用 DeepSeek 模型處理本地開發任務的開發者。

用 DeepSeek 做程式碼修改和專案分析。
不想打開完整 IDE。
希望 AI 工具能讀寫本地 workspace。
需要 Plan、Agent、YOLO 模式。
想保存會話、恢復長任務、回滾改動。
想接入 MCP、LSP 診斷、HTTP/SSE runtime API 和 skills。

如果只是簡單問答，Web 端或輕量 CLI 已足夠。DeepSeek-TUI 更適合把模型放進本地開發流程。

安裝方式

npm：

1
2
3

npm install -g deepseek-tui
deepseek --version
deepseek --model auto

npm 包是安裝器和 wrapper，會下載預編譯 Rust 二進位，要求 Node.js >=18。

Cargo：

1
2

cargo install deepseek-tui-cli --locked
cargo install deepseek-tui --locked

Homebrew：

1
2

brew tap Hmbown/deepseek-tui
brew install deepseek-tui

也可以從 GitHub Releases 下載 Linux x64/ARM64、macOS x64/ARM64、Windows x64 的預編譯版本。

Docker：

docker run --rm -it \
  -e DEEPSEEK_API_KEY \
  -v "$PWD:/workspace" \
  ghcr.io/hmbown/deepseek-tui:latest

配置 API Key

首次啟動會提示輸入 DeepSeek API key，並保存到：

`1`	`~/.deepseek/config.toml`

也可以手動配置：

1
2

deepseek auth set --provider deepseek
deepseek auth status

或使用環境變數：

1
2

export DEEPSEEK_API_KEY="YOUR_KEY"
deepseek

檢查環境：

`1`	`deepseek doctor`

清除已保存的 key：

`1`	`deepseek auth clear --provider deepseek`

Auto mode

`1`	`deepseek --model auto`

TUI 中也可使用：

`1`	`/model auto`

Auto mode 同時選擇模型和 thinking：

模型：deepseek-v4-flash 或 deepseek-v4-pro
Thinking：off、high 或 max

真正請求前，TUI 會做一次小型路由呼叫，分析最新請求和上下文，再決定本輪模型和思考級別。auto 是本地功能，上游 API 收到的是具體模型和設定。

需要基準測試、成本上限或固定行為時，建議直接指定模型。

三種模式

模式	用途
Plan	只讀探索和計畫
Agent	預設互動模式，工具呼叫有 approval gate
YOLO	在可信 workspace 中自動批准工具

Plan 適合分析，Agent 適合日常編程，YOLO 風險最高，只適合可信分支或測試目錄。

工具能力

DeepSeek-TUI 支援檔案讀寫、apply patch、shell、git、web search/browse、子 Agent、MCP、LSP 診斷、會話恢復、工作區回滾、持久化任務隊列、HTTP/SSE runtime API 和 skills。

LSP 診斷可把 rust-analyzer、pyright、typescript-language-server、gopls、clangd 等錯誤回饋給模型。工作區回滾使用 side-git 快照，提供 /restore 和 revert_turn，但正常 git 提交習慣仍然重要。

常用命令

deepseek
deepseek "explain this function"
deepseek --model deepseek-v4-flash "summarize"
deepseek --model auto "fix this bug"
deepseek --yolo
deepseek auth set --provider deepseek
deepseek doctor
deepseek doctor --json
deepseek models
deepseek sessions
deepseek resume --last
deepseek resume <SESSION_ID>
deepseek fork <SESSION_ID>
deepseek serve --http
deepseek serve --acp
deepseek pr <N>
deepseek mcp list
deepseek mcp validate
deepseek update

Zed 和 ACP

{
  "agent_servers": {
    "DeepSeek": {
      "type": "custom",
      "command": "deepseek",
      "args": ["serve", "--acp"],
      "env": {}
    }
  }
}

目前 ACP 支援新會話和 prompt response，但工具驅動編輯和 checkpoint replay 尚未透過 ACP 暴露。

配置和 provider

使用者配置：

`1`	`~/.deepseek/config.toml`

專案 overlay：

`1`	`<workspace>/.deepseek/config.toml`

api_key、base_url、provider、mcp_config_path 等敏感欄位不能放入專案 overlay。

OpenAI-compatible 示例：

1
2

deepseek auth set --provider openai --api-key "YOUR_OPENAI_COMPATIBLE_API_KEY"
OPENAI_BASE_URL="https://openai-compatible.example/v4" deepseek --provider openai --model glm-5

Ollama：

1
2

ollama pull deepseek-coder:1.3b
deepseek --provider ollama --model deepseek-coder:1.3b

小結

DeepSeek-TUI 是一個完整的終端 AI 編程 Agent，把 DeepSeek V4、TUI、工具呼叫、LSP 診斷、會話恢復、回滾、MCP 和 skills 放進同一套 Rust 工具鏈。它不一定最輕，但適合把 AI 從聊天推進到可執行的本地開發流程。

參考資料

DeepSeek V4 本地私有化部署方案：國產晶片與消費級顯卡叢集怎麼選

Fri, 08 May 2026 09:39:35 +0800

DeepSeek V4 發布後，很多企業開始關注一個問題：能不能不走外部 API，把模型部署在自己的機房、私有雲或專有叢集裡？

這個需求很現實。金融、醫療、政企、製造、法律和研發團隊往往不能把內部文檔、程式碼、合約、工單、客戶資料直接發到公有雲模型。對這些場景來說，DeepSeek V4 的吸引力不只是模型能力，而是它給了企業一個更接近「可控大模型基礎設施」的選擇。

不過，DeepSeek V4 本地部署不是下載模型、找幾張顯卡就能跑起來。尤其是 Pro 這類超大 MoE 模型，總參數規模、啟用參數、上下文長度、KV cache、並發量和推理框架都會直接決定硬體成本。企業真正要做的不是盲目追求滿血版本，而是先確認業務需要哪種部署形態。

先明確部署目標

企業做本地私有化部署，常見目標有三類：

資料不出域：內部文檔、程式碼、客戶資料、日誌和知識庫不離開企業環境。
穩定可控：模型服務、權限、稽核、日誌和升級節奏由企業自己掌握。
降低長期成本：高頻調用時，本地推理可能比長期購買外部 API 更可控。

如果只是少量員工偶爾問答，本地部署不一定划算。真正適合私有化的是高頻、穩定、資料敏感、流程明確的場景，例如：

內部知識庫問答。
程式碼審查和研發助手。
客服工單總結。
合約、病歷、報告等文檔分析。
資料庫查詢助手。
Agent 工作流自動化。

這些場景的共同點是：資料敏感、調用穩定、可透過權限和日誌納入企業治理。

不要一上來就追求滿血 Pro

DeepSeek V4 常見版本包括 Pro 和 Flash。公開資料中，Pro 面向更強推理和複雜 Agent 任務，Flash 更強調成本和回應速度。企業選型時，不應預設所有業務都上 Pro。

可以按任務複雜度分層：

簡單問答、摘要、分類、標籤生成：優先考慮 Flash 或更小模型。
內部知識庫檢索增強：Flash 足夠覆蓋大量場景，重點反而是 RAG、權限和檢索品質。
程式碼 Agent、複雜推理、長上下文分析：再評估 Pro。
高價值低頻任務：可以使用 Pro，但不一定需要高並發。
普通辦公助手：沒有必要長期占用最貴的推理資源。

MoE 模型的優勢在於每次推理只啟用部分參數，但它並不等於硬體壓力很小。權重儲存、專家並行、網路通訊、上下文快取和並發調度仍然很重。尤其是 1M token 級別長上下文，真正吃掉資源的往往不是單次回答，而是長上下文、多使用者並發和持續會話。

國產晶片路線：適合企業級私有雲

如果企業已經有國產算力池，或者有信創、合規、供應鏈要求，可以優先評估昇騰、寒武紀等國產晶片路線。

這條路線的優勢是：

更符合國產化和供應鏈可控要求。
適合進入企業機房、專有雲和政企專案。
便於統一做權限、稽核、資源隔離和維運。
對長期穩定服務更友好。

但國產晶片路線也要看三個現實問題。

第一，框架適配。模型能不能跑，不只取決於晶片算力，還取決於推理框架、算子、通訊庫、量化格式、MoE 專家並行和長上下文最佳化是否成熟。

第二，工程經驗。企業需要的不只是「啟動成功」，而是穩定服務：多租戶、限流、監控、失敗恢復、灰度升級、日誌稽核、權限隔離都要補齊。

第三，生態差異。同一套模型在 NVIDIA、昇騰、寒武紀等平台上的效能、精度、量化支援和部署工具不會完全一致。上線前必須做實際壓測，而不是只看標稱算力。

因此，國產晶片更適合預算明確、合規要求高、願意投入平台工程的企業。它不是最省事的路線，但可能是最符合長期治理要求的路線。

消費級顯卡叢集：適合試點和中小團隊

如果目標是先驗證業務價值，消費級顯卡叢集更容易起步。RTX 4090、RTX 5090、RTX 3090、RTX 3060 12GB 這類顯卡在社群工具、量化模型和本地推理框架上資料更多，試錯成本更低。

消費級顯卡路線適合：

研發團隊做內部試點。
中小企業做知識庫問答。
低並發程式碼助手。
離線文檔處理。
對 SLA 要求不高的內部工具。

但它也有明顯限制：

顯存小，難以直接承載完整大模型。
多卡通訊能力弱，跨機器通訊更麻煩。
消費級硬體長期滿載穩定性不如伺服器方案。
機箱、電源、散熱、驅動和維運會變成隱性成本。
不適合一開始就承諾企業級高可用。

更現實的做法是：消費級顯卡先跑 Flash、蒸餾版、量化版或小模型，把業務流程跑通；等調用量、效果和資料治理都驗證後，再決定是否遷移到伺服器 GPU 或國產算力平台。

可能的部署架構

一個比較穩的企業私有化架構可以分成六層：

模型層：DeepSeek V4 Pro、V4 Flash，或根據任務選擇更小的蒸餾模型。
推理層：SGLang、vLLM、llama.cpp、廠商 NPU 推理棧或企業自研服務。
閘道層：統一鑑權、限流、稽核、模型路由和調用日誌。
知識層：向量庫、全文檢索、文檔解析、權限過濾和 RAG。
應用層：客服、程式碼助手、文檔分析、報表問答、Agent 工作流。
維運層：監控、告警、成本統計、灰度發布、回滾和安全稽核。

這裡最容易被低估的是閘道層和知識層。很多專案失敗，不是模型完全不能用，而是權限、檢索、日誌、上下文管理、提示詞模板和業務流程沒有做好。

企業內部部署大模型時，應該把模型當作基礎能力，而不是一個孤立聊天頁面。真正產生價值的是模型進入流程後，能不能穩定處理企業自己的資料和任務。

硬體選型思路

硬體不要只看「能不能跑」，還要看「能不能穩定服務」。

可以按階段選：

驗證階段

目標是證明業務是否值得做。

使用 1-4 張消費級顯卡。
優先跑 Flash、小模型、蒸餾模型或量化模型。
並發要求低，重點看任務完成率。
不承諾高可用。

這個階段不要過早採購大規模硬體。先確認員工是否真的用、業務是否真的省時間、回答是否能進入流程。

試點階段

目標是讓一個部門或一個業務線穩定使用。

使用 4-16 張 GPU 或一組國產 NPU 節點。
加入統一閘道、日誌和權限控制。
做 RAG、文檔解析、模型路由和快取。
開始統計 token、並發、延遲和失敗率。

這個階段要開始關注維運。模型效果只是其中一部分，穩定性、成本和資料治理同樣重要。

生產階段

目標是進入企業級服務。

使用伺服器 GPU、國產算力叢集或私有雲資源池。
建立多副本、限流、故障轉移和容量規劃。
按任務路由模型：簡單任務走輕量模型，複雜任務走 Pro。
接入企業身份系統、稽核系統和安全策略。

生產階段不建議所有請求都打到最強模型。合理的模型路由通常比堆硬體更省錢。

推理框架怎麼選

DeepSeek V4 這類模型對推理框架要求較高，尤其涉及 MoE、長上下文、稀疏注意力、量化和多卡並行時，框架成熟度會直接影響速度和穩定性。

常見選擇可以這樣理解：

SGLang：適合關注高效能推理、Agent、多輪工具調用和複雜服務編排的團隊。
vLLM：生態成熟，適合通用 LLM 服務，但具體支援要看版本和模型適配進度。
llama.cpp：更適合小模型、量化模型和邊緣部署，不適合直接承載滿血超大 MoE。
國產 NPU 推理棧：適合信創和國產算力環境，但要重點驗證算子、量化和長上下文支援。

框架選擇不要只看 benchmark。企業更應該測試自己的真實輸入：內部文檔長度、並發數、平均輸出長度、RAG 命中率、Agent 工具調用次數、失敗重試次數。

資料安全要做在模型外面

私有化部署不等於自動安全。模型跑在本地，只是解決了「資料是否離開企業」的一部分問題。

還需要補齊：

帳號和權限：不同部門只能存取自己的知識庫。
日誌稽核：誰問了什麼、調用了哪個模型、存取了哪些文檔。
資料脫敏：客戶資訊、身分證號、手機號、合約金額等敏感欄位要處理。
提示詞安全：避免使用者透過提示詞繞過權限或洩露系統提示。
輸出審查：重要場景要有人審或規則審。
資料生命週期：上傳文檔、向量索引、快取和會話記錄要能刪除。

企業做本地大模型，不能只找演算法團隊。安全、法務、維運、業務負責人都要參與，否則上線後風險會被集中暴露。

成本不要只算顯卡

本地部署的成本通常被低估。除了顯卡或 NPU，還要算：

伺服器、機櫃、電源、散熱和網路。
儲存和備份。
推理框架適配和工程開發。
維運監控和故障處理。
模型升級、回滾和相容性測試。
安全稽核和權限系統。
業務側提示詞、RAG 和工作流建設。

如果調用量很低，外部 API 可能更便宜。如果調用量高、資料敏感、流程穩定，本地部署才更容易攤薄成本。

比較合理的策略是混合部署：

高敏感資料走本地模型。
低敏感通用任務可以走外部 API。
簡單任務走小模型。
複雜任務走 DeepSeek V4 Pro。
高頻任務優先最佳化快取、檢索和模型路由。

小結

DeepSeek V4 讓企業本地私有化部署有了更強的想像空間，但它不是一個簡單的「本地版 ChatGPT」。真正的難點在工程：硬體、框架、模型路由、權限、RAG、稽核、監控和成本控制都要一起考慮。

國產晶片路線更適合合規要求高、長期建設私有雲的企業；消費級顯卡叢集更適合試點和中小團隊快速驗證。Pro 適合複雜推理和 Agent，Flash 或小模型更適合大量普通任務。

如果只記住一句話：DeepSeek V4 私有化部署不要從硬體採購開始，而要從業務場景、資料邊界和調用規模開始。先把場景跑通，再決定要不要上大模型、上多大模型、上哪種算力。

參考資料

如何在 Cline 中呼叫 DeepSeek V4 Pro

Fri, 01 May 2026 20:59:06 +0800

Cline 本身已經支援 OpenAI Compatible Provider。 DeepSeek API 也相容 OpenAI SDK 風格的呼叫方式，所以把 deepseek-v4-pro 接到 Cline 裡並不複雜：選 OpenAI Compatible，填 DeepSeek 的 Base URL、API Key 和模型名即可。

下面按 VS Code 外掛介面和 Cline CLI 兩種方式整理。

準備 DeepSeek API Key

先到 DeepSeek 開放平台建立 API Key。

需要準備三個值：

項目	填寫內容
Provider	`OpenAI Compatible`
Base URL	`https://api.deepseek.com`
Model ID	`deepseek-v4-pro`

DeepSeek 官方文件說明，V4 系列使用既有 OpenAI 相容介面，base_url 保持為 https://api.deepseek.com，呼叫時把 model 設定為 deepseek-v4-pro 或 deepseek-v4-flash。

在 Cline 外掛裡設定

如果你用的是 VS Code 裡的 Cline 外掛，可以按這個路徑設定：

打開 VS Code 側邊欄裡的 Cline。
進入 Cline 的設定或模型設定頁面。
Provider 選擇 OpenAI Compatible。
API Key 填入 DeepSeek API Key。
Base URL 填：

`1`	`https://api.deepseek.com`

Model ID 填：

`1`	`deepseek-v4-pro`

儲存設定，回到 Cline 對話框測試一次簡單任務。

可以先讓 Cline 做一個低風險測試：

`1`	`請讀取目前專案目錄結構，並總結這個專案是什麼類型，不要修改任何檔案。`

如果能正常讀取和回答，說明模型鏈路已經通了。

在 Cline CLI 中設定

如果你使用 Cline CLI，可以用 cline provider configure openai-compatible 進入互動式設定。

範例：

`1`	`cline provider configure openai-compatible`

互動時填寫：

1
2
3

API Key: sk-...
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro

設定完成後，可以用一個只讀任務測試：

`1`	`cline "Summarize this repository structure without changing files."`

如果你希望先降低成本，也可以把 Model ID 臨時改成：

`1`	`deepseek-v4-flash`

等遇到複雜規劃、事實核查、多工具協作或高風險程式碼修改時，再切回 deepseek-v4-pro。

模型	適合場景
`deepseek-v4-flash`	日常程式碼閱讀、批量改小問題、生成腳本、整理上下文、低風險前端修改
`deepseek-v4-pro`	架構規劃、複雜 bug、跨檔案重構、事實核查、多工具呼叫、高風險改動

上下文長度怎麼填

DeepSeek V4 Pro 和 Flash 都支援很長上下文。在 Cline 裡如果需要手動填寫 context window，可以按 DeepSeek 官方模型頁給出的 1M 上下文來理解。

實際使用時不建議一開始就把所有檔案都塞進上下文。 Cline 會按任務讀取檔案，通常更好的方式是：

先讓它看目錄結構；
再讓它定位相關檔案；
最後只圍繞目標檔案執行修改。

這樣更省 Token，也更容易保持任務邊界清晰。

常見問題

1. 提示模型不存在

先檢查 Model ID 是否寫成：

`1`	`deepseek-v4-pro`

不要寫成 DeepSeek V4 Pro、deepseek-v4 或其他顯示名稱。

2. 提示 401 或認證失敗

檢查 API Key：

是否複製完整；
是否帶了多餘空格；
是否填到了 Cline 目前正在使用的 provider 設定裡；
DeepSeek 帳戶是否有可用額度。

3. 提示連線失敗

檢查 Base URL：

`1`	`https://api.deepseek.com`

不要在末尾額外拼 /v1/chat/completions。 Cline 的 OpenAI Compatible Provider 會自己按相容介面組織請求。

4. Cline 呼叫很貴怎麼辦

可以先把日常任務切到 deepseek-v4-flash，只在複雜任務裡使用 deepseek-v4-pro。

另外，盡量把任務描述寫清楚：

`1`	`只修改登入頁相關檔案，不要重構無關模組。先給出計畫，確認後再改程式碼。`

Agent 任務最怕邊界不清。邊界越清楚，讀檔案越少，工具呼叫越少，成本也越可控。

5. 報錯 reasoning_content must be passed back

如果你看到類似錯誤：

{
  "message": "400 The `reasoning_content` in the thinking mode must be passed back to the API.",
  "code": "invalid_request_error",
  "modelId": "deepseek-v4-pro"
}

這通常不是 Key、額度或 Base URL 的問題，而是 DeepSeek V4 Pro 的 thinking mode 和目前客戶端的多輪工具呼叫記錄沒有對齊。

DeepSeek 官方文件說明：

thinking mode 預設是 enabled；
thinking mode 下會返回 reasoning_content；
如果某一輪發生了 tool call，後續請求必須把該輪 assistant message 裡的 reasoning_content 一起傳回 API；
如果客戶端沒有正確回傳，就會返回 400。

Cline 透過 OpenAI Compatible Provider 接入時，如果目前版本沒有完整保留並回傳 DeepSeek 的 reasoning_content，就可能在第二輪或工具呼叫後觸發這個錯誤。

可嘗試的處理順序：

先升級 Cline 到最新版；
確認使用的是 OpenAI Compatible，而不是普通 OpenAI provider；
如果 Cline 支援自訂 request body，嘗試關閉 thinking mode：

{
  "thinking": {
    "type": "disabled"
  }
}

如果 Cline 不支援額外 body 參數，暫時改用不觸發該問題的模型或服務中轉；
等 Cline 適配 DeepSeek V4 的 reasoning_content 回傳後，再切回 deepseek-v4-pro。

需要注意：關閉 thinking mode 會犧牲一部分複雜推理能力，但可以繞開客戶端沒有回傳 reasoning_content 的相容性問題。

一個可直接複製的設定清單

Provider: OpenAI Compatible
API Key: sk-你的 DeepSeek API Key
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro

如果要低成本模式：

Provider: OpenAI Compatible
API Key: sk-你的 DeepSeek API Key
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-flash

小結

在 Cline 中呼叫 DeepSeek V4 Pro 的關鍵只有三步：

Provider 選擇 OpenAI Compatible；
Base URL 填 https://api.deepseek.com；
Model ID 填 deepseek-v4-pro。

設定完成後，建議先用只讀任務測試，再逐步交給它執行真實程式碼修改。如果你經常跑 Agent 任務，可以把 Flash 和 Pro 分開用：Flash 負責高頻輕量任務，Pro 負責複雜判斷和兜底。

參考來源：

DeepSeek V4 降價如何改寫 AI Agent 的成本模型

Fri, 01 May 2026 19:47:47 +0800

DeepSeek V4 發布時沒有製造出特別誇張的聲量。沒有大型發布會，也沒有一眼碾壓所有對手的跑分敘事。但幾天之後，它真正影響行業的地方開始顯現：連續降價。

這次變化的重點不是「模型強了一點」，而是「使用成本被打到另一個層級」。當 Token 價格低到普通 Agent 任務幾毛錢、一兩塊錢就能跑完時，很多 Coding Plan、Token Plan 的商業邏輯都會被重新審視。

發布當天沒有炸場

DeepSeek V4 的第一波反饋並不算熱烈。很多人期待它像 R1 那樣帶來強烈衝擊：跑分全面領先、國產算力驗證、多模態和 Agent 能力一起爆發。但真正發布後，大家發現它更像一次穩健升級。

V4 Pro 確實是強模型，尤其在程式碼、數學、長上下文和 agentic coding 上表現不錯。但它不是那種讓所有同類模型瞬間失色的產品。所以發布當天，輿論一度有些尷尬：想誇，但很難找到一個足夠爆炸的角度。

真正的轉折點不是發布當天，而是後續價格調整。

連續降價才是關鍵

DeepSeek V4 發布後，價格開始連續下探。按照 DeepSeek 官方價格頁和原文整理的資訊，當時的大致價格是：

DeepSeek V4 Flash：輸入 100 萬 Token 約 1 元；快取命中後 100 萬 Token 約 2 分錢；
DeepSeek V4 Pro：輸入 100 萬 Token 約 3 元；快取命中後 100 萬 Token 約 2.5 分；
全系列模型輸入快取命中價格降到首發價格的 1/10；
V4 Pro 曾處在 2.5 折優惠期，優惠延長到 2026 年 5 月 31 日 23:59。

如果按美元 API 價格看，會更直觀：

模型	快取命中輸入	非快取輸入	輸出	上下文
`deepseek-v4-flash`	$0.0028 / 100萬 Token	$0.14 / 100萬 Token	$0.28 / 100萬 Token	1M
`deepseek-v4-pro` 促銷價	$0.003625 / 100萬 Token	$0.435 / 100萬 Token	$0.87 / 100萬 Token	1M
`deepseek-v4-pro` 原價	$0.0145 / 100萬 Token	$1.74 / 100萬 Token	$3.48 / 100萬 Token	1M

這裡要注意兩個點。

第一，V4 Pro 的 $0.435 / $0.87 是促銷價，不是長期原價。 DeepSeek 官方說明裡，這個 75% 折扣延長到 2026 年 5 月 31 日 15:59 UTC。

第二，快取命中價格才是 Agent 成本模型裡的關鍵。 Flash 的快取命中輸入低到 $0.0028 / 100萬 Token，Pro 促銷期快取命中輸入是 $0.003625 / 100萬 Token。這意味著大量重複專案上下文、工具定義、系統提示詞和歷史摘要，不再按完整輸入價格計費。

這個價格最重要的地方，是它讓很多任務的 Token 成本變得「不敏感」。過去開發者會擔心一次 Agent 任務吃掉大量上下文、反覆讀寫程式碼、頻繁呼叫工具。現在只要快取命中率足夠高，成本會被壓得很低。

和 GPT、Claude 的價格對比

只看 DeepSeek 自己的價格，還不容易感受到差距。把它和同期常見的閉源模型放在一起，對比會更明顯。

模型	輸入	快取輸入	輸出	適合場景
`deepseek-v4-flash`	$0.14 / M	$0.0028 / M	$0.28 / M	高頻 Agent、常規 coding、批量任務
`deepseek-v4-pro` 促銷價	$0.435 / M	$0.003625 / M	$0.87 / M	複雜 coding、規劃、事實核查
`deepseek-v4-pro` 原價	$1.74 / M	$0.0145 / M	$3.48 / M	促銷結束後的 Pro 成本基準
GPT-5.5	$5 / M	$0.50 / M	$30 / M	高品質複雜任務、通用推理
GPT-5.4	$2.50 / M	$0.25 / M	$15 / M	程式設計和專業任務的中檔選擇
GPT-5.4 mini	$0.75 / M	$0.075 / M	$4.50 / M	成本更低的通用/子任務模型
Claude Opus 4.7	$5 / M	$0.50 / M	$25 / M	高品質寫作、複雜推理、長任務
Claude Sonnet 4.6	$3 / M	$0.30 / M	$15 / M	程式設計、Agent、綜合任務
Claude Haiku 4.5	$1 / M	$0.10 / M	$5 / M	輕量任務、摘要、分類

這張表裡最刺眼的是輸出價格。 Agent 不只讀上下文，還會不斷生成計畫、補丁、解釋、日誌和下一步動作。如果輸出很多，DeepSeek V4 Pro 促銷價的 $0.87 / M 和 GPT-5.5 的 $30 / M、Claude Sonnet 4.6 的 $15 / M 相比，差距會被不斷放大。

即使按 V4 Pro 原價 $3.48 / M 輸出算，它也明顯低於 GPT-5.4、GPT-5.5 和 Claude Sonnet / Opus。如果任務可以用 Flash 承擔，輸出價會進一步降到 $0.28 / M。

快取輸入差距更誇張。 DeepSeek V4 Flash 的快取輸入是 $0.0028 / M，而 GPT-5.5 和 Claude Opus 4.7 的快取輸入都是 $0.50 / M。這不是同一個數量級。對反覆讀取同一程式碼倉庫的 Agent 來說，這個差距比普通聊天更重要。

Agent 任務為什麼特別受影響

AI Agent 和普通聊天不一樣。普通聊天通常是一問一答，輸入上下文相對有限。 Agent 任務會反覆讀取專案檔案、生成計畫、呼叫工具、檢查結果、再修改程式碼。

這類任務有兩個特點：

Token 消耗大；
重複上下文多。

第二點很關鍵。在程式碼專案裡，模型會反覆讀取同一批檔案、目錄結構、錯誤日誌和修改結果。如果平台支援快取命中，重複輸入的成本會大幅下降。

原文裡提到一次實際體驗：把 DeepSeek V4 Pro 和 Flash 接到 Claude Code 一類工具中，讓它拉取一個提示詞倉庫並做成本地搜尋網站。任務最終完成，總成本大約 8 毛多，其中 Pro 快取命中率達到 98.7%。

這個例子說明了一個現實問題：Agent 任務越像「圍繞同一個專案反覆工作」，快取命中越有價值。如果一次生成網站、修 bug、改前端只花幾毛錢到幾塊錢，訂閱套餐的吸引力就會下降。

可以用一個簡化任務估算差距。假設一次 coding agent 任務包含：

50 萬 Token 輸入，其中 80% 能命中快取；
5 萬 Token 輸出；
不計算工具呼叫、搜尋和平台加價，只看模型 Token 成本。

大致成本如下：

模型	估算成本
DeepSeek V4 Flash	約 $0.03
DeepSeek V4 Pro 促銷價	約 $0.09
DeepSeek V4 Pro 原價	約 $0.36
GPT-5.4 mini	約 $0.30
GPT-5.4	約 $1.01
GPT-5.5	約 $1.75
Claude Sonnet 4.6	約 $1.11
Claude Opus 4.7	約 $1.65

這個估算不是說 DeepSeek 在所有任務上都更好。模型品質、工具呼叫穩定性、長上下文檢索能力、程式碼風格和事實可靠性都要單獨評估。但從成本上看，DeepSeek V4 把「讓 Agent 多跑幾輪」的邊際成本壓得很低。這會鼓勵開發者設計更長流程、更頻繁的自檢和更多候選方案，而不是每次都擔心 Token 帳單。

Coding Plan 和 Token Plan 的差別

很多 AI 產品現在會提供兩類套餐：Coding Plan 和 Token Plan。

它們的差別大致是：

Coding Plan 通常主要面向程式設計；
Token Plan 通常覆蓋更多能力，例如 STT、TTS、繪圖、搜尋、embedding、RAG；
STT 是語音轉文字；
TTS 是文字轉語音；
Coding Plan 往往把使用者限制在程式設計場景裡，其他能力還需要另買。

從商業角度看，Coding Plan 更像自助餐。使用者預先付一筆固定費用，廠商賭的是大多數人不會把額度用滿。有人用得多，有人用得少，平均下來平台仍然能賺錢。

但如果按量 Token 價格足夠低，使用者就會開始計算：我為什麼一定要買套餐？如果一個月真實使用成本只有幾塊錢、十幾塊錢，買 40 元、200 元的套餐就不一定划算。

降價為什麼會衝擊套餐模式

訂閱套餐的成立，需要一個前提：使用者覺得單次使用很貴，或者不想計算每次呼叫成本。當 Token 價格高時，套餐看起來更安心。當 Token 價格低到幾乎無感時，按量付費反而更自然。

DeepSeek V4 的降價相當於把底牌亮出來：

Agent 任務可以很便宜；
長上下文不一定貴到不能用；
快取命中可以顯著降低成本；
普通開發者不一定需要固定訂閱；
模型入口可以從「套餐平台」轉向「低價 API」。

這會讓做 Coding Plan 的平台不舒服。如果使用者發現按量呼叫更便宜、更自由，就沒必要為了一個平台的套餐被綁定。

Flash 和 Pro 怎麼選

DeepSeek V4 的一個實用思路，是把 Flash 和 Pro 分工使用。

Flash 適合高頻、輕量、可重複的任務：

改 bug；
寫前端；
寫腳本；
做常規程式碼理解；
處理較長上下文裡的普通資訊整理；
跑大量子任務。

Flash 便宜，速度快，而且同樣支援很長上下文。對日常 coding agent 來說，很多任務不需要一上來就用 Pro。

Pro 更適合複雜判斷和兜底任務：

多輪規劃；
複雜 Agent 流程；
多次 function call；
事實核查；
財經研究；
需要更強知識和判斷力的內容生產；
高風險程式碼修改。

一個合理配置是：Flash 負責跑量，Pro 負責兜底。普通任務先用 Flash，遇到長程規劃、複雜判斷、事實核查或多工具協作時再切 Pro。這樣既能控制成本，也能保留模型品質。

DeepSeek 為什麼可以這麼定價

DeepSeek 和很多大廠的業務結構不同。它沒有電商、社交、短影片、雲計算、手機、汽車、辦公套件、作業系統、瀏覽器或大規模企業 SaaS 生態。

這意味著它不需要把使用者鎖在一個完整平台裡。它可以只賣文字模型能力：你在這裡用便宜的文字模型，其他能力要呼叫誰都可以。

大廠的邏輯通常不同。如果你買了它的 Coding Plan 或 Token Plan，就會被拉進它的雲、搜尋、繪圖、語音、資料庫和開發工具生態。套餐不是單純賣模型，而是在爭奪使用者入口。

DeepSeek 的打法更直接：把文字模型價格壓低，爭取成為 Agent 的預設模型入口。只要預設入口被占住，很多開發者和工具鏈就會自然圍繞它適配。

開源模型和預設入口

DeepSeek V4 如果保持開放模型路線，第三方雲廠商和平台很可能會自行部署並提供服務。這對 DeepSeek 來說既是傳播，也可能是分流。

低價官方 API 的意義就在這裡。如果官方價格已經足夠低，其他平台即使能部署，也很難在價格上明顯更有優勢。使用者會傾向於直接使用預設、便宜、穩定的入口。

對 Agent 工具尤其如此。 Agent 任務依賴長上下文、快取、工具呼叫和穩定吞吐。一旦某個模型在這些場景裡成本足夠低，它就有機會成為預設選項。

Coding Plan 仍然不是完全沒用

這並不意味著 Coding Plan 會馬上消失。它仍然有適合的人群。

如果某些使用者真的是高強度使用者，每天把套餐額度打滿，那麼固定訂閱可能仍然划算。就像自助餐，如果完全沒有人能吃回本，使用者也不會願意買。

但問題在於，絕大多數使用者不是這種極端高頻使用者。低頻使用者、輕量開發者、偶爾寫腳本或改專案的人，更適合按量付費。當 DeepSeek 把按量成本壓低後，套餐的吸引力會被削弱。

未來更可能出現的是分層選擇：

高頻重度使用者繼續買 Coding Plan；
普通使用者轉向低價 API；
Agent 工具根據任務自動選擇 Flash / Pro；
平台套餐需要提供更多非模型價值，例如工作流、IDE 整合、部署、團隊管理和安全稽核。

小結

DeepSeek V4 的發布並沒有靠跑分製造最大衝擊。真正改變行業預期的是後續降價。

當輸入 Token 和快取命中價格被壓到很低時，AI Agent 的使用成本會發生變化。過去看起來昂貴的長上下文、程式碼專案分析、多輪工具呼叫，現在可能變成幾毛錢到幾塊錢的日常消耗。

這會直接衝擊 Coding Plan 和 Token Plan 的商業邏輯。如果使用者可以按量付費、自由組合模型和工具，而且成本足夠低，就不一定願意被綁定在某個平台套餐裡。

DeepSeek V4 這次真正動到的，不只是模型能力排名，而是 AI Agent 的成本結構和預設入口之爭。

參考來源：

free-claude-code：用代理把 Claude Code 接到 OpenRouter、DeepSeek 和本地模型

Fri, 01 May 2026 03:41:49 +0800

free-claude-code 是一個給 Claude Code 使用的 Anthropic-compatible proxy。

它的思路不是破解 Claude Code，也不是提供官方免費的 Claude 服務，而是在本地啟動一個相容 Anthropic API 形狀的代理服務，把 Claude Code 發出的請求轉發到其他模型後端。README 中提到的後端包括 NVIDIA NIM、OpenRouter、DeepSeek、LM Studio、llama.cpp 和 Ollama。

簡單說，它想解決的是：你喜歡 Claude Code 的終端體驗，但希望把模型請求接到別的 provider 或本地模型上。

它解決什麼問題

Claude Code 的互動體驗很適合開發任務。

它可以在終端裡閱讀程式碼、修改檔案、執行命令、根據專案上下文推進任務。問題是，很多使用者並不一定想始終使用同一個模型後端：

想試試 OpenRouter 上的不同模型
想用 DeepSeek 這類模型降低成本
想把請求接到本地 Ollama
想用 LM Studio 或 llama.cpp 跑本地模型
想在開發環境裡統一走一個代理入口
想比較不同模型在 Claude Code 工作流裡的表現

free-claude-code 的定位，就是在 Claude Code 和這些模型服務之間加一層相容代理。

這樣 Claude Code 仍然按 Anthropic 風格發請求，代理負責把請求適配到不同後端。

工作方式

可以把它理解成三層：

前端是 Claude Code
中間是 free-claude-code 代理
後端是 OpenRouter、DeepSeek、本地模型或其他模型服務

Claude Code 以為自己在存取一個 Anthropic-compatible API。

代理收到請求後，根據配置選擇目標 provider，轉換必要欄位，再把回應返回給 Claude Code。

這類結構的好處是，你不用改 Claude Code 本身，也不用讓每個模型服務都原生支援 Claude Code。只要代理能把介面對齊，就能把更多模型接進同一個工作流。

支援哪些後端

README 中列出的方向包括：

NVIDIA NIM
OpenRouter
DeepSeek
LM Studio
llama.cpp
Ollama

這些後端代表了幾類不同使用方式。

OpenRouter 更像模型聚合入口，可以測試不同商業和開源模型。

DeepSeek 適合關注中文能力、程式碼能力和成本的人。

LM Studio、llama.cpp、Ollama 則偏本地模型路線。它們適合在自己的機器或內網環境裡執行模型，減少外部 API 依賴，也方便做離線實驗。

NVIDIA NIM 則更偏企業和 GPU 推理部署場景。

為什麼是 Anthropic-compatible proxy

Claude Code 本來圍繞 Anthropic 的介面和模型習慣設計。

如果你想讓它接入其他模型，最直接的問題就是介面不一致：

請求欄位不同
模型名稱不同
streaming 格式不同
tool use 表達不同
錯誤返回格式不同
token 和上下文限制不同

代理層的價值就在這裡。

它把 Claude Code 這邊看到的介面維持在接近 Anthropic 的形狀，再在後端做適配。對使用者來說，配置一次代理後，就可以在相同 Claude Code 工作流裡測試不同模型。

適合什麼場景

free-claude-code 適合這些場景：

想用 Claude Code 的終端工作流
想測試非 Anthropic 模型在 Claude Code 裡的表現
想降低模型呼叫成本
想把 Claude Code 接到 OpenRouter
想接入 DeepSeek 等相容模型服務
想用 Ollama、LM Studio、llama.cpp 跑本地模型
想為團隊統一配置一個模型代理入口

如果你只是正常使用官方 Claude Code，並且對模型提供方、成本和本地部署沒有特殊需求，那不一定需要這類代理。

但如果你經常比較模型，或者希望讓 Claude Code 接入本地和第三方模型，這類工具會很有用。

和直接用 OpenRouter 或 Ollama 有什麼區別

直接用 OpenRouter、Ollama 或 LM Studio，通常只是和模型聊天，或者透過 API 呼叫模型。

free-claude-code 的重點不是替代這些服務，而是把它們接到 Claude Code 這個開發工作流裡。

區別在於：

你仍然使用 Claude Code 的終端體驗
AI 可以圍繞程式碼倉庫執行任務
模型後端可以換成其他 provider
本地模型也有機會進入 Claude Code 工作流
配置集中在代理層，而不是每個工具單獨改

所以它更像橋接器，而不是新的聊天客戶端。

本地模型要注意什麼

把 Claude Code 接到本地模型很有吸引力，但也要注意現實限制。

第一，模型能力差距。

Claude Code 的任務通常不只是聊天，還包括理解程式碼、規劃修改、編輯檔案、處理命令輸出。本地小模型不一定能穩定完成這些任務。

第二，上下文視窗。

程式碼任務很吃上下文。模型上下文太小，會導致它讀不全檔案、漏掉約束，或者在多輪任務裡丟失背景。

第三，tool use 相容性。

Claude Code 工作流依賴工具呼叫和結構化行為。後端模型即使能聊天，也未必擅長遵循工具呼叫協議。

第四，速度和硬體。

本地模型的速度取決於機器配置、量化方式和模型大小。程式碼任務如果回應太慢，體驗會明顯下降。

所以，本地模型更適合實驗、低風險任務和特定場景。真正複雜的程式碼任務，仍然要根據模型能力謹慎選擇。

使用邊界

這類專案很容易被標題誤解，所以邊界要說清楚。

第一，它不是官方 Claude Code 免費額度。

它只是把 Claude Code 的請求轉發到其他模型後端。你使用 OpenRouter、DeepSeek、NVIDIA NIM 或其他 API 時，仍然需要遵守對應服務的價格、額度和使用條款。

第二，它不是繞過授權的工具。

使用任何代理工具時，都應該遵守 Claude Code、模型服務商和專案本身的授權協議。不要把它理解成規避官方限制的方式。

第三，代理會處理你的請求內容。

程式碼、命令輸出、專案上下文可能會經過代理和後端服務。部署時要考慮日誌、金鑰、網路和隱私邊界。涉及公司程式碼或敏感專案時，最好使用受控環境。

第四，不同模型表現差異會很大。

同樣的 Claude Code 操作，換一個模型後可能出現完全不同的行為。不要預設所有模型都能替代 Claude。

和 LiteLLM 這類代理有什麼關係

從思路上看，free-claude-code 屬於「相容介面代理」這一類工具。

這類工具的共同目標是減少上層應用和底層模型服務之間的耦合。上層應用只需要面對一個相對統一的介面，底層 provider 可以按配置切換。

不同專案的側重點不同。有的更偏通用模型閘道，有的更偏 OpenAI-compatible API，有的專門為 Claude Code 這類工具做適配。

free-claude-code 值得關注的地方，是它把目標場景直接放在 Claude Code 上，而不是做一個泛泛的聊天代理。

適合怎樣的使用者

它更適合有一定折騰能力的使用者：

熟悉 Claude Code
知道 API key 和模型 provider 怎麼配置
能理解代理服務的啟動和環境變數
能排查網路、連接埠、模型名稱和 streaming 問題
願意比較不同模型在程式碼任務裡的表現

如果你只想開箱即用，官方配置通常更省心。

如果你願意搭代理、換模型、調參數，並且想讓 Claude Code 進入更多模型環境，這個專案就值得研究。

參考

Alishahryar1/free-claude-code

最後一句

free-claude-code 的價值，不在於「免費」這個詞，而在於它把 Claude Code 和更多模型後端之間接了一座橋。

當你想保留 Claude Code 的開發體驗，同時測試 OpenRouter、DeepSeek、本地模型或企業推理服務時，這類 Anthropic-compatible proxy 就有了用武之地。

DeepSeek V4 Pro 對比 GPT-5.5：前端、寫作、程式實測後，差距比想像更大

Sat, 25 Apr 2026 11:12:00 +0800

DeepSeek V4 Pro 和 GPT-5.5 這種對比，最近越來越容易引發討論。因為它已經不是「誰能不能用」的問題，而是：當任務落到前端、寫作、程式這三類高頻場景時，誰更適合當主力？

很多人做這類比較時，習慣先問一句：哪個更強。
但更有價值的問題通常不是這個，而是：在具體任務裡，哪個更穩、哪個更省溝通成本、哪個更容易產出能直接繼續推進的結果。

如果先給一個簡化版結論，可以大致這樣理解：

需要更均衡、產品化體驗更完整的綜合輸出時，很多人還是會先看 GPT-5.5
需要中文語境下高頻迭代、對成本更敏感、追求回應效率時，DeepSeek V4 Pro 會更容易進入候選名單
真正決定體驗的，往往不是模型名字本身，而是任務類型、提示方式，以及你後續還要不要繼續改

下面按三個最常見的比較場景展開。

1. 前端任務：比的不是「會不會寫頁面」，而是能不能繼續接著改

前端任務看起來很適合拿來做模型對比，因為結果很直觀：
頁面能不能跑、樣式好不好看、結構清不清楚，一眼就能看到。

但真正拉開差距的，往往不是第一版能不能寫出來，而是後續這些問題：

結構是不是夠清晰
元件拆分是否自然
改一處時會不會連帶改壞別的地方
能不能在多輪指令下繼續保持同一套實作思路

這也是為什麼很多「首輪效果驚艷」的前端演示，放進真實工作流後未必依然佔優。

如果你的任務是：

快速生成一個可執行的頁面原型
先把一個落地頁思路寫出來
按要求補齊樣式、按鈕、卡片、表單等基礎元素

那兩類模型通常都能完成得八九不離十，差別更多體現在輸出風格。

而如果你的任務變成：

持續多輪改 UI
一邊讀現有程式碼一邊接著改
同時兼顧元件結構、樣式一致性和可維護性
從靜態頁面逐步推進到真實專案程式碼

那你更應該觀察的就不是「第一輪誰更像樣」，而是「誰在第五輪以後還不容易跑偏」。

所以前端對比真正該看的，不是模型能不能生成頁面，而是它能不能在你連續追加限制之後，依舊保持結構穩定、命名一致、修改成本可控。

2. 寫作任務：比的不是字多不多，而是風格穩不穩、重寫順不順

寫作是另一類特別容易出現誤判的場景。

因為很多時候，模型第一次輸出看起來都不差：
結構完整、段落齊全、語氣順滑，乍看之下很容易覺得「差不多」。

但只要你把任務往前推一步，差異就會冒出來：

能不能準確理解你要的受眾
能不能在同一主題下切換不同口吻
重寫時會不會丟掉原文重點
壓縮、擴寫、改標題、換結構時是否穩定

寫作任務裡最怕的不是「寫不出來」，而是「看起來寫出來了，但你還得重改很多遍」。

所以在 DeepSeek V4 Pro 和 GPT-5.5 之間，更實用的比較方式通常不是讓它們各寫一篇，而是連續做這幾輪：

先寫初稿
再換一個語氣重寫
再壓縮成更短版本
再改成更適合標題黨或搜尋分發的寫法

如果一個模型在這幾輪裡仍然能保持重點不散、表達不飄、結構不亂，那它在真實寫作工作流裡的價值才會更高。

也就是說，寫作任務真正比的不是「文采」，而是改稿能力、服從度和連續協作感。

3. 程式任務：真正拉開差距的是長鏈路穩定性

程式任務比前端任務更容易暴露模型真實水平，因為它不只是要「輸出」，還要「對接現實」。

你很快就會遇到這些問題：

它能不能理解既有專案結構
能不能同時修改多個檔案
改完以後有沒有引入新的問題
出錯時會不會順著日誌繼續往下查
多輪之後還記不記得前面已經做過什麼

這類任務裡，使用者最在意的通常不是某一段程式碼漂不漂亮，而是：能不能幫我持續往前推進，而不是讓我來收拾殘局。

所以比較 DeepSeek V4 Pro 和 GPT-5.5 時，最值得看的往往不是單點題，而是這種更接近真實工作的過程：

讀一個既有倉庫
找到一個 bug
改多個相關檔案
根據報錯繼續修
最後把結果整理清楚

只要任務進入這種連續推進模式，模型的上下文保持能力、執行習慣、解釋品質和返工率，都會比「單輪答題效果」更重要。

這也是為什麼很多使用者在程式場景裡，最後形成的不是「永遠只用一個模型」，而是按任務階段切換主力。

4. 真正值得比較的，不是輸贏，而是「哪類任務交給誰更划算」

把 DeepSeek V4 Pro 和 GPT-5.5 放在一起時，如果目標只是爭一個總冠軍，最後往往會得到一個很空的結論。

因為現實任務不是統一題目：

有的是一次性生成
有的是多輪協作
有的是中文寫作
有的是工程改動
有的是強調速度
有的是強調穩定性
有的是強調成本

所以更接近真實使用的方法，通常是按任務目標分：

想要更完整的綜合體驗、更成熟的互動和更穩定的通用輸出，可以優先試 GPT-5.5
想要在中文環境裡高頻試錯、快速迭代，並且更關注投入產出比，DeepSeek V4 Pro 值得重點放進工作流裡
如果任務本身是長鏈路、多輪修正、多人協作，那就不要只看第一輪結果，要看五輪以後誰還更穩

換句話說，真正該問的不是「誰絕對更強」，而是：
前端、寫作、程式這三類任務裡，哪一個模型更像你當前階段最順手的工具。

5. 怎麼做一次更像樣的模型對比

如果你自己也準備測 DeepSeek V4 Pro 和 GPT-5.5，一個更可靠的做法通常不是只跑一輪，而是這樣測：

給兩邊同一份初始需求
保持相同限制條件
連續追問三到五輪
記錄改動品質、跑偏次數和返工量
最後再看速度、成本和最終可用度

這樣測出來的結果，會比「誰第一輪更驚艷」更接近真實工作。

尤其在前端、寫作、程式這三類任務裡，很多時候真正決定體驗的不是起跑線，而是誰能陪你把事情做完。

6. 可以先這樣記

如果只想先記一個夠用的版本，可以先這麼理解：

GPT-5.5：更像綜合型、產品化、預設可用的主流工作台
DeepSeek V4 Pro：更像在中文環境和高頻試錯裡更值得納入日常工作流的競爭者
真正的比較重點：不是首輪炫技，而是多輪修改之後誰更穩、誰更省事

所以這類對比裡，真正重要的從來都不是「誰贏了」，而是：
你的前端、寫作、程式任務，交給誰之後最容易持續推進、最少返工、最能穩定產出。

DeepSeek-V4 Preview 發布：1M 上下文、雙模型與 API 切換提醒

Fri, 24 Apr 2026 22:39:46 +0800

DeepSeek 在 2026-04-24 發布了 DeepSeek V4 Preview Release。從官方新聞頁來看，這次更新的重點非常集中：1M context、V4-Pro 與 V4-Flash 雙模型、針對 Agent 場景的專門優化，以及 API 側的模型切換。

如果只看一句話，這次發布的核心訊號是：DeepSeek 不只是繼續做更強的模型，而是在把超長上下文和 Agent 能力一起往「可以直接上線使用」的方向推進。

1. 這次一共發布了什麼

官方頁面裡，DeepSeek-V4 Preview 主要包含兩條產品線：

DeepSeek-V4-Pro
DeepSeek-V4-Flash

對應的官方描述也很直接：

DeepSeek-V4-Pro：1.6T total / 49B active params
DeepSeek-V4-Flash：284B total / 13B active params

從命名就能看出來，這次不是單模型升級，而是把高性能版本和更高性價比版本同時推出。

其中 V4-Pro 更強調上限，官方表示它的表現已經可以和全球頂級閉源模型競爭；V4-Flash 則更強調速度、效率和成本，更適合對回應速度和 API 成本更敏感的場景。

2. `1M context` 是這次最突出的賣點

官方頁面最醒目的表述之一，就是：「Welcome to the era of cost-effective 1M context length.」

DeepSeek 這次不只是說「支援長上下文」，而是明確把 1M context 當成這代模型的預設能力來講。頁面裡也寫得很清楚：

1M context 已經成為官方 DeepSeek 服務的預設標準
V4-Pro 和 V4-Flash 都支援 1M context

這件事的意義不只是「能塞更多 token」。它更直接影響下面這些任務：

長程式碼倉庫理解
長文件問答與資料整理
多輪 Agent 工作流
橫跨多檔案、多工具、多階段的複雜任務

如果上下文窗口夠大，模型就比較不容易因為中途丟失上下文而反覆回讀材料，這對 Agent 編碼和複雜知識工作會特別重要。

3. `V4-Pro` 主要在強調什麼

從官方頁的措辭來看，DeepSeek-V4-Pro 重點強調三件事：

Agentic Coding 能力
世界知識
推理能力

頁面提到，V4-Pro 在 Agentic Coding benchmark 上達到開源 SOTA；在世界知識方面領先目前的開源模型，只落後於 Gemini-3.1-Pro；在數學、STEM 和編碼能力上超過目前的開源模型，並且可以和頂級閉源模型競爭。

換句話說，V4-Pro 的定位並不是單純回答問題，而是更偏向高難度推理、複雜編碼和長任務執行。

4. `V4-Flash` 並不是簡單的縮水版

另一個值得注意的點是，官方沒有把 V4-Flash 包裝成「低配模型」，而是強調它在很多實際任務裡已經足夠強。

按照新聞頁給出的說法，V4-Flash：

推理能力已經很接近 V4-Pro
在簡單 Agent 任務上與 V4-Pro 表現相當
參數規模更小、回應更快、API 定價更便宜

這意味著 DeepSeek 這次給出的並不是「一個旗艦、一個入門」這種非常割裂的組合，而更像是：

V4-Pro：追求更高性能和更強上限
V4-Flash：追求更低延遲和更好的成本效率

對開發者來說，這樣的組合會更實用，因為很多線上任務真正需要的不是「理論最強」，而是「夠強、夠快、夠省」。

5. 官方特別強調了 Agent 優化

這次發布頁裡還有一個很明確的方向：DeepSeek 在主動把 V4 往 Agent 場景上推。

官方頁面提到，DeepSeek-V4 已經和一些主流 AI Agent 深度整合，包括：

Claude Code
OpenClaw
OpenCode

同時 DeepSeek 也提到，V4 已經在內部 agentic coding 場景中使用。

這說明它想覆蓋的，不再只是聊天或普通補全，而是更長鏈路的工作方式：讀程式碼、理解結構、調用工具、生成結果，再把整條流程串起來。

如果你最近剛好在關注 coding agent，這個訊號值得留意。因為它意味著模型廠商已經不再只拼 benchmark，而是在拼「能不能真正接進工作流」。

6. 底層結構創新是在為長上下文服務

在技術描述上，官方頁把這次的結構創新總結為：

token-wise compression
DSA (DeepSeek Sparse Attention)

頁面給出的方向非常明確：目標是把長上下文做得更便宜、更高效，盡量降低計算和顯存成本。

雖然新聞頁沒有展開完整技術細節，但這至少說明 DeepSeek 這次不是單純靠「更大算力硬堆更長窗口」，而是在結構層面針對長上下文效率做了專門優化。

對實際使用者來說，這通常比單純「窗口數字變大」更重要，因為真正決定可用性的，不只是能不能開到 1M，還包括：

速度是否還能接受
成本是否還能接受
長上下文任務是否真的穩定

7. API 已經可用，但要注意模型切換

官方頁面明確寫到，這次 API 當天就已經可用。

接入方式也比較簡單：

base_url 保持不變
把模型名切換為 deepseek-v4-pro 或 deepseek-v4-flash

同時頁面說明，這兩個模型都支援：

1M context
Thinking / Non-Thinking 雙模式
OpenAI ChatCompletions
Anthropic APIs

這意味著如果你原本已經接了 DeepSeek API，升級門檻並不高，主要是模型名切換和能力驗證。

8. 舊模型的退役時間也寫得很明確

對開發者來說，這次新聞頁裡最不能忽略的資訊之一，其實是舊模型退役提醒。

官方寫明：

deepseek-chat
deepseek-reasoner

會在 2026 年 7 月 24 日 15:59（UTC） 後完全退役並不可訪問。

頁面還說明，當前這兩個模型實際上已經路由到 deepseek-v4-flash 的非思考 / 思考模式。

這意味著如果你的專案裡還直接寫著 deepseek-chat 或 deepseek-reasoner，現在就應該開始安排遷移，而不要拖到正式下線前再處理。

9. 這次發布值得怎麼理解

如果把這次更新濃縮成幾個重點，大概可以這樣看：

DeepSeek 開始把 1M context 從「高配能力」變成預設標準
雙模型路線更清晰：一個衝性能上限，一個衝速度和性價比
Agent 能力已經被放到很核心的位置
API 升級路徑相對直接，但舊模型退役時間需要盡快關注

對一般使用者來說，最直觀的變化可能是：長文件、長程式碼、長流程任務會更容易放進一次上下文裡。
對開發者來說，更重要的是：如果你已經在做 Agent、程式碼助手、資料整理、複雜工作流，這一代模型顯然就是朝這些場景設計的。

DeepSeek 這次發布，不只是一次常規模型更新，更像是在明確它下一階段的產品方向：超長上下文 + Agent 優化 + 更實際的 API 可用性。

DeepSeek on KnightLi的博客

讓 Codex 使用 DeepSeek 模型的兩種方法：本機閘道和 OpenRouter BYOK

方法一：用本機閘道橋接 DeepSeek

方法二：用 OpenRouter BYOK 做線上橋接

要不要繼續用 deepseek-chat 這個模型名？

直接改 DeepSeek 官方 base_url 為什麼不推薦

改完設定後還是走 OpenAI 怎麼辦

排障清單

結論

DeepSeek-TUI：把 DeepSeek V4 變成終端裡的編程智能體

它解決的是 DeepSeek 的使用入口問題

TUI 比純命令列更適合長任務

Auto 模式適合明確邊界的任務

子智能體的意義在於拆任務

1M 上下文不是萬能，但很適合讀專案

更適合哪些使用者

需要關注的風險

總結

本地執行 DeepSeek 4：Antirez ds4 在 Apple Silicon Mac 上的嘗試

ds4 是什麼

為什麼值得關注

適合誰用

使用方式

目前的風險

和通用推理工具的區別

小結

參考

AI 編程工具這一輪，DeepSeek 為何成了省錢關鍵？

Agent 工具為什麼特別費 token

Superpowers 的好處是按需觸發

DeepSeek 的關鍵優勢是快取便宜

長上下文讓 Claude Code 更好用

V4 Pro 和 V4 Flash 怎麼分工

MiniMax、豆包和 DeepSeek 的位置不同

省錢的關鍵不是只找便宜模型

DeepSeek 適合哪類 AI 編程工作流

小結

DeepSeek-TUI：在終端裡執行 DeepSeek 編程 Agent

適合誰

安裝方式

配置 API Key

Auto mode

三種模式

工具能力

常用命令

Zed 和 ACP

配置和 provider

小結

參考資料

DeepSeek V4 本地私有化部署方案：國產晶片與消費級顯卡叢集怎麼選

先明確部署目標

不要一上來就追求滿血 Pro

國產晶片路線：適合企業級私有雲

消費級顯卡叢集：適合試點和中小團隊

可能的部署架構

硬體選型思路

驗證階段

試點階段

生產階段

推理框架怎麼選

資料安全要做在模型外面

成本不要只算顯卡

推薦落地路徑

小結

參考資料

如何在 Cline 中呼叫 DeepSeek V4 Pro

準備 DeepSeek API Key

在 Cline 外掛裡設定

在 Cline CLI 中設定

推薦的模型分工

上下文長度怎麼填

常見問題

1. 提示模型不存在

2. 提示 401 或認證失敗

3. 提示連線失敗

4. Cline 呼叫很貴怎麼辦

5. 報錯 reasoning_content must be passed back

一個可直接複製的設定清單

小結

DeepSeek V4 降價如何改寫 AI Agent 的成本模型

2. `1M context` 是這次最突出的賣點

3. `V4-Pro` 主要在強調什麼

4. `V4-Flash` 並不是簡單的縮水版