《So I stopped using Ghostty...》

来源：YouTube [Theo - t3․gg]
时长：00:23:21
视频ID：EUE8N6mqtGg
链接：https://www.youtube.com/watch?v=EUE8N6mqtGg
说明：以下文字按视频原讲述顺序整理，口语、重复和明显噪声已做轻度收束。

告别十年老友：为什么是时候换终端了

我明白，我知道那些 meme 早就传遍了——Theo 又在不停地换软件，但这次真的不一样。我用了差不多十年的同一款终端，直到发现 Ghosty 才从 Mac 原生终端迁过来。而真正让我下定决心的原因是，我意识到原生 Mac 终端根本不遵循标准，给终端 UI 的维护者带来了太多麻烦。Ghosty 确实太棒了——这也是为什么它刚发布时我就如此兴奋，也一直用到现在。它快、稳定、可靠、高度可定制，开源且维护得非常好，几乎满足了你对一个终端工具的所有期待。正因如此，我现在要离开它，才显得格外反常。

我的 Ghosty 配置堪称完美，我对自己目前的状态非常满意。它对 Tmux 支持得特别好，而我其实从十五岁起就开始用终端多路复用器了——最早是 GNU screen，之后就一直没断过。算下来，到今年三十一岁，我已经用终端多路复用器超过半辈子了。但最近我发现自己越来越频繁地创建新标签页，这让我开始反思：我的工作结构其实并不适合用传统终端多路复用器的方式来组织。我的任务分支越来越多，上下浮动频繁，处理并行任务的方式也越来越复杂。试图把所有这些工作塞进不同的窗口、标签页和面板里，简直让人抓狂。

于是，我做了一个实验：强制自己几周不使用 Tmux。结果我不仅更清楚地认识到了自己的工作流，还差点精神崩溃。就在这个阶段，我发现了新的终端工具——CMUX。没错，不是我做的。CMUX 是基于 LibGhosty 构建的，而 LibGhosty 正是支撑 Ghosty 的核心库。它真的很厉害。我一直关注 Maniflow 团队，因为我和 Laurence 很熟，他们之前的表现也让我印象深刻。但 CMUX 完全重塑了我对终端的认知。而且，它的上手门槛其实并不高。虽然它远非完美，但那些它真正做好的地方，已经彻底改变了我并行处理任务的方式。现在，我同时处理的事情比以往任何时候都多，而如果没有这样的工具，几乎是不可能做到的。

但我同时也觉得，有人完全可以在此基础上做得更好——远远超越现在的水平。我想聊聊我遇到的问题，CMUX 如何解决它们，以及它又带来了哪些新挑战。更重要的是，我想探讨这一切未来会走向何方，也许我们还能把其中最精华的部分，融入到 T3 代码中去。顺便说明一下，作为团队的粉丝，我在他们还没宣布要开发 Seamox 之前就投资了 Maniflow。甚至项目当时可能都还没启动。但现在这家公司只做免费的开源软件，我可不想让自己的投资全部打水漂。所以，我们得稍微赚点钱了。因此，今天先来个简短的赞助插播。

你的 AWS 账单现在怎么样？大、小，还是靠创业加速器给的额度撑着？不管怎样，大概率都比该有的高，除非你已经用了今天的赞助商。Milkstraw 来帮你降低 AWS 成本。他们能帮你节省最高达 50% 的费用，而且只按节省金额的 20% 收费。没错，如果他们没帮你省钱，你一分钱都不用付。只要省了钱，你也不用付太多。即便如此，账单也会大幅下降。另外，如果你还在使用创业加速器提供的信用额度，完全免费，直到你不再依赖为止。他们本可以趁机牟利，却选择了不这么做，我非常尊重这种选择。

我干了一件可能不该做的事——上传了我们真实的 AWS 账单。坦白说，大部分开销都是用于上传，也就是 S3，这部分成本很难削减。但即便如此，他们还是帮我找到了一千美元的节省空间，来自其他服务。如果你的账单里 S3 不占九成，那很可能有 30% 以上的节省空间。这真是一笔超值交易。他们不需要你授权访问整个 AWS 账户，只需要一个账单链接就行。他们不会接管你的账户，只是告诉你哪里可以省钱。光是他们的仪表盘就够值回票价了——我开玩笑地说，光是想从 AWS 导出一份 PDF，我就花了十分钟。这绝对值得。

你的 AWS 成本肯定偏高。现在就去修复吧，访问 soydev.link slash milk straw。

CMUX初体验：重构我的工作流

那么，我为什么又要换终端？这要回到我不久前发的一段视频，讲的是我写的一篇文章，关于“代理式编程”（agentic coding）的问题。我尽力描述了当前工作方式如何被拆散，以及它如何正在撕裂我的大脑：一个终端，带标签或面板。一个 IDE 写代码。一个浏览器看本地运行、GitHub 提交……这些不同应用之间来回切换，管理起来太费神。

现在我要说一句可能有点争议的话——我的朋友在 Manifloat 应该不会喜欢。我唯一喜欢 CMUX 的地方，是它把终端这一侧整合得非常好。我只喜欢它在这里的整合效果。至于浏览器部分，他们也尝试解决，但我非常反感那种做法。稍后我会具体展示原因。

之前我的终端在不同项目之间来回切换，处理各种任务时简直一团糟：一边开着开发服务器，一边挂着 Git 标签页，再加个 Claude Code 或 Codex，体验非常糟糕。让我来展示一下我现在如何使用 CMux。这是我在直播前实际运行的 CMux 实例，没有任何隐藏或关闭的窗口，就是我今天早些时候正在做的状态。这里是我 T3 代码的项目，四个标签页中分成了两半。它依然保留了你对 Ghostty 期望的所有快捷键，比如按 Command + D 会像这样均分成 50-50 的布局。

但真正有趣的地方在于，每个分割区域内部都可以打开新的标签页，而且这些标签页只存在于当前这个分区里。你可以通过侧边栏在不同内容间切换，还能重命名它们。我来把其中一个叫“T3 code 1”，另一个改成“T3 code active”吧。你还会注意到，它和 Claude Code 的集成做得相当不错——这挺有意思，因为就连 Claude Code 自己都没法很好地集成自己。

当我运行 Claude Code 命令时，现在它能识别出这是一个 Claude Code 终端。如果我输入类似“这个项目是什么情况？”这样的问题，然后跳去别的地方，它会告诉我 Claude 当前的状态。看起来好像有点小问题，提示说“Claude 正在等待输入”，但实际上我已经给了输入。可能是之前某个操作导致状态异常了。不过没关系，我先把所有这些都关掉，换另一个试试。我这就做个演示，问你两个简单问题。我离开一下，看看效果如何。

结果正如预期，终端应该会在提问完成后给我一个通知。但 Claude Code 没有使用提问工具，本应是多选题形式，还应该调用工具来问我。我们看看会怎样。目前看来，Claude Code 的集成似乎出了点问题。真可惜，Claude Code 是闭源的，否则这类集成会容易得多。Anthropic 要求我们用 Claude Code 构建这么多东西，却不愿意修复它，也不提供足够的能力让我们基于它进行扩展，这真的很奇怪。

好了，你看，那个小通知出现了，提醒我这里有需要回应的内容：回答问题、提交、跳转到其他地方。等完成后，它还应该再发一次通知告诉我已经完成。很好，但这并不是我用它的主要目的。我真正喜欢的是它帮我组织工作的方式。

我这里有个沙盒目录，之前没命名，现在补上。我的“沙盒”就是存放所有零散小项目的文件夹，随时可以快速启动，试一些新想法。当你频繁使用这些工具时，有一个沙盒目录真的特别方便。我还开了另一个 T3 代码项目，可能其实没必要。另外还有一个 Open Code 项目，因为我最近在折腾代码库，说不定将来要整合进什么功能里。我可以给它重新命名，让标识更清晰。

你还可以固定标签。我刚刚就把 T3 代码工作区固定到了顶部，因为我经常用。还有我之前为 Skatebench 做性能测试的基准数据，以及另一个 T3 代码 + Claude Code 的组合，那是我做 UI 相关工作的地方。我个人仍然觉得 Claude 模型在处理 UI 类任务时表现最佳。经常会出现这种情况：我在 T3 代码里用 Codex，又在终端里用 Claude Code，然后在同一个项目里来回切换。

最棒的是，我可以把项目排列方式和我在 T3 代码里的结构保持一致。比如这里有两个 T3 代码项目，但我的沙盒没有放进来，因为我一般不用 Codex 来管理它。我也有一阵子没碰过 Around 项目了，但如果我要开始做了，也可以直接打开并拖进去。在不同应用之间切换、查看每个项目的进展，变得非常轻松。

如果你希望根据当前关注的内容来组织界面，这种方式也非常合适。我经常在终端里做云编码时，会在这个面板里再开一个新标签页，用来启动我的开发服务器，比如 bun run dev desktop。我不需要一直盯着它看，但它就在同一空间里，一眼就能看到，又不占额外位置。这种感觉虽然细微，却很重要。

理想与现实：CMUX的局限与未来的想象

整个层级关系是这样的：T3 代码对应当前所在的文件夹。这个面板里有 Claude Code，背后是 bun run 命令。另一边则是我的 Git 终端，专门处理所有临时的 Git 操作。我刚想把改动暂存一下，于是执行 git stash，接着 git checkout main，git pull，肯定有不少变动。果然，我一运行就发现构建失败了，这在意料之中。于是我跳转过去，取消之前的命令，清空缓存，运行 bun install，再跑 bun run dev desktop，现在服务又正常起来了。

我的整体工作环境大致就是这样，符合我理想中的样子。当然，现在有点挤，因为我直播时用了 720p 分辨率的显示器。平时工作时我缩得更远，视野更开阔，用起来也舒服。但即便如此，现在这个布局也还算可用。如果想腾出更多空间，我也可以直接关闭侧边栏。

这里还藏着不少贴心的小功能。当你按住 Command 键时，所有项目都会显示对应的快捷键，方便快速切换。比如我想切到 sandbox 项目，用 Command + 2。打开 Code 则是 Command + 3，这样在不同任务间跳转非常顺手。而切换标签页时，只需按住 Control 键，就能像这样轻松切换。这体验真的很棒。

现在我的工作流已经拆分成多个并行任务，尤其跨项目操作频繁，因此一个能清晰展示当前项目列表的侧边栏，配合每个项目内的窗口管理，就显得格外重要。这套方案对我而言一直很有效。当然，它也不是完美无缺。这也是我为什么想做这个视频的原因——我看到了所有人共同改进的机会。事实上，不只是我这么觉得，Ghostty 的作者 Mitchell 本人也公开表达过类似观点。看到这么多基于 LibGhosty 的项目不断涌现，实在令人兴奋，仅昨天就在 Hacker News 上出现了两个。从一开始，Ghostty 这个应用就明确被定位为 LibGhosty 的“高级技术演示”，这才是 Mitchell 真正希望实现的目标：让 LibGhosty 成为一个生态，催生出一系列专注于特定目标和理念的终端相关工具。而如今，这一切正在发生。他本人也对目前的 GUI 管理界面表示不满，我能理解——我过去也用过不少这类应用，大多数都难堪大用。最近一周我强迫自己尝试了几款 GUI 代理工具，虽然经验还不足，但我认为它们至今都没真正抓住重点。我甚至一度强烈想按自己的审美去打造一个，但最终还是忍住了。我必须时刻提醒自己：要充分理解他遇到的问题，才能确保我们用 T3 Code 做出真正合适的东西。我非常期待能有机会构建他梦想中的那个应用，毕竟他已经为我实现了太多。

CMux 已经让我初尝了这种可能性。那我现在的问题又是什么？你可能已经注意到其中一个了——一个蠢得离谱的 bug，我相信迟早会被修复。但奇怪的是，我的状态栏在 Zish 默认主题下会重复显示。更搞笑的是，每次清空后，都会多出一行空白。好吧，让我们试试在空行上按回车——完全不知道这是什么情况，只能接受现实：我的终端里状态行开始堆叠，简直要命。虽然我知道他们迟早会修，但现在确实挺烦人的。还有一个内置浏览器，理论上未来或许有潜力，但目前只让人抓狂。它看起来像是一个来自 Safari 的网页视图，却连我的登录凭证、cookies 都没有，也不支持扩展插件，没法用 OnePassword 这类工具自动登录。默认情况下点击链接就会触发它，直接破坏了我每天几十次的开发流程。比如我本地有个分支，想提交 PR，通常会先运行 lg 打开 LazyGit，按数字 3，再按字母 O，就能跳转到创建 PR 的页面。这种操作每天重复无数次，但在 CMux 里，每次都会在应用内新开一个标签页，每次都让我火大。我不得不复制链接，然后跑去设置里找关闭选项，结果总是忘了改，最后干脆放弃，查了半天才找到「在 CMux 浏览器中打开终端链接」这个开关，一发现立刻关掉，真是恨得牙痒。不过这些都不是阻止我继续使用的理由。它依然远胜于我过去用过的任何方案，只是我想要更多。

也许听起来有点自私甚至疯狂，但请听我说完。当我要同时处理多个项目、且每个项目都有独立文件夹时，这种架构特别高效，尤其是当我没打算用 Claude Code 时——我不想浪费全部的内存和 CPU 资源。而现在的 setup 正好满足需求：我可以在同一界面里维护整个开发环境和所有项目的 Git 终端，一旦需要快速启动 Claude Code 或 Gemini CLI 来处理某个 UI 操作（在 Codex 里无法完成的），也能迅速搞定。这种体验很棒，但我还想走得更远。我希望这个系统可以无限嵌套。我希望能在其中建立多个独立区域，真正实现模块化。我也试过用 vibe coding 的方式来实现，但没花太多精力，所以没成功。我还希望支持无限滚动——顺便给 Brody 打个招呼，我直接用了他视频里的一个片段，懒得自己录了。

最近我沉迷于 Neary。需要说明的是，Neary 并不是传统意义上的平铺窗口管理器。平铺窗口管理器的特点是，新建窗口会挤占原有空间。比如我按 Command + Shift + D，会把当前终端垂直分屏，这很好，但一旦使用起来，空间就变得太小，根本看不清内容。我曾长期使用 i3 这类工具，大约在 2015 到 2016 年那段时期，我对这些工具投入过大量时间。可事实是，它们根本不适合真实的工作场景。如果你的生活就是终端，而且不关心窗口大小，那或许没问题，但对我来说，它们并不合胃口。经过多年的实践，我终于彻底放弃了。但自从接触 Neary 后，我彻底爱上了它。看看 Brody 如何打开新终端并灵活移动它们。你可以随时缩放视野，虽然我很少这么做。关键是，新终端不会侵占旧窗口的空间，而是作为新的面板出现在旁边，你可以……。

虽然我用的是 Neary，但我会告诉你原因。当你打开新终端时，它们不会挤占旧窗口的空间，而是以新的窗格形式出现在旁边，你可以自由地左右滑动、移动这些窗格。这种操作方式被称为“Peek 窗口管理器”，因为每个窗格都是一个独立的实体，拥有自己的尺寸。当你移动它们时，并不是在改变其他窗口的大小——每个窗口都保持其自身的大小，你只是在“窥视”其中，来决定自己想聚焦在哪一部分。

这些就是你机器上当前打开的窗口：比如这个是终端，那是浏览器，这个是编辑器。在传统的平铺式窗口管理器中，如果我在某个位置打开终端，它会把当前区域一分为二，然后以屏幕一半的宽度显示终端。而这就是我喜欢 Neary 的原因——它完全不这么运作。Neary 的工作方式是，你有一个主窗口，也就是你观察和操作的视角，然后你只需移动这个窗口本身。我可以向右移动，看到浏览器和编辑器的一半。也可以继续往右，只看到编辑器。甚至可以设置编辑器占据窗口三分之二的宽度，这样既能看到编辑器，也能瞥见浏览器的边缘。当鼠标悬停在浏览器上时，窗口会自动切换焦点到浏览器。悬停在编辑器上，则又切回来。这种体验非常神奇，因为你可以在任意方向打开更多窗口，却不会感到拥挤，因为 Neary 不仅支持横向布局，也支持纵向布局。你可以上下移动这个窗口，也可以相对上方的窗口左右滑动，比如我把这个移到这里或那里。整个导航过程极其流畅自然。

当然，有些人可能完全无法适应这种方式。我也听很多人说，迁移到 Neary 会有巨大的学习成本。诚然，我还没彻底切换过去，因为我 Mac 上还有太多事情要处理，没时间真正换设备。但说实话，这种工作流一上手就让我立刻理解了它的魅力。从那以后，我一直试图复刻那种极致顺畅的感觉。现在我意识到，其实我们完全可以把这种体验内化到一个应用里。想象一下，如果 CMUX 就是这样的结构：每一个区域都是一个独立的窗口组合。在任何一个区域内，我都可以左右滑动切换终端，也可以垂直切换不同任务，针对特定项目进行操作。如果能在应用内部通过三指滑动或两指加快捷键的方式实现左右切换终端，新建终端时自动偏移，还能向下扩展，同时保留更高层级的项目管理功能，像侧边栏标签一样组织任务，那会有多棒？一旦想到这个可能性，我就再也停不下来了。

再进一步设想：如果这些窗口不再局限于终端，而是整合了 Chrome，而且不只是个 Chromium 外壳，而是真正接入你现有的 Chrome 配置——包括书签、扩展、密码、Cookie 等全部数据呢？想象一下，把 T3 的代码直接作为一块面板嵌入进来。在这个任务中，左边选择项目，右边就可以打开一个 T3 终端——但它不再是传统意义上的终端，而是一个更优的 UI 层面，无需命令行就能直观展示你的工作内容。我可以渲染出真实的网页页面，也可以呈现 VS Code 的编辑界面。这样的 UI 能做的事情太多了。

正是 CMUX 让我突然意识到：未来开发工作的核心，或许真的可以是一个统一的应用。但我们需要的是符合大脑思维模式的任务层级结构。另一点我越来越清楚的是：你们当中有一半人会觉得我疯了，觉得这根本讲不通。另一半人则会惊呼：“天啊，这本来就应该这样！” 这也正是我如此期待未来工具发展的原因。一方面，CMUX 必须存在，因为 AI 已经改变了我们的构建方式，平行工作变得更合理。另一方面，这种构想之所以能实现，恰恰是因为 AI 让两个人的小团队也能在业余时间完成这类复杂项目。

问题是：为什么 macOS Spaces 没有做到同样的事？它们其实是我要的方案的反面。坦白说，就像 Igor 说的那样，它们有点烂。它们在很多地方根本就崩坏得毫无道理，所以我现在已经彻底放弃使用它们了。我目前只保留一个空间。比如在应用之间切换时，系统经常出问题——我按 Command+Tab，结果跳回了另一个工作区，接着又跳回来，来回折腾。我无数次想重新分组某些应用，却发现工作区根本不支持这种灵活调整。我也曾多次花时间去寻找某个应用的哪个窗口里开了什么内容，结果发现新开的窗口位置不对，不得不手动在 macOS 中来回穿梭调整。我喜欢那种说法：它们该隔离的地方没隔离，不该隔离的地方却强行隔离。总之，它根本不好用。对普通用户来说也许还行，他们只想开三四个程序，能接受那些慢得离谱的动画切换（每次切换可能长达半秒），但对于追求效率的人来说，这简直是灾难。

你根本不会在该隔离的地方隔离，反而在不该隔离的地方过度隔离，这根本行不通。它对那些只想同时打开三四个窗口、能忍受极其缓慢动画切换的普通用户来说还算凑合——但切换工作区的延迟可能高达半秒，简直难以忍受。太慢了，真的太慢了。我根本没法用，而你在 Mac 上甚至无法调低动画速度，只能彻底关闭动画，结果只是略微提升一点响应速度，换来的是难看至极的淡入淡出效果，糟糕透顶，简直要命。

如果苹果能让这些功能真正可用，我倒愿意给他们点掌声，可现实是它们根本不行。现在我试过 Seamux 之后，见识到了这种操作可以有多快、多流畅，我甚至开始讨厌用我的 Mac 了。Seamux 几乎让我崩溃，但也正是它让我看到希望：我们其实可以在应用层面实现这样的体验，而不必非要依赖操作系统级别的改造。我拼命不想自己去造一个 Mac 的窗口管理器，更别提整个操作系统了。但 Seamux 告诉我，这条路是存在的。

它还让我意识到，做一个终端其实也可以非常顺手。这就是我每天都在用的终端。所有窗口都集中在这里，我的 Ghosty 实例已经连续好几天没开了，因为根本不用了。我现在用 Seamux 当日常主力终端，真不敢相信自己竟然离开了 Ghosty。尽管如此，我认为我们仍处在这一变革的早期阶段。并行处理多个任务的概念对软件来说依然很新，大多数工具都不太适应这种高强度的并行工作模式。VS Code 不行，Seamux 也不行，Hyperland 或 macOS 也都一样——我之前用的所有工具，都没感觉像是为这种重度并行工作设计的。

但我相信，我们终于开始往前走了。就像技术发展有代际之分：在 AWS 之前有主机托管，在 Vercel 之前又有别的方案。如果你在 Vercel 之后还做一套像 AWS 那样老派的方案，那看起来会显得很滑稽。而现在的状态不是“当前技术的优秀版本”，更像是“下一代技术的粗糙拼接版”——而这恰恰让我无比兴奋。当我第一次用上 Seamux，尝到了未来的味道，那种感觉我再也回不去了。

我希望你们中的很多人也能感受到同样的冲击。我也祈祷有人能因此出发，去打造属于自己的类似工具或解决方案，让我们一起探索未来开发工具究竟会是什么样子。说实话，我也不知道答案。我不知道几个月后我会怎么写代码，因为我们还在摸索如何组织现代开发中的混乱局面。但我非常期待看到别人会做出什么。

在这期间，我无比期待继续使用 Seamux。是的，我已经从 Ghosty 转向 Seamux。是的，任何做大量代理类工作的 Mac 用户都应该试试 Seamux。虽然我是投资者，但我不确定一个月后还会不会用它，两周后会不会还在用，甚至不确定自己会不会亲手做出更好的方案，或者别人会做到更好，又或者 Seamux 本身就会变成我一切所需，甚至更多——我现在真的毫无头绪。

我唯一确定的是：它让我的工作组织变得容易多了。当它和 T3 Code 结合使用时，把不同任务模块化、分区域管理的感觉实在太棒了。可一旦我打开 VS Code，一切又瞬间崩塌。大概就这些了。

感谢 Maniflo 团队打造出这个项目，并将其开源。这是一个真正酷到不行的项目，我由衷地期待它接下来的发展。也请告诉我你们的感受，更希望你们开始动手打造自己的同类工具。未来正在被今天的人们构建，而我还不知道它到底长什么样。但我迫不及待想看看你们会创造出什么。下期见，各位，peace nerds。

本文由 AI 基于转写整理，仅供复查参考。