Rivya 點數、點數包與方案說明

理解 Rivya 點數時，最有用的不只是餘額上的數字。

真正重要的是：當專案開始跨對話、圖片、影片、音訊和已上線工具推進時，錢包正在負責什麼工作。如果你需要嚴格規則參考，Rivya 點數與計費仍然是主文件。這一頁是購買決策指南。

這份價格指南基於什麼

這份指南已在 2026 年 4 月 28 日對照 Rivya 目前的公開價格設定和帳單文件重新檢查。

它反映：

• 註冊點數：6 點數，30 天到期

• 方案點數：Basic 每月 300、Advanced 每月 800、Pro 每月 1800、Premium 每月 3600 點數

• 點數包：一次性 500、1500、3500 或 7000 點數，365 天到期

• /pricing 和 Stripe Checkout 是精確價格、折扣、稅費和付款可用性的最終來源

先從錢包實際用途開始

Rivya 在整個產品中使用同一個共用錢包。

這很重要，因為專案可以改變格式，而不用每次都重建花費邏輯。

通常更有用的問題不是：

我花了多少錢？

而是：

我是否還有足夠空間，讓這套工作流程不中斷地繼續推進？

這就是為什麼 Rivya 裡的錢包感覺更像營運工具。它不只是餘額顯示。它是讓跨格式工作不會停住的橋。

最清楚的購買分法

方案與點數包不是彼此的通用替代品，它們解決的是不同的使用週期問題。

把註冊點數當成體驗預算

註冊點數最有價值的用法，是回答一個實際問題：

• 這個產品是否符合我真實的工作方式？

通常代表：

• 一次真實的對話或工具工作階段

• 一次你真的在意的圖片、音訊或影片執行

• 一次能告訴你這套工作流程是否值得繼續的比較

只因為餘額存在，就把第一批點數分散在隨機測試上，通常不是好做法。如果你想搭配第一次體驗閱讀更多內容，請一併參考如何在 Rivya 執行第一個真實任務。

什麼時候點數包通常更合適

當工作符合以下情況時，點數包通常是更直接的選擇：

• 你仍在測試 Rivya 是否應該進入你的常態工作流程

• 工作以專案突發形式出現，而不是穩定月度使用

• 你已經有方案，但某個活動或修訂週比平常更忙

• 你想要額外空間，但不想全年背負更大的週期性承諾

點數包通常用來處理短期需求，與選擇長期使用基線是不同決策。

什麼時候方案通常更合適

當工作更像以下情況時，方案通常是更好的選擇：

• 你每週或每月都會使用 Rivya

• 專案定期在多個產品面之間移動

• 你不想每個忙碌期都變成另一個補量決策

• 錢包現在支撐的是運作節奏，而不是一次性尖峰

這時方案不再只是「更多點數」，而會成為更清楚的工作基線。

低餘額實際會中斷什麼

低餘額不只是帳單問題，也可能中斷工作流程。

當錢包太低時：

• 可計費生成可能根本不會在模型端開始

• 任務仍可能明顯失敗

• 通知可能記錄這次中斷

• 專案可能正好在你準備繼續的那一刻停住

這就是為什麼低餘額在 Rivya 中，比在各工作流程彼此隔離的產品中更容易造成干擾。

點數容易被誤解的地方

點數不保證每個結果都可以發布，成本更高的執行也不會自動成為更好的第一步。

以下情況要小心：

• 定義任務前就開始比較模型

• 只是探索不清楚的想法，卻選擇重型影片或音訊執行

• 假設失敗任務和完成但不可用的結果代表同一件事

• 還不知道工作是否真的週期性，就先購買週期性權益

如果購買決策仍不清楚，從能回答真實問題的最小執行開始。

一條可靠的 Rivya 購買模式

如果你想要最短且可靠的規則，使用這個：

1. 用註冊點數熟悉產品

2. 如果工作有發展空間但仍不規律，購買點數包

3. 當使用模式變成週期性時，改用方案

4. 即使方案成為常態，也可保留點數包處理尖峰

5. 當真正問題變成退款、取消或結帳狀態時，前往價格常見問題或 Rivya 付款結帳指南

這個模式通常比在理解自己的節奏前反覆查看方案表更有用。

下一步

• 如果你想要廣泛的公開比較，前往價格方案。

• 如果你想要簡短的購買說明，閱讀價格常見問題。

• 如果你想要更嚴格的錢包規則、到期邏輯和失敗執行行為，閱讀 Rivya 點數與計費。

• 如果你想要方案與點數包決策頁，閱讀 Rivya 方案與點數包。

• 如果你想要結帳後返回與重新整理的精確說明，閱讀 Rivya 付款結帳指南。

執行前先檢查成本

花費點數前，先把這次執行連到一個購買決策：

• 模型或工作流程：哪一次執行會真的從錢包扣除。

• 工作模式：學習輪、一次性突發、週期性工作、重試，或生產嘗試。

• 成本訊號：模型頁或價格頁對預期點數用量的提示。

• 更便宜的測試：較輕的執行是否能在較重的執行之前回答同一個問題。

• 購買含義：結果是指向註冊點數、點數包、方案，還是暫時不購買。

目標不是每次都花最少點數，而是讓花費符合工作的實際節奏。

迭代前先檢查花費

把每次完成的執行視為成本訊號，而不是證明同樣花費應該繼續。檢查模型是否比任務需要的更重、提示詞是否太寬，以及下一次執行是否真的需要更高設定。

如果結果方向有用，從最有效的部分繼續，而不是盲目重新開始。如果它沒有完成核心任務，先修正需求說明或模型選擇，再花更多點數或改變購買基線。