先说几个核心判断。你在用Cursor写性能定位问题的提示词时，是不是经常收到那种“打偏了”的回答？比如你问的是“为什么接口响应慢”，模型愣是给你分析了一通数据库连接池配置、前端渲染逻辑，甚至服务器磁盘IO——而真正卡点，其实就在某个没加索引的JOIN字段上。方向这么散，问题不在模型，在提示词本身。

明确锁定可观测维度

在提示词的开头，二话不说先把观测粒度亮出来。比如直接写：“仅基于APM工具（如SkyWalking）中trace链路的耗时分布图，聚焦子调用耗时占比＞30%且调用次数＞100次的节点”。不加这一句，Cursor默认会给你把全链路从头到尾讲一遍。

关键是要把那些模棱两可的词给禁掉。“可能”“大概”“一般情况下”这类词，统统删掉——它们一出现，模型就开启了发散联想模式。把“可能是缓存没命中导致的”改成“已确认Redis缓存命中率为0%，请只分析缓存穿透路径”，效果立竿见影。

最后，得把证据牢牢绑定上去。在提示词末尾追加一句“以下为真实采集数据：【粘贴火焰图片段/慢SQL执行计划/线程堆栈top3】”。【没有具体证据锚点，Cursor会自动补全虚构场景】

用结构化指令压缩推理路径

一种更高效的做法是分层过滤指令。写成一个箭头链：“先检查CPU占用率是否持续＞90% → 若否，跳过系统层分析 → 直接进入JVM堆内存dump分析 → 重点看org.apache.commons.lang3.StringUtils类实例数量”。模型沿着这个链条走，就不会再并行猜测所有可能性。

另一种有效的策略是否定约束。加入“排除以下情况：①网络延迟（已通过tcpdump确认RTT＜2ms）；②GC停顿（G1日志显示pause time均值＜10ms）；③外部依赖超时（第三方API返回码全是200）”。经验表明，模型对否定条件的遵守度远高于正向描述。

植入领域术语锚定上下文

把“接口慢”这种模糊表述替换成具体的监控数据。举个例子：“/api/v2/order/sync耗时P99=2.4s，对应trace中spanId=0x7a3f1c的AsyncHttpClient#execute耗时占比68%，该span下无子span，但threadName=pool-3-thread-5处于BLOCKED状态”。【用spanId、threadName、P99这些真实监控系统输出字段，能瞬间激活Cursor的Ja va性能分析知识图谱】

这一步操作起来很简单，直接把APM界面里看到的原始字段名搬进提示词里就行了。