cursor优化提示词需用动词开头的短句、明确“你”为执行主体、控制每行不超过15字，删尽“请”类敬语，禁用疑问句，确保指令可直接执行。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你在给Cursor写SQL优化提示词时，需要它既不显得居高临下、也不像在讨好用户，而是像一位坐在你工位隔壁、刚修完慢查询的DBA同事，一边敲键盘一边自然开口说话——不加敬语，不堆礼貌用语，但每句话都带着分寸感和专业底气。
把“请”字从提示词里删干净
直接说“重写这个JOIN逻辑，用EXISTS替代LEFT JOIN”，别写“请您考虑是否可以使用EXISTS替代LEFT JOIN”。【Cursor看到“请”会默认进入服务模式，输出带解释性前缀的软性建议，而不是可执行指令】
这一步操作起来很简单，删掉所有“请”“麻烦”“能否”“建议您”，只保留动词开头的短句。
用陈述句代替疑问句
方法一：把“这个WHERE条件是不是可以用IN来优化？”改成“把OR条件拆成IN列表，字段名保持为status_code”。
方法二：把“要不要加个索引？”改成“禁止建议任何CREATE INDEX操作，你只能重写SQL”。
疑问句会让Cursor误判你在征求同意，它就会回一句“可以考虑……但需评估成本”，而不是直接给你能跑通的代码。
用“你”字锚定责任主体
第一步：明确角色，“你是一名只读权限的BI分析师，不能执行DDL，也不能访问pg_stat_statements”。
Agents 正在你的整个代码库中处理越来越复杂、运行时间更长的任务。本次版本引入了新的 agent 框架改进，以实现更好的上下文管理，并在编辑器和 CLI 中带来了许多提升使用体验的修复。
第二步：绑定动作，“你负责每天9点前交付这份报表，超时将导致运营推送延迟”。
第三步：限定输出，“你输出的SQL必须能在PostgreSQL 13上直接运行，不依赖任何扩展函数”。
没有“你”，Cursor容易默认自己是文档生成器；有了“你”，它才清楚谁在执行、谁要担责、谁来验证结果。
把语气颗粒度控制在“三行以内”
方法一：用短主谓宾结构。“删掉SELECT *。”“只查v_user_event_summary视图。”“日期字段用created_at::date。”
方法二：必要时加半句理由，但不超过15字。“避免跨表排序，内存会爆。”“v_order_daily_agg已建好物化视图。”
长句+嵌套从句=AI开始脑补上下文。三行是人眼一扫就能确认是否可执行的极限长度。
