Vibe Coding 的經濟學：Rails、Django、Laravel 誰最省 token（一篇中肯的解讀）
AppSignal 在 2026 年 6 月做了一個實測，用同一個 AI 工具、同一組 prompt，分別叫 Rails、Django、Laravel 蓋一個含使用者認證、Posts CRUD、留言、JSON API 的小 app，直接從 Cursor 儀表板量 token。結果 Django 最省，約 3.1 萬 token，Rails 約 6.1 萬是它的兩倍，Laravel 約 10.5 萬最貴。帳面上 Django 完勝，但這不是同一件事的比較，Rails 多灌的 bcrypt、solid_queue、brakeman、bundler-audit 等於順手把背景工作、安全掃描、依賴稽核都做了，Django 灌 0 套件是因為它做得少。加上單一 app、單一工具、各跑一次、樣本很小，別當定論。文章最後把結論導向賣自家監控服務 AppSignal，論點本身合理但要意識到它是 sponsored。我的取法是，token 成本是真的、值得看，但它只是總持有成本的一軸，vibe coding 的經濟學更該看壞掉時多快能修、上 production 要補多少、半年後維不維護得動。
先說來源。這篇是 AppSignal 在 2026 年 6 月發的文章〈Vibe Coding Economically: Which Framework Is the Cheapest？〉，最後會導向賣他們自家的監控服務。但我看完覺得它前面的實測資料蠻扎實，值得認真看，也值得把它的限制跟那個「賣東西」的轉折一起講清楚，所以寫成這篇。
它到底在測什麼
作者的問題很實際：以前算 token 成本像是紙上談兵，現在用 Cursor 這類 AI 工具寫扣，token 就是真金白銀的工程開銷。那到底哪個框架用 AI 蓋起來最省？
方法是控制變因：同一個 AI 工具、同一組 prompt，分別叫 Rails、Django、Laravel 蓋一個一樣的小 app，功能是使用者認證、Posts 的 CRUD、留言、還有一個 JSON API 端點。token 直接從 Cursor 的儀表板讀，只算 input 加 output，不算 cached reads。除了 token，還記了跑幾輪 prompt、裝了幾個套件、記憶體占用、蓋到能動花多久。
資料本身
| 指標 | Rails | Django | Laravel |
|---|---|---|---|
| 總 token | 61,141 | 31,301 | 104,989 |
| input / output | 48,527 / 12,614 | 20,808 / 10,493 | 89,138 / 15,851 |
| 反覆次數 | 0 | 0 | 1（要除錯） |
| 額外套件 | 3 到 4（bcrypt、solid_queue、bundler-audit、brakeman） | 0（只用 Django 內建） | 2（laravel/breeze、laravel/pao） |
| 記憶體 | 約 80 MB | 約 20 MB | 約 18 MB |
| 蓋到能動 | 9 分鐘 | 3 分鐘 | 7 分鐘 |
帳面上很清楚，Django 在每一個跟成本有關的指標上都贏，token 只花 Rails 的一半、Laravel 的三成，一次就過、零額外套件。Laravel 最貴，還多一輪除錯把數字拉高。
我的中肯解讀
第一，Django 省 token 是事實，不用迴避。 身為喜歡 Rails 的人，我不會硬拗這件事。同樣一個小 app，Rails 吃了 Django 兩倍的 token，這個數字就是這樣。
第二，但這不是同一件事的比較。 Rails 那 6 萬 token 裡，有一部分是它順手多做的事。它灌了 bcrypt、solid_queue、brakeman、bundler-audit，等於一併把密碼雜湊、背景工作、安全掃描、依賴稽核都擺進去了。Django 之所以裝 0 套件，是因為它在這個任務裡做得比較少。所以 Rails 比較「貴」，有一塊其實是「它做得比較多」。同樣地，Laravel 貴又多一輪，也跟它中途要除錯有關，不全是框架本身囉唆。把這些攤開，單看 token 總數就會失真。
第三，方法論的限制要老實講。 這是單一一個小 app、單一一個工具（Cursor）、每個框架各跑一次、還排除了 cached reads 的結果。樣本很小，換一組 prompt、換個工具、換個任務規模，排名很可能就洗牌。它是一個有意思的訊號，不是定論。
第四，跟我之前那篇「各語言 token 效率」看起來衝突，其實不衝突。 我寫過 Ruby 在語言層是省 token 的，同樣的語意，Ruby 的字元數常常比較少。這篇卻顯示 Rails 建一個 app 反而吃更多 token。兩者量的是不同層：語言層看的是「表達同一段意圖要幾個 token」，框架層看的是「腳手架鋪了多少檔案、裝了多少東西、生成了多少樣板」。Ruby 語言省，但 Rails 框架鋪得厚，一個完整 app 疊起來就可能反過來。這個張力本身很值得記住，別把「Ruby 省 token」直接推論成「Rails 專案一定省 token」。
第五，那個賣東西的轉折。 文章結尾筆鋒一轉，說「最便宜的框架其實是壞掉時最好修的那個」，順勢誇 Rails 的可除錯性，然後就導向推銷 AppSignal 監控，論點是「AI 生的扣不會給你一份哪裡會壞的心智模型，所以你需要監控」。這個論點本身我其實同意，AI 快速生出來的東西，最缺的就是你對它哪裡脆弱的理解。但要意識到這是 sponsored content，結論的重心被有意識地導去買他們的服務，所以「debuggability 才是真便宜」這個收尾，一半是洞見、一半是業配鋪陳，讀的時候心裡要有這把尺。
我會怎麼用這篇
token 成本是真的、值得看，AI 時代它從紙上談兵變成實際帳單，這個提醒是對的。但它只是總持有成本的一軸。vibe coding 的經濟學如果只看「建起來花多少 token」，會選出一個當下最省、但壞掉時最難修、上 production 還要補一堆東西的框架。我更在意的是後面那些：壞掉時多快能定位、要達到能上線還差多少、半年後有沒有人維護得動。這也正好接回那篇文章自己繞回來的那句話，只是我不會停在「所以買監控」，而是停在「所以別用單一 benchmark 決定框架」。
延伸閱讀
