在写故障影响说明时，最忌讳的就是模糊表达。先明确三个核心锚点：故障模块是订单支付网关，中断时段是2026年7月12日14:23到15:47，核心指标是支付宝渠道支付成功率从99.92%跌至31.6%。所有描述必须基于这些锚点，不能使用推测性措辞。影响订单数19,427单，涉及商户386家，已确认资损¥842,563.20，人工补单耗时67.5人·小时。

用三锚点锁定影响范围

第一步，在提示词开头明确写清楚三项锚点：故障模块、中断时段、核心指标。比如，故障模块是订单支付网关，中断时段是2026年7月12日14:23到15:47，核心指标是支付宝渠道支付成功率从99.92%跌至31.6%。

第二步，加上刚性约束——所有描述必须基于上述三锚点推导，禁止出现‘可能’‘估计’‘疑似’等推测性措辞。

第三步，强制要求字段对齐，例如：“影响订单数：______单；涉及商户：______家；资损金额（已确认）：______元；人工补单耗时：______人·小时”。豆包会严格填空，不加解释、不补背景。

按业务角色分层写影响

方法一：面向技术团队——只写系统级事实。例如，“支付回调超时率峰值达92%，持续17分钟；下游ERP库存扣减延迟平均42秒；日志中ERROR级别报错共12,843条，集中在com.pay.gateway.retry.RetryPolicy类第87行。”

方法二：面向业务方——绑定具体动作与损失。例如，“期间共拦截2,146笔应发优惠券，导致1,832名用户未享受满减；3个自营直播间因支付失败触发自动下播，累计观众流失47,300人次。”

方法三：面向客服中心——聚焦可执行话术。例如，“统一应答口径：‘您7月12日14:23–15:47下单未成功，系统已自动重试，订单号尾号XXXX已补发电子券，有效期延至7月19日’。”

禁用泛化词并替换为可验证短语

把“用户体验下降”改为“iOS端支付页加载失败率升至68%，Android端点击‘去支付’按钮后平均白屏4.7秒”。

把“部分功能不可用”改为“微信JSAPI支付接口返回code=500且msg=‘signature invalid’，错误率100%持续23分钟”。

‘不可用’必须附带HTTP状态码或错误字符串，否则豆包默认补全‘暂未查明原因’

强制输出带时间戳的验证项

在提示词末尾加一句：“请用‘验证项’小标题列出2条可回溯验证的影响结论，每条含明确时间点与可观测指标。”

✅ 14:25:13起，Nginx access.log中pay_callback路径5xx响应占比突破85%，持续至15:47:02；

✅ 15:03:22开始，数据库order表payment_status=‘pending’且create_time∈[‘2026-07-12 14:23:00’,‘2026-07-12 15:47:00’]的记录新增1,942条。