你整天都在终端里工作。你用 vim 快捷键浏览文件，用前缀键切换 tmux 面板，用 Ctrl-R 搜索命令历史。然后你需要分拣积压工作，而市面上所有项目管理工具都想让你去够鼠标。

Jira 需要点击打开一个 issue。再点击关闭面板。再点击切换项目。Linear 更快一些，但本质上仍然是鼠标优先：你指向，你点击，你滚动。GitHub Issues 每打开一个 issue 都需要完整的页面加载。这些工具是为在浏览器中工作的产品经理设计的，而不是为在终端中工作的开发者。

每次操作的摩擦很小，但一天累积下来就很可观。如果你一上午要分拣 30 个 issue，那就是 30 次够鼠标-点击-阅读-关闭的循环。你的双手离开键盘 60 次，而本该只是顺序扫描一个列表。

我们为认为这很荒谬的开发者构建了 Beadbox。

完整的键盘分拣工作流

Beadbox 是一个原生桌面应用（基于 Tauri 构建，不是 Electron），为 beads issue 追踪器提供实时可视化仪表盘。它展示 epic 树、依赖标记、状态筛选器和进度条。而且你可以完全不碰鼠标就完成所有导航。

分拣会话是这样的：

打开 Beadbox。 你最近的工作区自动加载。issue 以表格形式呈现，带有状态标记、优先级指示器和负责人列。
按 j 向下移动列表。 按 k 向上。这些是 vim 风格的操作，你已经有的肌肉记忆。选中高亮跟随你的位置。
按 Enter 打开详情面板。 选中的 issue 展开为侧面板，显示完整描述、评论、依赖关系和元数据。你可以在不丢失列表位置的情况下阅读。
按 Escape 关闭面板。 你回到列表，光标正好在你离开的位置。按 j 移动到下一个 issue。
按 / 搜索。 出现搜索栏。输入关键词或 issue ID，列表即时过滤。按 Escape 清除搜索，返回完整列表。
用方向键操作 epic 树。 当你查看带有嵌套子项的 epic 时，左右方向键折叠和展开树节点。h 和 l 也可以（vim 风格水平导航）。你可以浏览一个 15 条 issue 的 epic 而不需要点击任何展开三角形。

就这些。j/k 移动，Enter 打开，Escape 关闭，/ 搜索，方向键展开树。五个键覆盖了 90% 的分拣导航。

如果你在分拣过程中发现某个 issue 需要更改状态或提升优先级，切换到终端：

bd update bb-f8o --status in_progress --priority 1

Beadbox 在毫秒级捕捉变更（通过文件系统监听和 WebSocket）并重新渲染。你无需刷新或点击任何东西就能看到更新后的状态标记。然后按 j 继续移动。

读写分离是有意为之的

这是大多数 GUI 工具搞错的地方。它们试图处理所有事情：阅读 issue、编辑字段、更改状态、管理依赖。结果就是表单。大量的表单。状态的下拉菜单。描述的文本输入。依赖管理的模态对话框。每一次交互都需要点击。

Beadbox 采用了不同的方案。它是一个读取为主的界面。CLI 负责写入。

beads CLI（bd）本身就是 issue 数据的权威来源。agent 使用它。脚本使用它。你的自动化流程使用它。通过 GUI 构建第二条写入路径会产生同步问题，并使 bug 的发生面翻倍。

取而代之，Beadbox 全力优化理解和导航。它回答终端最不擅长的问题：完整的 epic 树是什么样的？哪些 issue 被阻塞了，被什么阻塞？这个功能进展到哪了？过去一小时有什么变化？这些是视觉问题。bd list 的纯文本输出在技术上可以回答它们，但一棵可折叠的树加上进度条可以让你一眼就得到答案。

键盘快捷键的存在就是为了让这一眼更快。你扫视、你阅读、你理解。当你需要行动时，你输入一个 bd 命令。两个工具，各做各最擅长的事。

切换工作区不丢失上下文

如果你同时在多个项目上工作，每个项目有自己的 beads 数据库，工作区切换就成了日常摩擦点。在大多数项目管理工具中，切换项目意味着跳转到不同的 URL、登录不同的工作区或打开新的浏览器标签。你的筛选条件重置了。你的滚动位置重置了。你在前一个项目中的思维上下文丢失了。

Beadbox 的处理方式不同。header 中有一个下拉菜单，列出所有检测到的工作区。点击它（或用键盘导航到它），选择另一个项目，整个视图从该项目的数据库重新加载。关键细节：筛选条件和滚动位置按工作区保存。当你切回来时，一切都在你离开的地方。

检测是自动的。Beadbox 扫描 ~/.beads/registry.json 中注册的工作区，并发现包含 .beads/ 数据库的目录。添加一个新项目，在其中运行 bd init，下次打开 Beadbox 时它就出现在下拉菜单中。不需要导入、不需要配置界面、不需要"添加工作区"向导。

对于维护多个服务或跨多个仓库管理 agent 的开发者来说，这让 Beadbox 成为所有活跃工作的统一视图。替代方案是多个终端窗口，每个窗口对着不同的 --db 路径运行 bd list，然后在脑子里记住哪个窗口对应哪个项目。

竞品对比

每个主流项目管理工具在基本导航时都需要鼠标操作：

Jira 有键盘快捷键（j/k 是存在的），但它们在列表视图中导航时仍然需要点击才能打开详情、点击才能切换项目、点击才能穿过层层嵌套的菜单管理 epic。快捷键感觉是后加的而非基础设计。

Linear 是 SaaS 工具中最接近键盘友好的。它有 Cmd+K 命令面板和一些导航快捷键。但工作区切换仍然需要点击侧边栏菜单，而且命令面板是搜索优先的交互模式，不是扫描优先。你需要知道你在找什么。分拣是关于扫描你还不知道的东西。

GitHub Issues 没有有意义的键盘导航用于分拣。你点击一个 issue 打开它（完整页面加载），点击返回按钮回来，如此重复。在仓库之间切换就是换个 URL。没有键盘驱动的积压扫描。

Beadbox 从一开始就围绕键盘分拣设计。快捷键不是在鼠标优先 UI 之上叠加的事后补充。整个导航模型假设你的双手留在键盘上。鼠标也能用（所有东西都可以点击），但它是备选方案，不是主要交互方式。

你真正在比较的是什么

真正的区别不在于"哪个工具有更多键盘快捷键"，而在于交互模型。

鼠标优先的工具优化的是可发现性。每个操作都有一个可见的按钮。这对引导和非技术用户发现功能来说很好。但一旦你知道自己在做什么，对速度来说就很糟糕。

键盘优先的工具优化的是吞吐量。一旦你学会了 j/k/Enter/Escape，你就能以阅读的速度分拣，而不是以指向的速度。代价是更陡峭的初始学习曲线（你需要知道快捷键的存在）。对于已经在编辑器和终端中使用 vim 快捷键的开发者来说，这条曲线基本是平的。

Beadbox 还做出了一个 SaaS 工具无法做出的取舍：它只与 beads 配合使用。你得不到 Jira 的集成、Linear 的周期或 GitHub 的 pull request 关联。你得到的是一个可视化仪表盘，用于一个 Git 原生的 issue 追踪器，所有数据存储在本地、可离线运行，AI agent 可以通过 Unix 管道读写 issue。如果这就是你的技术栈，那么键盘工作流是无与伦比的。如果你需要 issue 关闭时收到 Slack 通知，那目前这不是合适的工具。

开始使用

用 Homebrew 安装 Beadbox：

brew tap beadbox/cask && brew install --cask beadbox

如果你已经在使用 beads，Beadbox 会自动检测你的 .beads/ 工作区。打开应用，开始按 j。

支持 macOS、Linux 和 Windows。Beta 期间免费使用。