[程序员] 感觉现在在数据库连接工具里面接 AI 也不太好使了，没有接代码库的差很多

一句话看懂：一位开发者在开源数据库连接工具 SkylerX 中接入 AI 辅助写 SQL，发现效果不佳——AI 看似生成正确，实则多为猜测。同一开发者却已大量依赖 Claude Code 完成查问题、造数据等任务，指出“工具类软件消失概率越来越大”，反映了当前 AI 在数据库场景的实用边界。

事件核心：发生了什么

一位开发者（GitHub 用户 duhbbx）在 V2EX 社区分享其开源项目 SkylerX（一款数据库连接工具）的体验。在给 AI 提供数据库连接后，AI 尝试为“根据手机号查询优惠券”场景编写 SQL，结果看似像样但实际是在“瞎猜”——不准确、不可用。开发者本人同时表示，目前已很少使用传统数据库连接工具执行 SQL，而是将跑脚本、查问题、造数据等工作全部交给 Claude Code（Anthropic 的 AI 编程工具）。他认为，这种模式比传统工具更方便，甚至预测未来类似数据库连接工具的软件会逐渐消失。

为什么重要

这一自我矛盾的体验揭示了当前 AI 代码生成的一个关键限制：缺乏上下文与代码库知识。AI 可以写 SQL，但如果无法理解业务表结构、字段含义、数据分布与历史查询模式，生成的 SQL 往往逻辑错误，尤其在涉及具体业务逻辑（如优惠券与手机号关联）时表现糟糕。与此对比，Claude Code 之所以能用，是因为它能访问完整的代码库、环境与历史记录，从而做出更准确的推断。该案例提示：AI 编程工具的能力更多取决于“是否接入了上下文”，并非单纯模型能力强就能替代所有工具。对开发者而言，选择 AI 工具的关键不在于是否“接入了 AI”，而在于是否接入了正确的信息源（如代码库、数据库元数据、业务规则）。

对用户/开发者/创作者的影响

开发者与数据工程师： 若想在数据库工具中接入 AI，不能仅提供连接字符串，需要同步表注释、字段约束、历史查询日志甚至业务文档，才能提升准确度。当前主流方案（如 Claude Code、Cursor、GitHub Copilot）都依赖代码库上下文，而不是单靠 “AI + 数据库” 的简单组合。
工具开发者与产品经理： 纯 SQL 工具接入 AI 若不解决“信息孤岛”问题，效果很容易停留在“看上去像回事”的阶段。未来可能出现的趋势是：AI 数据助手需要主动读取数据库元数据、理解业务视图，甚至自动执行多表关联推理。
普通用户与运维人员： 如果工具类软件（如数据库连接客户端、SQL 编辑器）不能进化成具备上下文理解的 AI 代理，用户可能会主动转向像 Claude Code、Cursor 这样的全能编程环境，而不是独立工具。

值得关注的后续

SkylerX 项目是否会进一步开发 AI 能力？ 目前开发者表示“没有接代码库的差很多”，如果其不解决上下文问题，AI 功能可能维持鸡肋状态。
Claude Code 在数据查询场景的普及度： 如果越来越多开发者像文中一样用 AI 编程工具替代数据库工具，是否会改变数据库管理工具市场的产品形态？
竞品跟进方向： DataGrip、DBeaver 等传统数据库工具是否会在后续版本中加入代码库感知的 AI 能力？这是判断“工具类软件是否会消亡”的重要观察点。