专访 DBX 作者 t8y2：20MB 轻量工作台，如何直面 70+ 数据库的兼容挑战

做业务开发时，一个任务常常要跨好几个数据源：关系型数据库里查主数据，Redis 里看缓存，MongoDB 里翻文档。真正写 SQL 的时间未必最多，更多时间花在连接、找库找表、看结构、切环境、核对结果，以及在不同客户端之间来回切换上。

DBX 想把这些操作收进同一个工作台。它轻量、开源，安装包约 20MB，用同一套界面和操作方式管理不同的数据库与数据系统，同时提供桌面端、Docker/Web、CLI、AI SQL 助手和 MCP Server。

从 2026 年 4 月初做出第一版，到访谈当天（8 月 5 日），DBX 的支持列表已覆盖 70 多种数据库与数据系统，获得 13k+ GitHub Star 和近 200 位贡献者。

但作者 t8y2（github.com/t8y2）并不急着把它推向 1.0。在他看来，DBX 目前差的不是功能，而是稳定性：只有连续一个月甚至几个月不再出现 P0 级 Bug，才算比较稳定。

从减少工具切换的个人需求，到面对数十种数据库的兼容、测试与发布，DBX 这四个月经历了什么？

由于内容较长，大家可以先通过下面的“懒人版”快速了解。

懒人版

本次访谈聊了近两个小时，从 DBX 最初要解决的个人使用问题，一直谈到驱动架构、兼容验证、发版节奏和 AI 参与开发的边界。时间有限的话，可以先看下面六条。

• 统一什么：将连接管理、对象浏览、查询、结果处理和数据修改收进同一套工作流。

• 方向怎么变：一条建议支持国产数据库的评论，让 DBX 从个人需求走向更多国内数据库场景。

• 为什么轻量：Tauri 复用系统 WebView；常用 Rust 驱动内置，其余通过外置 Agent 接入。

• 难点在哪：连上只是第一步，认证、元数据、分页、数据类型和 SQL 方言都要分别适配。DBX 目前最欠缺的是兼容深度。

• 为何频繁发版：用 t8y2 的话说，“不是发得快才不稳定，而是不稳定才需要频繁发版”。

• AI 做了什么：协助检索、调研、测试、文档和 PR 初审，发布与安全决策仍由人负责。

一句话总结：DBX 是一个轻量、开源的数据库与数据基础设施工作台，让开发者以相对一致的方式连接、理解和操作不同的数据系统。

一、真正写 SQL 的时间，反而不是最多的

小七：你是什么时候开始接触数据库的？

t8y2：我接触编程比较早，大概小学三四年级。数据库不是我的专门方向，但如果按使用频率排，数据库客户端能排进我常用工具的前三。

高中时我写过一个校园 BBS，数据量大到不能再用文件存储，就用上了第一个数据库 MySQL，后来陆续接触 PostgreSQL、Oracle、MongoDB。现在我在做 AI 平台相关的工作，日常仍然要频繁面对不同的数据库。

小七：做 DBX 这个项目的想法是怎么出现的？

t8y2：这个想法其实已经有两年了。我用过不少客户端工具。有的功能很完整，但启动偏慢；有的启动快，在我的环境里却经常闪退。而我很多时候只是想临时查一张表，或者改一点数据。

很早的时候用过 Navicat，当时不是官方授权版本，经常闪退，可能也不能完全归因于产品，而正版费用对我来说也比较高。后来用过 DBeaver，我觉得启动偏慢，界面也不太符合自己的审美；DataGrip 功能完善，但在我的机器上刚启动就占用约 3 GB 内存，界面也偏复杂。绕了一圈，我又用回了 Navicat。

当然，这些只是我的个人使用感受，不代表工具本身的好坏。

在多个客户端之间来回切换

小七：你希望 DBX 统一的，是哪一段工作流？

t8y2：先说我平时怎么用数据库。打开工具，在连接列表里找到环境，展开对象树确认库或者 Schema，进入表，打开 SQL 编辑器执行语句，看结果集。需要改数据时，会先在数据表格里暂存改动，保存前通过 SQL 预览确认目标连接和影响范围是不是自己想要的。之后回到查询历史，按连接和时间恢复上下文，最后导出结果或者把 SQL 保存下来交给别人。

这条链路最容易被连接和上下文切换打断。一个任务里，我可能用 Navicat 看关系型数据库，用 Tiny RDM 看 Redis，再用 MongoDB Compass 查 MongoDB。不断切换工具、重新寻找上下文，真正写 SQL 的时间反而不是最多的。

我不希望时间浪费在这里。作为用户，我希望在一个工具中使用相对一致的操作方式，让不同数据库适应这套工具，而不是每换一个工具就重新适应一次。

小七：所以 DBX 想统一的，并不只是 SQL 编辑器。

t8y2：对。查询历史就是上下文切换问题的一个代表，它能帮用户找回上下文。很多 SQL 不会只执行一次，用户可能需要回到昨天、上一次连接，或者某次问题排查的上下文中继续修改。

另一个我觉得做得还不错的，是连接和环境的统一管理。很多数据管理工具也有类似能力，但 DBX 可以兼容更多环境，比如消息队列和 Nacos 配置中心。我在很多群里都看到过类似评论："当我发现 DBX 还能连接 Nacos 时，我震惊了。"

DBX 里的 X，我更愿意把它理解成一个变量。它可以代表不同的数据库和数据系统——只要一种系统能以数据流的方式展示，我觉得就可以尝试接入 DBX。

从连接管理到对象浏览，再到查询和结果处理，DBX 想收拢的是一段完整的数据库操作路径。这也是 t8y2 更愿意把它称为“工作台”，而不只是“数据库客户端”的原因。DBX 还提供了从 DBeaver 或 Navicat 导入连接配置的功能，某种意义上也是在降低这段路径的迁移成本。

二、一条论坛评论之后

小七：第一版支持哪几个数据库，后来为什么扩展到 70 多种？

t8y2：最初的版本主要支持 PostgreSQL、MySQL、MongoDB 和 Redis，都是我自己常用的，另外还接入了少量兼容 MySQL 协议的数据库，基本都是国际上比较主流的那些。

我是 DBX 的第一个用户。4 月初做出第一版后，我先用它满足自己的工作需求，直到觉得可以交给更多人使用，才在 4 月底公开。

开源之后感受挺明显的：一个工具开源以后，就不再只属于作者个人，而是属于更多使用它的人。面对社区提出的 Issue，也会推动我去修复问题、完善功能。

小七：项目方向是什么时候发生变化的？

t8y2：开源之后大约一个小时，我在论坛上发了一个帖子。当时点赞最多的一条评论就是问：能不能支持国产数据库。它还是发帖后的前两条评论之一。

这让我意识到，国内特别是信创环境，缺少比较好用的工具。后来接入的 70 多种数据库和数据系统中，就有不少信创数据库及兼容 MySQL 协议的数据库。以我的观察，国际商业产品对国产数据库的关注相对有限。

支持范围扩大之后，随之而来的问题很具体：主程序会不会越来越重？

三、轻量，不是复杂度凭空消失

小七：你为什么选择 Tauri，而不是 Electron 或者完全原生的方案？

t8y2：主要是在轻量和开发效率之间找平衡。Tauri 使用系统 WebView，不需要随应用打包完整的浏览器内核，安装体积和默认运行负担更小；同时界面仍然可以使用 Vue 和 TypeScript 开发，能够保留 Web 前端的生态和迭代效率，本地能力和数据库核心则交给 Rust。完全原生的跨平台开发成本更高，而 Electron 虽然开发效率也很好，但整体会更重一些。

小七：这个选择有代价吗？

t8y2：有，而且踩过一个坑。

Tauri 用的是系统 WebView：Windows 上是 WebView2，macOS 是 WKWebView，Linux 通常是 WebKitGTK。这几个实现并不一致，字体、输入法、滚动、拖拽和 CSS 渲染都可能有差异。我平时用 macOS 开发，功能在我的电脑上运行正常，打包之后 Windows 或 Linux 用户却可能反馈渲染和样式问题。我们已经投入大量时间做这类兼容，现在仍然会遇到。一个应用不能只在 macOS 上看起来正常。

至于那些比较重的工具，比如自带 Java 运行时的，我理解它是为了更方便地接入不同数据库——多数数据库厂商会优先提供 JDBC 驱动，JDBC 生态非常成熟，代价是体积和内存占用比较高。不过这只是我的理解和猜测，因为它是闭源应用，我看不到代码。

这 5MB 加了什么，30MB 是条线

小七：README 里引人注意的是两个数字：约 20MB 和 70+。这两个数字在技术上该怎么理解？另外，描述也从 15MB 变成了 20MB，这 5MB 加了什么？

t8y2：15MB 和 20MB 都是 Windows 安装包的体积。增长来自迭代中新增的代码，以及新功能引入的新依赖。其他一些工具的安装包可能有一两百 MB。

轻量也不只是体积。打开速度快是一种轻量，连接速度快也是一种轻量。

其实也有人怀疑：体积这么小，功能是不是很简陋？我一般不会直接回答，而是让他们自己使用和体验。有人反馈用起来非常丝滑，也有人反馈卡顿——一部分和某些版本的设计问题有关，后来已经优化；还有一些来自用户电脑的兼容性问题，比如部分设备缺少可用的图形渲染设备或硬件加速环境，曾经影响过某些样式的渲染。

小七：那 DBX 未来的体积有上限吗？

t8y2：我觉得不能超过 30MB，而且应该也很难超过。现在已经引入的一些依赖其实是可以复用的，很多功能代码的实现都能复用这些依赖。

70 多种数据系统并非全部打包进这 20MB。DBX 只内置部分驱动，其余通过外置驱动 Agent 接入，这是控制主程序体积的前提。

四、把驱动拆出去

一个 Star 不到 1000 的库，已经是这个领域的主流

小七：DBX 为什么同时使用 Rust、Go 和 JDBC 三套驱动路径？内置和外接的分界在哪？

t8y2：分界主要取决于 Rust 生态。

Rust 生态不如 Java、Go 完善，学习和开发成本较高，流行度也不如另外两种语言。一些在 Rust 生态中已经算主流的库，GitHub Star 也不到 1000，这一点曾经让我比较惊讶。

PostgreSQL、MySQL、MongoDB、SQL Server 等数据库有较成熟的 Rust 驱动，因此直接内置。很多国产数据库主要提供 JDBC、Go 或 ODBC 驱动，就通过外置 Agent 接入。即使兼容 MySQL 或 PostgreSQL 协议，SQL 方言仍可能不同，也需要单独适配。

这里的 Agent 指独立运行、负责数据库连接和协议适配的驱动进程，不是通常所说的 AI Agent。

小七：Go 和 JDBC 之间怎么选？

t8y2：目前两类驱动大约各占一半。在兼容性允许的情况下，我会优先选择 Go：体积更小、启动更快，在我的使用中性能与 JDBC 大致持平，也不需要额外运行 JRE。按我的估算，这可以减少约 50MB、甚至上百 MB 的内存占用。

但 JDBC 的版本兼容范围通常更广，有时兼容旧版本比性能更重要。比如 Oracle，DBX 最初只支持 10g 以上版本，后来继续做了适配；人大金仓最初通过 JDBC 接入，需要用户安装 JRE，后来重构成了 Go 驱动。

驱动语言其实不限于 Go，用 Rust、C++、Python 都可以。从体积和性能考虑，Rust 和 Go 都合适；在同类实现下，Rust 性能可能略好一些，但 Go 编译更快，所以新增驱动时我会优先考虑 Go。

小七：有哪些能力是做出来又调整过的？

t8y2：一次比较明显的调整与 DuckDB 有关。它最初以内置驱动运行，需要经过 C++ 编译，CI/CD 和新贡献者配置环境时，可能要花 10—20 分钟。

后来我们将它调整为外置驱动 Agent，缩短了编译时间，也降低了主程序与 DuckDB 编译链路的耦合。按我当时的观察，相关发布产物还减少了约 5MB。

我觉得这是比较理想的一次调整，但也带来了一些老用户的不满或者不理解。有些人就是为了 DuckDB 内置、开箱即用的体验而来，改成外置驱动后反而没有以前方便，所以这个调整有利也有弊。

小七：外置驱动是独立进程，出问题会不会连累主程序？

t8y2：独立进程可以隔离大部分驱动故障，缩小影响范围；主程序仍要处理超时、进程退出和协议错误。

内置驱动出问题时，影响更直接。SQL Server 曾因字段数值转换不兼容，导致用户打开查询后应用闪退，当天被列为 P0。但为了开箱即用，该内置的驱动仍然要内置。

小七：官方驱动 Agent 和你说的插件系统，区别是什么？

t8y2：官方驱动 Agent 的范围比较窄，只支持数据库驱动，目前大多数由 DBX 项目维护。插件系统是未来允许第三方扩展 DBX 能力的方向，可以支持与数据库没有直接关系的功能。是否属于官方维护范围，是我认为两者的主要区别。

这个想法的起点是一个希望集成 S3 的 Issue。后来 SSH、Docker 这类能力也有贡献者提交了 PR，但还没有合并，因为插件系统本身仍在设计中。

需要区分的是，用于数据库连接的 SSH 隧道 DBX 已经支持；这里没有合并的，是更完整的 SSH 管理类功能。把驱动拆出去解决了体积和构建问题，却没有减少数据库适配本身的工作。一个数据库能够连上，也不代表它已经被完整支持。

五、支持 70 多种数据系统之后，验证才是难题

小七：对 DBX 来说，“支持一种数据库”究竟意味着什么？

t8y2：新增一种数据库时，有些部分是可以复用的。关系型数据库可以复用数据表格等前端页面，JSON 类可以复用 MongoDB 相关的页面，消息队列可以复用消息队列页面。

但接入一种数据库不只是增加驱动，还要适配连接参数、认证、元数据、分页、数据类型和 SQL 方言。如果出现新的数据库类型，还可能需要开发专用页面。其中，核对和适配 SQL 方言占用的时间最多，需要逐项查阅官方文档。

DBX 的支持列表已覆盖 70 多种数据库与数据系统，但不同系统的支持深度并不相同：能建立连接，不等于已经完整支持。

小七：这么多数据库和版本，现在是怎么做测试和兼容验证的？

t8y2：开发时通常会编写单元测试和协议测试。

另外，一位云厂商赞助商提供了一台内存比较大的服务器，我会在上面用 Docker 部署真实数据库，针对每一种数据库类型运行冒烟测试，再配合必要的人工验证。

前段时间，一位在云原生领域比较知名的贡献者二丫讲梵（github.com/eryajf ）开发了 Database Test Lab，可以把数据库版本、初始化方式和连接信息等配置沉淀下来重复使用，不需要每次临时搭建环境。这些方式结合起来，可以为端到端测试提供基础，尽量避免新增数据库带来回归问题。

目前出现的回归问题，更多来自前端，而不是后端。

Database Test Lab 在 deploy/database/ 中提供带版本的 Docker Compose 配方。例如，运行 make db-verify DB=mysql@8.4 可以启动环境并完成基础冒烟检查，即快速验证连接等关键路径。它解决的是环境复现和基础验证，还不等同于完整的桌面端 E2E 测试。

几千张表时，侧边栏卡住了

小七：实际使用中，什么问题最容易突破现有测试？

t8y2：先说一个性能问题。一个实例中存在几千个 Schema 或者几千张表时，侧边栏曾经非常卡顿，为此做过一次比较大的重构。

对象树改成按层级和用户操作延迟加载，而不是一次性取回所有 Schema 和表。从数据结构上，我们把树拍平成平铺列表：Tree 管层级，Flat List 管可见顺序，Index 管查找和定位，把相关操作优化到接近 O(1)。上线之后，很多用户反馈侧边栏不再卡顿。

数据表格也是同样的思路，先用虚拟滚动，只渲染可视窗口内的数据。第一版的虚拟化效果仍然不理想，后来又参考了一个高性能表格库的方案，改用 Canvas 原生渲染继续优化，行滚动和列滚动都比较流畅。

小七：这个问题是怎么发现的？

t8y2：主要靠用户反馈发现，因为我的机器性能比较好，本地不太容易感知这个问题。

但我觉得，其实还是 DBX 本身的问题。如果一个产品在一些老旧机器上无法流畅运行，可能就是产品设计存在问题。这样说也许有点绝对，但如果要归因，确实是 DBX 当时的代码逻辑有问题。

小七：本地测试为什么没能提前发现？

t8y2：很多前端测试用例比较难写，特别是滚动这一类交互，可能需要借助 Playwright 之类的自动化测试工具，它很难完整覆盖，有些内容可能需要在发包前手动测试。现在的测试流程还无法完整覆盖每一项功能和特性。

比性能更难提前发现的是兼容问题。刚才提到的 SQL Server 闪退，就是版本更新之后，一个上午就新增了二三十个 Issue，其中大部分都与这个问题有关。

六、不是发版快导致不稳定，而是不稳定才需要频繁发版

小七：群里有人说你们基本每天更新一个版本，也有人问，会不会是迭代太快、测试不够？

t8y2：可以这样理解一部分。但在我看来，不是发版快导致不稳定，而是因为不稳定，才要频繁发版。遇到重要 Bug，第二天就得修复。

为了尽快解决问题，有些版本的测试确实不够充分。不过项目的测试也在持续完善。

小七：一次发布需要构建多少产物？

t8y2：比较多。Linux、macOS 和 Windows 三个平台，每个平台还分 x64 和 ARM 架构，合计 6 种。Docker 也要区分 Linux 的两个架构，一共 8 种。

Tauri 默认不兼容 Windows 7，因此还要发布两个离线包：一个是 Windows 7 离线包，另一个是其他 Windows 系统的离线包，主要提供给内网环境和信创环境的用户，加起来是 10 个。此外还有两个静态 Web 包，提供给 Linux 环境中无法安装 Docker 的用户，总共大约十来份发布产物。

小七：macOS 公证和 Windows 代码签名怎么处理？

t8y2：macOS 公证通过 Tauri 配套的 GitHub Actions 自动完成。自动升级也需要证书签名，否则用户可能要手动运行 xattr 移除安全隔离属性。

Windows 端还没有厂商代码签名证书，目前只完成了构建和更新签名，因此可能被安全软件误报，一些企业用户也会受安全策略限制。

连接和设置保存在应用数据目录，正常升级不会覆盖；数据格式变化时会自动迁移，比如早期曾从 JSON 迁移到 SQLite。

小七：13k+ Star 和近 200 位贡献者，给这个项目带来了什么变化？

t8y2：DBX 本质上仍是个人项目，但有核心维护者长期参与，贡献者提交的 PR 也支撑了频繁更新。我平时比较关注 PR 和 Issue，尤其是 Issue，因为它能直接反映用户遇到的问题。

小七：这么多群，反馈怎么流转成 Issue？

t8y2：我写了一个 QQ 群机器人，用户通过指令让 AI 整理问题，确认内容后，机器人会通过 Webhook 自动提交 Issue。微信群受机器人机制限制，所以在微信群里，我会请提出问题的用户自己同步提交 GitHub Issue。由用户自己提交以后，无论是我还是其他贡献者，跟踪和回复都会更加清晰。

最初只有一两个群时，我会直接查看群消息中的问题，有时当场解决。现在已经有十多个群，消息太多，有些贡献者会主动提醒用户去 GitHub 提交 Issue。现在的 Issue 流转，更多依靠社区的自发协作。

Issue 的分类由一套 CI 自动处理，根据正文内容判断问题属于哪个数据库、或者是不是通用问题；优先级由用户填写。但我不会只根据讨论热度或者用户填写的优先级判断，最重要的还是需求的影响范围——需求是否成立、Bug 能不能复现、有没有数据风险、涉及多少用户以及维护成本有多高。

小七：这么多 PR，主要由谁 Review？

t8y2：基本是我本人。我有三条标准：

1. 不希望依赖体积变得太大，否则就超出轻量化的范围了；

2. 不希望 PR 带来回归，或者造成与上一版本不兼容；

3. 希望它确实实用。

AI 会先 Review 一遍，我再核验它提出的阻塞点。如果判断过于严格，就让它重新验证。最终是否合并仍由我决定，因为 AI 可能产生幻觉。

社区反馈也会改变实现。有人曾问：DBX 后端使用 Rust，为什么还要引入较重的 JDBC 和 Java 组件？这条反馈推动我重构了一批驱动。

七、AI 可以帮忙实现，但不能替开发者决定安全边界

小七：在 DBX 的开发过程中，AI 实际承担了哪些工作？

t8y2：不只是我，现在很多项目开发都会用到 AI。AI 虽然会产生幻觉，但它确实能够承担很多角色。它适合做代码检索、陌生驱动和协议调研，也适合补充测试。我不是测试工程师，有一个助手处理这些工作很有帮助。

以前搭建 MySQL、PostgreSQL 等验证环境，需要登录服务器、用 Docker 部署；现在可以让 AI 直接完成。它还会结合代码整理文档，再由我检查。

测试方面，AI 会补充前端 Vitest 用例以及后端脚本和测试。Rust 的编译期检查也能发现一部分错误。功能开发或 Bug 修复完成后，AI 通常会补充测试，再由 CI/CD 在代码提交时执行。

小七：有没有哪些事情你一直不放心交给 AI？

t8y2：有。在数据库管理工具中，安全边界非常重要。我一直有一部分工作不放心交给 AI，包括一些发布任务，不能让 AI 自己决定，因为我无法完全保证它写出的内容是否安全、是否正确。

我的工作方式是：每次启动项目前，先写一份自己认可的 PRD，不会一开始就让 AI 代写，而是自己有了初步想法、写得相对详细之后再让 AI 润色补充。PRD 完善以后，再编写 AGENTS.md 约束 AI 的行为，避免每次新的上下文都要重新说明项目规则。通常我用 ChatGPT（Codex） 辅助写代码，再用 Claude 做 Review。如果让同一款模型同时编写和 Review 代码，它可能更容易认为自己的实现是正确的；引入另一款模型，相当于交叉验证，也有一点“旁观者清”的感觉。

小七：当 AI 可以通过 MCP 连接数据库之后，你最担心的风险是什么？

t8y2：以前我觉得 AI 在生产环境中会带来很多安全问题。现在风险依然存在，但已经尽量减少了一部分。

DBX 和 MCP 对数据权限做了分级：只读 SQL 可以在相对开放的权限下执行，涉及数据读写或者完全访问时会受到更严格的限制，还可以设置生产保护。不能只依靠 AI 自己判断操作是否安全，而要从 DBX 这一层进行约束。

具体机制上，连接白名单会限制 Agent 能看到哪些连接，不在白名单中的连接，Agent 看不到，也无法写入。SQL 风险判断会识别 DELETE 这类关键词，也会判断语句是否涉及数据写入、表结构变更或者权限管理操作。如果无法判断一条语句属于什么类别，系统会默认拒绝，作为安全兜底。

不过，DBX 不一定是最终解决方案。更根本的安全边界，是用户和运维人员对数据库账号权限进行划分，包括最小权限、审计、事务和变更流程。这些才是更可靠的最后边界。

小七：目前 DBX 的权限管控这块做了哪些事情？

t8y2：DBX 的权限管控主要分三层。首先是连接范围，MCP 可以通过 allowlist 限制 Agent 能访问哪些连接；其次是操作权限，每个连接可以设为只读，MCP 还有只读、数据读写和完全访问三档；最后是执行保护，后端会判断 SQL 风险并叠加生产库保护，高风险操作需要更高权限，AI 和 MCP 默认情况下不能直接写生产库。

这些限制会在实际执行入口重新检查，不只是界面上的开关。

小七：如果不通过 AI，用户自己在 DBX 里改数据呢？

t8y2：修改会先暂存在表格中，提交前可以预览 SQL，确认目标连接和影响范围，不会在编辑后立即写入数据库。

这些机制只能提供缓冲，最后仍要依靠数据库账号的权限划分。

MCP Server 独立分发，核心服务使用 Rust，通过 npm 安装时包含轻量的 Node.js 启动器。原生连接可以不启动桌面端运行；外部 Agent/JDBC、SSH、集群连接及桌面界面相关能力，仍依赖对应组件。

八、1.0 不是功能更多，而是能够持续稳定

小七：DBX 达到什么状态时，你才会愿意把它定义为 1.0？

t8y2：我觉得功能层面已经相对充分。距离 1.0，主要还差稳定性。如果连续一个月或者连续几个月不再出现 P0 级 Bug，我觉得它才算比较稳定的版本。

1.0 也是对用户的承诺：工具足够可靠，升级不会引入明显回归，也不会破坏原有使用习惯。

小七：目前最不成熟的能力是什么？

t8y2：兼容深度。不同数据库的 SQL 方言需要逐项核对，一些商业数据库又缺少完整的测试环境。DBX 具体支持哪些版本、在哪些版本上验证过，目前也没有形成完善记录。

小七：现在建议用户在生产环境里用它吗？

t8y2：我觉得可以用于开发、测试和只读的生产排查。但如果涉及生产写入，我不建议只依赖 DBX 客户端的保护。开发者仍然应该使用最小权限账号，并通过团队的变更流程规范操作安全。

目前上线的功能没有特别标记为实验性；还在开发中的插件系统，未来可能作为实验方向。

小七：商业化上有什么计划吗？

t8y2：目前还没有明确路径。如果以后商业化，社区版已有功能仍会免费开放。企业端可能探索 Web 版 RBAC，个人端也可能探索云服务，但连接配置比较敏感，这些都还只是设想。

RBAC 指基于角色的权限控制。DBX 目前已支持通过 WebDAV、GitHub 或 Gitee 私有片段同步配置；未来云服务的具体形态尚未确定。

尾声

DBX 起于减少数据库工具之间的切换。接入数十种数据系统后，问题也从界面和 SQL 编辑器延伸到驱动、协议、跨平台构建、测试与兼容。

对 t8y2 来说，支持数量不等于支持深度，项目受到关注也不等于已经稳定。他给 1.0 设定的标准是：连续一个月甚至几个月，不再出现 P0 级 Bug。

比起继续增加数据库类型，持续可靠或许才是 DBX 进入长期使用前更难的一步。

文末彩蛋：t8y2 如何为 AI 编写项目说明

小七：关于 AI Coding，有什么经验可以分享？

t8y2：不同模型对 Skill 的依赖不同，流程过重也会增加任务耗时。相比堆叠现成 Skill，我更建议开发者编写适合自己的 Skill 或 AGENTS.md。

一份好的 AGENTS.md 就像项目操作手册，不只规定代码风格，还要说明怎样判断问题、验证结果，以及哪些操作不能执行。

以 DBX 为例，我采用分层维护：在 Workspace 目录中放通用规则，在子目录的 DBX 项目中放数据库和发布相关规则。离代码越近的规则，优先级越高。

在通用的 AGENTS.md 中，我基本会写明：执行任务前要进行网络搜索，并使用官方资料辅助验证，不能只凭模型已有知识做判断，要主动规避幻觉。我发现加上这条规则以后，任务成功率会明显提高。

修复完成以后，还应该运行针对性测试或者端到端测试，证明为什么会出错、修改后为什么变好，再针对这次问题补充一条规则。随着项目不断迭代，规则会越来越适合这个项目。这比每次临时编写一个很长的 Prompt 更稳定。

所以我觉得，AGENTS.md 本质上是长期踩坑换来的经验积累。

以后有空的话我会整理一套通用版本 AGENTS.md，以开源形式分享出来。