我给数据库客户端加了 AI 工作台：从查 SQL，到排查 Redis
接手一个不熟悉的系统，往往不是从写 SQL 开始，而是从找线索开始。
订单在哪张表？状态字段怎么解释？两个表能不能关联？数据库里的记录更新了，Redis 里的缓存为什么还是旧值？
以前，这些问题通常要在几个窗口之间来回切：数据库客户端、Redis 客户端、聊天工具，再加一份不一定及时更新的表结构文档。问 AI 之前，还得先复制 DDL、补充字段说明，把报错一起贴过去。
最近我把 FluxDB 的 AI 能力做进了日常操作流程：让 AI 在明确的连接和数据范围里找信息，把执行过程留在工作台里，再由人检查结果、决定是否继续。
上一篇文章主要聊 Rust + GPUI 的开发取舍。这次不讲 UI 框架、分层或打包，换个角度：拿到一个陌生数据库时，这个工作台能帮上什么忙，以及 Redis 和数据库的一些操作细节。
本文按 v0.1.9 已发布代码中的能力整理。下方提问是可复用的演示示例，不是一次线上排障实录；不预设 AI 的回复或查询结果。建议先用测试库和脱敏数据体验。
1. AI 工作台：先找到事实，再回答问题
我更想解决的，不是“帮我生成一段看起来像 SQL 的文本”，而是生成之前的信息准备。
比如一个演示库里有 orders、order_items、customers 几张表，想统计最近一周的下单情况。可以先这样问：
先查看当前库中订单相关的表结构和已登记关系。
告诉我哪些字段可能代表下单时间、订单状态和金额。
不要修改数据；不确定的业务口径先列出来，不要替我决定。
工作台里的 AI 可以在授权范围内检索对象、读取结构，再根据需要调用有界查询工具。比起在聊天框里手动粘一堆 DDL，这条路径少了一些搬运，也更容易发现“模型以为有这个字段，但库里其实没有”的问题。
输入区还可以用 @ 选择数据库对象等引用，或添加授权附件。当前页面也会提供相应的定位、结构或有界预览；页面摘录不是全库副本，也不表示 AI 已经读完了全部数据。
实际使用时，我建议把提问拆成两步：
- 先确认表、字段和口径。
- 再让它写查询，必要时在允许的范围内执行。
例如确认后再问：
使用刚才确认的字段，按天统计最近 7 天的订单数。
按下单时间过滤，说明时区和时间边界。
如果要关联明细表，先检查会不会让订单数重复计算。
这里最值得看的不是最后一句结论，而是中间过程：它读了哪张表、调用了什么工具、查询有没有成功、返回的结果是否支持结论。
工具失败了，不能用一段流畅的回答把失败盖过去。 这也是我想让工作台保留工具卡片、错误和审批记录的原因。
多表查询里，最容易错的不是语法，而是统计口径
orders.id = order_items.order_id 这个 JOIN 很容易写。
难的是：一笔订单可能有多条明细。连完之后直接 COUNT(*)，统计的就可能是明细数；直接对订单金额 SUM，也可能把同一笔金额重复累加。
FluxDB 现在有读取已登记关系、查找连接路径的工具，AI 不必只凭字段同名猜关联。对于没有明确登记的关系，也可以生成候选，放进逐条审阅弹框。
用户可以查看字段配对、关系角色、基数依据和警告，只勾选需要采纳的项。未采纳的建议不会写进关系目录。
上一篇讲过本地逻辑关系与物理外键的区别；这次增加的是**“AI 提建议，人逐条审阅”这一步操作**。它适合辅助整理陌生库，不代表模型已经核实了业务关系。
查询失败后，不用重新拼一份问题
查询结果区提供了“用 AI 修复”入口，会把失败 SQL 和错误信息带进 AI 对话，请它给出修复后的 SQL 和简短原因。
这对语法、字段名、方言差异之类的问题比较方便：不用分别复制 SQL、报错，再解释一遍发生了什么。
不过，修复 SQL 和执行 SQL 还是两回事。拿到建议后，仍要核对目标库、字段含义和影响范围，尤其不要把“能执行”直接当成“业务上正确”。
2. 从查询结果到报告：少搬一次数据
有时查完 SQL，事情还没结束。
“最近一周每天多少订单”只是一个结果表，接下来可能还要画趋势图、写几句说明，发给同事。原来的路径往往是导出，再去另一个工具里重新选字段。
在 AI 工作台里，可以接着提出这样的要求：
基于本轮已经成功返回的订单统计结果，生成一个趋势图和汇总表。
说明统计范围、时间口径和结果限制；没有查询到的数字不要补。
内置 BI 能力可以围绕同一任务的 SQL 查询结果生成图表、表格和报告产物。产物有独立的查看入口，可以导出 HTML 或 JSON，而不只是聊天记录中的一段文字。
我觉得这个功能最实用的场景，是做一份临时分析：查数据、看图、核对口径，再把结果带走。
这里有两个容易误解的地方：
- 报告是生成时的静态快照，不是接上数据库后自动刷新的 BI 大屏。
- 当前内置报告来源是 SQL 查询结果，不是把任意 Redis 返回值或模型描述直接变成有数据依据的图表。
图表呈现得再完整，选错了状态、时间或聚合粒度，结论仍然会错。工作台减少的是整理动作，不是省掉业务核对。
使用 AI 前，我建议先做三个设置
第一次用，先选测试库，并从只读策略开始。
内部工具有只读、写审批、帮我审批、自动执行等策略。不同策略下审批行为不同，不应笼统理解成“AI 的所有写入都会等我点击”。即使选择更自动的策略，连接权限和授权边界也不能因此被跳过。
另外两件事也要提前确认：
- 配置可用模型，并检查模型的数据出站设置。
- 确认允许模型接触的对象、查询结果和附件；使用远端模型时，相关内容会发送给配置的模型服务，不是“桌面客户端所以数据不出本机”。
AI 可以探索数据库，也能辅助看 Redis，但不应因为两个连接出现在同一个侧边栏，就假定它可以不经确认跨库、跨环境操作。
3. Redis：按数据类型看，比盯着一长串响应舒服
AI 是这次更新的重点，但排查问题时，我仍然希望自己能快速打开 Key，看到原始内容。
比如一个订单缓存异常，通常会按这个顺序查：
- 先核对连接和 DB 编号。
- 按 Key 模式找到目标，确认类型和 TTL。
- 打开值，检查字段是否完整、数据是否过期。
- 有疑问时，再去工作台运行命令交叉核对。
FluxDB 的 Redis 详情会按类型展示内容，而不是把所有数据都塞进一个通用文本框：
| 类型 | 排查时比较顺手的地方 |
|---|---|
| String / JSON | 看值、格式化 JSON，必要时进入完整值编辑 |
| Hash | 按字段检查缓存对象，查看或修改字段值 |
| List | 看条目顺序，区分从头部还是尾部增删 |
| Set / ZSet | 搜索成员；ZSet 还能查看、编辑分值 |
| Stream | 查看 Entry、按时间范围读取、查看消费者组信息 |
JSON 场景尤其直观。缓存里是一整个对象时，格式化之后比看一行转义字符串轻松；编辑态使用多行编辑器，也更适合检查嵌套结构。
大值要额外留意：预览被截断，不等于值本身只有这么多。 修改前先确认已经加载需要编辑的完整值，不要拿一小段预览覆盖原数据。
JSON 类型操作还依赖服务端 RedisJSON 能力；客户端有入口，不表示普通 Redis 服务端一定支持相应命令。
Workbench 和 CLI，我没有把它们做成同一个入口
这两个入口看起来都能执行 Redis 命令，但适合的场景不太一样。
Workbench 适合留下一组可回看的排查过程。 每条命令有执行记录，能查看状态、耗时和返回内容，单独重跑；结果适合时可以切换 Text / JSON 视图。
例如检查演示缓存，可以依次执行：
TYPE demo:order:1001
TTL demo:order:1001
GET demo:order:1001
这组示例假设目标是 String；如果实际是 Hash，就该换成相应命令。先看类型，再读内容，比遇到 WRONGTYPE 后凭感觉改命令更直接。
CLI 更适合已经知道要敲什么命令的时候。 熟悉命令行的用户可以直接操作，不需要所有场景都经过可视化表单。
它们和 AI 工具不是一条完全相同的执行路径。不要因为 AI 侧配置了写审批，就假设终端中的手工命令也一定经过同一张审批卡。
Stream 排查则可以换一种看法：除了看 Entry，还要看消费者组和 pending 等信息。界面把这些入口放在同一处，少查几次命令文档。Pub/Sub 也有独立页面，但它看的是实时消息，不是关闭后还能补回的历史消息队列。
4. 数据库本身，也要让人容易核对
AI 能给出 SQL，不代表数据库客户端的表格、查询结果和导出就可以随便做。
这次我更在意的是：从建议回到原始数据时，路径要短。
查询结果能同时看到返回行、受影响行、耗时和错误；多条结果可以切换页签。比如一段 SQL 前面成功、后面失败，不必只盯着一条总提示猜发生了什么。
表数据浏览里可以筛选、排序、看单元格详情。单值条件只保留一个输入值，不需要为了一个等号条件去管理一组值；IN 一类多值条件再使用多值选择。查到目标行后，再进入编辑流程。
需要带走数据时，导出前可以检查范围、字段和格式，而不是把整张表一股脑导出。
这些都不是什么独有概念，但它们决定了 AI 回答之外的工具是否好用：建议可以参考，原始记录要能自己查，结果要能自己带走。
最后：我想做的是少切窗口，不是少做判断
这一轮更新后，FluxDB 更像一个围绕数据问题组织的工作台：
- 不熟悉表结构时，用 AI 帮忙找线索，自己确认口径。
- 遇到多表查询时，先看关系，再检查 JOIN 和聚合。
- 做临时分析时，从成功的查询结果生成报告。
- 查缓存时，在类型详情、Workbench 和 CLI 之间选择合适的入口。
它还处在早期阶段。没有做跨客户端性能基准，也不打算把这些功能包装成“全自动运维”或“一句话搞定生产库”。
如果愿意体验，欢迎先用测试数据试一下，尤其想听这几类反馈：
- AI 是否找对了表和字段，哪些业务口径需要额外说明？
- Redis 哪种类型的操作仍然不顺手？
- 查完数据后，结果展示、报告或导出哪一步最费劲？
- 项目地址：fluxdb-alt/fluxDB
- 本文版本：v0.1.9
- 操作手册：FluxDB User Guide
- 问题反馈：GitHub Issues
项目使用 GPL-3.0-or-later。欢迎试用、提 Issue；如果对你有帮助，也欢迎给个 Star。
