加载失败
pgAdmin 4 是 PostgreSQL 的图形化管理工具，9.13 版本在 query tool 中加入了 "AI Assistant" 面板以借助外部模型生成或解释 SQL。讨论从是否能关闭、如何配置 provider，以及服务器端开关（LLM_ENABLED 在 config.py 中）是否必须启用展开；文档提到可将默认 provider 设为 'None'，但用户仍担心默认存在该功能会扩大攻击面。部分用户倾向于完全不在管理工具中使用 AI，而选择独立 chatbot 或自写 Python 脚本来查询数据库并在 CLI 呈现结果。另有实用修复被提出（如点击 "Reset layout" 将 AI 标签移走），反映出社区在便利性与可控性之间的权衡。
部分用户明确表示最有效的 LLM 交互是独立的聊天式界面，喜欢把代码片段复制粘贴到聊天框而非让 IDE 或管理工具猜测意图。有人把嵌入式的“AI 助手”视为视觉或功能上的干扰，升级后第一反应就是找办法移除它。另有评论以 MongoDB Compass 和 Cloudwatch 的“sparkle”图标为例，抱怨内置模型常常无用，因而更愿意用 Python 脚本直接查询 Postgres 并在 CLI 渲染结果以维持可控性和可预测性。总体上这类用户倾向于把 AI 功能与日常数据库运维工具分离，而不是让厂商在管理界面强制植入。
不少评论对将 AI 放入数据库管理工具带来的数据泄露风险表示担忧，尤其是找不到明显禁用选项时更令用户不安。有人强调即便只是用于测试/预发布，也不希望把潜在的非确定性特性或外部模型引入到管理界面，以免扩大攻击面或泄露 schema/敏感信息。还有观点认为若不想要这些功能，就不必使用 GUI 管理工具，直接用原生 Postgres 或脚本操作以降低风险。总体论调把焦点放在暴露凭据、元数据和增加不可控调用链的危险上，而非单纯的功能便利。
另一类评论认为风险是可控的：AI 模型本身不能直接在数据库上执行命令，它主要读取 schema 帮助生成查询；而且功能需要显式配置外部提供者和凭证，若不提供就无法工作。官方文档提到可以将默认 provider 设为 'None' 来禁用 AI 功能，同时这些偏好项只有在服务器端将 LLM_ENABLED = True（在 config.py 中）时才会出现。对于界面层面，已有简易修复方法，例如在 query tool 里点击“Reset layout”将 AI Assistant 标签移到右侧，使默认查询仍回到 Query 标签页。综上，反对嵌入式 AI 的用户可以通过不配置 provider、调整服务器端开关或简单的 UI 重置来回避该功能。
LLM: LLM（Large Language Model，大型语言模型）：用于生成自然语言或 SQL 建议的机器学习模型，pgAdmin 的 AI 功能通常通过外部 LLM 提供者来生成响应。
LLM_ENABLED（config.py）: LLM_ENABLED：pgAdmin 服务器端配置项（位于 config.py），必须设置为 True 才会在客户端偏好中显示并启用 AI/LLM 相关选项。
AI provider: AI provider：指提供 LLM 服务的外部模型供应商（需在 pgAdmin 中配置 API 凭证）。如果不配置或将默认 provider 设为 'None'，则无法调用外部模型。