Cursor写事故改进项提示词如何更像真实搜索需求

2026-07-13T01:47:22Z payment-gateway HTTP 5xx rate=87.3% (baseline=0.8%)。payment-gateway后端组在2026-07-15前于src/services/payment/gateway.ts第214行插入fallback逻辑，当auth-service返回503时跳过token校验走本地缓存权限；上线后curl -H "X-Debug: true" http://localhost:3000/api/pay响应体必须含"fallback_used:true"；代码提交至feature/2026Q3-payment-fallback分支并关联Jira PAY-482；该fallback逻辑硬编码启用，prod环境禁止通过环境变量关闭。

☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜

你在凌晨1:47收到PagerDuty告警，订单支付成功率从99.2%骤降至63%，查完Prometheus发现payment-gateway服务HTTP 5xx错误率飙升，但Kibana里error日志只显示“Connection reset by peer”，没看到具体堆栈——现在要快速生成可落地的改进项，不是泛泛而谈“加强监控”“优化代码”。

用真实故障时间戳锚定改进项范围

在提示词开头直接粘贴你刚复制的告警时间戳和指标快照：2026-07-13T01:47:22Z payment-gateway HTTP 5xx rate=87.3% (baseline=0.8%)。

这一步必须做，否则Cursor会默认按“日常优化”场景生成，比如建议加单元测试覆盖率——而你此刻需要的是能阻止下次凌晨崩溃的硬性约束。

删掉所有“建议”“可以”“应当”类模糊动词，把“建议增加超时配置”改成“将payment-gateway对auth-service的gRPC call timeout从5s强制改为12s”。

绑定具体失败链路而非抽象模块名

方法一：用箭头链描述真实调用路径
payment-gateway → auth-service（gRPC）→ redis（sentinel模式）→ mysql（主从延迟>12s）

方法二：嵌入你刚执行过的验证命令和结果
kubectl exec -n prod payment-gateway-6b8c4-9x2qz -- curl -v http://auth-service:8080/health → 返回503；
kubectl logs -n prod auth-service-7f9d2-p5r8s --since=10m | grep “redis” → 输出“ERR Connection refused”

【auth-service连接redis失败时，payment-gateway未做降级熔断，直接抛出500】

强制输出带责任人的可执行项

第一步：明确动作主体
由payment-gateway后端组在2026-07-15前完成

第二步：限定技术实现方式
在src/services/payment/gateway.ts第214行插入fallback逻辑，当auth-service返回503时，跳过token校验直接走本地缓存用户权限

第三步：写死验证方式
上线后执行curl -H “X-Debug: true” http://localhost:3000/api/pay → 响应体必须含"fallback_used:true"

第四步：指定交付物位置
修改后的代码必须提交到feature/2026Q3-payment-fallback分支，并关联Jira任务PAY-482

第五步：加入不可逆约束
该fallback逻辑禁止在prod环境通过环境变量关闭，必须硬编码为true