最容易误解的一点，是把 Rivya API 和 Rivya Studio 看成互相竞争的两条路。
更准确的理解是：它们是同一套产品里的两个阶段。Studio 适合人在里面探索、选择、复核和继续推进；API 适合把已经稳定的工作流接进自己的产品、脚本或后端流程。
如果你还在了解 API 本身，先读 Rivya API 是什么？。这篇只解决一个更具体的问题：某个任务到底该留在 Studio，还是搬到 API。
先看这张判断表
| 问题 | 更适合 Studio 的情况 | 更适合 API 的情况 |
|---|---|---|
| 输出还在探索吗？ | 是 | 否，流程已经可重复 |
| 需要人工比较结果吗？ | 需要 | 只需要在你的产品里接收后再复核 |
| 模型选择稳定吗？ | 还不稳定 | 已稳定，或可从 API 模型列表里选择 |
| 需要参考素材吗？ | 人还在准备和筛选素材 | 应用可以通过 Files API 上传 |
| 结果要更新另一个系统吗？ | 暂时不需要 | 需要，通过轮询或 Webhook |
| 积分使用需要可见吗？ | 测试阶段尤其需要 | 也需要，但通过账号级 API 控制处理 |
这不是在比较哪个入口更高级，而是在判断任务是否已经适合自动化。
工作还在变化时，用 Studio
当主要工作仍然是人的判断时，Studio 更合适。
包括：
- 在图片、视频、音频或 Chat 模型之间选择
- 测试某个提示词方向值不值得继续
- 肉眼比较多个视觉结果
- 判断参考素材是否真的有帮助
- 从历史记录继续上一次结果
创意工作尤其如此。如果 brief 还不稳定，把请求自动化通常只会让混乱变快，不会让问题变小。
工作流可重复时，用 API
当输入和下一步足够可预测时，API 才更适合。
比较好的信号包括：
- 产品已经知道需要哪个模型或模型类型
- 用户输入可以稳定映射成请求体
- 后端任务可以轮询状态，而不需要人盯着页面
- 任务完成后可以用 Webhook 更新正确记录
- 应用可以向团队或账号负责人解释积分消耗
到了这个阶段，每次都打开 Studio 反而会变慢。API 可以让你的产品直接开始任务。
一个实用边界：发现和接入
用 Studio 做发现。
用 API 做接入。
发现阶段的问题通常是：
- “该用哪个模型？”
- “什么提示词结构有效？”
- “参考素材对这个任务有没有帮助？”
- “这个质量是否适合当前用途？”
接入阶段的问题通常是：
- “这个用户动作应该创建一条生成任务。”
- “这个任务应该用幂等方式重试。”
- “这个文件应该上传后绑定到模型请求。”
- “任务完成后应该更新我们的产品记录。”
这个边界能避免把 API 变成一个藏在后台里的实验入口。
积分怎样影响选择
Studio 和 API 都使用同一个 Rivya 账户积分。
所以积分行为应该是产品设计的一部分，而不是接入完成后再补解释。
团队还在学习成本结构时，先用 Studio。任务稳定到产品能解释“什么时候预留或消耗积分”时，再用 API。
当前公开规则见 API 积分。如果一个流程贵到无法向账号负责人解释，就还不适合自动化。
文件会怎样改变选择
参考素材往往是接入变复杂的地方。
在 Studio 里，人可以上传、查看、重试，并判断文件是否足够好。在 API 里，你的产品需要通过 Files API 明确处理文件。
下面情况继续用 Studio：
- 参考图片、视频或音频还需要人工清理
- 团队还不确定哪个参考素材该指导模型
- 文件规则还没办法讲清楚
下面情况可以考虑 API：
- 应用可以安全收集文件
- 模型的参考要求已经明确
- 文件可以在生成或 Chat 请求前先上传
- 错误能在你的产品里清楚展示，而不是被隐藏
Files API 是桥梁，但它不能替你设计好文件体验。
Chat 怎样影响选择
Chat 两边都可能适合。
当人还在探索、写作、复核或决策时，直接使用 Rivya Chat。
当一轮 Chat 需要出现在你自己的产品或服务端流程里时，使用 Chat API。它可以覆盖非 streaming、可选 SSE streaming、API 创建的 session 和支持的文件附件。
关键问题是：这段对话应该活在哪里？如果它是 Rivya 工作的一部分，用 Rivya；如果它是你产品体验的一部分，用 API。
什么时候 Webhook 是信号
如果你的工作流已经需要 API Webhooks，它通常已经超过了纯手动 Studio 阶段。
Webhook 适合另一个系统需要响应生成任务完成的场景：
- 标记素材可用
- 通知用户
- 推进审核步骤
- 把失败任务送入支持或重试逻辑
这是接入工作。Studio 仍然适合测试模型路径，但生产闭环应该交给 API。
一个稳妥的迁移顺序
不要一口气把整条工作流搬进 API。
建议按这个顺序：
- 先在 Studio 里人工测试任务
- 记下稳定的模型、提示词结构、输入文件和预期结果
- 阅读 API 模型列表 和模型参考
- 按 API 快速开始 提交一条生成任务
- 只有模型需要参考素材时，再加入 Files API
- 轮询跑通后，再加入 Webhooks
- 只有产品需要在 Studio 之外发起 Chat turn 时，再接 Chat API
每一步都应该让流程更好运营，而不是只是“更自动化”。
什么时候继续留在 Studio
任务还需要下面这些能力时，继续留在 Studio：
- 主观复核
- 提示词调整
- 视觉比较
- 模型探索
- 已保存创意历史
- 人来判断下一步该去图片、视频、音频还是 Chat
这不是缺点。Studio 本来就是为这个阶段设计的。
什么时候迁到 API
满足下面这些条件时，就可以考虑迁到 API：
- 同类任务会反复发生
- 输入可以结构化
- 模型已经明确
- 应用需要从自己的界面创建任务
- 状态、错误和积分都能清楚处理
- 轮询或 Webhook 能接进产品后端
API 最强的地方，是把已经理解清楚的 Rivya 工作流变成可靠的产品动作。
下一步看哪里
- 打开 Developers，先预览 API 能力面。
- 写生产代码前，先读 Rivya API 快速开始。
- 保存 API Key 前，先读 API 鉴权。
- 如果下一步是把模型、文件、Chat 和 Webhook 串起来，读 如何用 Rivya API 接入多模态 AI 工作流。
- 如果项目仍然是人工主导的 Studio 工作，读 Rivya 的 Chat、Image、Video、Audio 如何衔接。
