订单创建服务在09:13–09:47期间返回500错误，影响微信小程序端全部下单链路，不涉及APP端与H5；① 微信小程序下单成功率从99.2%跌至63.1%（监控路径：APM→wx-order→/api/v1/create）；② 支付回调超时订单达287单（数据源：kafka topic ‘pay-callback-fail’）；③ 人工客服咨询量峰值达142次/分钟（来源：智能客服系统工单日志）。

让Gemini为一次线上故障生成可直接用于通报、复盘或升级的故障影响说明时，直接写“请描述故障影响”只会得到笼统的“部分用户访问异常”——真正要命的不是“出了问题”，而是“谁卡在哪”“钱少赚多少”“哪个接口断了却没人告警”。下面这套方法，就是用来解决这个问题的。

锁定影响范围与可观测边界

第一步：在提示词开头用一句话写死本次故障的真实业务切面。例如：“订单创建服务在09:13–09:47期间返回500错误，影响微信小程序端全部下单链路，不涉及APP端与H5。”

第二步：强制要求只识别三类必须写入影响说明的硬指标，且每条必须带可验证路径。例如：“① 微信小程序下单成功率从99.2%跌至63.1%（监控路径：APM→wx-order→/api/v1/create）；② 支付回调超时订单达287单（数据源：kafka topic ‘pay-callback-fail’）；③ 人工客服咨询量峰值达142次/分钟（来源：智能客服系统工单日志）。”

【未绑定具体监控路径的影响描述等于无效描述】

第三步：追加不可绕过约束：“若指标无实时采集能力，则该条不纳入影响说明；禁止使用‘大量用户’‘明显下降’等无基准表述。”

按角色视角拆解影响颗粒度

方法一：面向业务方——聚焦营收、客诉、SLA违约

在基础描述后追加：“你是一名技术运营负责人，正在向CTO和财务总监同步故障影响。任务：生成一段不超过120字的口头通报稿，含明确金额损失（按单均GMV 86元×失败订单数）、客诉峰值时段、及是否触发SLA罚则（合同约定可用性99.95%，本次跌至99.71%）。”

方法二：面向研发团队——聚焦调用链断裂点与兜底失效

追加：“你是一名SRE工程师，正在编写故障复盘初稿。任务：列出3个关键影响事实，每个事实必须包含‘上游服务→本服务→下游服务’完整调用路径，以及该路径上唯一生效的兜底策略是否被触发（如‘wx-gateway→order-create→inventory-check，熔断器开启但降级返回空库存’）。”

方法三：面向客服团队——聚焦用户感知与话术锚点

追加：“你是一名一线客服组长，正在更新今日FAQ文档。任务：写出2句用户可能问到的问题+对应标准应答，问题需来自真实会话日志高频词（如‘提交没反应’‘一直转圈’），应答中禁用技术词，必须包含明确动作指引（如‘请退出小程序重新登录，再试两次’）。”

注入时间锚点与状态快照

第一步：所有影响描述必须标注精确时间窗口。例如：“09:13:22 首次出现500错误 → 09:15:08 熔断器触发 → 09:47:11 全量恢复。”

第二步：在每个关键时间点后，强制追加一个可观测状态快照。例如：“09:15:08 熔断器触发 → 此时 /api/v1/create 接口TPS从1240降至37，下游 inventory-check 服务健康检查失败率100%。”

第三步：对“恢复”给出可验证定义。例如：“全量恢复 = 连续5分钟内下单成功率 ≥99.2%（基线值），且支付回调失败数归零。”