2026-07-13T01:47:22Z，payment-gateway HTTP 5xx错误率飙升至87.3%（基线值仅为0.8%）。订单支付成功率从99.2%断崖式下跌至63%，Prometheus监控面板上故障指标清晰可见，但Kibana错误日志中仅显示“Connection reset by peer”，缺少完整调用堆栈信息。面对这类支付网关故障，最紧迫的并非“加强监控”或“优化代码”这类泛泛之谈，而是能够直接落地、阻止下一次凌晨系统崩溃的硬性约束机制。

编写有效的改进项提示词，必须从真实故障时间戳开始锚定范围。直接粘贴你刚刚复制的告警时间戳和指标快照——2026-07-13T01:47:22Z payment-gateway HTTP 5xx错误率=87.3%（基线值=0.8%）。如果跳过这一步，Cursor会默认按“日常优化”场景生成建议，比如增加单元测试覆盖率，而你此刻真正需要的是能堵住漏洞、防止支付网关再次崩溃的硬性措施。

删除所有“建议”“可以”“应当”这类模糊动词。将“建议增加超时配置”改为“将payment-gateway对auth-service的gRPC调用超时时间从5s强制改为12s”。这些改动是底线要求，绝非可选项，而是必须执行的故障修复措施。

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

提示词开头直接粘贴你刚刚复制的告警时间戳和性能指标快照：2026-07-13T01:47:22Z payment-gateway HTTP 5xx错误率=87.3%（基线值=0.8%）。

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

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

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

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

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

【auth-service连接redis失败时，payment-gateway未执行降级熔断策略，直接抛出HTTP 500错误】

第一步：明确责任主体
由payment-gateway后端开发组在2026-07-15前完成修复

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

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

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

第五步：加入不可逆约束条件
该降级回退逻辑禁止在生产环境通过环境变量关闭，必须硬编码为true