DBeaver 26.1.4 的更新重点落在 AI 助手的日常可用性上：AI 聊天增加键盘访问能力，生成的脚本可以始终在新的 SQL 控制台中打开，同时修复了部分模型无法动态支持温度参数的问题。这些改动看似细小，却直接影响开发人员审查、修改和执行 AI 生成 SQL 的效率与安全性。
键盘访问让 AI 聊天进入高频工作流
数据库操作经常需要在对象树、SQL 编辑器、结果集和执行计划之间切换。AI 聊天支持键盘访问后，开发人员可以减少鼠标操作，更快地完成“选中上下文、提出问题、检查 SQL、继续编辑”这一连串动作。
需要注意的是，发布摘要只说明增加了一些快捷键，并未列出具体按键。升级后应在 DBeaver 的快捷键设置中搜索 AI 或 Chat，确认当前操作系统和键位方案下的实际绑定，并检查是否与输入法、窗口管理器或已有 SQL 编辑快捷键冲突。
团队也不必强制统一所有快捷键。更值得统一的是操作规则，例如：
- AI 可以帮助生成查询、解释执行计划和补充注释。
- 生成结果必须进入 SQL 编辑器审查，不能直接视为可执行答案。
- 涉及写操作时，先确认目标数据库、Schema、过滤条件和事务范围。
- 生产环境中的高风险语句继续走审核或变更流程。
新 SQL 控制台是一条重要的安全边界
26.1.4 新增了“始终在新的 SQL 控制台中打开 AI 生成脚本”的能力。它的价值不只是界面整洁，更在于隔离上下文。
复用现有控制台可能继承当前连接、活动 Schema、未提交事务或临时会话设置。将 AI 脚本放入独立控制台后，开发人员更容易看清这段 SQL 从哪里开始，也更容易在执行前逐项核对连接和事务状态。
可以把 AI 生成的查询整理成下面这种可审查脚本。运行前需要将 orders、字段名和日期范围替换为实际对象；示例使用 PostgreSQL 语法。
-- 1. 先确认当前会话连接到了哪个数据库和 Schema
SELECT current_database() AS database_name,
current_schema() AS schema_name,
current_user AS session_user;
-- 2. 只读检查：统计指定时间范围内的订单状态
SELECT status,
COUNT(*) AS order_count,
SUM(total_amount) AS total_amount
FROM orders
WHERE created_at >= DATE '2026-01-01'
AND created_at < DATE '2026-02-01'
GROUP BY status
ORDER BY order_count DESC;
如果 AI 生成的是更新语句，可以先用事务包裹，并将相同条件改写成 SELECT 验证命中范围。下面仍以 PostgreSQL 为例：
BEGIN;
-- 执行前先检查即将被修改的记录
SELECT id, status, updated_at
FROM orders
WHERE status = 'pending'
AND updated_at < CURRENT_DATE - INTERVAL '30 days'
ORDER BY updated_at
LIMIT 100;
-- 确认范围后再考虑执行 UPDATE
-- UPDATE orders
-- SET status = 'expired'
-- WHERE status = 'pending'
-- AND updated_at < CURRENT_DATE - INTERVAL '30 days';
-- 首次验证时默认回滚；确认无误后再改为 COMMIT
ROLLBACK;
这类脚本比一条孤立的 UPDATE 更适合从 AI 助手流转到 SQL 控制台，因为连接确认、影响范围检查和回滚策略都保留在同一份上下文中。
温度参数修复意味着更可靠的模型兼容
本次版本还修复了部分模型无法动态支持温度参数的问题。温度通常用于调节生成结果的随机程度，但不同模型和服务对该参数的支持并不一致：有的接受任意范围内的值，有的只支持固定值，还有的完全不接受该参数。
这里的关键不在于为 SQL 生成寻找一个“最佳温度”，而是让客户端根据模型能力处理配置，避免把不受支持的参数机械地发送给服务端。对于数据库场景，低随机性通常更便于复现和审查，但温度设置不能替代以下检查：
- 表名和字段是否真实存在。
- SQL 方言是否与当前数据库一致。
JOIN条件是否会造成重复计数。UPDATE或DELETE是否包含准确的过滤条件。- 查询是否可能触发全表扫描、长事务或大范围锁。
发布摘要还提到 OpenAI 引擎配置相关更新，但现有信息并不完整，因此升级后应以 DBeaver 26.1.4 的实际配置界面和版本说明为准，不宜依据截断信息推断具体字段或默认行为。
升级前后的落地检查
个人开发环境可以直接验证这次更新是否改善了 AI 工作流；团队环境则适合先选取一个非生产连接进行试用。建议按以下顺序检查：
- 备份或记录现有 AI 引擎配置，尤其是服务地址、模型名称和认证方式。
- 升级后检查 AI 聊天快捷键，并处理操作系统级快捷键冲突。
- 开启 AI 脚本始终使用新 SQL 控制台的选项，确认连接选择符合预期。
- 分别测试当前使用的模型是否接受温度参数，以及切换模型后配置是否正确变化。
- 用只读查询验证生成质量，再测试事务内的写操作，不要直接连接生产库试验。
- 检查日志和请求配置，避免 API 密钥、业务数据或敏感 Schema 信息被不必要地暴露。
DBeaver 26.1.4 没有改变 AI 生成 SQL 必须人工审查这一基本原则，但它改善了从聊天到编辑器的操作路径，并为不同模型的参数能力提供了更稳妥的处理。对频繁使用 AI 助手的开发人员来说，这些变化足以成为一次值得验证的小版本升级。