先说结论：使用 Cursor 编写日志排查清单时，最容易翻车的往往不是提示词写不好，而是忙活半天才发现生成的内容根本不是自己想要的排查路径。这种情况太普遍了：提示词改了好几轮，输出结果依然跑偏，要么漏掉了磁盘 IO 检查，要么跳过了服务依赖关系，最后反复拉扯，效率直接归零。

问题到底出在哪？其实归根结底就三点：排查物理动线没锁定、提示词写法太模糊、历史经验教训没用上。下面逐一解决。

先锁定日志排查的物理动线

打开终端 → 查看最近的异常时间点 → 定位对应的服务日志路径 → 检查错误关键词（如 Connection refused、OOM killed、timeout）→ 确认该时间点上下游服务的状态。这五步不是可选项，而是真实排查中必须烂熟于心的必经路线。提示词里如果不嵌入这个“时间—路径—关键词—依赖”的链路，Cursor 就只能泛泛而谈，给你堆砌一些套话。

怎么做？简单直接。把这五步写成中文短句，用换行隔开，粘贴到 Cursor 对话框的第一行，不加任何修饰词。别指望 AI 能自动理解你的操作习惯，你有责任把最短路径清晰地喂给它。

用“角色+约束”替代“功能描述”写提示词

一个关键技巧是：别再写“请生成一份专业的日志排查清单”这种 AI 套话。这种描述会让 Cursor 调用通用模板，绕开你手头真实面对的 kubectl 输出或 systemctl 状态。

不妨试试下面两种写法：

方法一：用运维工程师现场口吻来写
“我现在凌晨 2:17 收到告警，容器 CPU 打满，刚通过 SSH 连上服务器，/var/log/myapp 下只有 access.log 和 error.log 两个文件，还没查过 systemctl status。请按我接下来的操作顺序，只输出下一步该敲什么命令、为什么敲这句、预期看到哪几行关键输出。”

方法二：用符号强制分段
▸ 当前状态：kubectl get pods -n prod | grep myapp → 返回 Running 但 RESTARTS=3
▸ 已执行：kubectl logs myapp-7f8d4-2x9qz --previous | head -20
▸ 下一步要：检查该 Pod 所在节点的 dmesg 是否有 OOM killer 记录
▸ 输出格式：命令 + 10 字以内说明 + 预期关键词（如“Killed process”）

把历史失败提示词反向塞进新提示词

这招最老辣，也最容易被忽略。翻出上次生成后你手动删掉的那几行内容——比如“检查 DNS 配置”“验证 SSL 证书有效期”“确认 NTP 时间同步”——这些在你业务场景里根本不会发生，纯粹是干扰项。手动删掉只是第一步，更聪明的是把它们再丢回给 Cursor。

具体操作：在新提示词末尾加一句：“排除以下检查项：DNS 配置、SSL 证书、NTP 时间同步”。Cursor 会优先遵守“排除”指令，比你反复强调“只要磁盘、内存、端口、依赖服务”有效得多。

最后，把上次你补写的那句“再查一下 /var/log/syslog 里有没有‘segfault’”直接复制进来，放在提示词最底部，前面加上“必须包含：”。这样一来，历史教训和你缺失的步骤会被模型一起记住，不用反复修改稿子。

说到底，提示词优化的核心不是学会什么魔法词汇，而是摸清排查的本质，然后让 Cursor 在你的逻辑轨道上运行。