Thomas Ptacek 八月底那篇《Stop Making TUIs》登上 Hacker News 热榜，评论区吵起了一场老仗：终端界面（TUI）到底该不该被淘汰。开发者 ckardaris 随后写了篇博客，专门反驳评论区里出现最多的一条理由——"TUI 应该被优先做，因为它是键盘驱动的"。他的态度很干脆：这条理由站不住脚，GNOME 人机界面指南早就写明，GUI 也该能靠键盘走完全部操作，做不到只是开发者没花心思。
这场争论表面看是 TUI 和 GUI 的审美站队，实际吵错了重点。键盘顺不顺手从来不是 TUI 真正的护城河。真正决定 TUI 能活多久的，是另外两件事：能不能被脚本或 AI agent 稳定驱动，以及键盘友好是不是等于无障碍达标。这两条，原帖和大部分评论区都没提。
表面在吵什么
Ptacek 原文的论点其实很窄：把 CLI 留给自动化、远程操作和脚本调用，别再因为"原生 GUI 难做"就顺手糊一个 TUI 出来，该用 AI agent 或 SwiftUI 这类原生框架做小而好的桌面应用。
HN 评论区把这条窄论点放大成了"TUI vs GUI"的路线站队，吵得最凶的是"键盘优先"这一条。ckardaris 的反驳很简单：键盘驱动不该是选 TUI 的理由，因为 GNOME 规范明确要求，凡是能用鼠标做的操作，也该能用键盘做到。他拿自己的应用 Klisi 举例，说这事不难，只是愿不愿意花时间。
GNOME 那句话，被读窄了一半
这里有个容易被忽略的细节。GNOME 规范实际拆成两层：一层是"每个操作都必须键盘可达"——用 Tab、方向键、Enter 就能走到任何功能；另一层是"常用操作才配专属快捷键"。ckardaris 引用的是第一层，但很多开发者把两层混成了一件事，误以为规范要求处处配快捷键。
这个误读的代价不小。开发者为了"证明"支持键盘，往往一头扎进给每个功能都配快捷键的过度设计，结果快捷键系统臃肿难记，反而偏离了指南本意——指南要的是可达，不是花活。
- 提醒.把"键盘可达"当成"处处要有快捷键"，是最常见的过度设计陷阱。
键盘优先不等于无障碍达标
TUI 天然键盘优先，对视觉正常、习惯命令行的用户是效率利器。但对屏幕阅读器用户、语音输入用户、记不住一串命令键的人，TUI 未必更友好——它没有语义结构可读，读屏软件很难知道当前焦点在哪、状态发生了什么变化。
合规的 GNOME GUI 通过 GtkAccessible、AT-SPI 暴露角色、名称、状态这些信息，理论上能给屏幕阅读器提供比 TUI 更完整的语义。W3C WCAG 的可操作性原则也只要求"键盘可达"，从没说过键盘友好就等于无障碍。这是决定"该不该为 GUI 键盘化砸资源"的关键变量，原帖完全没碰。
真正的裁判可能是 AI agent
HN 讨论里还有一条比键盘偏好更硬的反对意见：交互式 TUI 往往带着隐藏状态，很难被另一个程序或 AI agent 稳定驱动。让 agent 操作一个 curses 界面，它得解析屏幕缓冲区、猜测焦点在哪，极其脆弱。相比之下，裸 CLI 输出结构化文本，agent 调用起来简单可靠。
这就是为什么 HN 上更折中的架构方案是：核心逻辑做成 CLI，人要交互用 TUI 还是 GUI 都行，agent 只连 CLI，绕开界面。键盘驱动的意义在这套架构里被稀释了——它只解决"人怎么操作"，没解决"程序怎么调用"，而后者正在变得更重要。
- 结论.能否被 agent 稳定脚本化驱动，可能比是否键盘驱动更决定 TUI 能活多久。
该怎么判断
TUI 能不能活下去，不取决于键盘顺不顺手，取决于两件事：是否留了一层可脚本化的 CLI 核心，以及键盘友好是不是真的等价于可访问。GUI 要不要补键盘化的功课，取决于开发者愿不愿意像 Klisi 作者那样，把"可达"和"专属快捷键"分清楚，而不是喊一句"我们支持键盘"就算过关。
可行性从来不是GUI的短板，意愿才是。
这场争论最容易被跳过的一句话，恰恰藏在原帖的注脚里。键盘导航不是可行性问题，是意愿问题。可行性从来不是 GUI 的短板，意愿才是。真正决定这场路线之争胜负的，不是谁的界面更酷，是谁先把"人用什么界面"和"程序怎么调用"这两件事拆干净。