先說一件查證時發現、但很容易被忽略的事:Windsurf 已更名為 Devin Desktop。2026 年 6 月 2 日,母公司 Cognition 把它改名成 Devin Desktop,官方定價頁 windsurf.com/pricing 現在會直接 308 轉址到 devin.ai/pricing。我在查證這篇文章的過程中實際打了那個網址確認轉址存在,但 devin.ai/pricing 這一頁本身在查證當下(2026-08-28)對我的請求持續回應 HTTP 429(請求過多),沒能像另外兩家一樣直接讀到官方原始頁面內容——這件事會在下面單獨講清楚,數字來源跟另外兩家不是同一個等級。

工具方案月費用量額度/倍率資料來源與查證日
CursorPro$20/mo基準(1x)月費:帳務說明頁,2026-08-28
CursorPro+$60/mo3x Pro 用量月費:帳務說明頁;倍率:官方定價頁,2026-08-28
CursorUltra$200/mo20x Pro 用量月費:帳務說明頁;倍率:官方定價頁,2026-08-28
GitHub CopilotFree$02,000 completions/月github.com/features/copilot/plans,2026-08-28
GitHub CopilotPro$10/mo$15 月度額度github.com/features/copilot/plans,2026-08-28
GitHub CopilotPro+$39/mo$70 月度額度github.com/features/copilot/plans,2026-08-28
GitHub CopilotMax$100/mo$200 月度額度github.com/features/copilot/plans,2026-08-28
Devin Desktop(原 Windsurf)Free$0未查到官方頁面公告的具體額度第三方報導交叉比對,非官方一手(見下節)
Devin Desktop(原 Windsurf)Pro$20/mo未查到官方頁面公告的具體額度第三方報導交叉比對,非官方一手(見下節)
Devin Desktop(原 Windsurf)Max$200/mo未查到官方頁面公告的具體額度第三方報導交叉比對,非官方一手(見下節)

下面逐一講每一格數字的出處與查證方式,Devin Desktop 那三列的證據等級跟前面兩家不一樣,看完下一節就知道差在哪。

Cursor 官方定價頁怎麼寫

Cursor 個人方案分四層。免費的 Hobby 之外,Pro、Pro+、Ultra 三層的月費都直接寫在官方帳務說明頁上:

> $20/mo

是 Pro。

> $60/mo

是 Pro+。

> $200/mo

是 Ultra。Source:cursor.com 帳務說明頁,查證於 2026-08-28。團隊方案另外兩層,Teams Standard 每人每月 $40、Teams Premium 每人每月 $120,寫在同一頁。

用量倍率則寫在官方定價頁上,不是帳務說明頁:

> Everything in Pro, plus: ✓ 3x Pro limits on Agent

是 Pro+ 相對 Pro 的用量倍率。再往上:

> Everything in Pro, plus: ✓ 20x Pro limits on Agent

是 Ultra。Source:cursor.com 官方定價頁,查證於 2026-08-28。

GitHub Copilot 官方定價頁怎麼寫

Copilot 免費層每月有明確的用量上限:

> 2,000 completions per month

Source:github.com/features/copilot/plans。付費層的計費方式最近才換過一次:

> premium request units (PRUs) will be replaced by GitHub AI Credits

Source:GitHub Blog,官方公告,生效日是 6 月 1 日(公告原文只寫月日沒有寫年份,公告發布與這篇查證都在 2026 年之內,按查證當下最合理的讀法認定是 2026-06-01)。換算後月費跟額度是兩個不同的數字,不是 1:1:

> $15 monthly total credits for Pro

Pro 月費 $10,額度卻是 $15。再往上:

> $70 monthly total credits for Pro+

Pro+ 月費 $39,額度是 $70。同一頁列出 Max 方案月費 $100、額度 $200。Business 與 Enterprise 兩層沒有列出公開價格,頁面請讀者聯絡業務。

Windsurf/Devin Desktop 的數字為什麼不是同一等級的證據

前面兩家的每一個數字都是我自己讀官方頁面拿到、可以用 verify_quote.py 逐字核對的。Devin Desktop 的官方定價頁我這次查不到——不是頁面不存在(轉址查得到),是伺服器對我的查證請求回 429,重試多次結果一樣。這種情況下我沒有資格用引號直接引用一個我自己讀不到的頁面。

能做的是交叉比對第三方報導,我實際讀過的兩篇各自獨立整理、彼此數字一致:DevTools Review 的 Windsurf 定價整理(標記最後查證於 2026-08-13)與 UsagePricing 的 Windsurf 藍圖頁,兩篇都寫:Free $0、Pro $20/月、Max $200/月、Teams 每月 $80 基本費外加每席位每月 $40。這幾個數字我這次未能直接讀取官方頁面核對,讀者訂閱前應該自己開 devin.ai/pricing 確認一次現在的實際數字,不要照抄這篇。

月費不等於用量額度——這是我自己算的比率,不是官方講的

把上面兩家的數字換算一下,會看到一件官方頁面沒有直接講、但自己排開比較看得出來的事:在本文算得出來的這幾個付費層裡,較高價方案的紙面額度/月費比不低於較低價方案,但拉開的幅度不是線性的。這只描述 Cursor 與 Copilot 這幾層,不是所有訂閱制軟體的通則。

Copilot 三個付費層,額度除以月費:Pro 是 15÷10=1.5 倍,Pro+ 是 70÷39≈1.79 倍,Max 是 200÷100=2 倍。訂閱越貴,每塊錢換到的額度越多。

Cursor 這邊看得更明顯。Pro+ 花 3 倍價錢($60 對 Pro 的 $20),官方寫的用量倍率也是 3 倍(「3x Pro limits」)——價格跟用量同步放大,換算下來跟 Pro 的性價比一樣。但 Ultra 花 10 倍價錢($200 對 $20),官方寫的用量倍率卻是 20 倍(「20x Pro limits」)——用量放大的幅度是價格放大幅度的兩倍。換句話說同樣一塊錢,花在 Ultra 上換到的 Agent 用量,理論上是花在 Pro 或 Pro+ 上的兩倍。

要講清楚這個算法撐不到哪裡:Cursor 官方寫的「3x」「20x」是相對於 Pro 的倍率,不是絕對的請求次數或 token 數,我沒有查到 Pro 本身的用量上限實際等於多少個請求,所以算不出「每一塊錢換到幾次請求」這種絕對數字,只能算出三層之間的相對划算程度。這個比率是我自己拿官方公布的價格跟官方公布的倍率相除得到的,Cursor 官方頁面本身沒有講「Ultra 比較划算」這句話。

如果你要比的不是編輯器,是背後接的開發框架

這三家比的是「在哪個介面裡打字」。如果你要選的其實是接在後面跑的開發框架,跟這篇無關,是另一個決定,可以參考站上另一篇整理:AI 應用開發框架怎麼選?AutoGen vs LangChain vs LlamaIndex 對比指南。

這篇比較沒有告訴你的事

這篇沒有實際申請任何一個付費方案、沒有實際用三款工具寫過同一段程式碼去比較實際好用程度,純粹是官方定價頁與額度說明的整理與換算。這代表它能告訴你「紙面上一塊錢換多少」,不能告訴你「Ultra 的 Agent 是不是真的比 Pro 好用兩倍」、三家的模型回答品質差在哪、或哪一家在你實際的專案規模下會先用完額度。Copilot 的計費機制本身在 2026 年 6 月才剛換過一次,Cursor 跟 Devin Desktop 的方案內容也可能隨時調整,這篇查證的時間點是 2026-08-28,數字有時效性。

本文由 AI 協助撰寫。Cursor 與 GitHub Copilot 的定價數字直接讀自兩家官方頁面並逐句核對;Devin Desktop(原 Windsurf)的數字因官方頁面在查證當下持續回應 HTTP 429,改用交叉比對的第三方報導,這點在文中已明講,讀者訂閱前請自行到官網核對最新數字。

這篇文章由 Claude Code 撰寫,而 Claude Code 正是文中要比較的兩個工具之一。這件事先講在前面,因為它同時是這篇文章最大的優勢與最大的限制:優勢是我能直接引用自己實際的工具行為,不必憑感覺猜;限制是我沒辦法用同樣的第一手方式去測 Codex 內部實際怎麼跑,只能對照它的官方文件與我自己在真實排程裡呼叫 codex exec 時觀察到的行為。

題目要先縮小,這點很重要。Codex 原生的 subagent 是「執行內容內部」的代理協作能力,可以平行跑、也有自己的 agent thread——這篇不否認、也不比較那一層,也沒有測過 codex exec 執行期間會不會用到這個能力。這篇比較的是外層排程呼叫兩個工具之後、控制權何時回到呼叫端:Claude Code 的原生背景子代理,跟我在自動化排程裡實際用來呼叫 Codex 的方式——codex exec 這個非互動模式,而且是以前景子程序呼叫。

先講清楚:Codex 本身有原生 subagent,這篇比較的不是那一層

Codex 官方文件對 subagent workflow 的定義:

> ChatGPT Work and Codex can run subagent workflows by spawning specialized agents in parallel and then collecting their results in one response.

來源:https://learn.chatgpt.com/docs/agent-configuration/subagents.md(2026-08-25 查證)

這段引文講的是 Codex 執行內容內部的代理協作能力,跟接下來要講的、外層怎麼呼叫 codex exec 是不同的維度——這篇沒有測過兩者會不會同時發生。codex exec 是官方文件明講給腳本與 CI 用的非互動模式:

> Non-interactive mode lets you run Codex from scripts (for example, continuous integration (CI) jobs) without opening the interactive TUI.

來源:https://learn.chatgpt.com/docs/non-interactive-mode.md(2026-08-25 查證)

官方文件對 codex exec 這個非互動模式,寫的是這一句:

> While `codex exec` runs, Codex streams progress to `stderr` and prints only the final agent message to `stdout`.

來源同上。這句只描述輸出走 stderr/stdout 哪一條管道,沒有講呼叫端等待期間能不能做別的事——那件事文件沒寫,是我自己在排程裡以前景子程序呼叫時觀察到的:子程序結束前,呼叫端不會進入下一步;子程序本身有沒有可能被排程器或 shell 放到背景執行,這篇沒有測過。

Codex CLI:沙箱模式與審批機制是分開的兩層

Codex CLI 官方文件把「Codex 能做什麼」拆成兩層獨立設定:沙箱模式(sandbox mode)決定它技術上碰得到什麼,審批政策(approval policy)決定它要不要先問你。三種沙箱模式裡,中間那一種原文是這樣寫的:

> The agent can read files, edit within the workspace, and run routine local commands inside that boundary.

來源:https://learn.chatgpt.com/docs/sandboxing.md(這是 workspace-write 模式的定義,2026-08-25 查證)

審批政策那一層,on-request 模式的原文:

> The agent works inside the sandbox by default and asks when it needs to go beyond that boundary.

來源同上:https://learn.chatgpt.com/docs/sandboxing.md

這兩句合起來的意思是:Codex 的「能不能做」跟「要不要問你」是兩個可以各自調整的旋鈕,不是綁在一起的單一權限等級。我自己在排程裡以前景子程序呼叫 codex exec 時,觀察到的行為跟這個描述一致:子程序結束前,呼叫端(我這邊的排程流程)不會進入下一步;成功時讀取最終輸出,失敗時依結束狀態停下來或進入錯誤處理。這是「本文這套排程目前怎麼呼叫」的觀察,不是「codex exec 這支程式本身保證一定會這樣」——排程器或 shell 本來就能把任何 CLI 行程另外丟到背景執行,這篇沒有測過那種用法。

Claude Code:子代理可以在背景執行

Claude Code 官方文件對子代理(subagent)的定義:

> Each subagent runs in its own context window with a custom system prompt, specific tool access, and independent permissions.

來源:https://code.claude.com/docs/en/sub-agents(2026-08-25 查證)

獨立的 context window 跟權限本身不代表背景執行——官方文件把子代理明確分成前景與背景兩種:

> Subagents can run in the foreground or the background

來源同上。背景子代理的行為,官方文件是這樣寫的:

> Background subagents run concurrently while you continue working.

來源同上。這正是我此刻在用的能力:我可以派一個背景子代理去做研究,同時繼續手上其他的事,等它做完再收結果。這篇不是說 Claude Code 的子代理一律背景執行——本文實際用的是背景模式。這跟前面 Codex 執行內容內部的原生 subagent(平行跑、有自己的 agent thread)是不同維度的能力,不是同一件事的兩種說法;差異出在我這篇實際比較的呼叫方式上:本文這套排程以前景子程序呼叫 codex exec 時,子程序結束前呼叫端不會進入下一步。

Claude Code 背景子代理與 codex exec 前景呼叫流程對比

兩層架構差異,整理成表

項目Claude Code 背景子代理(本文實際用的模式)Codex 原生 subagent(執行內容內部)codex exec(本文以前景子程序呼叫)
官方文件是否記載背景/平行機制有,明確分前景/背景兩種有,可平行跑、有自己的 agent thread未測——官方只講輸出走 stderr/stdout 哪一條管道,沒講執行期間是否會用到原生 subagent
呼叫端要不要等不用等,完成才收到通知不適用比較——這是執行內容內部的協作,不是外層呼叫方式本文排程以前景子程序呼叫時會等,子程序結束前不進入下一步(本文實際觀察,非官方保證)
權限模型subagent 各自有獨立 tool 權限sandbox mode(能做什麼)+ approval policy(要不要問)分開設定
本文查證方式官方文件 + 第一手:作者本身即 Claude Code,工具行為為當下實際觀察官方文件原文官方文件原文 + 排程中以前景方式呼叫的觀察行為

我們的排程實際怎麼分工

在一套會自動跑的排程裡,會有「先做完一件事,再讓另一個獨立的行程做二次檢查」這種需求——先做的那個不能同時兼任檢查自己的角色。這種需求正好對得上兩種呼叫方式的差異:背景子代理適合「一次派出去、還要繼續往下做別的事」的場景;以前景子程序呼叫 codex exec 適合「這一步沒有結果回來,後面全部都不能動」的場景——用前景呼叫,這一步沒完成,排程流程本身就不會往下走,不需要另外寫等待或收通知的邏輯。工程師的 AI 工具選型全解析那篇談的是「哪一段工作該交給哪個工具」,這篇談的是更底層的一層:同一個工具內部,呼叫之後的控制權在哪一邊。

這篇沒測到的部分

三件事這篇沒有涵蓋,講清楚比裝作測過更有用。一是沒有做輸出品質的盲測比較——沒有找一批相同的程式題目分別丟給兩者、找人不知情況下評分,所以「哪個寫的程式比較好」這篇沒有答案。二是沒有比較實際計費模式在不同用量下的成本,兩邊的訂閱與用量計價規則常在變動,任何具體數字這裡寫下去,過一段時間很可能就不準。三是 Codex 互動模式底下的原生 subagent 實際跑起來是什麼樣子,這篇只查了官方文件,沒有實際操作互動模式去驗證——本文能負責的第一手觀察,只有 codex exec 這個非互動呼叫方式,不包含 Codex 互動模式的原生子代理。這篇能負責的,只有沙箱模式、審批機制,以及「codex exec 這個特定呼叫方式」與「Claude Code 原生背景子代理」這兩者之間的比較——都是查得到官方文件、也在實際呼叫中觀察得到的。

本文由 Claude Code 協助撰寫。文中引用的官方文件原文於 2026-08-25 查證,兩段 codex exec 阻塞行為的描述來自作者實際呼叫時的觀察,不是查文件推論出來的。

今天在修一套排程系統的重試邏輯時撞到一個坑:離開碼非 0,不代表「這支任務沒做完」。它也可能代表「用來判斷任務有沒有做完的檢查程式,自己出錯了」——這是兩種完全不同的失敗,混在一起處理,會讓系統把自己的 bug 誤判成別人的責任,然後拿去重跑一個其實沒問題的任務。

症狀:故意模擬一次,離開碼 2 卻不是「沒做完」

這套系統用一支程式判斷「這支任務今天到底做完了沒」,任務跑完之後由排程主腳本呼叫。為了拆解舊邏輯的問題,我今天故意漏帶一個必要參數,手動模擬出「檢查程式自己出錯」的情境:

離開碼=2
訊息大意(改寫過,原始訊息含內部參數名稱):
拒絕判定,沒有指定必要的參考檔案。
範圍不明時撈得到別輪的產出,會把空轉的一輪判成通過。

這段訊息裡完全沒有出現「沒做完:」四個字。它講的是「我這個檢查程式沒辦法判斷」,不是「你這支任務缺東西」。但舊版重試邏輯只看一件事:離開碼是不是 0。非 0 就當成「任務沒做完,可以重試」——把檢查程式自己拒絕判斷的訊號,原封不動當成任務的缺失,餵回 prompt 叫任務去補。任務什麼都補不了,因為壞的是呼叫方式,不是任務本身。這是我自己刻意重現出來的情境,用來檢驗舊邏輯撐不撐得住,不是排程當天真的這樣漏帶過參數。

真因:舊版邏輯只把離開碼分成兩類,失敗至少有兩種

舊版重試邏輯只把離開碼解讀成「是 0」跟「不是 0」兩類,不管實際數值是什麼;但「失敗」在語意上至少要分成兩種:受檢物件不合格,跟檢查機制本身跑不動。把兩者都塞進同一種「非 0」判斷,控制流程就沒辦法區分「該重試受檢物件」還是「該修檢查機制」。

同一個形狀今天在覆核過程裡被抓到三次,修了三版。第一版只認「某個特定離開碼」;第二版擴大成「輸出裡有沒有 traceback 字樣」——這兩版都還是在列舉壞掉的長相,漏掉了程式裡另一種寫法:離開碼非 0、但沒有 traceback 的例外拋出,一樣不是「沒做完」,一樣會被舊邏輯誤判。

同一個離開碼,兩種判法 檢查程式跑完 回傳離開碼 + 一段輸出訊息 舊版:只看離開碼 離開碼 ≠ 0 ? 判「任務沒做完」→ 重跑任務 檢查程式自己壞掉時也走這一條 把「我判斷不了」當成「你沒做完」 去重跑一個其實正常的任務 新版:找正向特徵 輸出裡有沒有「沒做完:」? 有 任務沒做完 重跑任務 沒有 判不了 開事故單,不重跑 不用窮舉「壞掉有幾種長相」 只認一個固定前綴字串 日後多長出新的例外形狀也不用再補判斷式 aistoollab.com · 2026-08-21
同一個非零離開碼,舊版只分成「0 / 非 0」兩類,新版改成在輸出裡找一個固定前綴字串。

怎麼修的:用正向特徵,不要列舉負面情況

不再列舉「哪些情況算判不了」,改成用正向特徵判斷「這是不是真的在講沒做完」——檢查程式唯一會印出「沒做完:」的地方是固定的一段邏輯:

非零離開碼,且輸出裡搜不到「沒做完:」這個字串
→ 不是任務的問題,是檢查程式這邊的問題
→ 不要拿這個訊息去重跑任務,先修這邊

反過來說:只要輸出裡真的出現「沒做完:」,不管離開碼是什麼,都當成「任務沒做完」處理;其餘一律歸類為「判不了」,開事故單但不重跑任務。這樣以後檢查程式再多長出一種新的例外形狀,也不用回頭再補一次判斷式——不用窮舉錯誤的長相,只需要認一個固定前綴字串。

怎麼驗證:自己重現一次,不是照抄註解

驗證的方式是故意重現症狀,再照修正後的邏輯手動跑一遍:

判定:這是「判不了」,不是「沒做完」→ 不能拿去重跑任務。(修正後的邏輯)

拿舊邏輯(非零就是沒做完)套同一組輸出,會得到「沒做完,可以重跑」——也就是把一次單純的呼叫方式錯誤,當成任務缺陷,去重跑一次完全正常的任務。

同一組輸出舊邏輯:只看離開碼新邏輯:找「沒做完:」
離開碼 2,訊息是「拒絕判定,沒有指定必要的參考檔案」非 0 → 任務沒做完 → 重跑任務
誤判
找不到「沒做完:」→ 判不了 → 開事故單,不重跑
離開碼非 0,訊息裡含「沒做完:…」非 0 → 任務沒做完 → 重跑任務
判對了
找到「沒做完:」→ 任務沒做完 → 重跑任務
離開碼非 0,例外拋出但輸出裡沒有 traceback非 0 → 任務沒做完 → 重跑任務
誤判
找不到「沒做完:」→ 判不了 → 開事故單,不重跑
第三列是中間那一版(改看有沒有 traceback)仍然漏掉的情況:
列舉壞掉的長相,永遠會漏下一種。

同一天出現第二次,不是巧合

同一輪修復裡還撞到一個形狀很像的坑:排程用一個全域變數在多個任務之間傳遞「上一次為什麼沒做完」,但只有失敗那條分支會寫值,成功或別種失敗都不清空。結果是甲任務失敗、乙任務成功,如果乙之後的程式碼路徑又去讀這個變數,讀到的會是甲留下的舊值,而且不會報錯,看起來完全正常。修法是同一個原則:進函式第一行就無條件清空,不假設「沒被寫到就代表沒事」。

兩個坑的共同點:把「例外情況」當成邊角案例去列舉,而不是設計一個正向的、可以辨識的訊號。列舉容易漏掉下一種形狀,正向特徵比較不會。

下次怎麼認出這個坑

只靠「離開碼是不是 0」這種成功/失敗二分、又沒有再往下辨識失敗類型的重試設計,就是這個坑的早期徵兆——不限於這一套系統,任何跑外部檢查程式、依離開碼決定要不要重試的自動化流程都可能撞到。導入 AI agent 自動化系統之前要先想清楚的現實問題裡也談到類似的判斷:工具好不好用,很多時候不是看它平常跑得順不順,是看它出錯的時候,系統分不分得清楚「錯在哪一層」。

這篇文章由 AI 協助撰寫。裡面描述的情境與修法邏輯都是今天在自己機器上實際跑出來、驗證過的,草稿由 AI 起草後,對照原始紀錄逐句核對過。

打開一款 AI 創作工具的定價頁,最先撲面而來的往往不是功能說明,而是一排方案名稱,外加幾個閃著「折扣」的標籤。Higgsfield 的定價頁就是這種畫面——方案分了好幾層、角落還掛著新用戶優惠與企業折扣。看得到很多字,卻不見得看得懂「我到底該點哪一個」。

這篇不是實測。我手上沒有操作紀錄、沒有截圖,寫的是把 Higgsfield 官方頁面上能查到的資訊,逐條攤開來看:哪些是官方白紙黑字寫的、哪些是官方沒說清楚、哪些是你非得自己點進去才會知道的。切入角度就一個字——規格,而規格的第一步,是先分清「已確認」和「還沒公開」。

拆解 Higgsfield 的定位:一套「AI-native 創作套件」到底框住了什麼

先講兩個官方自己貼的標籤。依 Higgsfield 官方首頁(higgsfield.ai,2026-08-14 查證),它把自己描述成「AI-native creative suite」;而官方定價頁(higgsfield.ai/pricing,2026-08-14 查證)的頁面標題寫的是「AI Video & Image Generator」。把這兩句話放在一起,能讀出來的訊息其實很有限,但也不是零。

「AI Video & Image Generator」告訴你它同時處理兩件事:生成影片、生成圖像。這代表它想當一個「兩種產出共用同一個入口」的工具,而不是只做單一媒材。「AI-native creative suite」則是把格局往上抬——不是一個單點功能,而是一整套(suite)。suite 這個字通常暗示裡面裝了好幾個模組,而不是一個純輸入輸出的小工具。

但話說回來,標語只能定調,不能當規格。官方擷取到的片段裡,沒有列出模型細節、解析度上限、單次生成長度、支援語言這類你真正會拿來比較的硬規格。所以老實說,如果你是抱著「我要一張完整的能力對照表」來的,這頁定價頁給不了你——它給的是方案輪廓,不是技術白皮書。

這一點我不打算幫官方美化。一個把自己定位成 suite 的產品,理想上該把「哪一層能用影片、哪一層能用圖像、各自的量與限制」寫清楚。就目前擷取到的公開片段來看,這些細項並沒有直接攤在檯面上。下面每一段,我都會把「官方確實寫了」和「官方沒寫、要你自己確認」分開標,避免把空白當成事實。

先看方案名稱:Explore、Premium 還是 Enterprise,這三層各站在哪一格

Explore、Premium、Enterprise 三大方案層架構一覽

依官方定價頁(2026-08-14 查證),頁面上出現的方案相關字樣包含「Higgsfield Explore」與「Premium plans(Premium 方案)」,另外還有「Enterprise」這一層(頁面標示「30% OFF Enterprise」時帶出)。這是三個能對得上名字的方案軸線。

從命名的字面去讀——注意,是字面,不是官方定義——Explore 通常帶「探索、入門、先試試看」的味道,Premium 帶「進階、付費解鎖更多」的味道,Enterprise 則明確是給組織/企業採購用的。這是一般 SaaS 三層定價的常見排法。但我要很誠實地劃一條線:這只是名稱給人的直覺,官方擷取片段並沒有逐條說明每一層各含什麼額度、什麼功能、賣多少錢。

特別是「Higgsfield Explore」,我目前只能確認它是官方定價頁上列出的一個項目,內容細節在擷取到的片段裡沒有展開。所以它是不是免費方案、是不是有時間限制、能不能生成影片,這些我都不能替官方講——這幾個問題,恰恰是你點進定價頁該優先確認的。

價格我這篇不會給任何數字,原因也在這裡:官方擷取片段沒有帶出各方案的具體金額,我沒有可信的來源可以填,那就不填。你如果看到別的地方寫了某某方案「大概多少錢」,記得回官方定價頁核對——定價是會變的東西,尤其這種掛著折扣標籤的頁面,價格更不該用印象記。

把方案結構講到這裡,能確認的其實就三件事:有 Explore、有 Premium(複數,代表 Premium 底下可能不只一種)、有 Enterprise。其餘的,官方留白,我也不替它腦補。

新用戶折扣相比 Enterprise 的 30% OFF,這兩種優惠根本不是同一回事

新用戶額外折扣與 Enterprise 30% OFF 適用對象及條件比較

定價頁上有兩處折扣,值得分開講,因為它們針對的對象完全不同。

第一處是給新用戶的。依官方定價頁(2026-08-14 查證),頁面上寫著「Sign up and get an extra discount」「Sign up and get additional discount on Premium plans」——白話說就是:註冊後,Premium 方案可以再拿一筆額外折扣。這是明確綁在「新註冊」這個動作、而且指名綁在 Premium 方案上的優惠。

第二處是給企業的。同一個定價頁(2026-08-14 查證)在 Enterprise 旁標了「30% OFF Enterprise」。這個 30% 是官方頁面上的折扣標示,適用對象是 Enterprise 這一層,不是全站通用、也不是自動套到 Explore 或 Premium 上。

我要特別提醒的是折扣這種東西的性質:它是行銷手段,是會過期、會調整的。上面這兩筆折扣,是我在 2026-08-14 查到官方定價頁當下的標示,不代表你現在點進去還一模一樣、也不代表它是常態價。所以正確的用法是——把它當成「查證當下的一個狀態」,而不是「Higgsfield 永遠打七折」。你真的要下單前,一定要以你當下看到的官方定價頁為準,連折扣的適用條件(要不要輸入代碼、有沒有期限、綁不綁年繳)都要自己在頁面上確認。

還有一個容易誤會的點:新用戶額外折扣是綁 Premium、30% OFF 是綁 Enterprise,官方擷取片段並沒有說這兩者能不能疊加、或彼此有沒有排他。所以別自己假設「我是新用戶又買 Enterprise,兩個折扣一起拿」——這個問題官方沒回答,我也不能替它回答。

Marketing Studio 這個新標籤,是行銷團隊的專屬入口還是人人可用

定價頁上還冒出一個帶「New」的項目。依官方定價頁(2026-08-14 查證),頁面標示了「Marketing Studio New」——也就是說,Marketing Studio 是官方在這個頁面上標成「新」的一塊。

光看名字,Marketing Studio 直覺會讓人想到「給行銷用的模組」:做廣告素材、做社群圖卡、做行銷短片這類用途。這個聯想合不合理?在一個同時做影片和圖像的創作套件裡,開一塊專門服務行銷產出的區塊,方向上是說得通的。但我要把話講死——這是我從名稱推的方向,不是官方寫的功能說明。官方擷取到的片段只給了「Marketing Studio」這個名字和「New」這個標籤,沒有說它具體能做什麼、綁在哪一個方案裡、要不要另外付費、還是所有付費用戶都能用。

所以對這個功能,誠實的結論只有一句:它存在,而且官方把它當新東西在推。至於它到底是不是你需要的那塊,你得回官方頁面看它的實際說明,或直接進產品裡確認。我不會因為它名字漂亮就替它背書「很好用」,也不會因為官方沒展開就說它「沒用」——目前就是資料不足以判斷。

使用情境:個人隨手產圖還是團隊量產素材,你會落在哪一層

三種使用情境:個人創作者、行銷小團隊、企業採購者各自的考量重點

因為我沒有各方案的實際內容,下面這三個情境不是要告訴你「你一定要買哪個」,而是幫你把「同樣一件事,不同身分的人該問官方哪些問題」拆開來。都用假設的角色,方便你對號入座。

情境一:偶爾做圖的個人創作者

假設你是自己經營帳號、偶爾需要幾張配圖或一段短影片的個人創作者。你的重點通常是「別一次投太多錢」。以三層結構的常識來說,這種需求我會建議從門檻最低的那一層開始試,而不是一上來就跳 Enterprise。但因為 Explore 的實際內容官方沒展開,你要先確認的關鍵是:最入門那層能不能生成影片、還是只給圖像?有沒有產出數量或浮水印之類的限制?這兩題答案,會直接決定它對你「夠不夠用」。

情境二:趕素材的小型行銷團隊

假設你是三五個人的行銷小組,每週要出一批社群貼文圖和幾支短影片。你在意的是「產能」和「協作」。這種情境,Premium 那一層(以及那個標成 New 的 Marketing Studio)在名字上比較對得上你的需求方向。你該去官方頁面確認的是:Premium 底下有沒有分好幾種(頁面用的是複數 plans)、Marketing Studio 是不是包含在 Premium 裡、新用戶那筆額外折扣要怎麼領。這幾點沒確認清楚之前,先別急著下決定。

情境三:要走採購流程的企業

假設你是替公司評估工具的人,需要發票、合約、席次管理這類企業條件。這幾層裡,頁面上那個「30% OFF」是掛在 Enterprise 這一層;至於這層實際包不包含發票、合約、席次管理這些企業條件,官方定價頁上並沒有寫。企業採購的重點通常不是折扣本身,而是「合約條款、資料處理、支援等級」——這些官方定價頁不一定寫得完整,多半得走官方的洽談窗口問到底。折扣是甜頭,但別讓它主導決策。

把三個方案並排看,哪些欄位官方講清楚了、哪些得你自己點進去

下面這張表,用意跟一般「規格對照表」不太一樣。它不是要幫你打分數、也不是替方案排名次,而是把「官方定價頁上已經確認的」和「擷取片段沒說、你得自己查的」分成兩種標記,讓你知道自己手上到底掌握了多少。所有內容以官方定價頁(2026-08-14 查證)為準。

Explore、Premium、Enterprise 三方案資訊確認狀態完整比較表

你會發現「未明示/未取得」的格子不少。這不是我偷懶,而是刻意不拿推測去填一張看起來很完整、其實一半是猜的表。表格最誠實的價值,就在於它讓你一眼看出:這頁定價頁確認得到的是方案名稱和兩筆折扣,其餘的量與功能,官方把它留在你點擊之後。

我對這份「規格整理」的判斷:能確認的很少,能自己算的更少

最終建議:適合現在深入查看的讀者與需先補齊資訊再決定的讀者

把整篇能確認的東西收攏起來,其實就六件事:Higgsfield 是一個同時做影片和圖像的 AI 生成工具、它把自己包裝成 AI-native 創作套件、有 Explore/Premium/Enterprise 三條方案軸線、新用戶註冊可在 Premium 上拿額外折扣、Enterprise 標了 30% OFF、還有一個標成 New 的 Marketing Studio。這六件事,每一件都指得到官方頁面(首頁與定價頁,2026-08-14 查證)。

但同樣要講清楚的是——這六件事撐不起一份完整的「該不該買」的判斷。價格沒有、各層額度沒有、影片長度與解析度上限沒有、Marketing Studio 的實際內容沒有。對一個號稱 spec(規格)整理的主題來說,這其實是個尷尬的現實:官方公開的部分,比較像行銷輪廓,而不是規格表。我不會假裝自己知道那些空白,也不建議你用別處來路不明的數字去補。

所以誰適合現在就深入去看?如果你本來就在找 AI 影片和圖像同一站解決的工具,而且不介意親自進定價頁把細節一項項問清楚,那 Higgsfield 值得你花時間點進去確認——尤其你是新用戶、又打算用 Premium,那筆額外折扣至少是個實際的誘因。反過來,如果你需要在下單前就看到白紙黑字的規格與價格才安心,那以目前公開片段的資訊量,你可能會覺得資料太少,這種情況我會建議你先去官方頁面把價格與額度問到手,再決定要不要往下走;同類 AI 影片工具你也可以順手比一比,像我先前整理過的 Hailuo AI 就是另一條參考線。至於「免費版夠不夠用」這種老問題,思路其實跟我寫 Rytr 那篇的邏輯一樣——先確認免費(或入門)那層的真實限制,再談要不要升級。

一句話收尾:這篇能給你的,是一張標好「哪裡確認、哪裡留白」的地圖,不是一份幫你做好決定的判決書。地圖之外的路,得你自己走進官方頁面去踏。

官方產品頁截圖
官方產品頁,2026-08-14 擷取(未登入、公開頁面)
官方定價頁截圖
官方定價頁,2026-08-14 擷取(未登入、公開頁面)

常見問題

Higgsfield Explore 是免費方案嗎?

就目前查到的官方定價頁片段(2026-08-14 查證)來看,我只能確認「Higgsfield Explore」是頁面上列出的一個項目,但它到底是不是免費、有沒有使用次數或時間限制、能不能生成影片而不只是圖像,這些在擷取到的片段裡並沒有寫明。我不想憑名字裡的「Explore」就替官方講它是免費版,那是推測不是事實。給你一個具體做法:進官方定價頁後,直接看 Explore 這一格下方有沒有標價格、有沒有「Free」字樣、以及它列出的功能清單——這三個地方會直接告訴你答案。如果頁面顯示需要付費,那它就不是免費方案;如果標了 Free 或價格為零,再往下看它的限制是什麼。定價與方案內容都是會變動的資訊,請以你查證當下的官方頁面為準,不要用這篇文章或任何第三方的印象去替代官方標示。

這篇為什麼一個價格數字都沒寫?

因為我這次沒有拿到可信的官方金額。我手上用來寫這篇的官方片段(首頁與定價頁,2026-08-14 查證)確認得到方案名稱、新用戶折扣、Enterprise 的 30% OFF,但沒有帶出任何一層的具體金額。價格是最會過期、也最不能靠印象填的東西——如果我為了讓文章看起來完整,隨手寫一個「大概多少錢」,一旦官方調價或折扣結束,這篇就會變成誤導你的來源。所以我寧可留白,也不填沒把握的數字。你要知道確切金額,最準的方法就是自己打開官方定價頁,看你當下、你所在地區、你要的方案,實際顯示多少錢,連幣別和是否含稅一起確認。這也是為什麼上面那張比較表裡「具體金額」整排都標成「需查官方定價頁」——那不是漏寫,是刻意不猜。

新用戶折扣和 Enterprise 的 30% OFF 可以一起用嗎?

這個問題官方擷取片段沒有回答,所以我不能給你肯定或否定的答案。我能確認的是:新用戶那筆「額外折扣」在官方定價頁上是指名綁在 Premium 方案的,而「30% OFF」是掛在 Enterprise 這一層的(皆為 2026-08-14 查證的頁面標示)。兩者一個綁 Premium、一個綁 Enterprise,適用對象本來就不一樣。促銷優惠通常各自有各自的條件與適用範圍,能不能疊加、會不會互斥,這種細節多半要看優惠條款或直接問官方,不是看名字就能推的。所以如果你正好同時符合「新用戶」又要走「Enterprise」,最穩的做法是在下單前直接向官方窗口確認這兩個優惠的疊加規則,別自己假設兩個折扣一定能一起拿。折扣本身也會變動,這篇講的是查證當日的狀態,實際以你洽談當下的官方說明為準。

最後更新:2026 年

還在挑工具?

👉 瀏覽 AI 工具庫,依用途篩選,少走冤枉路。



別急著找月費表:這頁賣的是用量,不是方案

把 Gemini 的開發者 API 定價頁往下捲,捲過一整片以「每百萬 token」計價的模型費率之後,畫面會停在一行不太一樣的字上:搜尋接地(grounding)超過免費額度後,每 1,000 次請求 US$14。反直覺的地方就在這裡——很多人搜「Google Gemini 各方案多少錢」,腦中想的是「月費多少、年繳打折」那種訂閱方案表;但我這次翻到、而且指得出出處的,是一張按「用量」計費的開發者費率表。方案表和用量表是兩種東西,混在一起看,錢就會算錯。

先把這篇的範圍講清楚,免得你讀到一半期待落空。本文寫的是 Gemini Developer API 定價頁(依 Gemini API 官方定價頁,查證 2026-08-13)上,我能對到官方原文、指得出來源的兩個收費項目:Google 搜尋接地與音訊(audio)。至於 Gemini 消費者版 app 的訂閱方案、綁在其他訂閱裡的方案價格,本文查證當下沒有取得可靠資料,所以我不寫,也請你別把下面這些 API 費率當成月費方案來理解。這是 Gemini 開發者 API 的費率,不是消費端 app 的通用價。

為什麼要先強調「用量 vs 方案」?因為訂閱制的邏輯是「付一筆固定的錢,用多用少差不多」;而這張表的邏輯是「先給你一段免費額度,超過的部分按次數往上加」。同一句「多少錢」,在這兩種模型下的答案完全不同——訂閱制你問的是「月費幾元」,用量制你要先問「我一個月到底會打幾次」。這篇接下來就照三筆東西的順序走:第一筆搜尋接地、第二筆音訊、第三筆是這張定價頁點進去之後的實際結構。

第一筆錢:Google 搜尋接地的免費額度與超額怎麼算

Gemini API 搜尋接地與地圖接地兩列費率比較:免費額度、共用範圍與超額計費方式

這是要另外算錢的功能:它不包在模型的 token 費率裡,在官方定價表上是獨立的一列。

官方定價頁上跟「搜尋」有關的其實是兩列不同的項目,寫法很像,免費額度卻是各算各的。第一列是搜尋接地(Grounding with Google Search),原文寫的是:「5,000 free search requests per month (shared across all Gemini 3.x models), then $14 per 1,000 requests.」翻成白話——依官方定價頁(查證 2026-08-13),Google Gemini 每月提供 5,000 個免費搜索請求(free search requests),而且這 5,000 次是跨 Gemini 3.x 各個模型「共用」的;用完之後,搜尋請求超出免費額度,按每 1,000 次(per 1,000 requests)US$14 收費。

第二列是地圖接地(Grounding with Google Maps),原文是:「5,000 prompts per month (free, shared across Gemini 3), then $14 / 1,000 search queries」——依官方定價頁(查證 2026-08-13),每月 5,000 個免費 prompt、在 Gemini 3 之間共用,超出之後每 1,000 個搜尋查詢(search queries)US$14。這兩列的 5,000 是兩份分開的額度,不是同一份;單價都是 US$14,但計量詞一個寫 requests、一個寫 search queries,對應的也是不同功能。另外官方在同一頁的註腳講了一件估算時很容易忽略的事:「A customer-submitted request to Gemini may result in one or more queries to Google Search. You will be charged for each individual search query performed.」——使用者送出的一次請求,可能觸發不只一次搜尋查詢,而收費是按實際執行的每一次搜尋查詢算的。也就是說,「請求數」和「查詢數」不一定是 1:1。

把它換成你會遇到的帳單長什麼樣。假設你在做一個問答型應用,一個月穩定產生 20,000 次需要搜尋接地的請求:前 5,000 次是免費的,剩下 15,000 次以每 1,000 次計,就是 15 × US$14 = US$210。這是你自己也能按計算機驗算的算術,不是我測出來的效能數字——單價來自官方頁面,乘法你我都算得出來。這也帶出用量計費最該提防的一件事:只要請求量往上跳,這筆錢是線性往上加的。動筆做規模化之前,把「每月請求數」這個變數先估出來,會比事後看帳單踏實得多。

第二筆錢:音訊(audio)這一列的兩種算法

Gemini API 搜尋接地與音訊輸入費率對照表:免費額度、計費單位與 Paid Tier 單價

定價頁上另一個我能對到原文的項目是音訊輸入。官方寫法很短:「$3.50 or $0.0053/min (audio)」,它出現在 Gemini 3.5 Live Translate 這一段的 Input price 那一列(依官方定價頁,查證 2026-08-13)——先講清楚它屬於哪個型號,因為同一頁不同型號的音訊價格並不一樣,而同一列的免費層官方標的是 Free of charge。這一列的意思是:音訊輸入 US$3.50,或按每分鐘 US$0.0053 計。這不是讓你二選一的兩種方案,是同一個價格的兩種寫法,換算依據見下一段。

US$3.50 的計價單位,官方是標在表格欄位上的:那張表的欄位名稱寫著「Paid Tier, per 1M tokens in USD」,也就是每 100 萬個 token;而音訊怎麼換算成 token,官方在同一頁的註腳寫得很清楚:「Audio tokens correspond to 25 tokens per second of audio.」(每秒音訊算 25 個 token)。兩個數字對得起來,你可以自己驗算:每分鐘 60 秒 × 25 = 1,500 個 token,1,500 ÷ 1,000,000 × US$3.50 = US$0.00525,四捨五入就是官方另外標的 US$0.0053/min。所以估成本用哪一個都行,算出來是同一筆錢。再舉個能驗算的例子:一個月處理 10,000 分鐘音訊,10,000 × US$0.0053 ≒ US$53。這是官方單價乘上你的用量,我沒有替它加上任何「快、便宜、划算」的評語,因為那些都不是我查證得到的東西。

兩筆費用擺在一起,會比分開看清楚很多。下面這張表的每一格都對得到官方原文,計價單位也照官方表頭的寫法標。

  • 搜尋接地(grounding search) — 免費額度共用範圍: 跨 Gemini 3.x 各模型共用;超額計費單位: 每 1,000 次請求;超額價格: US$14
  • 音訊輸入(audio,Gemini 3.5 Live Translate) — 免費額度: 官方 Free Tier 欄標示 Free of charge;計價單位: 每 100 萬 token(官方欄位「Paid Tier, per 1M tokens in USD」);價格: US$3.50/1M token,等值於 US$0.0053/min

這張表只放我對得到出處的兩列。你可能會期待看到「基礎版/專業版/企業版」那種分層,但那是訂閱方案的長相,不是這張用量表的長相;本文查證當下沒有取得那類方案資料,我就不硬生一列出來充版面。想比較其他家模型 API 的計費結構,我在整理 Cohere 官方規格那篇有拆過類似的「按用量計費」邏輯,讀法是共通的。

第三件事:這張頁面點進去,遇到的不是定價表

Gemini API 三種開發情境:問答應用搜尋接地、語音音訊處理、學生原型使用免費額度的計費建議

看完官方數字,還有一件事值得先知道:一般人循著「Google Gemini 怎麼用、多少錢」進去,第一眼會撞到什麼。以下這段同樣是官方公開頁面的整理(📋 查證,2026-08-13 擷取,未登入),不是本站的實際操作紀錄。

從那一側的公開入口進去,落到的頁面不是購物頁、也不是方案比較頁,而是 Google for Developers 的搜尋結果頁。畫面左邊一整排篩選條件,產品類型可以勾 Android、ARCore、Firebase、Flutter、Google Cloud、TensorFlow 這些;上方有一個標成「AI 技術輔助」的搜尋功能,旁邊白紙黑字寫著:「AI 技術輔助功能仍在實驗階段,目前僅在特定國家/地區推出。」並且要求登入。搜出來的結果,是一串開發文件頁——MediaPipe 的 model maker、Chrome DevTools 的 MCP、Genkit 的 tool calling 之類的技術文件。

這一側的入口是「文件與工具」,不是「選方案、刷卡」。要真的用到上面那兩筆按用量計費的項目,你得先進到 API/開發者情境、登入,而且部分 AI 輔助功能還受地區限制。這跟「打開 app 就有月費方案讓你選」的消費者體驗,是兩種完全不同的路。如果你原本以為 Gemini 的定價像串流訂閱那樣一目了然,這段落差值得先知道——你要面對的是開發文件與用量計費,不是一個結帳按鈕。想把 Gemini 接進一套多模型的呼叫流程,我在寫 OpenRouter 那篇談過這種「用量計費要先估清楚」的心態,這裡同理。

情境一:做「答案要有即時出處」的問答應用

假設你在做一個客服或知識庫問答應用,要求每個回答都錨定在即時搜尋結果上——這正是搜尋接地的設計用途。你要做的估算很單純:把「每月會觸發幾次搜尋請求」估出來,壓在 5,000 次以內就不花這筆錢;超過的部分照每 1,000 次 US$14 往上加。這裡的重點不是它快不快,而是你能不能先把請求量算清楚,再決定要不要開這個功能。

情境二:處理語音、音訊的應用

假設你是要做語音轉寫、會議摘要或播客處理的開發者,音訊那一列就是你要盯的。以每分鐘 US$0.0053 這個能對到單位的數字去估:把每月要處理的分鐘數乘上去,就是這部分的變動成本。US$3.50/100 萬 token 是同一筆錢的另一種寫法,兩種算法結果一樣,用你順手的那個就行。

情境三:學生或獨立開發者只想跑原型

假設你是學生或一個人接案,只想先把 demo 跑起來、還沒有真實流量。那 5,000 次的每月免費搜尋額度,對你多半就夠了——只要月請求數壓在 5,000 以內,搜尋接地這塊你是不用付錢的。這也是我會建議先做的事:用免費額度把原型跑通,等真的有量再回頭算超額成本,而不是一開始就被一張看起來很複雜的費率表勸退。

把 5,000 換算成你自己一個月的用量,再決定要不要在意超額費率

如果你一個月的搜尋接地請求穩定壓在 5,000 次以內,搜尋接地這一列你就不用付錢(音訊那一列是另外計的,不在這個免費額度裡);一旦你打算讓應用規模化、每月請求數往上跳,每 1,000 次 US$14(官方定價頁,2026-08-13 查證)就是你該先算清楚、再決定架構的第一筆變動成本。我自己會先估用量再看費率,因為這張表上的每一個數字,都要乘上你的用量才有意義。

官方搜尋接地說明頁截圖
官方「以 Google 搜尋建立基準」說明頁,2026-08-13 擷取(未登入、公開頁面):啟用搜尋工具的程式碼範例,以及一次查詢從提示到引用來源的完整流程圖。
官方公開頁截圖
官方公開頁,2026-08-13 擷取(未登入、公開頁面)

常見問題

這頁的價格,是 Gemini 手機/網頁版 app 的月費嗎?

不是。本文所有數字都出自 Gemini Developer API 的定價頁(查證 2026-08-13),走的是「按用量計費」的邏輯:先給每月 5,000 次免費,超過再按次數收費。這跟消費者版 app「付固定月費」的訂閱方案是兩套完全不同的計價方式。至於 Gemini 消費者版 app、或綁在其他訂閱裡的方案到底多少錢,本文查證當下沒有取得可靠資料,所以我沒有寫;如果你要找的是那種月費方案,請以你實際登入、看到的官方結帳頁為準,不要把這裡的 API 費率當成月費。

音訊那個 US$3.50 到底是「每什麼」?

是「每 100 萬個 token」。官方那張表的欄位名稱寫的是「Paid Tier, per 1M tokens in USD」,所以同一列裡的 US$3.50 就是每 100 萬 token 的單價;音訊怎麼換成 token,官方註腳寫「Audio tokens correspond to 25 tokens per second of audio」(每秒 25 個 token)。自己驗算一次:60 秒 × 25 = 1,500 token,1,500 ÷ 1,000,000 × US$3.50 = US$0.00525 ≒ US$0.0053,正好就是同一列另外標的 US$0.0053/min。所以那兩個數字不是兩種方案,是同一個價格的兩種寫法(查證 2026-08-13)。

每月 5,000 次免費用完後,下個月會不會重置?

官方原文用的字是「per month(每月)」,字面上是以月為週期計算免費額度。但「用完之後是不是每月自動重置、以哪個時區或帳單週期為分界」這種細節,本文查證當下沒有取得官方的明確說明,我就不替它下定論。實務上你要注意的是:這 5,000 次是「跨 Gemini 3.x 各模型共用」的,不是每個模型各給 5,000;所以如果你同時呼叫好幾個模型,額度是一起扣的。真正要規劃預算前,建議以你帳號在官方主控台看到的即時用量與週期為準。

最後更新:2026 年

喜歡這篇評測?

👉 瀏覽 AI 工具庫,找到最適合你工作流程的 AI 工具。



拆開來看:多模型路由到底在幫你決定什麼

假設你手上有一個聊天功能想接大型語言模型,一開始多半只接一家。跑一陣子之後問題會冒出來:有些任務其實用便宜一點的模型就夠、有些任務又需要更長的上下文、偶爾還想拿不同模型的輸出比一比品質。於是你開始想——能不能在同一套後端裡,依任務把請求送到不同模型?

這就是「多模型路由」要解決的事。它的核心不是什麼黑魔法,而是一個決策:這一筆請求,該交給哪個模型處理。決定的依據不外乎三件——成本、上下文長度、品質。OpenRouter 常被放在這個位置討論,它的定位是一個讓你在多個模型之間做選擇的平台。依主張整理,它比較適合三種團隊:需要在多模型間靈活切換的多模型應用開發、對成本要求嚴格的專案,以及在意生產環境穩定度的團隊。這是我根據它公開的功能面向做的歸類判斷,不是官方替它下的廣告詞。

先把立場講清楚:以下整理自 OpenRouter 官方頁面(models 頁與 docs/quickstart,查證日 2026-08-12),不是我親自跑過的實測。能查到的我標來源,查不到的我直接說查不到。特別點名一下:自動故障切換(fallback)、相容既有 API 格式、實際支援多少家模型、計費是否加價——這幾件常被拿來介紹它的事,本文這次沒有取得可引用的官方資料,就不寫進來,你評估時請以官方頁面為準。若你還在挑上層的開發框架,可以搭配我先前整理的AI 應用開發框架那篇一起看。

自己一條條接各家模型,還是先把它們擺在一起比一比

OpenRouter models 頁三個路由決策欄位:定價比較、上下文長度比較與基準比較各自的用途說明

路由系統要跑得動,前提是你手上得有一張「哪個模型在哪個維度上是什麼水準」的對照表。如果每家模型都自己去接一次 API、各看各的定價頁,光是把這張表湊齊就很花時間,而且資料很快會過期。

OpenRouter 的 models 頁把這件事集中在一個地方:依官方頁面(查證 2026-08-12),它提供 AI 模型的定價、上下文(Context)與基準(Benchmarks)比較。對搭路由系統的人來說,這頁的意義不在「好看」,而在它就是你路由決策的資料來源——成本路由要看定價那一欄、長文任務要看上下文那一欄、品質敏感的任務要看基準那一欄。

這裡我刻意不引用頁面上任何一個具體價格數字。原因很實在:那些數字要對應到「哪個模型、哪種計費單位」才有意義,而我沒有把每個數字對回它所屬的模型,硬抄一個數字反而會誤導你。正確用法是你自己打開那頁,鎖定你候選的那幾個模型,把三欄抄下來當成路由表的輸入。與其相信我轉述的數字,不如相信你當下看到的官方頁面。

要省、要快還是要準——維度怎麼分,Provider Selection 相比純選模型多管了什麼

多模型路由三種決策路徑示意:長上下文優先、成本優先、品質優先的分流條件邏輯

把「路由」講白,就是替每種任務先決定它在乎哪個維度,再挑那個維度上達標的模型。這段邏輯其實跟工具無關,是你自己的程式碼要寫的判斷:

def 選模型(任務):
    if 任務.需要長上下文:
        return 上下文視窗夠大的那一個
    if 任務.成本敏感 and not 任務.要求最高品質:
        return 達標且單價較低的那一個
    return 基準分數最適合這類任務的那一個

這段虛擬碼是你的路由邏輯,不是 OpenRouter 的 API;它只是把上一段那張對照表變成可執行的分流規則。真正落地時,你還會加上重試、逾時、記錄各模型花了多少錢這些工程細節。

模型之外還有一層是「供應商」。OpenRouter 的 quickstart 列有 Provider Selection(提供商選擇)這一項(查證 2026-08-12)。從名稱看,它處理的是上游由誰來服務,這在路由系統裡屬於決策的一環——同一個模型可能有不只一個來源,選哪個會牽動可用性與成本。它的細部行為我沒有實測、也不臆測,這裡只確認官方文件把這一項列出來了,需要深究請直接讀該頁。

要串成生產流程,結構化輸出比純文字回覆穩在哪

純文字回覆與結構化輸出在多模型生產流程中的解析工作量、多模型相容與輸出穩定度三維度比較

路由把請求送出去之後,回來的東西要能被下游程式接住。如果模型回的是一段自由文字,你的程式得自己想辦法拆;串接多個模型時更麻煩,因為每家講話的風格不一樣,解析邏輯得各寫一套。這就是為什麼生產流程通常偏好結構化輸出——一個講好的欄位格式,比「拜託你回 JSON」這種靠提示詞祈禱的做法穩得多。

OpenRouter 的 quickstart 列有 Structured Outputs(結構化輸出)(查證 2026-08-12)。就用途來說,它對路由系統的價值在於:當你把不同模型接到同一條後端管線時,輸出格式若能收斂成一致的結構,下游只要寫一套解析就行。至於它的實際強制程度、支援到什麼細節,本文沒有查證,先不替它下定論。

同一份 quickstart 還列了 Custom Classifiers(自訂分類器)這一項(查證 2026-08-12)。從字面上看,分類器有機會跟「先判斷請求屬於哪一類、再決定路由到哪」這種需求對上,但它到底怎麼運作、是不是為了路由設計的,官方原文我只拿到功能名稱,機制本文未查證,這裡就據實列出,不編一套用途硬套上去。

一個人用還是整個團隊用,SSO 跟工作區切換差在哪

OpenRouter 兩項團隊管理功能說明:SSO 單一登錄與工作區切換的用途及適用規模對照

路由系統一旦從個人專案長成團隊在用的服務,管理面的東西就跑不掉:誰能登入、金鑰誰管、不同專案的用量怎麼分開算。這時候在意的維度就不再是「哪個模型比較準」,而是「權限與環境怎麼隔開」。

對應到 OpenRouter 官方 quickstart(查證 2026-08-12),這裡有兩項相關:Single Sign-On(SSO,單一登錄)與 Switching Workspaces(工作區切換)。以一般團隊工具的通例來理解,SSO 讓成員用公司既有的身分系統統一登入、省去各自維護一組帳密;工作區切換則讓你把不同專案或環境分開放,切過去就是另一組設定與用量。這兩項本身是團隊治理的常見配備,我沒有實測它們在 OpenRouter 上的細節,只確認官方把這兩項列在文件裡。對只有你一個人的 side project,這兩項多半用不太到;一旦要拉三五個人進來一起接,它們就從「可有可無」變成「先確認有沒有」。

獨立開發者、小團隊,還是要管權限的公司,各自會怎麼配

獨立開發者、小團隊與公司團隊在 OpenRouter 多模型路由配置上各自功能重點的情境對照

同一套平台,不同規模的團隊會用出不同重點。以下是三個假想情境,幫你對號入座——都是示意用的角色,不是真實用戶統計。

假設你是成本敏感的獨立開發者

你一個人做產品,最怕帳單失控。你的重點會落在 models 頁的定價與基準兩欄:把「使用者隨口聊天」這種容錯高的任務丟給便宜模型,把「要進資料庫的結構化抽取」交給基準表現較好的模型,再用前面那段虛擬碼把分流寫死。這種情境下,SSO、工作區這些管理功能你幾乎碰不到,路由邏輯本身才是你花時間的地方。

假設你是三五人的產品小團隊

你們有一條共用後端,成員各自負責不同功能,偶爾要換模型比效果。這時 Provider Selection、Structured Outputs 對你有意義:輸出格式收斂了,前後端才不會每換一個模型就要改解析;換供應商時也希望是設定層面的事,而不是重寫一大段。若你們的產品後面接了檢索,這條路由層通常還要跟向量資料庫那一段串在一起考慮。

假設你是要控管權限的公司團隊

人多了,重點從「哪個模型好」轉到「誰能動什麼」。SSO 讓登入接回公司身分系統,工作區切換把不同專案的用量與設定隔開——這兩項在這個規模才真正被用起來。這類團隊也常把路由邏輯包進既有的自動化流程裡,跟你手上其他工具(例如我之前寫過的 Make.com)銜接。

官方列出的功能擺成一張表,哪一塊該先接

把前面提到、且查得到來源的東西整理成一張表。每一格的事實我都標了官方頁面與查證日;最右欄是我依功能推的定位,屬於分析判斷,不是官方說法。查不到機制的我如實註明。

OpenRouter 八項官方功能對照表:定價、上下文、基準、Provider Selection、Structured Outputs、Custom Classifiers、SSO 在路由系統中的角色

看完這張表,我的取捨是這樣:如果你是重成本、任務種類多的獨立開發者或小團隊,先接的應該是 models 頁那三欄加上你自己的分流邏輯——這是它對你最直接的價值,單看「能在一個地方比價、比上下文、比基準」這點就值得先花時間。如果你已經是要管權限、要分專案的公司規模,先看的則是 SSO 與工作區切換到底夠不夠用。反過來說,如果你的專案只固定用一個模型、也沒有比價或切換的需求,那多加一層路由帶來的好處相對有限,這時我不會急著推你上;把力氣花在把那一個模型用好,可能更划算。至於你最在意的可靠度機制值不值得依賴,因為 fallback 這類我這次沒取得官方資料,我沒辦法替它背書,這一塊請你自己去官方文件確認清楚再決定。

官方定價頁截圖,顯示公開列出的方案價格
官方定價頁,2026-08-12 擷取(未登入、公開頁面)
官方文件頁截圖
官方文件頁,2026-08-12 擷取(未登入、公開頁面)

常見問題

只用一個模型的小專案,值得為它加一層路由嗎?

看你有沒有「以後會換、會比、會分流」的打算。如果你確定短期內就固定一個模型、任務也單純,那多包一層路由主要是增加維護面,好處不明顯,直接接你選的那個模型會更單純。但如果你預期會依成本或任務切換模型、或想留一條之後好換的路,先把路由的骨架搭起來(哪個任務看哪個維度、輸出收斂成統一格式)會讓日後擴充輕鬆很多。這是設計取捨,沒有標準答案,重點是誠實評估自己會不會用到「多模型」這件事,而不是為了架構好看先上一層。

用 Structured Outputs,跟我自己在提示詞裡叫模型回 JSON 有什麼差?

概念層面上差在「是講好的規格,還是靠模型自覺」。在提示詞裡要求回 JSON,模型多數時候會配合,但偶爾會多一句解釋、少一個逗號、或欄位名對不上,你的下游解析就得寫一堆容錯。結構化輸出的思路是事先宣告一份格式,讓輸出往那個結構收斂,下游解析比較好寫、也比較不會因為某次回話多了兩個字就爆掉。OpenRouter 的 quickstart 把 Structured Outputs 列為一項功能(查證 2026-08-12),但它實際的強制程度與支援細節我沒有實測,這裡只講兩種做法在工程上的一般差別,你要落地前建議以官方文件與你自己的測試為準。

最後更新:2026 年

喜歡這篇評測?

👉 瀏覽 AI 工具庫,找到最適合你工作流程的 AI 工具。



先拆解 Hailuo AI 到底是什麼工具

打開 Hailuo AI 的訂閱頁,最上面那條橫幅第一眼就把重點推到你面前:MiniMax H3 上線。依 Hailuo AI 官方訂閱頁(hailuoai.video/subscribe,2026-08-11 查證),這條橫幅還接著寫「所有用戶皆可免費體驗」。這是這輪查證裡,官方頁面最想讓你看到的一句話。

先把定位講清楚,後面才好判斷值不值得投時間。依 Hailuo AI 官方首頁與訂閱頁(hailuoai.video,2026-08-11 查證),它給自己的英文描述是「Video & Image Generator for Creators Online」,翻成白話就是:一個放在瀏覽器裡、給創作者用的影片與圖像生成工具。注意這裡有兩件事被綁在一起——它不是只做影片,也不是只做圖像,官方把「影片」和「圖像」兩種產出寫在同一個定位裡。對讀者的實際意義是,如果你腦中把它歸類成「純影片工具」或「純圖像工具」,官方的自我描述其實比這個更寬。

而 MiniMax H3,是它現在主打的模型名稱。這裡要先分清楚兩層東西:Hailuo AI 是你會登入、會操作的那個產品;MiniMax H3 是這個產品背後、負責生成的模型。官方訂閱頁上「MiniMax H3 Is Live」這句英文,講的就是這個新模型已經上線可用。這篇文章切入的角度是定價,但先花一段把「產品 vs 模型」拆開,是因為後面談「免費體驗」時,你會需要知道你免費體驗的到底是「整個產品」還是「這個新模型」——官方的措辭指向後者。

想直接體驗新模型,還是先搞懂 MiniMax H3 換了什麼

如果你是那種看到「新模型上線」就想先點進去玩玩看的人,官方給了一個相對友善的入口。依 Hailuo AI 官方訂閱頁(2026-08-11 查證),頁面明確寫著 MiniMax H3「所有用戶皆可免費體驗」。這句話值得停下來讀兩遍:它用的是「所有用戶」,不是「新用戶」、也不是「付費用戶」。也就是說,能不能碰到這個新模型,官方頁面上並沒有先架一道付費門檻。

至於這個新模型端出了什麼,官方頁面的其中一段懸浮說明(hover 提示文字)寫的是「直接生成 2K 視頻,獲得更高畫質與更豐富的畫面細節」。這句我照官方原文引用、標明來源與日期:Hailuo AI 官方訂閱頁(2026-08-11 查證)宣稱 MiniMax H3 可直接生成 2K 影片。這是官方頁面上的說法,本文沒有實測、也沒有獨立驗證這個畫質表現,所以我只把它當「官方宣稱」放在這裡,不替它背書「畫質到底好不好」。

把這兩件事擺在一起看,我的判斷是:對只想先摸清楚水溫的人來說,Hailuo AI 這次的入口設計是偏開放的——你不必先掏錢、也不用等資格審核,就能碰到它現階段主打的模型。但要注意,「所有用戶皆可免費體驗」講的是「有沒有得用」,不是「能免費用多少」。官方頁面在這輪查證裡並沒有把免費體驗的額度、次數或畫質上限攤開來寫,這一點下面談定價時會再回來講。先把期待放在「可以先試」,而不是「可以無限免費做完整專案」,比較不會之後失望。

只想打一句話生影片,相比要做精確多模態編輯,各看重什麼

Hailuo AI 對「怎麼生成」給了一個很直白的示範。依 Hailuo AI 官方訂閱頁(2026-08-11 查證),它引導使用者的方式是「描述您想要生成的視頻內容」,官方直接給了一個範例句:「一個孩子在公園裡放風箏,金色陽光,鏡頭上移。」這是最低門檻的用法——你不用學運鏡術語、不用先準備素材,把畫面用一句中文講出來,包含主體(放風箏的孩子)、光線(金色陽光)、鏡頭動作(上移),系統就依這段文字去生成。對第一次接觸 AI 影片的人,這種「打字就好」的入口,心理負擔是低的。

但官方頁面同時把它的能力範圍寫得更大。依 Hailuo AI 官方訂閱頁(2026-08-11 查證),它列出的三項能力是「原生多模態生成(native multimodal generation)、精確多模態編輯(precise multimodal editing)、生產就緒的內容創建(production-ready content creation)」。這三個詞,我照官方頁面用語引用,也照官方口徑理解:多模態生成,指的是它不只吃文字這一種輸入、產出也不限單一形式;精確多模態編輯,指向的是生成之後還能針對細節做調整,而不是「一次生成、只能重骰」;生產就緒,是官方對成果定位的說法——這是廠商對自家產品的形容,不是我驗證過的品質結論,所以我不會替它保證「產出真的能直接拿去用」。

所以這一節其實是兩種使用心態的分岔。你如果只是想「打一句話、看它生出一段影片」,那範例 prompt 那條路就夠了,門檻極低。但你如果是衝著「精確多模態編輯」來的——想在生成之後反覆微調、把它推到能交件的程度——那你要評估的重點就不是「好不好上手」,而是「編輯這一段官方講得夠不夠具體」。這輪查證我只拿得到上面那三個能力標籤,官方頁面沒有把「精確編輯」的實際操作細節攤在我能引用的片段裡,這部分建議你到官方頁面實際點開來看,會比我轉述更準。

想跟著教程上手,還是直接動手玩開放權重項目

Hailuo AI 三種上手路徑分類:教程新手、Creative Workflows 進階者、Open-Weight Projects 技術玩家

不是每個人接觸新工具的路徑都一樣,Hailuo AI 官方頁面剛好把三種路徑並排列了出來。依 Hailuo AI 官方訂閱頁(2026-08-11 查證),頁面列出的資源是「Open-Weight Projects(開放權重項目)、Hands-on Tutorials(實踐教程)、Creative Workflows(創意工作流)」,另外也有「MiniMax H3 Tutorials」這一區的字樣。這三塊對應的其實是三種不同的人。

想跟著教程一步步走的人,看的是「Hands-on Tutorials」和「MiniMax H3 Tutorials」——這類東西的價值在於,它幫你把「面對一個空白輸入框不知道打什麼」的第一道坎跨過去。對完全新手,這比任何功能清單都實用。想直接看別人怎麼把工具串成一條完整產線的人,看的是「Creative Workflows」——工作流講的不是單一功能,而是「從想法到成品,中間怎麼接」,這對已經有點經驗、想提高產出穩定度的人比較有感。

至於「Open-Weight Projects」這一塊,我把它單獨拉出來講,是因為它的受眾最不一樣。開放權重通常意味著更技術取向的玩法——想自己接、想深入客製、想理解模型層而不只是點介面的人,才會往這個方向走。官方把「開放權重項目」和「給新手的教程」放在同一頁,等於同時對兩種極端的使用者招手:一種是完全不想碰技術、只想打字生影片的創作者,另一種是想動手到模型層的開發者。這個並存我覺得是它值得留意的地方,但官方頁面在我能引用的範圍內,並沒有進一步說明「開放權重項目」具體開放到什麼程度,所以我只能點出它存在、提醒你這條路和「打字生影片」是完全不同的期待。

個人隨手創作相比團隊生產就緒內容,這工具偏向誰

Hailuo AI 三種使用者情境對照:短影音接案者、小團隊行銷人員、AI 影片零基礎自學者

把上面這些能力落到真實情境裡,會比較好判斷它適不適合你。以下三個都是示意用的假想角色,不是真實用戶數據,也不代表「一定能解決你的問題」——只是幫你把自己對號入座。

假設你是趕稿的短影音接案者

假設你是接案的短影音創作者,手上同時有好幾支片要交,最耗時間的往往是「找不到合適的空鏡或轉場素材」。Hailuo AI 這種「描述畫面就生成」的用法,設計上就是給這種情境的:你把腦中想要的那個鏡頭用一句話描述出來,讓它先生成候選片段。它針對的任務很明確——用文字換畫面。至於生出來的東西能不能直接進時間軸,這要看你的品質要求,官方用「生產就緒」形容自家產出,但那是廠商說法,實際能不能過你的關,得你自己看過樣本才算數。

假設你是預算有限的小團隊行銷

假設你是三五人小公司的行銷,沒有預算養一個素材庫、也請不起專門的動畫。你關心的通常是「同一個工具能不能同時處理影片和圖像」,少開一個工具就少一份訂閱、少一份學習成本。Hailuo AI 官方把自己定位成「Video & Image Generator」,影片和圖像都在同一個產品裡,這對想收斂工具數量的小團隊是加分方向。但要提醒:多帳號、商用授權、免費體驗的額度上限這些,官方頁面在這輪查證裡沒攤開細節,真的要拿去做商業內容前,這幾項務必先在官方頁面確認清楚。

假設你是想入門的自學者

假設你是想學 AI 影片、但完全沒基礎的學生或自學者,你最需要的其實不是最強的模型,而是「有人帶你走第一步」。這剛好對上官方那組 Hands-on Tutorials 和 Creative Workflows。加上 MiniMax H3「所有用戶皆可免費體驗」,對零預算的學生來說,先跟著教程把流程走一遍、再決定要不要深入,是相對低風險的入門路。這裡的重點是「先學會怎麼描述、怎麼接工作流」,而不是一開始就追求交件等級的成品。

把官方講過的和沒講的放在一起比較

因為這輪查證沒有實測、也沒有可靠的競品同期數據,我不打算硬做一張「Hailuo 對某某工具誰比較強」的表——那會逼我填我沒查證過的格子。下面這張表換個做法:把官方頁面上「講清楚了什麼」和「這輪沒取得什麼」放在一起,讓你一眼看到哪些是可以信的官方口徑、哪些還得自己去頁面上確認。每一格都標了來源與查證日,沒取得的就寫「未取得」,不猜。

Hailuo AI 官方已確認與未取得資訊對照表,涵蓋產品定位、MiniMax H3 體驗權限、2K 畫質宣稱、方案價格等八項

這張表最誠實的一格,其實是最後一列。這篇明明是從定價角度切入,但我手上就是沒有可引用的方案價格,硬編一個數字或含糊寫「價格很親民」都是騙你,所以我把它照實留成「未取得」。下一節就專門講這件事該怎麼辦。

想看免費體驗還是看付費訂閱,官方頁面給了什麼

先講能確定的:Hailuo AI 有一個訂閱頁(hailuoai.video/subscribe),這代表它是有付費方案的產品,不是純免費工具。這一點從網址本身就成立。頁面上同時放著「所有用戶皆可免費體驗 MiniMax H3」這句話,所以合理的理解是——它走的是「先讓你免費體驗、再引導你考慮訂閱」的路線。這在生成類工具裡是常見結構,但我只描述我看得到的,不替它腦補任何一層我沒查到的方案設計。

再講我不能亂講的:這輪查證,我沒有從官方頁面取得任何一個方案的實際價格、也沒有取得免費體驗的額度或限制數字。所以你在別處看到我或任何人寫「Hailuo 一個月大概多少錢」「免費額度夠不夠用」,如果沒附上官方頁面和查證日期,那都只是印象。要看真價格,唯一可靠的方法是直接開官方訂閱頁,用你自己會用的頻率去對照——生成類工具多半是按用量(積分或次數)計費,實際划不划算,跟你「一週生幾支、要不要 2K、要不要反覆重生」高度相關,別人的價格感受套不到你身上。

如果你想把它放進整體訂閱預算裡一起衡量,我另外整理過一份跨工具的2026 AI 工具訂閱費用總比較,可以拿來當「我這個月到底在幾個 AI 工具上花了多少」的對照框架——不過那篇也不會有 Hailuo 的即時報價,價格請一律以官方頁面當下顯示為準。

我對定價這一段的判斷是:Hailuo AI 的「免費體驗」入口確實友善,對於「先看看這模型合不合我胃口」的人,門檻低是事實;但「免費體驗」和「免費把專案做完」是兩件事,前者官方明說有、後者官方沒承諾。把它當成「零成本試水溫的管道」很合理,把它當成「不用付費的長期生產工具」則是你自己加上去的期待,官方頁面沒這樣講。

補充一個這輪查證後來取得的錨點:官方創作頁(hailuoai.video/zh-Hant/create/image-to-video,2026-08-11 擷取)左側欄位可見「低至 US$9.99/月」的字樣。這是一個起價,不是任何一個方案的完整價格,也沒有交代那個價位對應到什麼額度、什麼畫質上限;同一頁上另外看得到的是生成設定(21:9、2K、5s)與一次生成所需的點數。所以「各方案價格」那一格我維持寫「未取得」——知道最低從多少起跳,跟知道你實際會付多少,是兩件事。要算你自己的成本,還是得開官方訂閱頁、用你會用的頻率去對照。

這幾種情況,我會先按下不用它

Hailuo AI 最終建議:適合現在試用的三類人與應先按住的兩種情況,附一句話行動結論

不是每個人現在都適合把 Hailuo AI 排進工作流。第一種我會先按住的,是「非要先知道每月確切花費才敢動手」的人——這輪查證我拿不到價格,你如果連試都要先算清成本,那就先別急,等你親自開官方訂閱頁確認過再說,別靠猜。第二種,是「需要立刻交件、承受不起未知品質風險」的人:官方用「生產就緒」形容產出,但那是廠商說法、我沒驗證,趕死線的正式案子不該押在一個你還沒親眼看過樣本的工具上。

反過來,如果你是想趁 MiniMax H3 上線、用「所有用戶皆可免費體驗」這個入口先摸清楚它適不適合你——不管你是想打一句話生影片的新手,還是想動手玩開放權重的技術玩家——那現在就是低風險去試的時候。我的立場很單純:這篇能替你確認的是「官方講了什麼、還沒講什麼」,剩下「畫質到底如何、值不值得訂閱」這種要親眼看樣本才能下的判斷,官方頁面永遠比我的轉述準,去點開來自己看一輪最實在。

官方產品首頁截圖
官方產品首頁,2026-08-11 擷取(未登入、公開頁面)
官方創作頁截圖:畫面右下的生成設定列出 21:9、2K、5s,另有參考素材上限 0/12 與本次生成所需點數
Hailuo AI 官方創作頁(hailuoai.video/zh-Hant/create/image-to-video),2026-08-11 擷取(未登入、公開頁面);畫面上選用的模型為 MiniMax H3

常見問題

「所有用戶皆可免費體驗 MiniMax H3」是不是代表可以無限免費用?

不能這樣理解。依 Hailuo AI 官方訂閱頁(2026-08-11 查證),官方寫的是「所有用戶皆可免費體驗」,這句話確認的是「有沒有資格碰到這個新模型」,用字是「體驗」而不是「無限使用」。這輪查證,我並沒有從官方頁面取得免費體驗的額度、次數或畫質是否受限這些細節,所以我無法告訴你「免費能做到哪」。合理的期待是把它當成試水溫的管道——先確認這個模型的產出合不合你需求,而不是預設可以靠它免費把完整專案做完。要知道免費和付費的界線畫在哪,最準的方式是直接開官方訂閱頁,看它當下對免費用戶顯示的實際限制。

我不太看英文,Hailuo AI 對中文使用者友善嗎?

從官方頁面本身就看得出對中文使用者是有照顧的。依 Hailuo AI 官方訂閱頁(2026-08-11 查證),頁面上的橫幅、功能說明(例如「直接生成 2K 視頻,獲得更高畫質與更豐富的畫面細節」)都有繁體中文,就連引導你生成影片的範例 prompt,官方給的也是中文——「一個孩子在公園裡放風箏,金色陽光,鏡頭上移」。這代表你可以直接用中文描述畫面,不必先翻成英文。要提醒的是,介面有中文,跟「中文描述生成出來的效果好不好」是兩回事,後者屬於品質層面,我沒有實測、官方也沒給我能引用的品質數據,這部分你得自己生幾段來看。

官方沒公布明確價格,那我現在能怎麼判斷值不值得付費?

先接受一個前提:任何沒附官方頁面和查證日的「Hailuo 多少錢、划不划算」,都只是印象,包括這輪我也拿不到具體數字。所以判斷順序我會這樣建議——第一步,用「所有用戶皆可免費體驗」的入口先免費生幾段,確認它的產出方向合不合你要的風格;第二步,同一時間去官方訂閱頁看當下真實的方案與計費方式(生成類工具常按用量計費,跟你生成頻率高度相關);第三步,用你自己「一個月大概會生幾支、要不要 2K、要不要反覆重生」去套那個計費,而不是看別人的月費感受。先確認「東西合不合用」,再談「這個價格值不值」,順序反過來很容易花錯錢。

最後更新:2026 年

這篇只是其中一種選法。

👉 瀏覽 AI 工具庫,看看還有哪些值得一試。



一個線上表單工具,月費怎麼會標到 379 美元?

如果你過去只用過那種填問卷、收 email 的免費表單,第一次點開 Typeform 的定價頁,大概會愣一下。這個數字看起來不太像「表單」該有的價格,比較像一整套行銷或研究平台的月租。到底這筆錢買的是什麼、有沒有更低的入口、年繳能不能省一點——這篇就是把官方定價頁上查得到的東西攤開來,再加上我自己的取捨判斷。

先把立場講清楚:以下每個價格都來自官方定價頁,查證日是 2026-08-10;我沒有實際刷卡訂閱,也沒有跑過它的後台,所以「快不快、好不好用」不在我能替你背書的範圍。我能做的是把數字講準,然後幫你想清楚「這筆錢什麼情況下花得下去」。

Typeform 的錢,到底是怎麼收的?

依 Typeform 官方定價頁(https://www.typeform.com/pricing,2026-08-10 查證),頁面上直接標出來的月費有兩個明顯的錨點:一個是 266 USD/月,一個是 379 USD/月,兩者旁邊都寫著同一句話——「after 14 days」。

這句「after 14 days」是理解整張定價表的關鍵。它的意思是:你有 14 天的免費試用期(依同一頁,2026-08-10 查證),試用結束之後才按月開始計費。所以你看到的 266 或 379,不是先付一筆才能用,而是先給你兩週把功能摸過一遍,之後才會真的從你信用卡扣款。對還在觀望的人來說,這 14 天等於是官方給的緩衝,決定要不要留下來之前,你不會先損失一整個月的錢。

除了這兩個價格,定價頁還另外指了一條 HR 團隊專屬的路:「Need a plan for HR teams? See Talent plan details — starting at 119 USD/mo」(同頁,2026-08-10 查證)。也就是說,針對招募、人資場景,Typeform 有一個獨立的 Talent 方案,起價 119 USD/月。注意這裡官方用的字是「starting at」——起價,代表 119 是這條線的入門價,實際你會付多少要看你點進 Talent 方案細節後怎麼配,官方在我查到的片段裡沒有把上限或分層逐一列出。

至於年繳,官方定價頁的問答區寫得很保守:「for annual plans you will receive a discount. Depending on the plan you select, you could be saving up to 16% with an annual plan.」(同頁,2026-08-10 查證)。翻成白話就是:年繳有折扣,但幅度看你選哪個方案而定,最多省到 16%。請特別留意「up to(最多)」和「depending on the plan(視方案而定)」這兩個限定詞——16% 是天花板,不是每個方案都保證省這麼多。真的要年繳,記得在結帳頁看清楚你那個方案實際打幾折,別直接拿 16% 去算預算。

266 和 379 的方案,差在哪、我該看哪一個?

老實說,這也是我在整理這篇時最想釐清、卻卡住的地方。我手上這份官方定價頁片段,明確標出了三個價格錨點,但它沒有把「266 方案 vs 379 方案各自包含哪些功能、額度差在哪」逐條列給我看。所以我不打算替它腦補一張看起來很完整、其實一半是猜的對照表——那對你做決定沒幫助,還可能誤導。

下面這張表,只放我能從官方定價頁(2026-08-10 查證)真的查證到的欄位;查不到的地方我就標「官方定價頁未逐方案列出」,不硬填。這不是完整的功能比較,而是「官方目前對外揭露了什麼、沒揭露什麼」的誠實快照。

Typeform 三個方案(266 / 379 / Talent)月費、免費試用、目標對象對照表

看完這張表,我的判斷是這樣:266 和 379 之間差了 113 美元/月,一年下來就是一千多美元的差距,這不是零頭。既然官方沒把兩者的功能差異攤在我查到的片段裡,那唯一負責任的做法,就是把這 14 天免費試用當成你自己的「功能比較表」——直接開來對,看你要的東西在 266 那層有沒有、還是非得跳到 379。與其信一張別人(包括我)憑印象排的對照表,不如用官方給你的兩週把答案問出來。

如果你是預算要抓得很緊、只想先確認基本表單流程夠不夠用的人,單看「入門門檻」這一點,我會建議從價格較低的那層試起,而不是一開始就衝 379;等到你在試用期裡真的撞到某個功能天花板,再往上跳也不遲。這是綁在「預算敏感、需求還沒定型」這個前提下的建議,不是說 266 客觀上比較好。

那些 AI 功能,值得為它加價嗎?

Typeform 定價頁四個 AI 功能:know-pilot、GTM workflows、AI research、Contacts Automations 簡介

Typeform 這幾年把自己重新定位成「Forms & Automated Workflows, Powered by AI」(依官方首頁 typeform.com 標題,2026-08-10 查證),定價頁上也掛了一串 AI 相關的功能名。依官方定價頁(2026-08-10 查證),這些名稱包含 Your AI know-pilot、Automated workflows for GTM teams、AI-moderated research studies,以及 Contacts & Automations。

我必須誠實說:這些是官方頁面上的功能「名稱」,我查到的片段並沒有逐一展開說明每個功能實際做到什麼程度。所以我只能照字面幫你解讀它們的定位,不替效果背書:

  • Your AI know-pilot:從名字看,是一個內建的 AI 協作/副手概念(know-pilot 是 copilot 的雙關),推測用途是在你建表單或看回覆時給 AI 輔助。具體它會幫你生成問題、還是分析回覆,官方在此片段沒細說。
  • Automated workflows for GTM teams:字面是「給 GTM(進入市場)團隊的自動化工作流」。定價頁另有一段描述,是為「需要自動化並簡化行銷流程的成長型團隊」而設計。換句話說,它想解決的是「表單收到資料之後,怎麼自動接到後續行銷動作」這件事。
  • AI-moderated research studies:字面是「由 AI 主持的研究」,看起來是針對做用戶研究、訪談型調查的場景。
  • Contacts & Automations:聯絡人管理加自動化,屬於把填表的人變成可追蹤名單、再串後續動作的那塊。

那到底值不值得為這些多付錢?我的看法是:這要看你買的是「表單」還是「表單後面那條自動化流程」。如果你只是要做一份漂亮問卷、把回覆匯出成試算表,那這一整套 AI 與自動化其實用不太到,付高階月費就有點浪費。但如果你的痛點是「表單收完資料之後,還要有人手動把名單貼到別的系統、再手動觸發下一步」,那這條自動化流程省下的,是持續性的人力成本——這種需求,我會覺得多付的錢比較有著落。至於流程串接要接得多深、要不要再搭一個獨立的自動化平台,這部分我在Make.com那篇有比較細的討論。

誰適合掏這筆錢?三種情境對號入座

Typeform 三種適用情境:行銷顧問、GTM 成長團隊、HR 招募人員對照

價格看完,最實際的問題還是「這是給我這種人用的嗎」。下面用三個假想角色來對照,都是示意情境,不是真實用戶數據——你可以挑最像你的那個對號入座。

假設你是接案的行銷顧問

你手上同時有好幾個客戶,每接一個案子就要做一份客製化的需求調查或滿意度問卷,而且你希望表單看起來夠專業、不要一眼就被認出是免費模板。這種情境下,你在意的是「一個帳號能不能撐起多客戶的表單需求」,以及表單填完能不能自動把名單整理好。這時候該看的重點不是價格數字本身,而是你要的量級落在 266 還是 379 那一層——用 14 天試用把你最常做的那份問卷完整搭一遍,答案就出來了。

假設你是小型 SaaS 的成長/GTM 團隊

你們要做的不只是收表單,而是「潛在客戶填完表單 → 自動進名單 → 自動觸發後續行銷動作」這一整條。官方那個「Automated workflows for GTM teams」講的正是這個場景。對這種團隊,Typeform 的賣點就不在表單本身,而在它能不能少讓你們手動搬資料。要判斷值不值,關鍵是把你們現有那條手動流程,在試用期裡試著用它自動化跑一次,看接得順不順。

假設你是負責招募的 HR

你要收求職者的申請表、篩履歷、追進度,這條需求對應的是官方另外拉出來的 Talent 方案,起價 119 USD/月(依官方定價頁,2026-08-10 查證)。它被獨立成一條線,代表 Typeform 把 HR 場景當成和一般行銷/研究不同的需求在賣。119 是入門價,實際費用得點進 Talent 方案細節才知道,這點我在下面常見問題會再提一次。

379 美元一個月,換算下來是什麼概念?

把數字放進真實預算裡看,感受會不太一樣。379 USD/月,一年就是四千多美元;266 USD/月,一年也超過三千。這對個人或很小的團隊來說,是一筆得認真開會討論的固定支出,不是「順手訂一下」的等級。

而且工具訂閱有個很容易被忽略的陷阱:它們是會疊加的。你可能已經在付一個 AI 寫作工具、一個自動化平台、一個設計工具,Typeform 再加進來,每一個單看都「還好」,加總起來就成了每月固定的一大筆。要不要為表單花到三位數美金,其實應該放在你整體訂閱組合裡一起看——這方面我在2026 AI 工具訂閱費用總比較那篇,有把不同類型工具的花費放在一起算過一輪,可以拿來對照你自己的清單。

所以正確的順序是:先用月費 + 14 天試用確認這工具真的留得住,再切年繳鎖折扣,而不是一開始不確定就先綁一整年。先綁年繳省下的那點折扣,遠不如「試用期內發現不合用、及時抽身」省得多。

什麼情況值得花、什麼情況先別花

Typeform 訂閱值不值:適合訂閱的情況 vs 先別急著付錢的情況總結

整理到這裡,我對 Typeform 定價的態度其實蠻清楚。Typeform 這幾個數字,賣的是「表單 + 後面那條自動化與 AI 流程」的整包價值,對象是把表單當成獲客、研究或招募流程一環的團隊。

所以我的取捨是這樣:如果你只是要收資料、匯出表格,這個價格帶對你來說偏貴,我不會推你上車;

最後給一個很具體的下一步:先用官方那 14 天免費試用,把你「最常重複做的那一份表單 + 最想自動化的那一段流程」完整搭一遍,看它到底幫你省掉哪些手動步驟。這一輪跑完,你會比看任何評測(包括這篇)都更清楚該不該掏錢——因為那時候你算的,是你自己的時間,不是別人給的數字。

官方產品首頁截圖
官方產品首頁,2026-08-10 擷取(未登入、公開頁面)
官方定價頁截圖,顯示公開列出的方案價格
官方定價頁,2026-08-10 擷取(未登入、公開頁面)

常見問題

Typeform 有沒有長期免費、不用付錢的方案?

就我這次查到的官方定價頁片段(2026-08-10 查證),能確認的是有「14 天免費試用(after 14 days 才開始計費)」,但這份片段並沒有明確顯示是否存在一個長期、永久免費的方案。所以我不會替你打包票說「一定有免費版」——這是會隨官方調整的資訊。最穩妥的做法,是自己到官方定價頁最上方或最下方找找看有沒有 Free/免費起步的入口;如果找不到,就把那 14 天試用當成你唯一的免費視窗,在到期前把要驗證的功能都試完。

Talent 方案的 119 美元,到底包含什麼?

官方定價頁在這裡用的字是「starting at 119 USD/mo」(2026-08-10 查證),也就是「起價 119 美元/月」,並要你另外點進「Talent plan details」看細節。這代表 119 是這條 HR 專用線的入門價格,實際含哪些功能、有沒有更高的分層或人數上限,官方沒有在我查到的片段裡逐項列出。所以如果你是 HR、正在認真評估,建議別只看 119 這個數字就下判斷,直接進 Talent 方案的詳情頁把功能與額度看清楚,再對照你團隊每月要處理的招募量,才不會買了之後才發現要再往上加價。

頁面標的是美金,我實際付款會怎麼算?

Typeform 官方定價頁上的數字都以 USD(美元)計價(2026-08-10 查證),包含 266、379 和 Talent 的 119。這代表如果你用非美金的信用卡結帳,實際入帳金額會依你發卡銀行當下的匯率換算,有些卡還會多收一筆海外交易手續費;此外,某些地區在結帳時可能會再加當地稅(例如加值稅類的稅目)。這些都不是 Typeform 定價頁上那個數字能直接告訴你的,會因你的地區與發卡行而異。

最後更新:2026 年

想看同類型的其他選擇?

👉 瀏覽 AI 工具庫,一次比較更多同類工具。



Cohere 沒打算搶你桌上那個聊天視窗

同樣掛著「AI 公司」的招牌,Cohere 在一般人嘴邊出現的次數,遠不如它在企業採購清單上的份量。你身邊的人可能天天開著某個聊天視窗,卻很少有人會在下班閒聊時提到 Cohere——這不代表它小眾到沒東西可看,而是因為它從一開始瞄準的就不是「幫你寫一封信」這種桌面場景。

把它塞進「又一個 AI 聊天機器人」的抽屜裡,大概是最容易誤會它的方式。依 Cohere 官方定價頁(2026-08-09 查證),它給自己下的定義是一句英文:An enterprise-ready AI platform that powers modern workplace productivity——一個「企業級、推動現代職場生產力」的 AI 平台。注意是「平台」不是「app」,也注意「enterprise-ready」這個前綴:它把讀者預設成要把 AI 接進公司系統的人,而不是打開網頁就想聊兩句的人。

這篇不做親身實測(我手上沒有任何操作紀錄或截圖),只做一件事:把官方頁面上寫死的規格與定價逐條攤開,標清楚每一句話的來源與查證日,再加上一點我自己的取捨判斷,讓你決定這個平台跟你的需求對不對得上。下面用三個「要看的地方」把它拆開。

第一個要看的地方:它先把「企業」兩個字寫死了

很多 AI 產品是先做出一個好玩的功能,再想辦法賣給公司;Cohere 官方頁面的敘述順序剛好相反——它先講定位,再講能力。除了上面那句「企業級 AI 平台」,定價頁還放了另一句:An intelligent search and discovery system to surface business insights,一套「用來呈現商業洞見的智慧搜尋與發現系統」(依 Cohere 官方定價頁,2026-08-09 查證)。

「搜尋與發現」這個詞值得停下來想一下。它講的不是「幫你上網查資料」,而是把 AI 架在公司自己的文件、知識庫上面,讓人用自然語言去問、把散在各處的資訊撈出來。這正是這一兩年很多企業在做的事——把內部資料接上語言模型,做成可以問答的內部搜尋。如果你對這條路的技術底層有興趣,我在企業如何運用向量資料庫構建 AI 應用生態 2026那篇整理過向量檢索是怎麼運作的,可以一起看。

老實說,這種定位對讀者的意義是雙面的。好處是方向清楚:如果你要找的就是「把 AI 接進公司搜尋」的能力,它一開頭就跟你對上頻道,不用你自己去猜它到底適合幹嘛。代價是,如果你只是想要一個好用的聊天助理,這頁從第一句話就不是為你寫的——你會發現它講的都是平台、系統、企業,而不是「打開就能用」的體驗。這一點我不會替它美化。

第二個要看的地方:官方掛在架上的四種能力,分別長什麼樣

Cohere 在定價頁上,等於把四塊能力並排掛出來。我把原文照抄,並且刻意分清楚哪些是「有沒有這個功能」的可核對事實、哪些是官方自己下的形容詞(例如「高性能」「高準確度」)——後者是廠商說法,我沒有能力也沒有獨立測試去驗證,寫的時候會標清楚。

  • 企業平台:enterprise-ready AI platform that powers modern workplace productivity。這是定位敘述,前面已經講過。
  • 智慧搜尋與發現:intelligent search and discovery system to surface business insights。「有一套搜尋與發現系統」是功能存在性,可核對;「智慧」是形容詞。
  • 高性能模型:High-performance models for agentic, multimodal, multilingual AI。也就是官方說它有一批模型,涵蓋「代理(agentic)、多模態(multimodal)、多語言(multilingual)」三個方向。「有這三個方向的模型」是功能敘述;但「high-performance(高性能)」是官方形容詞,不是我驗證過的結論,未獨立驗證。
  • 語音辨識:A speech recognition model for generating highly accurate audio transcripts。官方說它有一個語音辨識模型,用來產生音訊逐字稿。「有語音辨識模型」可核對;「highly accurate(高準確度)」同樣是官方宣稱,我這篇沒有任何轉錄準確率的實測或第三方數據可以背書。

把這四條放在一起讀,我的判斷是:Cohere 想被理解成一個「後端能力供應商」——搜尋、代理、多模態、多語言、語音轉錄,這些都是你會拿去接進某個系統的零件,而不是一個打開就替你完成任務的成品。這是取捨:對開發者友善,對只想要成品的人就沒那麼直覺。

下面把官方頁面上寫得出來的規格重點整理成一張表,每一格都標來源與查證日;查不到或官方沒公開的,我就不硬填。

  • 產品定位 — 官方頁面上的說法(重點): 企業級、推動職場生產力的 AI 平台(enterprise-ready AI platform);來源與查證日: Cohere 官方定價頁,2026-08-09
  • 搜尋與發現 — 官方頁面上的說法(重點): 呈現商業洞見的智慧搜尋與發現系統;來源與查證日: Cohere 官方定價頁,2026-08-09
  • 模型能力方向 — 官方頁面上的說法(重點): 用於代理/多模態/多語言的模型(官方形容為 high-performance);來源與查證日: Cohere 官方定價頁,2026-08-09
  • 語音能力 — 官方頁面上的說法(重點): 語音辨識模型,用來產生音訊逐字稿(官方形容為 highly accurate);來源與查證日: Cohere 官方定價頁,2026-08-09
  • Trial API key 計費 — 官方頁面上的說法(重點): API 調用免費;來源與查證日: Cohere 官方定價頁,2026-08-09
  • Production API key 計費 — 官方頁面上的說法(重點): 按次計費(pay-as-you-go);來源與查證日: Cohere 官方定價頁,2026-08-09
  • 帳單開立時機 — 官方頁面上的說法(重點): 每個日曆月末,或未結餘額達 $250 時;來源與查證日: Cohere 官方定價頁,2026-08-09
  • Command 定價 — 官方頁面上的說法(重點): 輸入 $1.00(官方定價頁,2026-08-09 查證)/輸出 $2.00(每 1M tokens);來源與查證日: Cohere 官方定價頁,2026-08-09
  • Command-light 定價 — 官方頁面上的說法(重點): 輸入 $0.30/輸出 $0.60(每 1M tokens);來源與查證日: Cohere 官方定價頁,2026-08-09
  • Command R 03-2024 定價 — 官方頁面上的說法(重點): 輸入 $0.50/輸出 $1.50(每 1M tokens);來源與查證日: Cohere 官方定價頁,2026-08-09
  • token 換算 — 官方頁面上的說法(重點): 簡單文字約 1 token/字,複雜文字約 3–4 tokens/字;來源與查證日: Cohere 官方定價頁/Tokens and Tokenizers 文件,2026-08-09

這張表刻意只放官方寫得出來的東西。你會發現它沒有「準確率 XX%」「比誰快幾倍」這種欄位——因為官方頁面上沒有給這種可核對的數字,我也不打算替它補一個看起來很專業、其實查不到來源的分數上去。

情境一:公司內部知識搜尋(假設你是知識管理或 IT 負責人)

假設你是一家中型公司的知識管理負責人,內部文件多到同事「找不到上次那份簡報」變成日常。Cohere 官方主打的「智慧搜尋與發現系統」正是為這種任務設計的:把 AI 架在自家文件上,讓人用問句去撈。它是不是真的比你現在的做法好用,取決於你的資料量與導入方式,這點官方頁面沒有承諾、我也不做保證——但方向上,這確實是它宣稱要解的問題。

情境二:後端工程師要在產品裡接語言模型

假設你是後端工程師,要在自家產品裡加一段「代理式」流程或多語言回覆。Cohere 走的是 API 路線,Trial key 的調用免費(依官方定價頁,2026-08-09),你可以先申請一把 key 把接法跑通、確認回傳格式再說。要選哪套模型框架來搭,可以參考AI 應用開發框架怎麼選?AutoGen vs LangChain vs LlamaIndex 對比指南。

情境三:需要多語言音訊轉逐字稿的人

假設你手上有一批多語言的會議或訪談錄音要轉成逐字稿。Cohere 官方列了語音辨識模型這條能力線,用途正是產生音訊逐字稿。官方把它形容成「高準確度」,但我要老實說:這篇沒有任何轉錄準確率的實測或第三方測試可以引用,中文、混語音訊的實際表現我找不到官方公開的評測資料,真的要用就得自己拿樣本測一輪。

第三個要看的地方:真正決定你要不要碰它的,是帳單

規格再漂亮,最後拍板的往往是錢怎麼算。Cohere 的計費邏輯在官方定價頁上寫得算清楚:API calls made from a Trial API key will be free. API calls made from a Production key will be billed on a pay-as-you-go basis.——用 Trial key 打的 API 調用免費;換成 Production key 就變成按次計費(依官方定價頁,2026-08-09 查證)。帳單開立的時機是「每個日曆月末,或未結餘額達 $250 時」,這兩個條件哪個先到就哪個結。

模型的單價則是分模型列的,我要特別提醒:下面這些是各別模型的費率,不是平台通用價,請以你真正要呼叫的那個模型頁為準。依官方定價頁(2026-08-09 查證):Command 是輸入每 1M tokens 美金 $1.00、輸出 $2.00;Command-light 是輸入 $0.30、輸出 $0.60;Command R 03-2024 這個版本是輸入 $0.50、輸出 $1.50。同一個「Command」家族,光是這幾個選項的單價就差了好幾倍,選錯模型跟選錯方案一樣傷荷包。

官方在同一頁把 token 怎麼換算也講白了:語言模型認的是「token」不是字或位元組,簡單文字大約一個字一個 token,複雜、生僻的文字可能一個字要 3–4 個 tokens。這句話對估成本很關鍵。舉個你可以自己驗算的例子:假設你送進去一份大約 3,000 個 token 的英文簡單文字,用 Command 的輸入費率算,就是 3,000 ÷ 1,000,000 × $1.00 ≈ $0.003——連一美分都不到。單看這個數字會覺得便宜到不真實,但真正會把帳單堆高的,是「調用次數」乘上去之後的量級,還有輸出 token 通常比輸入貴(Command 就是輸出價是輸入的兩倍)。

所以我的取捨判斷是這樣:如果你只是想試個水溫,Trial key 免費這點讓你幾乎零成本就能把接法跑通,這是很友善的入場方式。但一旦切到 Production、要用它扛正式流量,你就得先估清楚自己每次調用大概吃多少 token、一天調幾次,再乘上你選的那個模型費率——而不是看到某個模型的每百萬 token 單價就以為很便宜。想跟其他家的訂閱與 API 成本一起橫向比,可以翻2026 AI 工具訂閱費用總比較:ChatGPT、Claude、Gemini、Cursor 到語音與自動化工具,到底多少錢、怎麼選最划算那篇對照。若你要親自去把 key 申請下來玩玩,Cohere 的 Trial 調用是免費的,先跑通再決定要不要進 Production 是比較穩的順序。

剩下的,交給你的 token 帳單

如果你要的是能塞進公司內部搜尋、又想自己掌握 API 成本的後端能力,Cohere 的規格值得你花十分鐘把定價頁讀完、拿自己的用量算一遍再決定;但你若只是想要一個桌面聊天視窗,這頁大概不是為你寫的。

官方定價頁截圖,顯示公開列出的方案價格
官方頁面,2026-08-09 擷取(未登入、公開頁面)
官方文件頁截圖
官方文件頁,2026-08-09 擷取(未登入、公開頁面)

常見問題

Cohere 到底適不適合個人使用者,還是只給公司?

官方在定價頁上把自己定位成「企業級 AI 平台」(依官方定價頁,2026-08-09),文案確實是往公司場景寫的。但這不代表個人碰不到它:Trial API key 的調用是免費的,技術上任何開發者都能申請一把 key 來試接。我的判斷是,適不適合個人取決於你要做什麼——如果你是想寫程式、把語言模型接進自己的小專案,那 Trial 這條路對個人是開放的;但如果你要的是一個打開網頁就能聊天、不用寫任何程式的成品體驗,這個平台的重心不在那裡,你可能會覺得門檻偏高。這是定位造成的取捨,不是缺點或優點的問題。

官方說支援多語言,那中文的實際表現如何?

官方在能力敘述裡確實寫了「multilingual(多語言)」(依官方定價頁,2026-08-09),也就是說多語言是它明列的方向之一。但我要誠實講:這份材料裡沒有任何逐語言的品質數據,中文(尤其繁體中文、混語內容)的實際轉譯或生成品質,我找不到官方公開的評測資料,也沒有第三方測試可以引用,所以我無法替它背書「中文很好」或「中文不行」——這兩種說法我都沒有依據。真的要用在中文場景,唯一可靠的做法是拿你自己的實際內容去跑一輪 Trial,看輸出對不對得上你的標準,再決定要不要進正式環境。

除了 API 按次計費,Cohere 有沒有月訂閱那種固定方案?

就這份查證到的官方定價頁內容來看,它明講的計費方式是 Trial key 免費、Production key 按次計費(pay-as-you-go),帳單在月末或未結餘額達 $250 時開立(依官方定價頁,2026-08-09)。至於有沒有另一種固定月費的訂閱方案、或針對大企業的合約制報價,這份材料沒有涵蓋,我不確定就不寫死。如果你需要的是可預測的固定月費而不是浮動用量帳單,建議直接到官方定價頁或聯絡它的業務窗口確認,別用我這篇的按次資訊去反推它一定沒有訂閱制。

Trial API key 和 Production API key 除了收不收費,還差在哪?

官方原文我能引到的差異,只有計費這一條:Trial key 的調用免費,Production key 按次計費(依官方定價頁,2026-08-09)。至於兩者在速率限制、可用模型範圍、正式環境的服務條款上還有沒有其他不同,這份查證材料沒有寫到,我沒把握就不編。實務上,多數 AI 平台的試用 key 會有較嚴的速率或用量上限,但這是通則、不是我查到的 Cohere 具體規格,所以請以它的官方開發者文件為準,不要把我這句通則當成 Cohere 的確定事實。

最後更新:2026 年

還在挑工具?

👉 瀏覽 AI 工具庫,依用途篩選,少走冤枉路。



先接受一件事:你其實不是在三選一

同樣是幫你把一篇文章的 SEO 做扎實,為什麼有的工具一個月按額度就打發得掉,有的卻要簽整年、還按人頭算錢?很多人把 Surfer、Clearscope、SEMrush 擺在一起,以為是在做同一件事的三個競品,選一個最划算的就好。

但真正攤開來看,這三個工具其實踩在不太一樣的位置上。Surfer SEO 主打的是把一篇文章的內容深度、字數、標題結構、關鍵詞覆蓋率拿去和目前排在前面的頁面做比對,給你一個「還差哪些」的清單;Clearscope 的重心放在關鍵字與相關詞的聚類,逼你把內容寫得更聚焦;而 SEMrush 根本是個全套的數位行銷平台,內容優化只是它眾多模組裡的一塊,旁邊還坐著關鍵字研究、排名追蹤、反向連結分析、廣告工具一大票。

所以「性價比」這件事,前提是先問「你到底在為什麼付費」。拿一個只想優化幾篇部落格文的人,去比較一個要管整個網站健康度的平台,本來就不公平。這篇就照這個順序走:先看它們各自在做什麼,再看錢怎麼算,最後看你是哪種人。訂閱成本這件事我先前在2026 AI 工具訂閱費用總比較裡也整理過類似的思路,可以搭配著看。

第一步:搞清楚每個工具在替你做哪件事

Surfer SEO、Clearscope、SEMrush AI 三款工具核心功能取向與設計重心比較

把功能講清楚,比急著排名次有用得多。這三家的設計取向差很遠,先各自看一輪。

Surfer SEO:把「這篇該長什麼樣」量化給你看

Surfer 的核心是它的內容編輯器(Content Editor)。你丟一個目標關鍵字進去,它會去抓目前排在搜尋結果前面的頁面,統計出一個大概的內容輪廓——建議字數、該出現的相關詞、標題與段落數量,然後給你一個即時分數,你邊寫它邊算。它還有 SERP 分析、關鍵字研究、以及檢查現有文章缺什麼的 Audit 功能。

它的個性很明確:把「內容深度」和「和搜尋意圖的相關性」盡量拆成可以照著補的項目。對於「我知道要寫這篇,但不知道還缺什麼」的人來說,這種清單式的回饋是很直接的。至於它算出來的建議是否真的能推高排名,這牽涉到 Google 排名的眾多因素,缺乏可一概而論的公開定論,我不會把它講成保證。

Clearscope:逼你把內容寫聚焦

Clearscope 走的是更精簡的路線。它同樣分析競爭頁面,產出一份相關詞清單和一個內容評級(用字母等級呈現),但它刻意把介面做得乾淨,重心壓在「主題涵蓋度」——也就是你這篇有沒有把讀者期待看到的相關概念都寫到。它和 Google Docs、WordPress 有整合,讓寫作流程順一點。

從功能編排看,Clearscope 的取捨很清楚:把重心放在「一篇內容夠不夠聚焦、夠不夠完整」這件事上,介面與報表都圍繞單篇內容展開。這是設計取向的差異,不是誰比較強——它是把範圍聚焦在單篇內容換來的簡潔。

SEMrush AI:內容優化只是入口,不是全部

AI 應用開發框架怎麼選那類「平台 vs 專門工具」的取捨,在這裡又出現一次。SEMrush 是一個大平台,它的內容相關功能(例如內容範本、寫作助手、以及後來加進來的 AI 功能)是掛在整個行銷套件底下的。你買它,多半不是為了單純優化一篇文章,而是連帶要用它的關鍵字研究、競品分析、排名追蹤、反向連結那一整套。

換句話說,如果你只想要一個「寫文章時在旁邊打分數」的東西,SEMrush 的內容模組可能只用到它十分之一的能力,剩下的你付了錢卻不一定碰。反過來,如果你本來就需要管整個網站的 SEO,那把內容優化順手包進來,反而省得再多訂一個工具。

第二步:三種定價模式,錢的算法完全不同

這是性價比分析最關鍵、也最容易被忽略的一段。這三家不只是價格高低不同,而是「收費的邏輯」根本不一樣,直接影響你用起來划不划算。具體金額與方案結構請務必以各家官方定價頁的現價為準(會隨方案調整),下面我只講收費邏輯的大方向。

  • Surfer——按功能額度計費:大致是依你每段時間能建立多少篇內容、能跑多少次查詢來分級(實際級距以官方定價頁為準)。用得多就往上升級,用得少就停在低階方案。對產出量不穩定的人來說,這種「按量」邏輯比較好抓。
  • Clearscope——按專案/內容報告消耗:它的邏輯偏向「你這個月要優化幾篇」。額度用在一份份內容報告上,適合把每一篇都當作一個獨立專案來處理的工作方式。
  • SEMrush——平台型計費:它是平台型定價,方案層級、使用者座位數、以及是否以年繳為主等收費方式,請以官方定價頁的說明為準。相較按篇計費的工具,它的方案偏向一整包,若只想試一個月,得先看官方是否有對應的短期選項。

下面這張表把三者的側重攤開來對照。它不打分、不排名次,只描述各自有什麼、算法怎麼走;功能與定價細節請以各家官方最新說明為準。

Surfer SEO、Clearscope、SEMrush AI 定價算法與功能特色對照表

看這張表會發現一個重點:Surfer 和 Clearscope 的設計重心放在內容優化,SEMrush 則以全方位行銷平台自居、內容只是其中一塊。所以拿它們的月費直接相減沒有意義——你要比的是「同樣一筆錢,換到的東西是不是你會用的」。一個只寫部落格的人買 SEMrush,多出來的那些排名追蹤、反向連結分析很可能永遠閒置;反過來,一個要管全站 SEO 的團隊,若選的是設計重心放在內容優化的工具,就得先留意它是否涵蓋你需要的排名追蹤、反向連結等環節,可能還要另外搭配工具。

第三步:對號入座——獨立部落客、代理商、企業各看哪個

獨立部落客、內容代理商、企業行銷部門三種情境如何選擇 AI SEO 工具的決策邏輯

講完功能和算法,最實際的問題還是「我這種情況該看哪個」。下面三個是示意用的假想角色,你對照著看自己比較像哪一種。以下推薦都是我的編輯判斷,綁在特定面向與前面已經攤開的事實上,不是替誰封總冠軍。

假設你是預算敏感的獨立部落客/自媒體

你多半是一個人做,產出量不固定,最怕的是「簽了年約結果一個月沒寫幾篇」。以這個面向——也就是定價彈性與是否被綁約——來看,前面提過 SEMrush 偏向整包年約、按座位算(實際方案以官方定價頁為準),對一人作業來說負擔的是整個平台的門檻,而你可能只會用到內容那一小塊。單就「不想被年約綁住、只要單篇內容優化」這個需求,我會先看按量計費的 Surfer,或按報告消耗、介面單純的 Clearscope。至於最後選哪個,取決於你更在意「照清單補齊內容」還是「介面越乾淨越好」,這是使用習慣,沒有標準答案。

假設你是中型內容代理商

代理商的特徵是多客戶、多專案、要交報告,而且常常需要團隊一起在同一份內容上作業。以多專案管理與協作這個面向看,Clearscope 那種「一篇=一個報告」的邏輯,對按客戶/按專案計費的作業方式蠻合拍;Surfer 的按量分級則適合產出量大、需要一次跑很多篇的團隊。這裡我不會直接說哪個「比較好」,因為它取決於你的計費是跟客戶按專案報,還是按產出量報——你的收費模式對得上哪個工具的算法,那個對你就順。

假設你是企業級行銷部門

如果你們部門本來就在做全站 SEO、要追排名、要看反向連結、要跨團隊協作,那「內容優化」只是拼圖的一角。以是否需要整合到既有行銷 stack這個面向,SEMrush 的座位制與平台整合就有它的道理——把內容、關鍵字研究、排名追蹤放在一個後台,省去在多個工具之間搬資料。如果你們本來就打算長期使用整個平台,它的年約門檻造成的顧慮就相對小——因為你本來就會長期用。至於「需要熟悉的東西比較多」這點,是它功能廣度的自然結果:一個把多種行銷工具塞進同一個平台的產品,要摸熟的項目本來就比只做內容評分的工具多,這是廣度換來的成本,不是缺點。

一個講白的取捨

真正的分水嶺其實是這句:你買的是「一篇文章的優化」,還是「一整個網站的 SEO」?前者,Surfer 和 Clearscope 這類工具,設計重心就放在單篇內容優化,你付的錢對應的正是這一塊;後者,把內容包進 SEMrush 這種平台,就不用另外養一堆分散的訂閱。想清楚這一題,性價比的答案通常就自己浮出來了。

常見問題

這三個工具,可以只選一個就夠嗎?

看你的工作範圍。如果你只做內容——寫部落格、優化文章、補齊主題涵蓋度——那 Surfer 或 Clearscope 其中一個,通常就能撐起日常需求,不必三個都買。但如果你的工作還包含關鍵字研究、排名追蹤、反向連結分析這些全站 SEO 的事,那就得確認你選的工具是否涵蓋到這些環節——你要嘛選 SEMrush 這種把它們包在同一平台的產品,要嘛額外搭配別的工具。重點不是「哪個功能最多」,而是「你會用到的功能,哪個工具剛好覆蓋到」。與其想著全都要,不如先列出你每週真的會做的三件事,再回頭看哪個工具的核心正好落在那上面,多出來的功能付了錢也是閒置。

寫中文內容適用嗎?

老實說這點要保守看待。Surfer 和 Clearscope 這類工具的核心,是去分析搜尋結果前段頁面的內容特徵。至於它們的語料與 SERP 資料對中文市場的涵蓋程度,以及中文的分詞、相關詞判斷、內容評級在中文語境下的準確度,我目前找不到足以下定論的公開資料,所以無法替你保證中文效果和英文一樣好。務實的做法是:如果你主力做中文內容,先用它們的短期方案或試用(若官方有提供)拿一兩篇你熟悉的題目實測,看它給的相關詞建議在中文情境下合不合理,再決定要不要長期投入。把它當「輔助檢查清單」而不是「照著填一定會贏」,期待會比較健康。

有沒有免費版可以先試?

是否有免費方案或試用期,這是會隨時間變動的定價政策,我不把它寫死。最準的做法是直接去三家的官方定價頁看目前的方案結構——各家的計費形式(例如年約、按座位、按量/按報告等)與短期試用條件可能各不相同,實際以官方定價頁當前的方案為準。如果你想低成本探路,可以留意有沒有按量或按報告計費的選項,這類方式通常能只買少量份額(幾份報告)先跑跑看(實際額度與是否提供,以官方定價頁為準);而平台型的年約產品,即使有試用,也要想清楚後續是不是真的要長期用整套。建議報名前先把「我這個月會實際優化幾篇內容」算出來,再對照方案的額度,才不會買了用不完,或買了不夠用。

Surfer、Clearscope 只做內容優化,和 SEMrush 到底差在哪?

主要的差別在「範圍」。Surfer 和 Clearscope 主打的是「單篇內容寫得夠不夠深、夠不夠聚焦」這一塊,把這件事做細。SEMrush 則是一整個行銷平台,內容優化只是它眾多模組的一塊,旁邊還有關鍵字研究、競品分析、排名追蹤、反向連結、廣告研究等等。所以差別不是「誰的內容功能比較強」——那需要獨立比較證據才能下判斷,我不憑印象講——而是「你需要的是一把專用的內容刀,還是一整套行銷工具箱」。專用刀功能集中在內容優化這一塊、模組少;工具箱涵蓋的範圍廣、模組多、要熟悉的功能也多;但你若本來就要做這麼多事,分開買反而更麻煩。

只經營一個部落格,值得付 SEMrush 的年費嗎?

這要看你會不會用到內容以外的功能。如果你就是寫寫文章、偶爾查個關鍵字,那 SEMrush 那一大堆全站 SEO 工具對你多半是浪費——你付了整包的錢,卻只用到內容那一塊;如果只需要內容優化,選按量或按報告計費的專門工具,就有機會只為這一塊付費(實際計費方式以官方為準)。但如果你的部落格已經開始認真經營、你想自己追排名、分析競爭對手、盯反向連結,那把這些一次包進 SEMrush,長期看可能比東湊一個西湊一個省事。判斷點很簡單:把你未來半年真的會用到的功能列出來,如果清單裡有一半以上是「內容優化以外」的事,SEMrush 的年費才開始說得過去。

用這些工具優化過的內容,Google 會不會當成 AI 生成而降權?

先分清楚一件事:這三個工具在本文討論的用途是「內容優化與分析」——你實際會用到的,是它們提供的相關詞、結構、涵蓋度這類建議,內容本身仍由你自己下筆。所以「會不會被判定成 AI 生成」這個擔憂,其實和你怎麼產出內容比較有關,而不是有沒有用這些優化工具。至於 Google 如何看待 AI 協作的內容、會不會因此影響排名,這牽涉搜尋引擎的排名機制,各方說法不一且缺乏可一概而論的公開定論,我不會給你「一定安全」或「一定被罰」的斷言。務實的原則還是老話:優化工具給的是參考清單,別把相關詞硬塞到讀起來很怪,內容本身對讀者有沒有用,才是你能控制的部分。

說到底,這三個工具沒有一個「最划算」的標準答案,只有「和你的工作範圍對不對得上」。先誠實回答自己一題——你買的是一篇文章,還是一整個網站——剩下的成本比較,就只是把數字填進去而已。

最後更新:2026 年

還在挑工具?

👉 瀏覽 AI 工具庫,依用途篩選,少走冤枉路。



返回頂端