上线检查清单严格按物理路径锚定：【CI流水线触发→镜像推送到harbor→k8s集群滚动更新→ingress生效→监控大盘确认】；查kubectl get pods -n prod -l app=order-service输出中READY列是否全为“1/1”；连prod集群内任意node节点，执行nc -zv payment-service.prod.svc.cluster.local 8080；抓取order-service Pod中Java进程堆栈：jstack $(pgrep -f 'java.*order-service') > /tmp/heap.log；比对当前版本Git commit hash与harbor镜像标签是否一致；查harbor UI确认v2.3.1镜像digest是否完整；kubectl get deploy order-service -o jsonpath='{.status.conditions[?(@.type=="Progressing")].reason}'；curl -sf http://localhost:8080/actuator/health | jq '.status'；Prometheus中query 'rate(http_request_duration_seconds_count{job="order-service",status=~"5.."}[5m])'结果若＞0.01则失败；Grafana面板ID 7892中‘Order Create Success Rate’曲线若低于99.95%需中断上线；NewRelic中Apdex分数＜0.92时自动触发rollback；排除NTP时间同步、SSL证书、DNS TTL、
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让Cursor生成的上线检查清单每一条都指向真实环境里的具体操作，而不是反复出现“检查配置”“确认权限”“验证连通性”这类万金油式条目。
用真实部署动线锚定检查点
第一步：在提示词开头写明本次上线的物理路径——【必须包含：从CI流水线触发→镜像推送到harbor→k8s集群滚动更新→ingress生效→监控大盘确认】这五步不可跳过。不写清动线，AI会默认从“git push”开始编排，漏掉harbor校验、ingress就绪探针等关键断点。
第二步：把CI输出日志里真实出现的行号和关键字直接塞进提示词。例如：“CI日志第142行显示‘pushed to harbor.mycompany.com/prod/order-service:v2.3.1’，第189行报错‘waiting for rollout status: timeout’”。Cursor会据此生成“查harbor UI确认v2.3.1镜像digest是否完整”“kubectl get deploy order-service -o jsonpath='{.status.conditions[?(@.type==\"Progressing\")].reason}'”等带真实路径的动作。
第三步：指定检查动作必须绑定到具体工具命令。禁止出现“检查健康状态”，必须写成“curl -sf http://localhost:8080/actuator/health | jq '.status'”，否则AI会泛化为抽象描述。
注入业务级故障模式反推检查项
方法一：贴出最近一次线上回滚的真实原因
把SRE复盘报告里那句“因payment-service未同步更新Redis缓存key格式，导致订单支付成功但状态未刷新”原样复制进提示词。Cursor会生成“比对payment-service v2.2与v2.3的redis-key-template.yml差异”“在Redis中执行KEYS 'order:*:status'确认是否存在旧格式key”等业务强相关条目。
方法二：给出灰度阶段暴露的具体异常现象
例如：“灰度5%流量时，/api/v1/orders接口P99延迟从120ms升至2.4s，但CPU/内存无明显变化”。这会让AI聚焦于“抓取该接口SQL慢查询日志”“检查MyBatis二级缓存命中率指标”“比对灰度Pod与全量Pod的JVM Metaspace使用量”，而非泛泛而谈“检查数据库连接池”。
强制字段级可执行动词
① 每条检查项必须以动词开头，且动词需匹配真实操作对象：
查 → 查kubectl get pods -n prod -l app=order-service输出中READY列是否全为“1/1”
Agents 正在你的整个代码库中处理越来越复杂、运行时间更长的任务。本次版本引入了新的 agent 框架改进，以实现更好的上下文管理，并在编辑器和 CLI 中带来了许多提升使用体验的修复。
连 → 连接prod集群内任意node节点，执行nc -zv payment-service.prod.svc.cluster.local 8080
抓 → 抓取order-service Pod中Java进程堆栈：jstack $(pgrep -f 'java.*order-service') > /tmp/heap.log
比 → 比对当前版本Git commit hash与harbor镜像标签是否一致（curl -H "Authorization: Bearer $TOKEN" https://harbor.mycompany.com/api/v2.0/projects/prod/repositories/order-service/artifacts/v2.3.1）
② 禁止出现“确认”“确保”“验证”等虚动词，全部替换为“查/连/抓/比/重放/删缓存/改配置”。例如不写“确认服务已启动”，而写“查systemctl is-active order-service返回active”。
排除历史无效检查项
翻出过去三次上线检查清单里被你手动删掉的条目，比如“检查NTP时间同步”“验证SSL证书有效期”“核对DNS解析TTL”。在新提示词末尾加一句：【排除以下检查项：NTP时间同步、SSL证书、DNS TTL、Kubernetes集群版本兼容性】。Cursor会优先遵守排除指令，比反复强调“只要镜像、配置、依赖、监控”更有效。
绑定实时监控数据锚点
在提示词中嵌入当前监控系统的真实指标路径和阈值：
“Prometheus中query ‘rate(http_request_duration_seconds_count{job=\"order-service\",status=~\"5..\"}[5m])’结果若＞0.01则失败”
“Grafana面板ID 7892中‘Order Create Success Rate’曲线若低于99.95%需中断上线”
“NewRelic中Apdex分数＜0.92时，自动触发rollback流程”
没有监控锚点的检查项一律视为无效——它无法被值班同学一键执行或自动化拦截。
