Cursor做SQL查询字段不明确，本质是模型缺乏数据库元数据上下文；需在提示词开头粘贴CREATE TABLE语句，说明主键与外键，用“我要查……对应的……”锁定逻辑，对歧义字段加业务限定，并强制指定输出格式与字段来源约束。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
Cursor做SQL查询时字段不明确，本质是模型没收到足够上下文来判断表结构和业务含义，不是提示词“不够聪明”，而是缺关键约束信息。
补全数据库元数据信息
在提示词开头直接粘贴目标表的 CREATE TABLE 语句或字段清单。例如：CREATE TABLE users (id INT, name VARCHAR(50), email VARCHAR(100), created_at DATETIME);。这比写“查用户信息”有效十倍——模型没有数据库连接能力，【不提供表结构，它只能靠猜】。
Agents 正在你的整个代码库中处理越来越复杂、运行时间更长的任务。本次版本引入了新的 agent 框架改进，以实现更好的上下文管理，并在编辑器和 CLI 中带来了许多提升使用体验的修复。
如果表字段多、关系复杂，额外加一句说明主键和常用关联字段，比如：“users.id 是主键，orders.user_id 外键关联 users.id”。否则模型可能把 email 当成关联字段去 join。
用自然语言锁定字段用途
方法一：用“我要查……对应的……”句式。 比如不说“查订单金额”，而写“我要查每个用户的最新一笔订单对应的金额”。这样模型能识别出要聚合（MAX(created_at)）、要关联（users→orders）、要提取（amount 字段）。
方法二：对歧义字段加业务限定。 如表里有 price、cost、fee 三个数值字段，就不要写“查价格”，改写为“查客户实际支付的订单价格（即 price 字段，不含运费和税费）”。【字段名本身不带业务含义，必须人工注入】。
强制指定输出格式并约束字段来源
第一步：在提示词末尾明确要求“只返回标准SQL语句，不解释，不加```sql代码块”。 第二步：追加约束条件：“所有字段必须来自上述提供的表结构，禁止虚构字段名或表别名”。 第三步：如果涉及多表，加上“使用显式 JOIN 语法，ON 条件必须基于已知外键关系”。
这三步能砍掉 80% 的“unknown column”报错。模型常默认用隐式逗号连接+WHERE关联，一旦字段名在多个表中重复（比如两个表都有 id），就会报错。
