工欲善其事：AI 时代的开发工具选型与打磨

昨天写了如何用聚合工作区组织 AI 的多项目、多任务开发。工作区把项目和任务组织起来以后，还有一个问题绕不过去：AI 到底通过什么工具来干活？我这段时间陆续换掉或改造了一些用了很久的开发工具，留下了 Paseo、DBX、Zed 和 Tabby。这篇不做功能排行榜，主要记录我为什么选它们，以及为了真正用起来，又做了哪些打磨。

工欲善其事，先让工具接得上

以前选开发工具，我首先考虑的是自己用起来顺不顺手：界面好不好用、快捷键熟不熟、功能全不全。现在多了一个使用者：AI。

比如，一个数据库客户端里已经保存了测试库连接，我可以点开连接、查看表结构。但 AI 要查同一个库时，如果还得让我重新提供地址、账号、密码，再临时写一段连接代码，那这套工具对它来说基本等于不存在。

终端也一样。我在 SSH 客户端里维护了服务器分组、连接和认证方式，AI 却要另外维护一份主机清单。时间长了，人用一套配置，AI 用另一套，哪一份更新了、哪一份已经过期，自己也容易搞混。

所以我现在看工具，会多问几个很具体的问题：

• 我在界面里维护的信息，AI 能不能通过稳定接口复用？
• 它能不能返回结构化结果和明确的失败原因，而不是让我截图解释？
• 换一个 Agent、换一台电脑以后，这些工作能不能接着做？
• 遇到不合适的地方，我能否修改，并把修改长期维护下去？

所谓不能再完全沿用“古法编程”的工具链，对我来说，主要是不能继续假设所有步骤都由人盯着界面、逐个点击来完成。工具好不好用，要把人与 AI 之间来回搬运上下文的成本也算进去。

Paseo：统一工作入口，保留 Agent 的选择权

我不想把日常工作固定在某一个 AI Agent 客户端上。

Codex、Claude Code、Zcode、OpenCode 这些工具，我都会关注。不同任务、不同阶段，适合的 Agent 和模型可能不一样。如果每次换一个，就要跟着换一整套操作入口和工作习惯，切换成本就有点高了。

我选择 Paseo，是希望把工作台这一层相对稳定下来。Paseo 为已经适配的 Agent 提供统一入口，上游目前明确支持 Claude Code、Codex、OpenCode 等。具体能接哪些 Agent、支持到什么程度，仍要看实际适配器和版本，不能理解成任意 CLI 都能直接接入。Paseo 官方项目

这里我比较看重两个地方。

把工作入口与执行者分开

对我来说，项目目录、任务说明、分支和验证结果，是需要长期保留的工作资产。今天由哪个 Agent 执行，则是可以根据任务调整的选择。

Paseo 帮我减少了更换操作入口的麻烦；昨天介绍的聚合工作区，则负责把规则和任务上下文落在文件里。这两者配合，比把所有知识只留在某个客户端的聊天历史里更方便接续。

不过，统一界面不等于所有 Agent 的能力、权限和历史格式都一样，也不等于可以把一个未完成会话随意切给另一个 Agent。真正能接着做，还是要靠清晰的任务状态、代码现场和交接材料。

跨端接入同一个开发现场

Paseo 的 Agent 在 daemon 所在的开发机器上执行，桌面、Web 和手机是进入这个现场的不同入口。

这个区别对我挺重要。手机不需要重新安装一套编译环境，也不用再复制一份项目。我可以离开电脑后，从手机查看同一开发机器上的任务和输出，必要时补充指令或处理确认。

远程工作的便利，来自开发现场仍然在那里，而不只是把一个聊天页面做成手机版。当然，开发机器和连接服务仍要在线；模型请求也仍遵循各 Agent 自己的服务和配置，不会因为套了一层工作台就自动变成离线执行。

我还在自己的 Paseo 版本里补了项目和工作区访问保护、文件预览下载、会话分享范围等功能。这些是为了让统一入口更贴合我的工作方式，不是把上游新增的所有能力都算成个人定制。

DBX：人维护一次连接，AI 也能用

数据库工具是我最不想重复维护配置的地方。

我看中 DBX，首先是它开源、可以定制，同时提供桌面端、CLI 和 MCP 等入口。它的桌面端使用 Tauri，后端主要由 Rust 实现；CLI 可以读取桌面端使用的连接存储。DBX 官方项目

这样，我在桌面界面里维护连接，自己需要时打开界面操作；AI 需要检查结构或查询数据时，通过 CLI 使用同一份连接信息，而不是让我把密码粘贴到提示词里。

一个典型过程可以是：

# 先确认 CLI 读取的是哪份配置，以及当前数据库能力
dbx doctor --json
dbx capabilities --json
dbx connections list --json

# 以下连接名是示例，需要从实际连接列表中选择
dbx schema list '业务测试库' --json
dbx query '业务测试库' 'select 1 as ok' --limit 10 --timeout 10s --json

关键不在这几条命令本身，而在于 GUI 和 CLI 最终指向同一份数据目录。尤其便携版和多版本共存时，程序启动对了，不代表读取的连接库就对了。我会先用 doctor 核对；自己的便携版也给配套 CLI 加了包装入口，让它指向相邻的数据目录。

连接同步解决的是另一层问题：换电脑以后，不必把所有连接重新录入。DBX 提供了配置云同步能力，但连接信息、敏感字段和设备本地密钥有各自的边界，不能把复制数据库文件当成万能迁移方法。DBX 同步说明

同样，AI 能列出连接，也不意味着它能查询所有类型的数据库，更不意味着已经具备完整的连接管理能力。实际使用时要看 CLI 的能力报告，有些类型依赖桌面桥接或其他驱动方式。我的习惯是先确认能力、再读结构，最后做有行数和超时限制的查询。

共用连接信息，也不代表把人的所有操作权限原样交给 AI。 查询和写入仍要区分，生产操作也仍有自己的边界。工具适配得好，应该能让这些边界被执行，而不只是写在提醒里。

另外，我确实在意资源占用。经常同时开着多个项目、终端和数据库连接，几个“单独看也没多大”的程序加起来就不小了。Rust、Tauri 和不随应用打包整套 Chromium，是 DBX 对我有吸引力的地方。不过这里没有做同负载性能测试，也不能只凭编程语言就断言所有场景都更省内存。

在个人版本里，我又补了更合用的对象导航、MySQL 表详情等功能。选型解决大方向，最后每天顺不顺手，还得靠这些具体的调整。

Zed：编辑器围着多项目工作区转

我以前很依赖 IntelliJ IDEA。代码导航、编译测试、调试和各种框架集成，一套工具里都能完成，用起来很方便。

现在编译和测试更多由 AI 调用命令来执行，我自己的工作重心也随之变了：阅读改动、确认调用链、检查差异、判断实现是否符合需求。一个编辑器能否让我方便地查看多个项目，变得更重要。

一个功能从前端到 API，再到后台数据服务，经常涉及几个仓库。我不希望为了看同一条链路，反复在多个独立窗口之间找来找去。

因此我选择 Zed，并维护了自己的版本，重点打磨一个窗口里多个项目的打开、关闭、保存和恢复，以及 Windows 下的最近项目入口。多项目本身也是上游正在支持的方向；这里说的是我在自己的版本和工作方式下做的进一步适配，不是说上游完全没有这项能力。Zed 多项目说明

这个编辑器承接的是昨天那套聚合工作区和固定工作区池：AI 在任务分配的目录里工作，我在编辑器里查看对应的几个仓库。项目切换方便以后，审核一条跨服务改动链路也更连贯。

当然，把编译测试交给 AI，并不意味着调试器和 IDE 的能力没有价值。遇到复杂运行时问题，专门的调试工具仍然有用。只是对我现在的日常工作而言，不再需要让完整 IDE 成为每一个项目都常驻的中心，所以才从 IDEA 切到了 Zed。

Tabby：服务器连接也应该能被复用

SSH 这一块，我从 Xshell 换到了 Tabby。

我看重的是连接管理、跨平台和配置同步，以及能够继续接入自动化的空间。Tabby 官方项目

我目前使用的是 Tabby 的配置同步功能，接到自己部署的精简同步服务。换电脑时先下载已有配置，检查连接和分组，再开启自动同步。这里没有同时叠加几套同步插件，免得几份配置互相覆盖。

但配置同步完成，不代表另一台电脑立即具备完全相同的登录条件。Windows 凭据管理器里的密码不会自然跟着 YAML 同步，SSH 私钥文件、本机路径、VPN 和网络条件也要分别准备。把这几件事分清楚，比追求“点一次就全部同步”的说法更实用。

AI 接入则是我额外做的一层：tabby-bridge。

它是一个按需运行的 CLI，读取 Tabby 保存的 SSH 连接，按当前机器可用的认证方式执行命令或传输单个文件。Tabby 不必一直开着，也不用另外维护一份供 AI 使用的服务器列表。

# 先找到连接，再用确定的 ID 执行，避免同名连接选错
tabby-bridge list --search '测试' --json
tabby-bridge exec --id '<connection-id>' --command 'uname -a' --json

这部分要明确区分：Tabby 是我选用的连接管理工具，tabby-bridge 是我为了自己的 AI 工作流增加的适配层。 不能把自己的桥接能力写成 Tabby 原生就支持所有 Agent。

桥接也有实际限制。当前它没有覆盖 Tabby 的全部能力，例如部分跳板和代理配置、持续交互会话；配置里出现尚不支持的设置时应报错，不能静默忽略。结构化结果中也要区分“远端命令失败”和“工具根本没有连上”。

人和 AI 共用连接以后，我还希望看到可信的主机身份、超时和退出码。命令超时断开了连接，不代表远端任务一定已经结束；再次执行前仍要核对运行现场。这些细节，才决定一个脚本能不能放心交给 AI 反复使用。

我真正选择的是一条能接起来的工作链

把四个工具放在一起，会更容易看出各自负责什么：

比如分析一个接口问题，我希望能在 Paseo 里描述任务，AI 根据工作区记录找到前后端项目，通过 DBX 读取指定连接的结构，再在有需要时用 Tabby 桥接检查服务器。我则在 Zed 中查看这几个项目的改动与证据。

这是一条工作链的组织方式，不是每个任务都要把四个工具调用一遍。能从现有代码和文档得出结论，就不需要为了“集成完整”去访问数据库或服务器。

从人的界面到 AI 的执行入口，共享的是已经维护好的项目、连接和工作状态；可以更换的是具体执行者。输出再回到人能阅读、能核对的文件、差异和报告里，才算接上了。

打磨工具，也要算维护账

开源让我可以修改不顺手的地方，但 fork 以后并不是一劳永逸。

上游升级会带来冲突，桌面程序和 CLI 可能需要配套发布，源码更新了还得构建、安装，实际使用的版本才会变化。我会尽量把上游同步线与个人使用线分开，保留原有定制历史，再把打包、安装和验证过程整理成脚本、Skill 和维护笔记。

所以，一处功能值得不值得改，我会看它是不是反复出现的摩擦。如果只是偶尔多点一下，未必值得长期背着一套补丁；如果每天都要在多个项目之间恢复现场，或者每次都要给 AI 重复维护连接，那投入就更容易说得过去。

资源占用也要放在这本账里看。虽然我喜欢 DBX、Zed 这类实现路线，但 Tabby 和我使用的 Paseo 桌面端本身也采用 Electron。这并不矛盾：我关心的是它解决的问题，是否值得相应的资源和维护成本，而不是看到某个框架名字就一票否决。

以后再换工具，我也会先看它能否复用已有状态、是否提供可调用的能力、结果能不能核对，以及我能否承担它的维护成本。

工欲善其事，必先利其器。到了 AI 参与开发的阶段，“利器”除了让我自己用着顺手，还得让 AI 接得上、看得懂、执行后有结果可查。把这个接口打磨好，往往比再换一个模型，更能减少每天工作里那些重复的搬运和解释。