在交出信用卡之前，值得先知道的四個數字：
- 每月額度在每個週期結束時，未使用的餘額會歸零重置。
- 點數包完全沒有到期日。
- 未動用的點數包在購買後 14 天內可申請退款。
- 失敗的產出仍然會確實扣掉一份點數，無論你是否喜歡結果。
其中三項屬於定價頁面的內容。真正有趣的一項，藏在花費順序實際如何安排之中，值得仔細說明——因為這正是「點數具有實質意義」和「點數只是行銷數字」之間的差別。
為什麼優先扣除月度額度
當你的帳戶同時有月度額度和已購買的點數包時，系統會先扣除月度額度，之後才會動用點數包。這件事不會寫在定價頁的標題文案裡，但它正是讓點數包真正值回票價的機制。
換個方式想：如果先扣點數包，你的月度額度就會一直閒置未用，直到帳單週期輪替時被清空。你在三月買來因應忙碌週的點數包，就會在背後悄悄補貼你的訂閱，而不是為你增加額度——你等於為同一份工作付了兩次錢，一次透過方案，一次透過點數包，而你原本已經付費取得的額度卻在背後悄悄蒸發。先扣額度則反過來：方案內含的免費額度先被使用，而你特地額外付費買來的容量，能撐過原本會被重置抹去的一切。三月買的點數包，到了十一月依然值得原本的價值。
這種不對稱，也正是這兩種點數一開始就以不同方式到期的原因。月度額度是隨你所付週期附贈的用量——如果無限累積，那我們等於每季都在讓沒登入的人用一期的錢買到三期的點數，定價頁就得加上一大堆但書來解釋。所以它就直接了當地重置，而不是被埋在常見問答裡。點數包則是你特地花錢買來的用量，不是訂閱附贈的福利，因此它的行為像是一筆餘額，而不是一項優惠——背後沒有倒數計時的到期時鐘。
我用過一些工具，付費加購的額度會隨著訂閱週期悄悄消失，雖然技術上在條款某處有寫明，但讀起來總像個陷阱。
花費順序，就是那個讓這個產品不至於變成那樣的小小機制設計。
什麼動作真正會扣點數
任何需要模型代你實際進行運算工作的動作：
- 初次建置
- 變更後重新建置
- 閱讀競爭對手頁面的研究過程
- 行銷文案草稿
- 重寫中繼資料的優化過程
這些動作的計價本來就不該相同——完整建置可能要在數分鐘的模型運算時間內動到十幾個檔案，而修改一個標題可能只需要幾秒鐘的精準編修。各動作類型的費率列在定價頁，而且會隨著底層模型的調整而變動；比起悄悄壓低品質來維持一個過時的價格，我們寧可公開調整數字。
什麼動作不會扣點：
- 已發佈的網站持續上線——每天都不花任何點數
- 查看儀表板
- 查看排名
- 瀏覽過去執行紀錄
- 向助理提出單純的問題
以上皆免費，直到答案需要它實際「動手做」而不只是「告訴你」為止。這條規則到處都一致：模型是產生或轉換了某樣東西，還是你只是讀取了已經存在的內容。
而你不喜歡的產出，仍然要付出那份點數，因為工作確實已經發生——token 已消耗、算力已使用、模型已完整跑完。這和我們這端出錯、還沒產出任何東西就失敗的情況不同，那種情況由我們負責，詳見下方說明。「不滿意就免費重試」聽起來很大方，直到你發現每個人的第三次嘗試都在悄悄由第一次就成功的人買單。
哪裡會出問題，以及我們怎麼處理
如果在建置過程中用完點數，執行會就地暫停在紀錄裡，而不是再拖三步後留下一個做到一半的頁面——不會靜默失敗、不會平白吃掉餘額，也不用猜測它是不是卡住了。加值或等待重置後，即可從中斷處繼續。我曾在一次客戶展示中親眼碰到：客戶要求「再跑一次」的當下，額度正好用盡，暫停訊息清楚說明需要什麼，我們當場買了一個小點數包，不到一分鐘就恢復執行。
| 失敗類型 | 是否退款？ |
|---|---|
| 平台端故障（我們的基礎設施出問題） | 會——申請即可補發點數，不需要苦苦纏鬥工單 |
| App store 審核被拒或 API 金鑰被撤銷 | 不會——但我們仍會協助解決根本問題 |
退還點數並不能修復一個壞掉的 Search Console 連線，所以我們刻意把這兩種情況分開處理。
退款僅適用於未動用的點數包，以及在那 14 天期限內、尚未使用的新週期，僅此而已。已消耗的工作無法退回——如果代理人已經建好網站而你改變心意，那份運算早已發生，就像承包商不會為你決定放棄的草案退還已計費的工時。完整的退款政策之所以簡短，是因為我們盡量不讓自己需要那些會讓退款政策變得又長又複雜的例外條款。
