夜雨聆风
它首先是一款数据管理工具，可以连接数据库、浏览数据对象、编写和执行 SQL、查看和编辑数据。
但在这些传统能力之上，我又加入了 AI Chat、数据库 Agent、内置 Skills、交互式 Notebook、任务和记忆 等模块。
我希望Ta不只是一个“带 AI 的数据库客户端”，而是一个面向 AI 时代的数据工作站。
先看一下它现在的样子。
目前，Ai Data Studio 支持 SQLite、MySQL 和 PostgreSQL，提供数据库对象浏览、SQL 查询、数据增删改查等基本能力。
在中间工作区里，用户既可以像传统数据库客户端一样操作数据，也可以打开交互式 Notebook，使用 SQL、TypeScript 和 Markdown 组织分析过程。
右侧则是一个能够感知当前数据库、数据对象、查询结果和 Notebook 上下文的 AI 助手。
它也有 Windows 版本。
不过，介绍完这些功能之后，一个问题也随之而来：
市面上已经有这么多 SQL Agent，为什么还要再做一个 Ai Data Studio？
这也是我在开发过程中反复思考的问题。
AI 写 SQL，已经不稀奇了
过去，使用数据库通常要求人先理解表结构，再编写 SQL，最后从查询结果中寻找答案。
人的问题↓理解数据库↓编写 SQL↓执行查询↓分析结果
大模型出现后，这条链路发生了变化。现在，用户可以直接说：
帮我统计不同城市的客户数量。
AI 可以检查表结构、生成 SQL，甚至直接执行查询并解释结果。
自然语言↓AI 生成 SQL↓执行查询↓返回答案
这显然降低了数据库的使用门槛。
很多产品也正是沿着这个方向发展：给数据库客户端增加一个聊天窗口，或者直接做成一个自然语言查询工具。
但随着开发逐渐深入，我越来越觉得：
“AI 写 SQL”虽然有价值，却不足以构成下一代数据软件。
因为 SQL 只是数据工作的一个执行步骤，而不是数据工作的全部。
真实的数据工作，也不是一次问答。
假设我们提出一个很常见的问题：
最近订单为什么下降？
这个问题很难通过一条 SQL 直接回答。真实的分析过程可能是：
先查看整体订单趋势；
发现某个地区下降明显；
继续按客户类型、产品类别或渠道拆分；
检查下降究竟来自客户流失、客单价变化，还是订单数量减少；
生成图表；
记录阶段性判断；
再根据结果调整下一步分析方向。
整个过程不是一次查询，而是一条不断展开的工作链路：
提出问题↓查看整体趋势↓发现异常↓继续拆分↓验证假设↓生成图表↓形成结论
在这个过程中，会产生许多真正有价值的内容：
使用了哪些数据； 执行了什么 SQL； 中间结果是什么； 为什么继续沿某个方向分析； 做了哪些数据转换； 最终得出了什么结论； 下一次如何重新运行。
如果这一切只存在于聊天记录里，那么对话结束之后，大量工作实际上也随之消失了。
聊天记录可以告诉我们 AI 曾经说过什么，却很难成为一份可以修改、重新执行和继续演进的工作成果。
这也是我做 Ai Data Studio 时最重要的一个判断：
数据工作的核心产物，不应该只是一段回答，而应该是一份可执行、可检查、可继续的工作资产。
为什么我把 Notebook 放在产品中心
在 Ai Data Studio 里，Notebook 不是一个附加功能，而是整个分析过程的核心载体。
它支持三种主要类型的内容：
SQL 负责与数据库交互，TypeScript 负责把工作继续向外扩展，Markdown 则让分析过程能够被人理解。
Notebook 还可以保留运行结果，让一次分析形成完整的上下文：
问题说明↓SQL 查询↓结果表格↓TypeScript 转换↓图表或文件↓分析结论
它不是单纯记录代码，也不是把聊天内容换一种形式保存下来。
Notebook 中的 Cell 应该尽可能可以单独运行、修改和复用。用户第二天重新打开它，即使不再继续之前的对话，也仍然能够看懂分析过程，并从某一步继续工作。
所以我很认同一句话：
Chat 是临时的，Notebook 才是资产。
但 Ai Data Studio 中的 Notebook 又不完全等同于传统的 Jupyter Notebook。
它从一开始就建立在数据库上下文之上。
当前连接的是哪个数据库、正在查看哪张表、最近一次查询得到了什么结果，这些信息都可以成为 Notebook 和 Agent 的工作上下文。
同时，TypeScript 运行环境允许用户安装一部分 npm 包。这意味着它不只可以完成数据库查询，还可以继续承担数据转换、统计计算、外部 API 补充、文件导出和报告生成等任务。
我想做的不是一个通用代码沙箱，而是一个以数据库工作为中心的运行环境。
AI 不应该只给建议，还应该落下真实工作
很多 AI 助手的问题是：它可以给出很好的建议，却把真正的执行工作继续留给用户。
例如它会说：
你可以先查询最近三个月的订单趋势，再按城市进行分组。
这段建议可能是正确的，但用户仍然需要复制 SQL、打开编辑器、执行查询、整理结果，再决定下一步。
在 Ai Data Studio 中，我希望 Agent 不只是建议用户做什么，而是可以在明确边界内直接完成工作：
检查必要的数据库结构； 生成 SQL； 验证并执行安全查询； 获取真实结果； 生成分析 Cell； 把查询、结果和说明写入 Notebook； 根据结果继续生成图表或后续步骤。
也就是说，Agent 的输出不应该只是一段“看起来完成了”的文字。
每一步可见的进展，都应该对应一个真实结果：
不是：我计划查询订单数据而是：SQL Cell 已生成并执行
不是：我建议画一张趋势图而是：图表已经作为结果或 Cell 写入 Notebook
只有这样，AI 才真正进入了软件的工作流，而不是停留在聊天层面。
Skills、任务和记忆分别解决什么问题
除了数据库、Chat 和 Notebook，Ai Data Studio 目前还有三个重要能力：Skills、任务和记忆。
它们不是为了让产品看起来功能更多，而是分别补足数据工作的不同环节。
Skills：让 Agent 掌握稳定的方法
大模型可以临场生成答案，但真实工作不能永远依赖临场发挥。
例如解释 SQL、优化查询、生成迁移脚本、分析查询结果，这些任务都有相对稳定的方法和输出要求。
内置 Skills 的作用，就是把这些方法沉淀下来。
它不仅告诉 Agent 应该如何思考，也可以约束它使用哪些工具、按照什么步骤执行，以及最终应该留下什么成果。
因此，Skill 在这里并不只是一个提示词模板，而更接近：
任务方法+上下文规则+可调用工具+结果规范
任务：让工作可以继续发生
聊天和交互式 Notebook 主要处理当前工作，但很多数据任务并不会在一次操作中结束。例如：
下周继续完成某项分析； 定期检查数据质量； 重新运行某个 Notebook； 生成周期性报告； 继续一个耗时较长的 Agent 工作。
任务能力让 Ai Data Studio 不再只服务于“此时此刻”的操作，而能够承载未来和持续发生的工作。
记忆：让 Agent 不必每次从零开始
数据库结构只告诉 AI 数据在技术上是什么，却不一定告诉它数据在业务上意味着什么。
例如，同一个 status 字段，在不同系统里可能有完全不同的定义；某个金额到底是含税还是未税，也很难仅从字段名判断。
通过记忆，系统可以逐渐积累：
表和字段的业务含义； 常见数据关系； 指标定义； 数据库中的特殊约定； 用户偏好的查询和分析方式； 过去工作中形成的有效经验。
这会让 Agent 的上下文从单纯的 Schema，逐渐扩展为：
数据库结构+历史工作+业务语义+用户偏好
它不只是“看到了数据库”，而是在逐步理解这个数据库所对应的业务世界。
这些功能最终组成了什么
如果把 Ai Data Studio 的能力拆开来看，它似乎只是一个功能较多的数据库客户端：
数据库增删改查； AI Chat； DB Agent； Built-in Skills； 交互式 Notebook； 任务； 记忆。
但我真正想构建的，并不是这些功能的简单集合。
它们分别扮演着不同角色：
数据库：提供可信上下文和执行环境Chat：承接人的自然语言意图Agent：理解目标并组织执行Skills：提供可复用的工作方法Notebook：承载和沉淀可执行成果任务：让工作能够持续推进记忆：积累长期业务上下文
组合起来，完整链路更像是：
数据库上下文↓用户表达目标↓Agent 调用 Skills↓执行真实的数据工作↓结果进入 Notebook↓任务推动后续执行↓记忆积累长期理解
因此，Ai Data Studio 并不只是想解决：
如何让不会 SQL 的人查询数据库？
它更想解决的是：
一项数据工作，如何被 AI 理解、执行、沉淀、复用，并持续推进？
它首先仍然应该是一款好用的数据库软件
虽然我一直在强调 AI、Agent 和 Notebook，但我并不认为传统数据库能力已经不重要了。
恰恰相反，数据库层是整个产品的信任基础。
如果连接不稳定、对象浏览不好用、SQL 执行不可靠、数据编辑容易出错，那么上层的 AI 能力越强，反而可能带来越大的问题。
所以 Ai Data Studio 首先仍然要做好一款数据库软件应该完成的事情：
稳定连接数据库； 清晰展示数据库对象； 可靠执行查询； 正确呈现结果； 提供可理解的错误信息； 谨慎处理数据修改和结构变更。
AI 并不是要绕过这些专业能力，而是建立在它们之上。
我不希望做一个脱离数据库工作现场的通用聊天机器人，而是希望 Agent 真正生活在一个专业、可检查、有边界的数据工作环境里。
写在最后
我给这个软件取名为Ai Data Studio，它不是一个只能完成单次查询的工具，而应该是一个可以展开工作、保留过程、继续创作和逐渐积累资产的地方。
在 AI 时代，软件可能不再只是由人点击按钮、填写表单和执行固定流程。
人可以表达目标，AI 可以理解上下文、调用工具并完成部分工作，但最终产生的成果仍然需要可见、可编辑、可执行、可复用。
Ai Data Studio 是我对这种新型软件形态的一次实践。对于 Ai Data Studio，我现在还不敢说已经找到了最终答案。
但我越来越确定：
AI 时代真正需要重新设计的，不只是 SQL 输入框，而是整个数据工作的组织方式。
