构建 Terminal UI 让我抓狂

Source: Dev.to

我大部分职业生涯都在为浏览器构建东西。

如果有什么地方看起来不对，你会打开 DevTools。
如果间距不对，你会检查 DOM。
如果布局出问题，你会调试 CSS 直到它不再“喊叫”。

所以我自然以为构建终端 UI（TUI）会…类似。
结果并非如此！

这篇文章是我在公开构建名为 TurboStream 的项目时的记录——一个让你能够将高速 WebSocket 流（区块链、BGP、金融数据等）连接到 LLM，而不会耗尽 token 或让系统崩溃的开发者工具。

想象一下：

WebSocket → Cache → Triggers → LLM → Short human‑readable alerts.

后端是比较容易的部分。
终端 UI 差点把我逼疯。

来自浏览器世界的视角

在网页世界里

• Figma → HTML/CSS 大多是机械化的
• 布局是可视的
• 调试是交互式的

在 Bubble Tea（终端 UI）领域

• 布局是数学
• 填充是“氛围”
• “为什么这个盒子宽了两列？”是哲学问题

没有 DOM 检查器。
没有“悬停查看边界框”。
你改动一个 lipgloss.Style()，整个界面就会瞬间移动。

最难的屏幕：AI 分析

从概念上讲，这很简单：

• 显示 LLM 上下文大小
• 显示 token 使用情况
• 显示生成时间
• 流式输出文本

但实际情况是：

• 内容高度不断变化
• 宽度必须与兄弟面板保持对齐
• 滚动文本 + 边框 + 填充相互冲突

我总是得到：

• 文本被截断
• 面板超出 1 个字符
• 边框在不同终端宽度下错位

在一种尺寸下看起来还行，调节大小后就彻底崩溃。

如果你用过 Bubble Tea，你一定懂这种感觉：

“这应该能工作… 为什么不行？”

我迄今为止学到的东西

1. 停止用像素思考

终端布局关注约束，而不是视觉。所有东西都是 行 × 列。没有免费空间。

2. 明确测量每一个尺寸

如果你不自己计算宽度/高度，Bubble Tea 会让你大吃一惊。

3. 边框会欺骗

边框和填充也算在内。那“多出的一列”永远是你的错。

4. 调试 TUI 需要仪表化

我开始加入：

• 临时背景颜色
• 框内的宽度/高度标签
• 用假内容来压测布局

虽然看起来很丑，但确实有效。

接下来我会做的事

• 创建布局调试模式 – 可切换的覆盖层，显示组件边界和尺寸。
• 编写小型布局测试工具 – 每次只隔离一个视图，而不是在完整应用中调试。
• 标准化布局契约 – 每个面板声明它需要的尺寸，而不是“随便搞”。
• 接受 TUI UX ≠ Web UX – 不同的媒介，不同的规则。