适用场景
- 线上偶发问题复现不了、团队已改过三版都没根治
- 想让模型先推翻自己的假设再动手改代码
- 接手别人写的状态机代码，需要快速摸清哪里会卡住
PROMPT
线上订单每天有十几单卡在「待发货」不动，排查两周没结论，团队需要换个思路从头质疑假设时用这个。 【需求】 我贴出现象和代码，你按下面的顺序分析，不要一上来就给修法： 1. 先列出这个现象所有「看起来合理但其实没被验证」的假设（至少 3 条），逐条说明怎么用一条日志或一次 SQL 证伪； 2. 再看代码里的状态流转，找出哪些路径会让订单停在待发货且不再被任何定时任务捞起； 3. 检查并发场景：两个请求同时改同一订单时，乐观锁版本号有没有可能被后到的旧版本覆盖； 4. 最后才给修法，并说明修法会不会引入新的死状态。 现象：每天 10–20 单在支付成功后状态停在待发货，超过 24 小时无变化；重试发货接口能手动推过去；没有任何报错日志。 代码：状态机有 WAIT_PAY / PAID / WAIT_SHIP / SHIPPED / DONE 五个状态，发货由 MQ 消费者触发，消费者失败会重投 3 次。 【输出要求】 1. 按上面 4 步分节输出，第 1 节的假设必须写清「怎么证伪」，不能只列猜测； 2. 第 4 节给出最小改动方案，不要重写整个状态机； 3. 最后附 3 条可以直接粘进日志的排查命令或 SQL。 ---