title: 便宜到不可能好用？再想想。
published: true
description: 我把 aaPanel/OpenLiteSpeed 換成 Caddy 和 shell 腳本，並把整個流程做成一個基準測試。分成兩個階段（架構與程式碼），再加上一個外部程式碼審查。勝出的模型？大概不是你會猜到的那個。
tags: ai, benchmark, devops, webdev
cover_image: https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/ubntswe9out232oq40rv.png

published_at: 2026-02-09 15:36 +0000

多年來，我都用 OpenLiteSpeed 來跑我的 WordPress 網站。伺服器速度快，LSCache 的確很驚人，OLS/WordPress 這組合在原始效能上幾乎無敵。至於控制台，我一開始用的是 CyberPanel——比微軟的產品還不穩，而且團隊看起來像是刻意把免費功能弄壞，逼使用者升級付費方案。我說的不是那種「修得好」的 bug。我說的是那種看起來像是被設計來阻止免費版功能完成任何動作的 bug。

舉兩個例子。WordPress 安裝：我用了好幾年都沒問題。自從 CyberPanel v2.4.x 之後，最後一步會被一個 SQL 錯誤擋住。檔案都在，而且也完整下載好了，但你必須手動建立資料庫，然後自己執行安裝。老實說，這只能說是反直覺。

第二個例子：Let's Encrypt SSL 憑證產生會持續失敗，因為生成出來的設定檔是錯的。而且在這兩種情況下，都有一個付費的「增強版」可用。這也不意外。

我的立場很簡單：如果某個功能多年來都能用，現在卻不能用了，我沒有任何保證付費版也能用——也不能保證明天條款不會改。這算不算誘餌換魚？我不會直接這麼說。但當免費功能多年可用，接著在連續多個版本中都失效，而付費替代方案又涵蓋同樣功能時——答案其實已經自己說明了一切。我問過這個問題，也得出了結論，並把這家供應商列入黑名單。

於是我轉向 aaPanel：比較順眼、更穩定、也更輕量。但它對 OLS 的管理方式完全不走常規——你無法直接設定 OpenLiteSpeed，所有東西都要經過 aaPanel 的抽象層，你失去對自己技術堆疊的控制。只要直接碰 7080 連接埠，就可能把整套系統弄壞。你只能用 aaPanel 儀表板。僅此而已。

接著，我的使用情境改變了。更多 Astro、更多半靜態網站、更多不需要 PHP 的專案。當你走出 WordPress 的範圍時，OLS 的吸引力就大幅下降。相較之下，Caddy 會自動處理 HTTPS，設定檔只要幾行可讀性很高的內容，而且沒有 OLS 那些重寫規則的怪癖。

問題變成：能不能用 Caddy 加上一個控制面板，取代 aaPanel/OLS？GitHub 上其實有一個——CaddyManager，1,100 顆星，只有一位貢獻者，永遠處於「早期開發」階段。還有 CaddyGen，一個只花 8 小時做出來的 Caddyfile 產生器——比較像概念驗證，而不是完成品。沒有任何一個足夠接近可直接上線。

結論很明顯：用寫得好的 shell 腳本，加上一個極簡的 FastAPI 介面，就能做到，而且會好維護得多。只是得有人把它寫出來。

與其自己做，我開始想把規格交給 GitHub Copilot CLI。或者 Claude Code。但考量到 Copilot 新的計價方式，幾乎只夠你抿一口，帳單就已經來了……我對 OpenCode 和 Kilo CLI 起了興趣，透過 DeepInfra 或 OpenRouter 來串接。然後，我決定把這件事做成一個基準測試。

📋 TL;DR：在真實 VPS 專案上測試了 8 種工具／模型組合。分成兩階段——先架構，再程式碼。最後再加上一個獨立的外部審查來分勝負。唯一被判定可直接上線的工具組合，總成本只有 1.94 美元。勝出的模型？你大概沒在一般比較文章裡看過。

💡 閱讀提示：直到第 5 節之前，程式碼階段挑出的四個實作會以 A、B、C、D 代稱。模型名稱會在外部審查結果之後揭曉——理由就跟你匿名陪審團一樣：先看程式碼，再看標籤。

1. 測試專案

這份需求刻意設計得很具體：一個用於 Ubuntu 24.04 的極簡 VPS 管理工具包。Web 伺服器用 Caddy，PHP-FPM 使用兩個版本（現行與備援），資料庫使用 MariaDB 和 PostgreSQL，物件快取則用 Valkey。所有操作都用 shell 腳本，並提供 FastAPI 介面做自動化。不要 Docker、不要控制台、不要不必要的抽象層。

要處理四種網站型態：靜態站（只有 HTML／資產，不用 PHP，也不用資料庫）、PHP 站（自訂應用，可選資料庫）、WordPress（透過 WP-CLI 完整安裝，必須有資料庫），以及反向代理。最後一種特別說明一下：它其實就是一個 Caddy 虛擬主機，會把請求轉發到本機埠號——像是同一台伺服器上執行的 Node.js、FastAPI 或 Go 應用。Caddy 負責 HTTPS 和網域；應用程式不需要管這些。沒有 PHP-FPM、沒有資料庫——只有一個 reverse_proxy 區塊和一個埠號。

預期操作涵蓋完整生命週期：伺服器初始化、網站建立、刪除前自動備份的破壞性操作、按需建立資料庫、透過 rsync 發佈靜態網站、備份，以及服務管理。

為什麼要用真實專案，而不是合成基準測試？因為合成基準測試只是在測模型在理想條件下能做什麼。真實專案則是在測模型面對層層限制時會怎麼做——安全性、冪等性、跨檔案一致性、shell 與 Python 層之間的錯誤處理。差異就是在這裡浮現。

完整功能需求可見於專案的 GitHub 儲存庫。

2. 方法

這個流程分成兩個明確階段，中間由人工驗證隔開。

階段 1 — 架構

相同的功能需求會送給每個工具／模型組合。不提供額外脈絡、不提供設定檔、不提供預期解法的提示。工具會提出一個架構、專案結構、腳本清單與各自職責、API 路由圖。如果設計得好，它會先問問題，再開始產出任何內容。

階段 2 — 實作

一旦規劃被驗證、決策被確認，就會向所有工具送出同一個開發提示。內容包含已驗證的架構、十項已確認的技術決策、腳本→API 的退出碼約定，以及一個毫不含糊的指示：依順序把三十個檔案寫到磁碟上，不要摘要，不要偷工減料。

測試組合

原本計畫測 Devstral 2（123B）。可惜的是，這個模型沒有出現在 OpenCode 或 Kilo CLI 的模型選單裡——兩者都從 models.dev 拉取目錄，而那裡雖然已經能在 OpenRouter 上使用，卻還沒完成索引。透過 OpenRouter playground 的測試確認，這個模型確實可透過 API 存取，但若不放在編碼代理工具裡，它會失去我們想測量的大部分能力。Devstral 2 是因純技術原因缺席，不是因為品質問題。

Haiku 4.5 出現了三次——分別搭配三種不同工具。這是刻意安排的：這正好能讓我們把工具的影響獨立於模型之外。

程式碼階段最後挑了四個具代表性的實作，在第 5 節揭露前先標成 A、B、C、D。

外部審查

這四個實作產出的程式碼會送交給一個未參與基準測試的模型，並使用固定的評分標準：安全性、正確性、冪等性、程式碼品質、完整性。每個實作抽五個代表性檔案，總分 25 分。

3. 規劃階段 — 到底誰真的會思考？

這份功能需求隱含地問了每個工具一個問題：當你拿到一個沒有現成解法、範圍開放的專案時，你會怎麼做？

首先你會注意到一件很明顯的事：沒有任何一個受測模型會先問問題再產出規劃。沒有一個。它們全部都是先給完整架構，最後才在結尾問澄清問題。這跟人類架構師的做法完全相反；人類會先卡在模糊處，確認清楚後才會開始畫圖。

這很重要。事後才提出的幾個問題，如果一開始就問，會直接改變架構決策。其中一個模型辨識出「磁碟上不能有秘密」與應用程式設定檔必須合法保存憑證之間的張力——wp-config.php 就是最明顯的例子。這是一個真正會阻礙進度的問題。若是在規劃之後才問，它就只剩下一則註腳。

這些規劃透露了什麼

問題品質是第一個可區分的訊號。有兩個模型提出了四、五個真正會卡住的問題，還附上選項與建議。另一個則問了八個很泛的問題——像是壓縮格式、日誌輪替——但在架構上不會改變任何東西。

提出的結構是第二個訊號。只有一個模型主動提出一個統一的 CLI 入口點——bin/vpsmgr——由它去分派到各個腳本。這個細節把一堆腳本變成了一個一致的工具。其他模型沒想到這一點。

有一個模型是唯一在規劃階段就提出標準化、具文件化的退出碼約定的：

這不只是美觀問題。這是 shell 腳本和 FastAPI 層之間的合約——沒有它，HTTP 對應就會變得任意，每條路由的實作也會各自為政。

規劃階段成本

Gemini 3.1 Pro 產出的內容最精簡——27k token 就交出一份品質不錯的規劃。OpenCode 上的 Haiku 4.5 則用了 69k token，品質還比較差。Token 數量無法預測品質。

4. 程式碼階段 — 到底誰真的能交付？

程式碼階段以單一開發提示開始，送給四個選出的實作。內容包含已驗證的架構、十項確認的技術決策、退出碼約定，以及一個毫不含糊的指示：依相依順序把三十個檔案寫到磁碟上，不要摘要，不要偷工減料。

差異從這裡開始變得具體。

common.sh 透露了什麼

共用函式庫是第一個交付的檔案。它是所有東西的基礎——記錄、秘密處理、網站狀態管理、密碼產生。只要 common.sh 有缺陷，所有引用它的腳本都會一起被污染。

模型 A 交出 98 行，內容簡潔。秘密遮罩明確涵蓋 WordPress 的全部十種樣式——salt、驗證金鑰。這一點最完整。但沒有網域驗證、沒有 require_cmd()、沒有原子化狀態檔寫入。

模型 B 交出 310 行。用 readonly 定義命名常數，normalize_domain() 搭配 RFC-1035 正規表示式，並發鎖、使用 mktemp+mv 做原子寫入。功能最完整的系統工具函式庫。但秘密遮罩漏掉了 WordPress salts。

模型 C 交出 366 行。遮罩模式可以透過環境變數設定，而不是硬寫死。純 shell 的 JSON 輔助函式，若沒有 jq 則退回 Python。print_credentials() 依提示規格用 <<>> 標記包住輸出。render_template() 用於設定檔，不依賴 Jinja。密碼產生會排除容易混淆的字元（0/O/1/l/I）。這是唯一一個能預先想到開發提示中記錄的所有邊界情況的實作。

模型 D 交出 184 行。這個基準測試裡最有創意的想法：把退出碼封裝成命名函式——exit_input_error()、exit_conflict()——比直接寫 exit 3 更易讀。而且在 common.sh 裡直接提供 json_output()，把 shell 內容轉成 API 可用的 JSON。沒有原子寫入、也沒有 require_cmd()。

你自己才會發現的 bug，或根本沒發現的 bug

模型 C 在會話中有自己測試自己的程式碼。它在寫完 schemas.py 之後，立刻用測試案例執行，找出兩個 bug 並馬上修正：一個是 Pydantic v2 的 validator 實作錯誤（跨欄位驗證應該用 model_validator，卻用了 field_validator），另一個是 schema 層級沒有強制互斥。它也修正了 render_template() 裡的 sed 替換問題——因為路徑中的 / 會壞掉——改成純 bash 參數展開。

在會話結束時，模型 C 提供了一份驗證摘要：所有腳本都通過 bash -n，所有 Python 檔案都通過 AST 檢查，19/19 個 API 路由都透過 OpenAPI 規格驗證，18/18 個 bash 輔助函式都測試過，PHP 備援規則也驗證過（8.5→8.4、8.4→無、7.x 拒絕）。

模型 A 在結束前檢查了 shebang。模型 B 交出精美的使用者文件——疑難排解、curl 範例、快速上手。模型 D 驗證了 bash 與 Python 語法。這三個都沒有測試功能邏輯。

程式碼階段成本

模型 D 在 9 分 42 秒內交出的內容，模型 C 需要 23 分 37 秒才交完——但沒有功能測試。模型 C 之所以多用了 3.4 倍的 token，是因為它在會話中執行了程式碼，每次迭代都要重新載入上下文。

5. 外部審查——以及揭曉

四個實作，四種安全性做法。為了避免偏誤，程式碼審查交給了一個不在基準測試內的模型，並使用固定的五項評分標準。每個實作抽五個代表性檔案——common.sh、site-create.sh、site-delete.sh、backup.sh、api/runner.py——一次載入二十個檔案。

審查成本：543k token，花費 $0.0766。比一小時的初階工程師工時便宜十倍。

逐檔觀察

在 site-create.sh 中，審查者發現了模型 D 的一個靜默 bug：SFTP 密碼有產生，但從未被捕捉或回傳給呼叫端。使用者永遠看不到自己的憑證。核心功能壞掉，但沒有錯誤訊息。模型 B 則在三個腳本中於函式外使用了 local——這會造成 bash 錯誤並導致執行失敗。這些都不是細微問題，而是阻斷性 bug。

在 site-delete.sh 中，只有模型 C 同時處理了兩種呼叫模式——互動式 TTY 與非互動 API 呼叫用的 --confirm 旗標。模型 D 只做了互動模式，導致 API 驅動、略過備份的刪除流程無法使用。

在 backup.sh 中，模型 A 和 B 都用了 eval "$POST_HOOK"——有潛在的命令注入風險。模型 C 則把封存檔路徑當成參數傳遞——更安全。模型 A 沒有實作自動封存清理。

在 api/runner.py 中，只有模型 C 使用了 asyncio，而且從不記錄 stdout——因為裡面可能包含憑證。模型 D 有死碼：build_command() 有定義但從未被呼叫。模型 A 只有 28 行，沒有 timeout、沒有記錄、沒有錯誤處理——一次卡住的請求會讓 API 無限期阻塞。

結論

可直接上線：四個裡面只有一個。模型 C，25/25。

揭曉

模型 B——Claude Code + Haiku 4.5——以實際邊際成本來看是最貴的，最低就是一個月 $20 的 Pro 訂閱。它拿到 12/25，而且因為基礎 bash bug，無法部署。模型 C——來自清華大學 THUDM 實驗室的 GLM 5.2——拿到 25/25，也是唯一被審查者判定可直接上線的模型。它只花了 $1.73。

附錄一 — 模型 E：Kimi K2.7 Code

在發表後，根據一則讀者留言提到這個模型，於是新增測試。相同流程、相同開發提示、相同的 Qwen 3.7 Plus 審查標準。

外部審查分數：19/25

可直接上線：否。 阻斷問題：資料庫密碼以內嵌參數的方式傳給 mysql -e 和 psql -c——系統中的任何使用者都能在 /proc/*/cmdline 看見。修正其實很直接（改用環境變數 MYSQL_PWD / PGPASSWORD），但它沒有做。

就審查者而言，這是整個基準測試中最模組化的架構——乾淨的 lib/ 拆分、一致的冪等性模式。但安全性缺口讓它無法挑戰 GLM 5.2。

在排名中的位置： 在 DeepSeek V4 Pro（$0.24，12/25）與 GLM 5.2（$1.73，25/25）之間，兩個軸向都是如此。架構／成本比優於 B 與 D，但還不是可直接上線的程度。

附錄二 — 多審查者驗證

根據留言中的讀者建議，盲測審查擴充到另外兩個模型：GPT-5.3 Codex 與 Gemini 3.1 Pro Preview。相同流程、每個實作同樣抽五個檔案、同樣的評分標準。

審查成本

比較分數

三位審查者的比較說明

排名 C > E > D > A > B 在三位審查者之間都成立——原始結果是穩定的。

GLM 5.2 是唯一一個被兩位獨立審查者打出 25/25，且有兩位將其判定為可直接上線的模型。GPT Codex 則是最嚴格的審查者——沒有任何模型通過它的可直接上線門檻，包括 GLM 5.2；它給 GLM 5.2 打 17/25，理由是 site-create.sh 的參數解析 bug，以及 common.sh 少了 set -euo pipefail。這些都是真問題；Codex 這份審查可以說是三者之中最嚴謹的一份。

最大的分歧出現在模型 B（Claude + Haiku）上：Qwen 和 GPT Codex 都給 12/25，但 Gemini 給 18/25，對其回滾邏輯和 shell 結構評價更高。Gemini 也把 Kimi K2.7 評到 21/25，並給出條件式可直接上線的判定——比 Qwen（19/25，否）和 GPT Codex（13/25，否）都寬鬆。

方法論批評是對的。 單一審查者會帶來偏誤。三個獨立的盲測審查者收斂到同一個排名，這比任何單一分數都更有說服力。

6. 智慧路由——真正的經濟學

這個基準測試引出了一個隱含問題：你每件事都需要 GLM 5.2 嗎？

不需要。而這大概是這次實驗最有價值的結論。

GLM 5.2 的費率是 $1.40/M token，當複雜度足夠時，它是正確選擇——像是架構、安全性、跨檔案一致性、關鍵決策。但在真實專案裡，這類任務只佔互動的一小部分。其餘的通常都是樣板、微調、文件、commit 訊息。

三個層級，三個模型

BigPickle 在一個完整的 32 檔實作上拿到 15/25。它完全有能力讀 50 行 diff，然後寫出一則及格的 commit 訊息。也能除錯像 1064 You have an error in your SQL syntax 或 Fatal error: Call to undefined function 這類問題。也能根據既有程式碼產出 README。對這些任務來說，GLM 5.2 的架構深度太過頭了——而且 BigPickle 是免費的。

DeepSeek V4 Pro 的費率是 $0.44/M token——比 Haiku 4.5 便宜五倍，也比 GLM 5.2 便宜三到四倍——很適合處理簡單程式碼生成、CRUD、微型重構、內嵌文件、短腳本。它在程式碼階段的成績是 129 萬 token、$0.24、9 分 42 秒，足以證明這一點。

GLM 5.2 則是在複雜度超出上述範圍時才上場——架構設計、跨檔案一致的實作、安全性決策、非平凡商業邏輯。

每個層級各佔多少任務，取決於專案、你目前的開發階段，以及你怎麼定義「複雜」。沒有通用數字——每個團隊都得用自己的實際使用情況去校準。

「
💡 值得注意的是：GLM 5.2 相較於 BigPickle 貴得非常多——在程式碼階段，4.42M token 的成本是 $1.67，而 BigPickle 是 $0。但純文字輸出——規劃、架構、分析——其實只消耗很少 token，成本幾乎可以忽略：這次基準測試的規劃階段只花了 $0.06。真正讓帳單飆升的是程式碼階段，因為裡面有反覆迭代、會話中執行測試、以及不斷累積的上下文。智慧路由的意思，正是把 GLM 5.2 保留給值得承擔長上下文的任務，並把其他事情交給較低兩個層級。
」

令人不舒服的比較

GitHub 已在 2026 年 6 月 1 日改成 token 計費。Copilot 上的 Claude Sonnet 4.6，大約是輸入 $3.00/M token、輸出 $15.00/M token。若要重現這個基準測試中 GLM 5.2 的會話——4.46M token——在 Copilot + Sonnet 4.6 上的預估成本大約是 25 美元。還沒有功能測試。沒有自我修正。沒有外部審查。

Copilot Pro+ 每月 39 美元，包含 39 美元的 AI 點數。像這樣的一整段會話，會吃掉月額預算的三分之二。使用者回報說，在切換當天只用了兩個提示，就把當月點數燒光了。

最後的比例：全部只花 $1.94 vs 在 Copilot + Sonnet 上約 $25。便宜了 13 倍，而且得到的還是外部審查者判定唯一可直接上線的結果。

結論

$1.94。這就是這個基準測試從頭到尾的成本——包含規劃、實作、外部審查。

而且，這還是唯一一個被審查者判定可直接上線的工具組合。

這個數字對 AI 編碼工具市場來說很刺眼，因為它一直透過價格來販售安心感。Copilot Pro+ 每月 $39、Claude Sonnet 每百萬輸出 token $15、那些大牌工具站在最前面——暗示品質會跟價格成正比。但這個基準測試顯示，事情未必如此。

勝出的模型叫 GLM 5.2。它的實驗室 THUDM 是清華大學的一部分。你大概沒在上週的比較文章裡看過它。它產出了唯一一個在規劃階段就有標準化退出碼約定的架構，唯一一個在會話中會自己測試程式碼的實作，唯一一個具備可配置遮罩、而且在沒有 jq 時會退回 Python 的 common.sh。而且它在交付前修掉了三個 bug。

有兩個重點。

第一：模型的價格，無法預測它在複雜任務上的輸出品質。Haiku 4.5 在三種不同工具——Claude Code、Copilot CLI、OpenCode——上得到的結果完全一樣，成本也一樣。在規劃階段——純文字生成、沒有回饋迴圈、沒有程式碼庫探索——工具對結果沒有可測量的影響。真正重要的是模型。而這個基準測試中最不顯眼的模型，反而表現最強。

第二：不是所有 token 都一樣。規劃階段花 $0.06、程式碼階段花 $1.67——這是 28 倍的差距。這不是異常，而是問題結構本身。規劃只是幾千個推理 token；實作則是數百萬 token 的上下文累積、執行過的程式碼、反覆測試。根據任務複雜度，在 BigPickle（$0）、DeepSeek V4 Pro（$0.44/M）與 GLM 5.2（$1.40/M）之間做智慧路由——這才是這些工具真正的經濟學。

VPS Manager 工具包的四個版本都已在 GitHub 上提供。

{% github https://github.com/pcescato/LLM-Challenge

規格說明、提示詞和評分標準也都在那裡。若你想驗證，完全可以重現。

便宜到不可能好用？這才是錯的問題。

原文出處：https://dev.to/pascal_cescato_692b7a8a20/too-cheap-to-be-good-think-again-4nj0