Mike Chong

DHH 錯了：Rails 並不適合 AI 時代的開發

2025年8月28日

近年來，圍繞「Rails 是否仍是最佳生產力框架」的討論再起。我的結論很直接：在 AI 原生（AI‑native）的產品與工程範式下，Rails 的核心假設與關鍵瓶頸，使它很難成為最佳選擇。

這不是對 Ruby 語言的否定，而是對「單體全棧、約定優於配置、伺服器渲染 + 膠水式 ActiveRecord」這套哲學，與 AI 工程實際需求之間的結構性不匹配的討論。

為什麼 Rails/Ruby 不再適合 AI 編程

Rails不太適合AI編程，我覺得有如下幾個原因。

第一點，Rails是沒有強類型的，這個沒法工程化。你可能有說，比如說Shopify和Stripe規模是用了Ruby，Ruby他們即使是在這種超大型的項目使用也是需要一個類型檢查器的。如果沒有類型檢查器是沒辦法，這個對AI來說也是，AI如果沒有類型檢查器，它可能寫出來很壞的代碼，你一開始沒有檢查到，最後會出現差之毫釐，謬以千里的結果。第一點，Rails是沒有強類型的，這個沒法工程化。你可能有說，比如說Shopify和Stripe規模是用了Ruby，Ruby他們即使是在這種超大型的項目使用也是需要一個類型檢查器的。如果沒有類型檢查器是沒辦法，這個對AI來說也是，AI如果沒有類型檢查器，它可能寫出來很壞的代碼，你一開始沒有檢查到，最後會出現差之毫釐，謬以千里的結果。

第二點是Ruby on Rails的前後端體系過度約束。David他個人不喜歡現在的前端的工具鏈，但是如果你想要前端工具鏈的話就沒有什麼official solution。我知道有一些不錯的solution，但是都不是官方的。像Rails這種框架如果不用官方的solution，未來的遷移和維護成本會非常高，這也是我最大的concern之一。第二點是Ruby on Rails的前後端體系過度約束。David他個人不喜歡現在的前端的工具鏈，但是如果你想要前端工具鏈的話就沒有什麼official solution。我知道有一些不錯的solution，但是都不是官方的。像Rails這種框架如果不用官方的solution，未來的遷移和維護成本會非常高，這也是我最大的concern之一。

第三點就是說，它的生態已經遠遠落後於Node.js、TypeScript和Python。為什麼這麼說呢？因為舉個例子，像AI的工具庫，地球上沒有第二個工具庫像Vercel的AI SDK一樣更全面。這只是AI這方面，還有比如說Mobile移動端開發沒有React Native和Expo這麼好的東西。Ruby在很早期會有一個框架商業的會花錢的叫Ruby Motion，但是它早就已經過時了。所以我作為一個十多年經驗同樣也是Ruby和Rails的開發者來說，我不會再用它做任何新項目了。第三點就是說，它的生態已經遠遠落後於Node.js、TypeScript和Python。為什麼這麼說呢？因為舉個例子，像AI的工具庫，地球上沒有第二個工具庫像Vercel的AI SDK一樣更全面。這只是AI這方面，還有比如說Mobile移動端開發沒有React Native和Expo這麼好的東西。Ruby在很早期會有一個框架商業的會花錢的叫Ruby Motion，但是它早就已經過時了。所以我作為一個十多年經驗同樣也是Ruby和Rails的開發者來說，我不會再用它做任何新項目了。

框架設計：為什麼 AI 原生開發與 Rails 不合拍

1) 架構假設衝突：

  • Rails 假設請求‑回應同步交互、MVC 緊耦合與資料庫中心化。
  • AI 工作流是長時任務、事件驅動、流式（streaming）、多代理協作與外部工具編排。

2) 吞吐與並發模型：

  • 大量 LLM/向量檢索/函式調用需要高併發、非阻塞 I/O、任務隊列與可觀測性鏈路。
  • Rails 傳統堆疊（Puma + ActiveRecord + callbacks）在 I/O 密集場景容易形成瓶頸與 N+1 模式蔓延。

3) 上下文與狀態管理：

  • AI 應用核心在「長期記憶」「對話上下文」「工作記錄與可回放」。
  • 這更適合事件溯源（event sourcing）、append‑only 日誌、向量索引與可組合的管道，而非典型 CRUD 驅動的頁面/表單模型。

4) 多模態與邊緣協作：

  • 語音、影像、文件代理協作需要邊緣與雲之間靈活調度。
  • Rails 的單體形態不利於在不同執行環境（雲函數、Workers、GPU 服務）之間細粒度拆分。

5) 成本與可觀測性：

  • AI 成本主要在推理與檢索路徑，要求對每次 span 做精細追蹤與動態策略（如分級模型、退避、Guardrails）。
  • Rails 傳統監控鏈路更偏頁面請求、資料庫查詢，難以直觀表達「prompt → 檢索 → 工具 → 代理迭代」的全鏈路。

什麼樣的技術棧更貼近 AI 原生

不一定要追逐新潮，而是選擇與「事件、流、任務、可觀測」對齊的設計：

  • 執行環境：雲原生（Serverless/Workers/Queues）+ 可並行的任務編排（Temporal/Cloud Tasks/Workflows）。
  • 通訊模型：HTTP/3、WebSocket、Server‑Sent Events，支援長連線與流式回傳。
  • 資料層：Postgres + 向量索引（pgvector）或專用向量庫；事件日誌（Kafka/PubSub）承載可回放上下文。
  • 服務切分：把「人機迴路」「檢索」「工具執行」「評估/觀測」拆成可獨立擴縮的服務或函數。
  • 語言/框架：重視非阻塞 I/O 與輕量組合，如 TypeScript/Node、Go、Elixir、Rust，或 Swift on server（針對蘋果生態）。

Rails 仍可用，但要付出「違背框架」的代價

如果團隊深諳 Rails，也可以疊加以下做法勉強適配：

  • 用 Sidekiq/Queues 轉移長任務；
  • 以 ActionCable/SSE 提供流式輸出；
  • 引入 OpenTelemetry 建立 LLM 與工具調用的 trace；
  • 把檢索與代理服務外掛為獨立服務（非 ActiveRecord 中心）。

問題在於：當你做到這一步，已經在「繞過」Rails 的主要路徑，並承擔了複雜度與一致性成本。

結語

AI 原生開發不是「把 LLM 貼到舊的 MVC 上」。它需要從請求模型、狀態管理、可觀測、成本控制到部署拓撲的整體重構。Rails 作為經典的生產力框架，在傳統 Web CRUD 場景依舊優雅，但面對多代理、流式與任務編排驅動的 AI 應用時，並不是最省心的選擇。

選擇能順勢而為的工具，比選擇你最熟悉的工具更重要。