1. 为什么你写的 SQL 总是“差点意思”？——DBeaver 里那层看不见的 AI 隔膜
我接手过三个不同团队的 SQL 审查任务，发现一个高度一致的现象：90% 的低效查询、冗余 JOIN、漏写 WHERE 条件、甚至字段类型误用，都不是因为开发者不会写 SQL，而是因为他们在 DBeaver 里敲完SELECT * FROM后，下意识停顿了——不是在思考业务逻辑，而是在等那个“该出现却没出现”的补全提示。他们以为 AI 编程工具该自动接上users u JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid'，结果光标孤零零悬在分号前。
这不是能力问题，是上下文断裂。DBeaver 默认的 SQL 编辑器，本质上是个“哑终端”：它认识语法，但不认识你的表结构、不认识你上周刚加的tenant_id字段、更不认识你项目里约定俗成的别名规则（比如所有订单表必须 alias 为o，所有用户表必须是u）。AI 编程工具再强，喂给它的上下文只有当前光标所在行的几个字符。这就像让一个顶级厨师做菜，只给他看砧板上的一片葱花，却不告诉他今天主菜是红烧肉还是清蒸鱼。
更麻烦的是，很多团队把“AI 辅助编程”简单等同于“装个插件点几下”，结果模板越堆越多，补全越配越深，SQL 质量反而滑坡——因为没人告诉 AI：哪些字段绝不能 SELECT *，哪些 JOIN 必须带索引提示，哪些 WHERE 条件必须走分区键。这些约束不是写在配置文件里的，是刻在团队代码规范里的。
所以这篇不讲“怎么打开 AI 插件”，也不列“To
