一个你一定经历过的场景

你给 Agent 一个需求：「帮我加个用户认证模块」。

然后你泡了杯咖啡回来，发现它已经写了 800 行代码——但用的是你项目里根本没有的 JWT 库，认证逻辑跑在错误的中间件层，而且完全跳过了你上周刚定的 session 过期策略。你问它为什么不用项目里已有的认证中间件，它振振有词地解释了一通"JWT 的优势"，好像它才是这个项目的架构师。

这不是模型蠢。模型聪明得很。问题在于：它太急着动手了。 在它看来，写代码就是它的使命，而你那句模糊的需求指令，它选择用自己最擅长的方式去"填补空白"——用代码。至于你的真实意图、项目的技术栈约束、已有的代码规范，这些都是它主动跳过的"障碍物"。

或者另一个场景：你让它重构一个有 47 个文件的服务层。它改了 15 个文件就告诉你「已完成」，剩下的要么忘了，要么上下文窗口溢出，改到一半就开始编造已经不存在的函数签名。你打开代码一看，新调用的方法在旧文件里根本没有定义，而旧文件里被删除的方法还有三个地方在引用。整个项目跑不起来了。

这两种失败，看起来都是"Agent 不够好"。但实际上，它们指向的是完全不同的两个问题。

第一种——急着写代码——是纪律问题。模型有能力做对，但它没有足够的约束去保证每次都做对。

第二种——一个 Agent 干不完——是产能问题。单个 Agent 的上下文窗口和并行能力有物理上限，任务超过这个上限，再守纪律也没用。

这两个痛点，恰好是今天 AI 编程领域最值得关注的两套解法各自瞄准的靶心。一个叫 Superpowers，一个叫 OMO。

而你可能正打算把两个都装上——千万别。

Superpowers：给 Agent 立规矩

先说清楚一个背景。Superpowers 的作者是 Jesse Vincent——RT（Request Tracker）的创始人，现在运营 Prime Radiant 公司。这是一个写过大型工程软件、吃过流程管理苦头的人。GitHub 上 obra/superpowers 已经攒了 236K+ stars，MIT 协议，完全开源。

它的核心思路一句话就能说清：Agent 不是不够聪明，是太自由了。

Superpowers 做的事情，是通过一种叫 SKILL.md 的文件，给 Agent 注入强制性的行为约束。不是建议，不是提示词技巧，是约束——Agent 每次响应之前，都会自动检查有没有匹配的 Skill，有就必须执行，不可跳过。

它的标准流程是四个字：先想后做。

具体来说，Agent 收到你的需求后，不会直接写代码，而是走这样一条路：

1. Brainstorm：先跟你讨论方案，澄清模糊需求
2. Git Worktree：拉一个隔离的工作分支，不碰你的主干
3. Plan：输出结构化执行计划
4. TDD Execute：测试驱动开发，写一个测试跑一个测试

注意，这不是 Agent 的"建议流程"，而是 Skill 文件强制规定的。你见过那种「让 Agent 先做计划再做」的 prompt 技巧吧？Superpowers 的区别在于，它是硬编码到执行循环里的，Agent 绕不过去。

2025 年 4 月，OpenAI 发布 Codex CLI。社区的排名毫不留情——“Cursor > Claude Code > Codex CLI”。

十一个月后，2026 年 3 月，Codex 周活用户突破 200 万，增长 5 倍（Reuters, 2026-03-10）。开发者社区最热的讨论不再是"选哪个"，而是"怎么搭配着用"。

一个产品从"差远了"到"重新定义赛道"，中间到底发生了什么？答案比你想的要简单，也比你以为的要深刻。

从"追赶者"到"重新定义者"

低谷：5% 的使用量

Codex CLI 发布的时机其实不差——2025 年 4 月 16 日，与 o3、o4-mini 模型同期亮相（TechCrunch, 2025-04-16）。开源、免费、运行在终端里。但发布后的反馈泼了一盆冷水：Zack Proser 的评测记录了 40%-60% 的一次成功率（Zack Proser, 2025-05-18）；Reddit 上的排名直接把它排在第三位（r/ChatGPTCoding, 2025-04）；2025 年 8 月，Check Point Research 发现了一个关键安全漏洞 CVE-2025-61260，恶意 .env 文件可以在开发者机器上静默执行任意命令（Check Point Research, 2025-08-07）。

到 2025 年 9 月，Codex 的使用量大约只有 Claude Code 的 5%（WIRED, 2026-03-11）。Medium 上一篇评测的标题直白得刺眼：“So, OpenAI’s Codex CLI is Claude Code, but worse?”

本文面向关注 AI 编程工具的开发者，以「思路驱动」的方式分析 DeepSeek-TUI——不教你安装，而是帮你理解它为什么这样设计、什么场景值得用、边界在哪里。

一、引言：为什么你需要关注 DeepSeek-TUI

2026 年 5 月，一个名为 DeepSeek-TUI 的项目在 GitHub 上突破 26,000 Stars，单日增速从 8.7K 跳涨至 16.3K。它不是 DeepSeek 官方产品——作者 Hunter Bown 在 README 中明确写着 “Not affiliated with DeepSeek Inc."——但它做了一件事：把 DeepSeek V4 模型塞进了一个 Rust 原生的终端 Agent 里，成本仅为 Claude Code 的 1/10 到 1/17。

这件事的意义不在于「又一个 AI 编程工具」，而在于它验证了一个假设：当底层模型能力足够强时，Agent 外壳本身可以成为差异化的主战场。 Claude Code 的护城河是 Anthropic 的模型 + 成熟的 Agent 工程；DeepSeek-TUI 的护城河是一套围绕低成本、长上下文、子代理并行而设计的架构选择。

如果你正在选择自己的 AI 编程工具栈，或者好奇终端 Agent 这个品类接下来会怎么演化，这篇报告会帮你建立判断框架。

需要提前说明的是，本文基于 40+ 信源的综合分析（涵盖 Reddit、36氪、YouTube、英文科技媒体、GitHub 仓库数据等），所有事实性陈述可追溯至原始信源。但在几个关键问题上（比如 DeepSeek V4 的绝对编码能力排名、1M 上下文的真实检索效率），不同信源给出了矛盾的说法，目前的证据不足以做出单一结论。遇到这类情况，我会明确标注推断性质，而不是给出一个似是而非的确定结论。