最近幾天，一個叫 DeepSeek-TUI 的開放原始碼專案突然在 GitHub 徹底火了，僅僅在過去一天，Star 數量直接從 8.7k 又漲到了 16.3k。
DeepSeek-TUI 不是 DeepSeek 官方產品，而是個人開發者基於 DeepSeek V4 開發的終端原生程式設計智能體。但它漲星的速度很快，吸引了國內外很多 AI 開發者的關注，短短幾天時間就沖上了 GitHub Trending 前列，被很多開發者稱為「DeepSeek 版 Claude Code」「國產 Codex CLI」或者更本土化的「鯨魚」。
開發者 Hunter Bown 也乾脆入鄉隨俗，把 DeepSeek-TUI 使用者稱為「鯨魚兄弟（whale bros）」。
但我們已經有了 DeepSeek V4 的網頁版、APP 以及 API，為什麼還需要一個 TUI？
這個問題其實很關鍵。因為過去一年，大模型行業最明顯的變化之一，就是模型之上的 Agent 框架。GPT-5.5 很強，但真正改變開發者工作流的，是 GPT-5.5+Codex，而真正讓 Anthropic 在開發者圈子裡形成統治力的，也是基於 Claude 模型的 Claude Code。
這也是 DeepSeek-TUI 火起來的真正背景。DeepSeek V4 明顯提升了程式碼能力、推理能力、長上下文、多輪理解等方方面面，但始終缺少了一個基於模型專門打造的 Agent 框架。
先不說 Codex、Claude Code 對自家模型有著更好的理解和支援，單單 Codex 最近的一次升級，把推理介面從「聊天補全 (chat/completions API)」全面切換到「響應 (Responses API)」，就使得 V4 在 Codex 全面失效。
DeepSeek V4 需要一個自己的 Codex，但問題是作為一個第三方的個人開放原始碼專案，DeepSeek TUI 真的能撐起大家的期待嗎？
不到 10 塊錢，小白也能開發 macOS 應用、修 Bug
我是在 macOS 上實際部署和體驗 DeepSeek-TUI 的。坦白講，DeepSeek-TUI 畢竟還是一個面向開發者的工具，沒有圖形化引導，沒有所謂「面向普通使用者」的包裝，整個過程裡依然充滿命令列、環境依賴和工具鏈的味道。
相比 Codex 那種完全圖形化的下載安裝體驗顯然更複雜，但又沒有 OpenClaw（龍蝦）那樣複雜。
實際上，DeepSeek-TUI 提供了 npm、Cargo、Homebrew 和直接下載二進制四種方式，我是直接通過 Homebrew 進行安裝，但一開始就遇到了系統報錯：Your Command Line Tools are too outdated.（你的命令列工具太舊了。）
問題不大，通過蘋果官網更新最新版重新執行 brew 命令，僅僅兩行很快就能一鍵成功安裝 DeepSeek-TUI，完成後輸入「deepseek-tui」就能啟動進入引導組態，一路確認、輸入 DeepSeek API 就能進入對話介面。
這裡需要一提，DeepSeek-TUI 默認有三種模式：Plan、Agent 和 YOLO。Plan 更像觀察模式。它會先分析項目、生成計畫、列出 Todo，但不會真正執行修改。Agent 模式則會開始呼叫工具，比如讀檔案、改程式碼、執行 shell 命令，但很多關鍵步驟仍然會要求使用者確認。YOLO 模式最激進，幾乎等於「放權模式」，允許 AI 自動推進整個任務鏈。
這種模式設計，其實非常像 Claude Code。
但真正讓我開始意識到 DeepSeek-TUI 有點東西的，還是後面的實測。我試著用 DeepSeek-TUI 開發一個可以只滿足個人需求的 macOS 剪貼簿，我強調了釘選、iCloud 本地同步、菜單欄支援等要點，花的時間並不少，包括最後的編譯打包。
從實際成果來看，DeepSeek-TUI 開發出來的這個 ClipMemo 完全可用，我要的功能基本都能正常運行，甚至還增加了一些我根本沒提及的重要功能，比如定期的清理和去重等。另外在 UX、UI 設計上，ClipMemo 雖談不上多驚豔，但也完全能滿足正常的要求。
最主要的問題是，儘管存在 iCIoud 同步的功能開關，但實際並不能夠在 iCloud 下生成保存複製內容的剪貼簿檔案。
我還選了一個實際存在開放原始碼專案 GKD（gkd-kit/gkd）進行 bug 修複測試。這是一個 Android 自動化相關的開放原始碼專案，整個項目是 Kotlin + Android Framework 的結構，程式碼量不小，而且涉及 AccessibilityNodeInfo、快取深度、事件服務等偏底層的邏輯。
GKD 的上一次版本更新是 2025 年底，不過從 Git 記錄來看，開發者至少兩週前還為 GKD 升級了 Android 17 的支援。
說回 DeepSeek-TUI，我不僅讓它自己將項目克隆到本地，還下了一個工作量不低的任務，就是檢查項目裡的潛在 bug，並嘗試修復。而接下來，DeepSeek-TUI 就開始自己克隆倉庫、閱讀項目結構、分析 Kotlin 檔案、尋找函數呼叫關係、生成 patch、運行 git diff、驗證修改結果，整個過程持續了 13 分鐘多。
過程中，它會自己形成 debugging loop：先讀程式碼，再修改，再運行，再看結果，再繼續修改。尤其是右側不斷變化的 Todos，非常有「工作流」的味道：先克隆項目、再瞭解程式碼庫、接著檢查 bug、最後修復問題。
這也是 DeepSeek-TUI 和網頁版 DeepSeek 最大的區別。網頁版本質上仍然是「聊天」，哪怕你上傳程式碼、貼日誌，它也依然是在「建議」。但 DeepSeek-TUI 已經開始自己讀檔案、自己跑命令、自己維護任務狀態、自己驗證 patch、自己持續推進任務。AI 不再只是告訴你「應該怎麼做」，而是開始真的去做。
另外需要一提的是，很多人現在會把 Agent 理解成「更聰明的大模型」，但實際體驗就會發現，真正重要的變化是圍繞模型建構的一整套工程，包括邊界約束、上下文工程、工具呼叫等。另外值得一提的是，DeepSeek-TUI 也原生支援了 MCP 和 skills，可以將自訂的工作流封裝成 skills。
而考慮到這畢竟還是一個比較小的項目，DeepSeek-TUI 修 bug 時間確實不算短，結果找出並「修復」三處 bug。
我也請了 Codex(GPT-5.5 高) 通過 Computer Use 閱讀終端對話進行審計評估，指出了六個問題，其中還提到了 DeepSeek-TUI 漏掉了它看到的一個明確邏輯 bug。
必須要說的是，在介面設計上，相比 Codex 把很多具體的細節「摺疊」起來，DeepSeek-TUI 還是傾向於所有細節展開，在資訊獲取上存在一定的壓力。在 AI Coding 場景下，這或許還是一個能接受的設計，但如果 DeepSeek-TUI 最後還是要像 Claude Code、Codex 一樣走向全能型 Agent，這就很難讓人接受了。
而從結果來看，DeepSeek-TUI 和 Codex 之間還是存在明顯的差距，這種差距不只是在模型層面，也體現在 Agent 工程成熟度上。
不過 DeepSeek-TUI 現在的 Auto Mode 還是挺有意思的，它會先用 deepseek-v4-flash 判斷當前任務到底該用更便宜的 deepseek-v4-flash 還是更強的 deepseek-v4-pro，簡單任務省錢，複雜任務再呼叫更強模型。
這個設計其實很現實。因為今天所有 Agent 最大的問題之一，就是 token 成本，尤其進入持續工作模式之後，token 消耗會迅速暴漲。而 DeepSeek V4 這次升級給人最深的印象還是極高的性價比，再加上 DeepSeek-TUI 的架構和 Auto Mode 設計，真的很便宜。
一次十幾分鐘的 bug 修複測試，加上 ClipMemo 的開發，總共花費也只有 9.47 元。
當然，實際來看其實還需要花費更多 token 進行最佳化、迭代，但也已經足夠說明在 DeepSeek-TUI 上用 DeepSeek V4（主要使用 Pro）的優勢。
寫在最後
現在再回頭看 DeepSeek-TUI，會發現它最重要的意義，其實未必是「一個開源 TUI」。真正重要的是 DeepSeek 生態終於開始出現真正的 Agent 外殼了，而且 DeepSeek 官方其實已經注意到了這件事，在 awesome-deepseek-agent 中加入了 DeepSeek-TUI。
核心在於，今天的大模型競爭正在從「模型能力」轉向「Agent 工作流」。Codex 是 OpenAI 自己做的，Claude Code 是 Anthropic 自己做的。它們最大的優勢，其實不是「功能」，而在於模型團隊和 Agent 工程團隊的垂直整合。模型知道工具鏈需要什麼，工具鏈也知道模型擅長什麼。而這種協同，會越來越重要。
而 DeepSeek 現在的問題在於官方的 Agent 框架仍然缺位。DeepSeek-TUI 或許能夠證明 DeepSeek V4 真正進入 coding agent 工作流後的巨大優勢，但我們還是期待 DeepSeek 官方，到底什麼時候親自下場。 (電車通)