在日志排查过程中，很多人会借助Cursor生成检查清单，但最常遇到的痛点就是——内容过于空泛。表面上看列出了一堆项目，实际遇到线上故障时，几乎找不到可落地的条目。问题根源在于缺乏可执行的具体抓手。
那么，如何让生成的清单真正具备实战价值？关键在于三个维度：精准限定范围、绑定具体现象、强制使用动作动词。
明确限定日志来源与时间范围
先讲第一个要点。提示词开头必须写清楚日志来源，例如“Spring Boot微服务中的order-service日志”。这一步绝对不能省略——不指定服务名称，Cursor会自动虚构一个通用模板，后续步骤会完全偏离方向。
第二步，强制设定一个时间窗口。“仅分析2024-06-12T14:22:00Z至14:25:00Z之间输出的日志行”，加上这个条件，才能有效区分冷热数据。否则生成的清单里会混入各种陈年旧账，干扰判断。
第三步，再补充一条过滤规则：“忽略INFO级别以下且不含异常堆栈、HTTP状态码或SQL关键词（如‘timeout’‘duplicate’‘500’‘ROLLBACK’）的日志行”。这一步能直接过滤掉90%的噪音内容，剩下的才是真正需要关注的线索。
绑定真实错误现象反推检查点
方法其实并不复杂。直接把运维同学反馈的原始异常现象嵌入提示词。例如：“用户提交订单后前端一直显示‘加载中’，Nginx access.log里对应请求返回了504，但order-service日志最后一条是‘Sending to payment queue’”。Cursor收到这个输入后，自然会生成“检查payment-service连通性”“查看RabbitMQ队列堆积量”这些具体可操作的条目。
另一个更直接的做法：给出一条典型错误日志原文，用三个反引号包裹。例如：
2024-06-12 14:23:17.882 ERROR [order-service,,] 12345 --- [nio-8080-exec-7] c.e.o.c.OrderCreateController : Order creation failed: org.springframework.dao.DuplicateKeyException: PreparedStatementCallback; SQL [INSERT INTO orders(...)]; Duplicate entry 'ORD-20240612-7789' for key 'uk_order_no'
这样一来，生成的清单必然包含“检查orders表uk_order_no索引是否生效”“确认订单号生成逻辑是否存在并发冲突”这类硬核检查项。
强制输出结构化动作动词
最后一步，在提示词末尾增加一条硬性约束：“每条检查项必须以动词开头：查/连/抓/比/重放/重启/删缓存/改配置/补监控。禁止出现‘应关注’‘建议检查’‘可能涉及’等模糊表述。”
这一刀下去，所有空话都会被彻底清除。比如“注意数据库连接池配置”这类表述不会再出现，取而代之的是“查HikariCP activeConnections值是否达maxPoolSize”——这才是真正能落地的执行动作。