日常开发中，查询数据库这件事占了大量时间。写 SELECT、拼 JOIN、调 WHERE 条件——重复劳动多，出错概率也不低。如果你想让 AI 帮你接管这部分工作，Gemini 2.5 Pro 是目前一个值得尝试的选择。通过 KULAAI（k.877ai.cn） 这类聚合平台，可以直接调用 Gemini、ChatGPT、Grok 等多个模型，国内网络直连，每天有额度可用，省去了自己折腾 API 接入的麻烦。下面重点聊聊，怎么基于 Gemini 搭一个能操作数据库的 Skill。
为什么要选 Gemini 做这件事
大模型处理 SQL 任务，核心看两点：上下文窗口够不够大，以及对结构化数据的理解能力够不够强。
Gemini 2.5 Pro 的上下文窗口达到了百万 token 级别。这意味着你可以把整张数据库的表结构、字段说明、甚至部分样本数据一次性喂给它，不需要反复分段传递。对复杂业务场景来说，这个优势很实在——模型能"看到"更多上下文，生成的 SQL 准确率自然更高。
另一个值得关注的点是 Gemini 对多模态输入的支持。你可以把数据库的 ER 图截图直接丢给它，它能识别表与表之间的关联关系，这在快速理解一个不熟悉的数据库时非常方便。
Skill 的核心设计思路
所谓 Skill，本质上就是一套预设的提示词（Prompt）加上必要的工具调用逻辑。目标很明确：用户用自然语言描述需求，Skill 负责把它翻译成可执行的 SQL，执行后返回结果。
整个流程分三步：
- 1.接收用户意图——把自然语言问题转成结构化的查询需求
- 2.生成 SQL——根据数据库 schema 生成对应语句
- 3.执行并返回——跑 SQL，把结果整理成人话反馈给用户
关键在第二步。要让 Gemini 生成准确的 SQL，必须给它足够清晰的上下文。
实操：搭建过程和提示词示例
第一步：准备数据库元信息
把你的表结构导出来，整理成一段清晰的描述。比如：
text
text
数据库类型：MySQL 8.0
表名：orders
字段：
- id (INT, 主键)
- user_id (INT, 关联 users 表)
- product_name (VARCHAR)
- amount (DECIMAL)
- status (ENUM: 'pending', 'paid', 'shipped', 'completed')
- created_at (DATETIME)
表名：users
字段：
- id (INT, 主键)
- username (VARCHAR)
- email (VARCHAR)
- region (VARCHAR)
第二步：编写系统提示词
这是 Skill 的灵魂。以下是一个可直接使用的模板：
text
text
你是一个数据库查询助手。根据用户的自然语言描述，生成对应的 MySQL 查询语句。
规则：
1. 只生成 SELECT 语句，不执行任何写入操作
2. 如果用户需求模糊，先给出最合理的解读，再在回复中说明假设
3. 输出格式：先给出 SQL 代码块，再用一两句话解释查询逻辑
4. 涉及日期时，默认使用 UTC+8 时区
5. 如果查询涉及多表关联，明确写出 JOIN 条件
当前数据库结构如下：
[此处粘贴上面的表结构]
第三步：测试几个典型问题
把 Skill 部署好后，试着问它：
- "查一下上个月北京地区用户的订单总额"
- "最近 7 天有哪些订单还没发货"
- "统计每个地区购买金额排名前 3 的用户"
观察它生成的 SQL 是否正确，JOIN 条件有没有遗漏，日期范围是否合理。发现问题就微调提示词，多迭代几轮。
几个容易踩的坑
Schema 描述不够详细。 字段名是 status，但它代表什么状态？枚举值有哪些？不写清楚，Gemini 只能猜。描述越精确，输出越靠谱。
没有限制写操作。 如果不加约束，模型有可能生成 INSERT、UPDATE 甚至 DELETE。务必在提示词中明确限制，或者在代码层做二次校验。
忽略安全防护。 即便模型生成的 SQL 看着没问题，也一定要用参数化查询来执行，防止 SQL 注入。AI 生成的代码不能直接信任，该做的安全措施一步都不能省。
这套方案适合什么场景
数据分析师日常做临时查询、产品经理想自己拉数据看趋势、运营人员需要定期出报表——这些场景都很适合。它不是要取代 DBA，而是让非技术人员也能快速拿到自己想要的数据，同时把开发人员从重复性的 SQL 编写中解放出来。
Gemini 在这类结构化任务上的表现确实可圈可点，尤其是大上下文窗口带来的优势，在处理复杂业务表结构时体会会更明显。如果你正在找一个能降低数据库查询门槛的方案，不妨动手试一试。
