发布时间

使用 Arch Linux 一年后：从终端极简到浏览器优先工作流

一年前，Arch Linux 改变了我理解计算机的方式。最开始，这个故事是关于离开不透明的系统，转向一个我能理解、能控制的环境：每一个服务、快捷键和应用都应该有明确存在的理由。这个过程让我经历了窗口管理器、终端工具、dotfiles、AI 编码 agent，也最终形成了我在我在 2025 年的三次重大变化中总结过的思想：用更少的东西、更统一的逻辑，去控制整个系统。

这段旅程背后的真实配置，都放在我的 arch-config 仓库里。这篇文章不只是一次想法上的回顾，也是在总结这个真实运行了一年的 Arch Linux 配置项目，在日常使用中发生了什么变化。

现在，工作流又变了。

有意思的是，这次变化并不是离开 Arch Linux，而是继续沿着同一个方向深入。我仍然想要一个简单、键盘友好、可控制的系统。但在近一年的日常使用之后，我意识到：现在我工作的中心，已经不再是终端，也不再是窗口管理器，而是浏览器。

回顾：第一年真正改变了什么

使用 Arch Linux 的第一年，并不是一次单纯的系统迁移，而是一连串关于“控制感”的实验。

一开始，重点是操作系统本身。Arch Linux 给了我一个轻量的基础系统，让我能理解自己安装了什么、为什么它在运行、它又是如何被配置的。和 Windows 相比，最大的变化不只是性能或包管理，而是透明性。系统变成了一个我可以检查、可以塑造的对象。

随后，重点转向窗口管理。我尝试了不同的 Wayland 工作流，从 Hyprland、River，到 Niri 和 Sway。关于 Wayland 窗口管理器、Arch Linux 窗口管理器、Niri 和 Sway 的文章，本质上都来自同一个问题：窗口、工作区和屏幕，能不能遵循一套清晰逻辑，而不是变成一团视觉混乱？

与此同时，我也大量投入到终端优先的工具中。终端应用很吸引人，因为它们轻量、快速、可脚本化，并且对键盘用户友好。Neovim、OpenCode、shell 工具、Git 和 dotfiles 都符合这个模型。我的 Arch Linux dotfiles 也逐渐变成了把个人工作流代码化的一种方式。

这些选择背后的想法是一致的：一套操作逻辑应该尽可能控制更多计算机行为。我不希望每个应用都强迫我记住一套不同习惯。我想要更少的界面、更少的鼠标移动、更少隐藏状态，以及更可复用的肌肉记忆。

这个想法是对的。但它的实现方式也有成本。

终端优先并不能解决一切

当终端应用暴露出清晰的文本界面时，它们非常优秀。启动快、容易和脚本组合，通常也尊重键盘驱动的工作流。对开发者来说，这种体验很自然。

但终端应用也有一个现实问题：每个 CLI 应用都有自己的逻辑。

有的工具使用 Vim 风格导航，有的使用 Emacs 风格快捷键，还有的有完全自定义的按键模型。有些工具可以深度配置，有些工具只暴露少量选项。如果我想用同一套操作逻辑控制一切，就必须为每个应用单独做适配。

有时这种适配很简单。有些应用本来就支持 Vim keymap 或清晰配置文件。但更多时候并不是这样。时间久了，隐藏成本就会出现：我采用的终端工具越多，就越需要花时间让它们表现得一致。

这形成了一个矛盾。终端优先的工作流原本是为了减少复杂度，但为了在许多独立 CLI 应用之间维持统一控制，维护成本本身也会变复杂。

于是我开始问另一个问题：如果目标不是“使用终端”，而是“使用一套简单的控制逻辑”，那么终端一定是工作流的最佳中心吗？

今天我的答案是否定的。

浏览器变成了真正的工作台

现在，我的大部分工作其实已经发生在浏览器里。粗略来说，大约 80% 的日常工作依赖浏览器或 Web 技术栈应用。

这包括 AI agent 控制、文档阅读、搜索、写作、在 Bilibili 或 YouTube 看视频、听音乐、消息沟通，以及许多小型研究任务。即使底层工作是技术性的，最终面对的界面也经常是一个网页。

很长一段时间里，我把 Firefox 作为主力浏览器。但在日常使用中，我反复遇到兼容性阻塞：有些网站行为异常，有些功能明显假设 Chrome 行为，还有一些 Web 应用显然主要在 Chromium 系浏览器上测试。这些问题频繁到足以打断工作流，于是浏览器选择本身也变成了生产力问题。

所以我切换到了 Chrome。

这不是因为 Chrome 在理念上完美，而是因为浏览器现在已经是我的主要应用平台，而 Chrome 对我每天使用的 Web 技术栈来说阻力最小。如果大部分工作都发生在 Web 应用中，那么浏览器兼容性就不是一个小细节，而是基础设施。

重要的变化是：我不再把浏览器看成众多应用中的一个。我把它看成工作流的运行时。

Surfingkeys 让浏览器符合 Linux 哲学

如果把更多工作搬进浏览器，意味着退回到鼠标密集、GUI 密集的使用方式，那这就是倒退。那会违背我最初迁移到 Arch Linux 的原因。

让这次转变成立的关键工具，是 Surfingkeys。

Surfingkeys 给浏览器加上了一层键盘优先的控制系统。链接提示、标签切换、滚动、页面搜索，以及大量浏览器操作，都可以通过一致的键盘命令完成。与其在复杂 Web UI 中移动鼠标，我可以用一套熟悉的模态逻辑操作大部分网页应用。

这件事比表面上更重要。在旧工作流里，我需要在多个层级配置键盘行为：窗口管理器、终端模拟器、shell、CLI 应用、编辑器和浏览器。每一层都需要独立适配。

有了 Surfingkeys，很多交互都移动到同一层：浏览器。如果更多应用本身就是 Web 应用，而浏览器又拥有统一的键盘控制系统，那么我就不需要为每个终端应用或窗口管理器流程重复构建同样的控制逻辑。

这节省了时间。更重要的是，它减少了心智切换。

目标仍然和以前一样：更少、更统一的控制。变化只在于，浏览器成了最容易实现这个目标的地方。

Web 应用替代了旧工作流的一部分

最明显的例子是 AI agent 工作。

过去，我主要把 OpenCode 当作终端应用来使用。这很符合终端优先哲学：agent 离 Git 仓库、命令、测试和 shell 工具都很近。

但 agent 工作本身正在变化。在许多任务中，agent 已经占据超过一半的工作时间。当 agent 在规划、编辑、运行工具或等待审查时，人的角色不再是持续输入命令，而更像是监督、比较、批准和重定向。

对于这种工作方式，Web 界面有时比纯终端界面更合适。

现在，我使用 OpenCode export SDK 构建 ikanban 和 ipaper 这样的 Web 应用，把 agent 工作流重新包装成浏览器界面。底层仍然是 agent 通过工具链完成工作，但我通过 Web UI 来控制和观察它。

这让界面从“一个终端会话运行一个 agent”，变成了“一个浏览器工作区管理 agent 驱动的任务”。它更符合实际的职责划分：agent 执行长时间操作，而我在更高层界面中监督。

同样的模式也出现在编码之外。视频观看发生在 Bilibili 或 YouTube，音乐通过 Web 服务完成，消息和沟通也越来越集中在浏览器中。这些不再是孤立工具，而是同一个应用层的一部分。

结果是跨系统的可移植性。如果一个操作系统能运行现代浏览器和我依赖的 Web 技术栈，那么它就能运行我大部分工作流。

这对窗口管理器和工具意味着什么

这并不意味着窗口管理器不再重要。它仍然重要，只是角色变得更小、更清晰。

在早期 Arch Linux 阶段，我希望窗口管理器承担生产力系统中的很大一部分。工作区设计、快捷键、窗口移动、屏幕布局、应用启动，都是核心问题。

现在，窗口管理器更多是为浏览器和少数辅助应用提供一个稳定容器。我仍然关心键盘控制、多显示器行为和可预测布局。但我不再需要窗口管理器解决每一个交互问题。

终端应用也是一样。我仍然会在它最合适的地方使用终端：Git 操作、本地开发、调试、系统管理和直接命令执行。但我不再需要把每个日常活动都变成终端活动。

这是一个更实际的极简主义版本。极简不是强迫一切进入终端，而是移除不必要的界面差异。如果浏览器加 Surfingkeys 能为许多日常应用提供同一套控制层，那么它就比维护许多分散的终端界面更极简。

代价：对 Web 技术栈的依赖

这个工作流有一个明确缺点：它高度依赖 Web 技术栈。

并不是每个应用都有优秀的 Web 版本。一些性能密集型工作、图形工作、绘图工具、本地计算工具，以及特殊桌面应用，仍然更适合原生应用。在这些场景里，浏览器优先工作流是不够的。

还有一个更大的问题：Web 应用可能更重、更依赖网络，也更容易受到服务提供方控制。终端工作流通常带来更强的本地所有权；浏览器工作流则用一部分所有权，换取便利性、兼容性和跨系统一致性。

目前我接受这个权衡，因为我现在的工作很少依赖重型原生桌面应用。我的主要任务是写作、AI agent 监督、研究、沟通、观看、收听，以及基于 Web 的工具使用。对于这样的工作负载，浏览器优先模型已经足够好，而且经常更好。

关键是要诚实地承认边界。浏览器优先并不是普遍最优。它只是最适合我当前的工作分布。

结论：同一个哲学，新的中心

使用 Arch Linux 近一年后，我的工作流从终端优先的极简主义，转向了浏览器优先的统一控制。

乍看上去，这像是一种反转。但其实不是。更深层的原则没有变。我仍然想要透明系统、键盘优先操作、更少心智模型，以及能够围绕我的工作流塑造的工具，而不是被动适应工具。

改变的是重心。

第一阶段，Arch Linux 教会我通过窗口管理器、终端工具、dotfiles 和 configuration as code 来控制系统。新的阶段里，浏览器成了主要应用运行时，Surfingkeys 提供统一键盘层，Web 应用承载大部分日常工作流。

结果以一种意外方式变得更简单。我在窗口管理器和终端应用层面的配置变少了。我更依赖一个浏览器控制层。我用 Web UI 监督 agent、处理媒体、沟通和研究。由于工作流大多基于 Web 技术栈，只要浏览器环境可用，它也更容易跨系统迁移。

这就是使用 Arch Linux 一年后的最新体会：目标从来不是崇拜终端。目标是构建一个摩擦更少、控制更统一、能把更多时间留给真实工作的计算环境。

现在，浏览器正是这个环境最适合存在的地方。