最近几天，一个叫 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）」。
图片来源：X
但我们已经有了 DeepSeek V4 的网页版、APP 以及 API，为什么还需要一个 TUI？
这个问题其实很关键。因为过去一年，大模型行业最明显的变化之一，就是模型之上的 Agent 框架。GPT-5.5 很强，但真正改变开发者工作流的，是 GPT-5.5+Codex，而真正让 Anthropic 在开发者圈子里形成统治力的，也是基于 Claude 模型的 Claude Code。
这也是 DeepSeek-TUI 火起来的真正背景。DeepSeek V4 明显提升了代码能力、推理能力、长上下文、多轮理解等方方面面，但始终缺少了一个基于模型专门打造的 Agent 框架。
图片来源：Github
先不说 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 虽谈不上多惊艳，但也完全能满足正常的要求。
刚开发的 ClipMemo 初版，图片来源：雷科技
最主要的问题是，尽管存在 iCIoud 同步的功能开关，但实际并不能够在 iCloud 下生成保存复制内容的剪贴板文件。
我还选了一个实际存在开源项目 GKD（gkd-kit/gkd）进行 bug 修复测试。这是一个 Android 自动化相关的开源项目，整个项目是 Kotlin + Android Framework 的结构，代码量不小，而且涉及 AccessibilityNodeInfo、缓存深度、事件服务等偏底层的逻辑。
GKD 的上一次版本更新是 2025 年底，不过从 Git 记录来看，开发者至少两周前还为 GKD 升级了 Android 17 的支持。
图片来源：Github
说回 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 的审计评估，图片来源：雷科技
必须要说的是，在界面设计上，相比 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。
图片来源：Github
核心在于，今天的大模型竞争正在从「模型能力」转向「Agent 工作流」。Codex 是 OpenAI 自己做的，Claude Code 是 Anthropic 自己做的。它们最大的优势，其实不是「功能」，而在于模型团队和 Agent 工程团队的垂直整合。模型知道工具链需要什么，工具链也知道模型擅长什么。而这种协同，会越来越重要。
而 DeepSeek 现在的问题在于官方的 Agent 框架仍然缺位。DeepSeek-TUI 或许能够证明 DeepSeek V4 真正进入 coding agent 工作流后的巨大优势，但我们还是期待 DeepSeek 官方，到底什么时候亲自下场。
本文来自“雷科技”，36氪经授权发布。
