Rivya 故障排查指南
排查 Rivya 常见问题：对话发不出去、上传失败、生成任务卡住、结果找不到、支付状态未更新、积分、历史记录和通知。
最近审阅于 2026/04/28
当 Rivya 的对话、上传、生成任务、历史记录、通知、积分或账单状态不符合预期时，先用这篇故障排查指南定位问题。
当 Rivya 看起来出现异常时，最快的办法不是到处乱点，而是先判断哪一层真的出了问题。
大多数问题都落在这五层之一：
- 访问与登录
- 模型和输入是否匹配
- 异步任务状态
- 钱包或支付状态
- 已保存结果到底在哪一层
这个切法，比把所有问题都当成一个“系统故障”要有用得多。
1. 对话发不出去
如果对话没法真正运行，先看最基础的几个原因：
- 你可能还停留在公开落地页，需要先登录才能发送
- 输入框里其实没有有效内容
- 某个已保存会话没有被正常加载出来
如果你怀疑是会话本身出了问题，最稳的方式通常不是继续猜原路由，而是从 历史记录 重新打开那段对话。
如果任务本身很窄、很重复，也可以考虑直接换成工具入口，而不是在一个过于开放的普通对话里继续硬撑。
2. 生成根本发不起来
如果图片、视频或音频任务在真正开始前就失败了，最常见的原因通常是：
- 提示词是必填项，但你没有提供有效内容
- 对话型音频表单没有填完整
- 当前模型要求参考文件，但你没有上传对应文件
- 当前账号积分不足
在现在的产品里，积分不足会在上游模型真正被调用之前就直接失败。所以你会感觉“好像什么都没发生”，但账号里仍然可能留下失败记录和通知。
3. 上传失败
上传规则是按模型驱动的，不是按大类统一的。
这意味着：
- 同一个类别里的模型，不一定接受同一种参考文件
- 不同模型，可接受的文件数量也不一样
- 大小和类型限制会在真正发起生成前先被拦住
如果上传失败，优先检查：
- 这个模型到底支不支持该文件类型
- 你是不是已经达到当前参考文件数量上限
- 文件大小或类型是不是超出了当前上传规则
如果任务是音频清理或人声分离，还要记得：这种需要上传文件的音频流程，和直接写提示词生成语音或 TTS，根本不是同一类路径。
4. 任务卡住
Rivya 里的 image、video、audio 都走异步任务模型。
当前可见状态是：
WAITINGGENERATINGSUCCESSFAILED
如果你觉得任务“卡住了”，不要只盯着当前页面看。
一起检查这些地方：
有些任务依赖回调完成，有些任务需要轮询或手动刷新才能补齐最终状态。所以“还在生成”并不等于“丢了”，很多时候只是上游结果还没真正写回。
5. 任务失败了
在 Rivya 里，失败通常会被保留下来，而不是被藏掉。
一条失败任务可能会保留：
FAILED状态- 错误信息
- 如果符合条件，还会显示退款状态
- 一条生成失败通知
更好的下一步通常是：
- 先看清楚失败状态
- 判断问题到底来自积分、prompt，还是输入不匹配
- 修正具体原因后再重新发起
不要把所有失败都当成短暂 UI 抖动。
6. 结果像是消失了
大多数时候，结果不是消失了，而是你去了错误的页面找。
当问题是：
我到底做过什么、聊过什么？
去看 历史记录。
当问题是：
账号层或工作流层到底发生了什么？
去看 通知中心。
可以这样记：
- 对话回到对话历史
- 图片、视频、音频回到生成历史
- 账单和积分事件通常在通知中心里看得更清楚
7. 支付状态没更新
如果结账已经完成，但钱包或账单看起来还是旧状态，先按支付链路检查，不要直接假设支付丢了。
当前产品流程是：
- 完成结账
- 回到
/payment - 让产品轮询并刷新账单或钱包状态
- 再去
/settings/billing或/settings/credits看
通知中心也可能保存这类账单事件，所以当账号状态看起来不同步时，也值得一起检查。
8. 先看哪个页面
可以直接这样判断：
- 当前 Studio：正在进行中的实时工作
- 历史记录：已保存的输出和会话
- 通知中心：已经发生过的运营事件
/settings/billing：订阅状态/settings/credits：余额、积分包、过期和交易记录
很多“排查半天还没找到原因”的情况，本质上只是第一步去了错误的层。
下一步建议
排障分流检查清单
先判断该从哪里排查，不要反复点同一个动作：
- Chat 发不出去：检查登录、会话状态、模型可用性和积分行为。
- 上传失败：检查文件类型、大小、模型支持，以及这条任务是否真的需要文件。
- 生成卡住：检查任务状态、provider 回调、轮询、历史记录和通知。
- 账单状态旧：检查 Checkout 返回、webhook 落定、billing 设置和 credits 设置。
- 结果像是丢了：检查正确的历史分类，以及任务是否真的完成。
升级处理前先复核
只有当你能说清账户区域、任务 ID 或支付上下文、期望结果、实际结果和最后可见状态时，才适合升级处理。这样支持才是在诊断，而不是猜。